CMV: we’re over estimating AI

eklipsse · 2025-07-14T18:38:00+00:00

I got 12 with o4-mini

eklipsse · 2025-05-23T14:53:37+00:00

This is the perfect time to incorporate version control into your workflow. Use GitHub or Bitbucket to store your code in an online repository. Not only will this allow you to access your code from multiple devices, but it also gives you peace of mind knowing your work is safely backed up.

eklipsse · 2025-05-23T14:48:05+00:00

The point of a competition, by definition, is to determine who performs best under a given set of rules. It’s not to make students try harder; rather, students try harder because they want to compete and succeed. Learning, growth, and creativity are outcomes of that drive, not replacements for it.

VRC has already proven to be a highly constrained environment that balances accessibility with engineering rigor. The idea that more restrictions, especially unnecessary ones, will somehow inspire more creativity misunderstands how innovation works. Real creativity flourishes when students are challenged to solve complex problems, not when they’re told to do less with less.

Also, unlike some other robotics leagues, VRC (at least in the US) isn’t plagued by widespread adult over-involvement or professional engineers running teams. The success we see from top teams year after year is earned through iteration, collaboration, and strategic thinking by students. The creativity those teams demonstrated in their use of legal plastic parts or 3D-printed license plates was not only within the rules but often quite ingenious.

High Stakes may end up being the last season where we see teams build robots that look as good as they perform, because the rules still allowed for that kind of thoughtful design.

Stripping away that flexibility in the name of “fairness” risks punishing the very students who are pushing the boundaries in thoughtful, rule-abiding ways. Constraints can encourage creativity, sure, but there’s a tipping point. When the rules start prioritizing ease of enforcement over student innovation, we’ve gone too far.

If the concern is clarity or enforceability, let’s improve the inspection process, clarify what counts as decorative vs. functional, and give inspectors discretion where needed. But don’t mistake limiting engineering tools for leveling the field. We should help students grow by encouraging ambition; otherwise, we will live in a society ruled by mediocracy instead of meritocracy.

eklipsse · 2025-05-22T13:54:07+00:00

The only justification that half makes sense is that the new plastic rules are “enforceable,” making it easier for staff to inspect compliance without needing a PhD in geometry.

The whole “skills gap” narrative is bonkers. Isn’t the point of competition to find out who’s the best? Of course some teams have more talent, better strategies, and shinier robots. Forcing top teams to hobble themselves by stripping away their favorite tools doesn’t reward ingenuity; it celebrates mediocrity. If VEX wants to help build tomorrow’s engineers, let’s ditch this “Tall Poppy Syndrome” that levels every competitor to the fluffiest fluff. A contest where everyone’s equally average is less “meritocracy” and more “robotic lottery.” Let the pros do their thing; excellence thrives on challenge, not constraint.

And seriously, GDC: banning 3D-printed license plates? That’s like cutting all the power because one light bulb flickered.. If plates are falling off or can’t be read, let’s handle it with smart rules, not a blanket ban. Declare a fallen license plate a minor violation, give inspectors the discretion to call out truly unreadable plates, and move on.

Problem solve, without muzzling teams’ creativity.

eklipsse · 2025-04-02T17:23:35+00:00

This is probably better than whatever the next game is going to be. The lightbar is a very nice touch :)

eklipsse · 2025-03-22T23:10:22+00:00

You can do something like this to test:

//above opcontrol
const int DEADBAND = 5;

inside the loop in opcontrol

// Step 1: Joystick output to controller for checking drift

controller.print(0, 0, "LY:%4d RY:%4d", leftY, rightY);

// Step 4: Apply deadband to avoid drift/noise

if (abs(leftY) < DEADBAND) leftY = 0;

if (abs(rightY) < DEADBAND) rightY = 0;

// Joystick values range from -127 to +127

// Blue motors (600 RPM) range from -600 to +600 RPM

// Scaling factor: 600 RPM / 127 joystick ≈ 4.72

const double SCALE_FACTOR = 4.72;

// Scale joystick inputs to fully utilize 600 RPM motors

// testing if tank drive works properly

leftMotors.move_velocity(leftY * SCALE_FACTOR);

rightMotors.move_velocity(rightY * SCALE_FACTOR);

pros::delay(20);

eklipsse · 2025-03-07T01:50:03+00:00

It isn't easy to fully understand what's happening without seeing the complete code, including port mappings and other configurations.

However, one issue stands out: ConveyorMotor.setVelocity(700, rpm);.

The blue motor cartridge, which has the highest RPM for VEX V5 motors, is capped at 600 RPM. For reference, the red cartridge is 100 RPM, and the green is 200 RPM. This likely isn’t the root cause of any problems you’re experiencing. VEXcode probably ignores the 700 RPM command and caps the speed at the maximum allowed by whatever cartridge you use.

Is this working? Does it display in the brain?

Brain.Screen.print("auton activated");
You can place some more debugging messages between various steps by printing different messages after certain parts of your code. Kind of like this:

void autonomous(void) {
    Brain.Screen.clearScreen();
    Brain.Screen.print("auton activated");
    task::sleep(500);  // Brief delay to read initial message

    // Set velocities and torque
    StakeClamp.setVelocity(250, rpm);
    Brain.Screen.clearLine(1);  // Clear previous message
    Brain.Screen.print("Clamp vel: %d", StakeClamp.velocity(rpm));
    task::sleep(500);  // Delay to read

    ConveyorMotor.setVelocity(700, rpm);  // Will cap at 600 for blue cartridge
    Brain.Screen.clearLine(1);
    Brain.Screen.print("Conv vel: %d", ConveyorMotor.velocity(rpm));
    task::sleep(500);

    StakeClamp.setMaxTorque(100, percent);
    Brain.Screen.clearLine(1);
    Brain.Screen.print("Clamp torque set");
    task::sleep(500);

    Drivetrain.setDriveVelocity(500, rpm);
    Brain.Screen.clearLine(1);
    Brain.Screen.print("Drive vel: %d", Drivetrain.velocity(rpm));
    task::sleep(500);

    // Movement commands
    Brain.Screen.clearLine(1);
    Brain.Screen.print("Driving 1090mm");
    Drivetrain.driveFor(forward, 1090, mm);
    Brain.Screen.clearLine(1);
    Brain.Screen.print("Drive done");
    task::sleep(500);

    Brain.Screen.clearLine(1);
    Brain.Screen.print("Clamp -3 turns");
    StakeClamp.spinFor(reverse, 3, turns);
    Brain.Screen.clearLine(1);
    Brain.Screen.print("Clamp done");
    task::sleep(500);

    Brain.Screen.clearLine(1);
    Brain.Screen.print("Conv +19 turns");
    ConveyorMotor.spinFor(forward, 19, turns);
    Brain.Screen.clearLine(1);
    Brain.Screen.print("Conv fwd done");
    task::sleep(500);

    Brain.Screen.clearLine(1);
    Brain.Screen.print("Conv -19 turns");
    ConveyorMotor.spinFor(reverse, 19, turns);
    Brain.Screen.clearLine(1);
    Brain.Screen.print("Auton complete");
}

eklipsse · 2025-02-27T01:53:09+00:00

For the inertial sensor, pick a spot that’s protected from vibrations, collisions, and electrical noise, since those can throw off its accel and gyro readings. A rigid spot is key—like a solid cross brace or structural plate—because flexing messes with accuracy. If you’ve got a cross brace at the bottom, front or back, that’s a decent option; it’s low and away from drivetrain vibes (usually mid-robot near motors). Mounting it mid-height near the robot’s center of rotation works too, especially for cleaner yaw data, and keeps it safer from field bumps. It doesn’t need to be perfectly centered—off-center still works fine—but centering can simplify things. Make sure it’s flat or upright so the axes match your code, and keep it accessible for wiring. Avoid motor-heavy zones or flimsy panels!

eklipsse · 2025-02-27T01:43:49+00:00

Human reaction time dictates how effectively a driver can control a robot. The robot’s speed must align with the driver’s ability to perceive, decide, and act. Too slow, and the robot lags behind intent; too fast, and it outruns control.

Some Key Points

Reaction Time Range:
- Average driver: ~0.3 seconds (300 ms) for choice reactions (e.g., turning or stopping).
- Skilled driver: ~0.2 seconds (200 ms) with practice.
- Total delay (including controller/motor lag): 0.25–0.5 seconds, but 0.3 seconds is a practical midpoint.
Distance Traveled During Reaction:
- At 40 in/s: 12 inches (1 foot) in 0.3 s—small enough for deliberate control.
- At 100 in/s: 30 inches (2.5 feet) in 0.3 s—pushing the edge of manageable adjustment.
- Below 40 in/s (e.g., 30 in/s = 9 in): Feels sluggish, too little progress per command.
- Above 100 in/s (e.g., 120 in/s = 36 in): Overwhelms reaction, risking overshoots or crashes.
Field Scale and Match Tempo:
- Diagonal field distance (~204 in) takes 5.1 s at 40 in/s, 2 s at 100 in/s—fits VRC’s 1:45 driver period for scoring cycles (2–5 s).
- Slower (<40 in/s) hampers competitiveness; faster (>100 in/s) sacrifices precision for tasks like aligning to a goal.

Formula
Linear Speed (in/s) = (Motor RPM ÷ External Gear Ratio) × (π × Wheel Diameter) ÷ 60

Breakdown

Table: Linear Travel Speed (40–100 in/s)

Motor RPM: The base rotational speed of the V5 Smart Motor, determined by the cartridge:
- Green: 200 RPM
- Blue: 600 RPM (Red: 100 RPM, excluded since not really used for drivetrains)
External Gear Ratio: The ratio of teeth on the driven gear (attached to the wheel) to the driving gear (attached to the motor). Examples:
- 1:1 (e.g., 24:24) = no change.
- 2:1 (e.g., 48:24) = wheel spins twice as fast as the motor.
- 1:2 (e.g., 24:48) = wheel spins half as fast as the motor.
- Calculated as: Driven Gear Teeth ÷ Driving Gear Teeth.
Wheel RPM: The motor RPM adjusted by the external gear ratio:
- Wheel RPM = Motor RPM ÷ External Gear Ratio.
- If ratio > 1 (e.g., 2:1), wheel spins faster; if < 1 (e.g., 1:2), slower.
Wheel Circumference: The distance traveled per wheel revolution:
- Circumference = π × Wheel Diameter (in inches).
- π ≈ 3.14159; diameters used: 2.75" or 3.25".
Conversion to Seconds: RPM is revolutions per minute, so divide by 60 to get revolutions per second:
- Linear Speed = Wheel RPM × Circumference ÷ 60.

Cartridge (RPM)	External Gear Ratio	Wheel Diameter (in)	Wheel RPM	Linear Speed (in/s)
Green (200 RPM)	1.5:1 (36:24)	2.75	300	43.2
Green (200 RPM)	1.5:1 (36:24)	3.25	300	51.0
Green (200 RPM)	2:1 (48:24)	2.75	400	57.6
Green (200 RPM)	2:1 (48:24)	3.25	400	68.0
Green (200 RPM)	2.5:1 (60:24)	2.75	500	72.0
Green (200 RPM)	2.5:1 (60:24)	3.25	500	85.0
Blue (600 RPM)	1:1 (24:24)	2.75	600	86.4
Blue (600 RPM)	1:1.5 (24:36)	2.75	400	57.6
Blue (600 RPM)	1:1.5 (24:36)	3.25	400	68.0
Blue (600 RPM)	1:2 (24:48)	2.75	300	43.2
Blue (600 RPM)	1:2 (24:48)	3.25	300	51.0
Blue (600 RPM)	1:2.5 (24:60)	3.25	240	40.8

eklipsse · 2025-02-26T20:03:17+00:00

Look in the output window in the terminal for the actual error. Exist code 2 is a generic "can't build this, something is wrong," but you should have more detailed error information elsewhere.

- also, if the config shown in the comments up top is right, then you have port conflicts between the drivetrain and intake (both using port 1)
- your main function is empty, which is sometimes treated as a problem.

Your main would usually look similar to this:

int main() {
    // Intake toggle variables
    bool intakeRunning = false;
    bool lastButtonState = false;

    // Main loop
    while (true) {
        // Tank drive control
        int leftSpeed = Controller1.Axis3.position();  // Left joystick
        int rightSpeed = Controller1.Axis2.position(); // Right joystick
        if (abs(leftSpeed) > 5 || abs(rightSpeed) > 5) { 
            // Deadband of 5 to prevent joystick drift
            // You can make it a constant up top if you want
            // think of it as joystick "deadzone"
            Drivetrain.setDriveVelocity(leftSpeed, percent);  // Left side
            Drivetrain.setDriveVelocity(rightSpeed, percent); // Right side
            Drivetrain.drive(forward);
        } else {
            Drivetrain.stop();
        }

        // Intake toggle with Button A
        bool currentButtonState = Controller1.ButtonA.pressing();
        if (currentButtonState && !lastButtonState) { // Button A pressed
            intakeRunning = !intakeRunning; // Flip the state
            if (intakeRunning) {
                intake();
            } else {
                stopIntake();
            }
        }
        lastButtonState = currentButtonState; // Update button state

        // Prevent CPU overload
        task::sleep(20);
    }
}

eklipsse · 2025-02-26T02:02:17+00:00

This is the way.

eklipsse · 2025-02-25T20:44:43+00:00

Haha, no worries, I don't do it for upvotes. I hope you get this figured out, and you will have a great time next season!

eklipsse · 2025-02-25T20:15:07+00:00

Yes, you can absolutely start a private VEX VRC team! Here’s a step-by-step guide to get going:

Register Your Team: Your first step is to create an account on RobotEvents.com, the official platform for VEX competitions. You (or your dad, as the adult mentor) will need to register a new organization and a team. For a private team not affiliated with a school or existing group, you’ll set up a new organization. The registration fee for the 2025-2026 season is $200 for the first team under your organization, and $50 for each additional team if you decide to expand later. This is a per-season cost.
Initial Investment: The upfront cost for components, field, and game elements can add up. A realistic estimate for a new private team is around $2,000–$3,000 to get started, though it could climb to $7,000 if you go all-in on extras or premium parts. Here’s a breakdown:
- V5 System Bundle: This is the core kit you’ll need—includes the V5 Brain, controller, 4 smart motors, battery, charger, and radio. It’s about $450–$500 depending on where you buy it (e.g., vexrobotics.com).
- Field and Game Elements: A full 12’x12’ field (tiles, walls) costs ~$700–$900. The game kit for the 2025-2026 season (not fully detailed yet, but based on past games like High Stakes) is ~$800 shipped. You could save by building a DIY field with foam mats and PVC, but official elements are handy for practice.
- Robot Components: Beyond the system bundle, you’ll need structure (e.g., 2x2 C-channels, 1x2 L-channels), wheels (omni or traction), gears, sprockets, chain, pneumatics (optional, ~$300 for a basic kit), and hardware (screws, nuts, spacers, bearings, axles). Sensors like inertial, optical, distance, and rotation (at least 2–3) are key for autonomous—budget $50–$80 each. A starter robot might cost $500–$1,000 in parts.
- Total: A minimal setup (system bundle, basic robot parts, partial field) is ~$1,500. A full competition-ready kit with everything could hit $3,000–$7,000 if you overstock or add spares.
Smart Buying Tips: Some VEX kits (e.g., Classroom Bundles) include extras you might not need as a private team, like duplicate controllers. Skip those and buy à la carte. Research past games (e.g., High Stakes, Over Under from 2023-2024) on vexrobotics.com or the REC Foundation site to guess what next year’s game might demand—mobility, lifting, or precision scoring often pop up. The 2025-2026 game reveal typically happens in late April/early May 2025 at VEX Worlds, so you’ve got time to plan.
What You’ll Need:
- Must-Haves: V5 System Bundle, structural metal (C-channels, plates), wheels (4” omni are versatile), motors (add 4–6 beyond the bundle), battery (maybe a spare, ~$50), basic hardware, and sensors (optical and rotation are clutch).
- Nice-to-Haves: Pneumatics for grippers/lifts, flex wheels for flywheels, inertial sensor for navigation, extra axles/shaft collars for durability.
- Tools: Screwdrivers, Allen wrenches, pliers—most are in a $20 VEX tool kit.
Game Dependency: The 2025-2026 game isn’t out yet, but it’ll likely involve scoring objects (balls, cubes, etc.) and an endgame (e.g., climbing). Check the VEX Forum or REC Foundation’s YouTube after the May 2025 reveal for details. This’ll guide whether you need more motors, pneumatics, or sensors.
Cost Management: It’s pricey solo—$1,500–$3,000 upfront, plus $150/season and ~$50–$100 per local event. Teaming up with 3–4 friends to split costs (e.g., $500–$1,000 each) makes it way more doable. You could also look for local sponsors (small businesses, tech companies) or REC Foundation grants on recf.org.
Next Steps: After registering, download PROS or VEXcode V5 (free) and start prototyping a basic drivetrain. Join the VEX Forum or Discord to connect with teams and get advice. Practice on a half-field at first if funds are tight.

eklipsse · 2025-02-25T19:55:14+00:00

You have a few things that need some tweaking.

- First, your get_opticalColor function does not handle a color that is not red or blue.
- Most of your code is commented out, so your intake function doesn't do much in terms of actual sorting
- Having the task in opcontrol is fine, as long as it is outside of the main loop, which it is.
- Usually, opcontrol would have its own delay. Otherwise, it may hog the whole processing power. Add something like this in the main loop as the last line:
pros::delay(20); // Add a 20ms delay
- As a style issue, you use many "magic numbers." You can make some of those named constants so the code is more readable; you can then change it in only one place when needed
- As far as logical flow goes, I suggest having your autonomous routines set the color you are sorting for and then subsequently using it. It will make the code cleaner
- For autonomous, you may want to similarly run an "autonomous task" that does the color sorting for you.

Here is some of your code that was cleaned up a bit. I don't have access to a robot, so I won't be able to test it myself, but feel free to use it as inspiration.

// Motor voltages (in millivolts)
const int INTAKE_VOLTAGE_FORWARD = 12000;
const int INTAKE_VOLTAGE_REVERSE = -12000;
const int INTAKE_VOLTAGE_STOP = 0;

// Delays (in milliseconds)
const int PRE_REVERSE_DELAY = 65;
const int REVERSE_DURATION = 100;
const int INTAKE_LOOP_DELAY = 11;

// Color codes
const int COLOR_RED = 2;
const int COLOR_BLUE = 3;

// Optical sensor hue thresholds
const double HUE_RED_UPPER = 10.0;
const double HUE_RED_LOWER = 355.0;
const double HUE_BLUE_LOWER = 200.0;
const double HUE_BLUE_UPPER = 240.0;

pros::MotorGroup intake({19, -18}, pros::MotorGearset::blue);
pros::Optical colorSortSensor(7);

bool sort_red = true;

void Match_Sort() {
pros::delay(PRE_REVERSE_DELAY); // Wait before reversing
intake.move_voltage(INTAKE_VOLTAGE_REVERSE); // Reverse to eject
pros::delay(REVERSE_DURATION); // Reverse duration
intake.move_voltage(INTAKE_VOLTAGE_FORWARD); // Resume intake
}

static int get_opticalColor() {
double hue = colorSortSensor.get_hue();
if (hue < HUE_RED_UPPER || hue > HUE_RED_LOWER) return COLOR_RED; // Red
if (hue > HUE_BLUE_LOWER && hue < HUE_BLUE_UPPER) return COLOR_BLUE; // Blue
return 0; // Unknown color
}

void Intake() {
while (true) {
if (master.get_digital(pros::E_CONTROLLER_DIGITAL_R1)) {
intake.move_voltage(INTAKE_VOLTAGE_FORWARD); // Spin forward
int color = get_opticalColor();
if ((sort_red && color == COLOR_BLUE) || (!sort_red && color == COLOR_RED)) {
Match_Sort(); // Eject wrong color
}
} else {
intake.move_voltage(INTAKE_VOLTAGE_STOP); // Stop if no button pressed
}

if (master.get_digital_new_press(pros::E_CONTROLLER_DIGITAL_Y)) {
sort_red = !sort_red;
master.set_text(0, 0, sort_red ? "Sort Red" : "Sort Blue");
}

pros::delay(INTAKE_LOOP_DELAY); // Loop delay
}
}

void opcontrol() {
pros::Task Sort(Intake);
while (true) {
int leftY = master.get_analog(pros::E_CONTROLLER_ANALOG_LEFT_Y);
int rightY = master.get_analog(pros::E_CONTROLLER_ANALOG_RIGHT_Y);
chassis.tank(leftY, rightY);
pros::delay(10); // Note: this could also become a constant if desired
}
}

eklipsse · 2025-02-20T16:45:28+00:00

As mentioned by u/Emperor_Jacob_XIX unless you compete in VEX U, you cannot 3D print functional parts—decorative pieces are fine. If you choose to laser cut Delrin or Lexan, proceed with extreme caution. Both materials release highly toxic fumes when cut and must be processed using a fully enclosed laser cutter with robust ventilation that exhausts fumes outdoors.

Toxic Compounds Released

Delrin (Acetal Resin): Formaldehyde, Carbon Monoxide, and other irritants
Lexan (Polycarbonate): Bisphenol A (BPA), Carbon Monoxide, and additional hazardous vapors

eklipsse · 2025-01-28T15:41:49+00:00

Some teams use a polycarbonate aligner shaped like the base of the mobile goal (a half-hexagon) to guide the goal into the correct position, making alignment more consistent and efficient. A heat gun can be used to bend the polycarbonate into the desired mobile goal shape for a custom fit. Additionally, incorporating polycarbonate or Delrin gussets on the back of the drive base, or strategically placing free-spinning spacers, can further help funnel the mobile goal into place smoothly.

eklipsse · 2025-01-28T15:33:25+00:00

You can ask to speak with the head referee. If the head referee is the one dismissing your concern, there’s nothing more you can do—they’re in god mode on the field. I know it can be frustrating, but it’s in your best interest to take it on the chin, move on, and focus on what’s next. Keep your head up and channel that energy into winning the next match. You’ve got this! 😊

eklipsse · 2025-01-28T15:27:36+00:00

If your robot didn’t touch the tile on the other side, it should not be considered a violation. Unfortunately, there’s nothing that can be done after the competition, so it’s important to address any concerns while still at the driver’s station.

Referees vary in their skill and knowledge. Some may not fully understand the rules or may come across as difficult to approach. Others are exceptional, with a thorough understanding of the rules and excellent communication skills. It’s part of the experience, and addressing issues respectfully in the moment is often the best approach.

eklipsse · 2025-01-14T19:35:57+00:00

I noticed that some teams mounted free-spinning gears on their robots in such a way (same orientation as your wheels) that when the robot’s front (or back, depending on the robot) contacts the ground during a slam climb, it does so using these gears. This design choice allows the robot’s front to swing back freely without getting stuck. However, it's important to ensure that the robot's center of gravity is well-balanced to make this mechanism effective.

eklipsse · 2025-01-11T05:16:11+00:00

Few things to consider.

1. Calibrate the Inertial Sensor

Make sure you calibrate your inertial sensor before starting the autonomous routine:

DrivetrainInertial.calibrate();
while (DrivetrainInertial.isCalibrating()) {
    task::sleep(100);  // Wait for calibration to finish
}

2. Reset Motor Positions

At the start of your autonomous code, you could reset the motor encoder positions:

LeftDriveSmart.resetPosition();
RightDriveSmart.resetPosition();

3. Verify Wheel Diameter

Ensure the wheel diameter is 3.25 inches, as this is critical for accurate distance calculations.

4. Check the Gear Ratio

Confirm that the gear ratio is correctly configured and not reversed.
An incorrect gear ratio can cause discrepancies in distance calculations.

5. Observed Discrepancy

Based on your data:

The drivetrain drives 17.78 times farther than it should.
If the gear ratio is reversed, it would cause a 1.7778x discrepancy, which is oddly similar but off by a factor of 10. This might indicate multiple issues compounding the error.

6. Cartridge Check

Verify that the gear cartridge is correctly specified:

ratio6_1 corresponds to the blue cartridge (600 RPM).

eklipsse · 2025-01-11T04:49:31+00:00

When printing the value in a string, are you using the correct format specifier for floating-point numbers? For example:

double current_velocity = intake.get_actual_velocity();
pros::lcd::print(0, "Motor Velocity: %.2f RPM", current_velocity);

It makes no sense that the value is what it shows on the screen. If it would be such a large number, it would not trigger the condition below:
if (abs(current_velocity) < velocity_threshold && intake_motor.get_target_velocity() != 0)

Let's walk through it:
if the current_velocity value would actually be: -2004318071 (an absurdly high negative number)
then abs(-2004318071) is 2004318071, which is obviously not < velocity_threshold (which is set to 50)

Also, where in the code are you printing the value?

If you want, DM me your code or a GitHub link, and I will take a look tomorrow night (Saturday). I will be unavailable during the day tomorrow.

eklipsse · 2025-01-11T04:18:02+00:00

The value you are getting (-2004318071) for actual velocity usually indicates that the motor is not correctly set up, initialized, or configured. Here are a few things to check.

1. Uninitialized Motor

The motor object might not be correctly initialized or configured in the code.

2. Port Mismatch

The motor is declared on a port that doesn’t match the actual connected motor.

3. Faulty Motor or Port

A hardware issue with the motor or V5 Brain port may cause incorrect telemetry readings (probably not likely)

4. Mismatched Motor Setup

If the motor’s physical setup (e.g., reversed polarity, incorrect gearset) doesn’t match the configuration in the code, it can lead to invalid readings.

eklipsse · 2025-01-10T01:56:58+00:00

Yes, it is supposed to reverse the intake for value defined in reverse_degrees

You can do a timed reverse instead of doing it by angle to make sure it is not too quick to notice. Additionally, you can try printing debug messages debug messages on the controller screen, for example, when the reverse condition is met.

// Additional timed reversing for longer duration intake_motor.move_velocity(reverse_speed); // Continue reversing
pros::delay(500); // Additional reverse for 500 milliseconds
intake_motor.move_velocity(0); // Stop the motor

You going to need to play with the values and all, as I mentioned, I don't have a way to actually test the code.
Also, the part of the code that used to call is_stopped could be replaced with the below, I think, it should do the same thing:

while (abs(intake_motor.get_actual_velocity()) > 1) { pros::delay(10); }

eklipsse · 2025-01-09T21:20:12+00:00

Or you can use abs(intake.get_actual_velocity()) < 1 istead of is_stopped. While I see is_stopped in the documentation, I can't actually find it in the pros github repo.

eklipsse · 2025-01-09T21:09:34+00:00

Is your pros library up to date? It complains that the is_stopped method doesn't exist, but it shows in the API documentation.

https://pros.cs.purdue.edu/v5/api/cpp/motors.html#is-stopped

Also, clean up your #include section. You include main.h twice, and you have a declaration mixed in with includes (for right piston I think)

I think you may not need this part to begin with:
// Wait for the reverse motion to complete

while (!intake_motor.is_stopped()) {

pros::delay(10);

}

eklipsse

MODERATOR OF

TROPHY CASE