OKAPI Chassis Auton Issue

Good Day,

We’ve been doing some preliminary testing of a chassis with V5 Rotation sensors for tracking wheels. In our testing we’ve discovered some unexplainable behavior that we have nailed down to not be a hardware problem as far as we can tell.

We run some simple commands to have the robot drive straight and then turn 90 degrees. Every other run the robot would veer off to the left for no reason. We then performed a test where we lifted the entire frame off the ground including the tracking wheels. You would expect the robot to attempt to endlessly drive straight… but instead every time we started the autonomous program it would do something different. Run both wheels the first try, run only the right wheel the second try, and then right wheel full output and then very small output on the left.

Is there something we are doing wrong? Did we come across a bug?

MAikenMagic1102/VEX-Pros-Odometry-Test (github.com)

@jpearman recently documented how more recent versions of the VexOS handles threads between the Disabled->Auton->Disabled->Driver stateflow. I’m assuming you are using a Competition Switch when doing this test? Behind the scense, the chassis uses threads when configured for odometry, and I wonder if there’s some adverse interaction between these threads and what the OS is doing to them…

Could you change where you declare your chassis object from a global to your autonomous function and remove the references to it from initialize and competition_initialize and see if that changes your observed behavior?


This did work… (For testing I was just starting a Timed match sequence from the remote.)

I’ve been doing Global variable/object definitions for several things for a long time now. Unfortunate that I now have to change that.


Thanks for reporting back!

You might consider opening an issue with OkapiLib on GitHub so that the documentation is clear about no longer declaring the chassis object at the global scope.


Just to clarify, the OkapiLib documentation says that it only uses the odometry to calculate the distance to turn and drive. It does not correct itself in real-time using odometry. So basically, a drive to point function that went from (0,0) to (4,4) would calculate the relative rotations needed to turn the motors so the robot faces (4,4), and then the relative rotations needed to drive straight to (4,4). It then executes those relative commands one after the other, with limited accuracy. If the next command supposedly told the robot to drive to (5,8), the robot would use the position from the odometry to calculate the turn and distance commands, and then execute them again.
For more information, this information is discussed in this okapilib documentation page: Odometry | OkapiLib A PROS library for programming VEX robots


I’m confused because what you are saying doesn’t have anything to do with the issue I described I wouldn’t think.

In this quote, I stated that the robot does not use the encoders to correct itself during the movement: it precomputes relative functions using the information it has about the initial position and direction and then runs the Okapilib relative functions. This is why the robot does not endlessly drive forward, as it would if you programmed the robot to correct itself using odometry. It stops based on motor rotations moved, not the position it is at.

Looking at your code, perhaps the PID constants are off. Did you tune them at all? They could be severely undershooting because they look really small. However, I don’t think this will explain the different responses in auton, but you never know with PID.

Based on observed behavior after I moved the declaration of the chassis to local auton scope your statement does not line up with what the robot is doing.

I forgot that a ChassisControllerPID uses odometry with PID.

You are correct. That is my mistake.