Weird Okapi Bug?

Programming Support PROS Support
#1

Hi, so there’s a weird bug when using odometry and coordinates with okapi for us. We run the following command:

chassis->setState({6.5_in, 36_in, 0_deg});
chassis->moveToPoint({2_ft, 3_ft});

All is well for now. The robot moves to the correct spot. However, now if I run the following…

chassis->moveToPoint({4_ft, 3_ft});

Instead of moving two feet further in the Y-Axis (as would be expected), the robot actually moves 4 feet forward, as if the Y coordinate were 0. However, the robot moves in a straight line, meaning it realizes that the X-Coordinate is the same. This is a really weird bug, and a bit annoying. We’ve gotten around it somewhat by setting the state after every movement, but obviously that isn’t something we should be doing. Does anyone have a solution for this? For reference, below is our chassis initialization.

   std::shared_ptr<OdomChassisController> chassisAuton = ChassisControllerBuilder()
       .withMotors(
         {1, 12}, //left motors are ports 1 and 2
         {-10, -19}
       )  //right motors are ports 10 and 19 (reversed)
       .withSensors( //declares rotation sensors; left at port 3 and right on port 5 (reversed)
         RotationSensor{3},
         RotationSensor{5, true}
       )
       //blue gearset, 3.25 inch wheel diameter, 9.75 inch wheelbase (Left-Back to Right-Back Wheel)
       .withDimensions(AbstractMotor::gearset::blue, {{3.25_in, 9.75_in}, imev5BlueTPR})
       //3.25in tracking wheel, 15_in distance between encoder wheels, 4090 Ticks Per Rotation
       .withOdometry({{3.25_in, 15.5_in}, 4090})
       /
       //Builds the chassis
       .buildOdometry(); // build an odometry chassis
2 Likes
#2

What happens if you print out, either to terminal, controller, or the brain, the location the robot thinks it is at before each call to moveToPoint?

#3

Hmm, I’m not actually sure. I didn’t have the foresight to check that. Next time I go to our robotics place i’ll check that out. Do you have any suspicions as to what might be causing it, though?

#4

The concern would be whether the odometry is properly updating the robot’s position as it does the first movement. I’m assuming you don’t reset/hard-code the robot position after the first chassis->moveToPoint({2_ft,3_ft});

4 Likes
#5

Correct, we do not. That is the issue - when we do reset/set it, then it works fine for the next movement.

#6

Ok, I’m super late, but basically, we never found a possible cause or fix for the issue. Couple that with the fact that the latest release of PROS somehow destroyed our code with a sledgehammer (I.E errors on every line) and we decided to just redo it. We’re using VexCODE now, and we wrote our own position tracking algorithm. It’s certainly not as fancy, but it works ok, and we can always improve it over time.

#7

I understand that you have switched to vexcode, but for the record all you had to do to fix this was compile your code.

3 Likes