Okapilib odometry problems

Programming Support PROS Support
#1

I’ve been trying to implement three tracking wheel odometry using Okapilib and PROS, and no matter what my robot does not even move. I’ve rewritten the code multiple times and even straight up copy-pasted the tutorial code from here. On top of this, driver control does not work after I try to run the auton, as if the entire program is locked up. Driver will work if I don’t try the auton, but not after I try it.
my code:

std::shared_ptr<OdomChassisController> odom = ChassisControllerBuilder()
  .withMotors(Dleft, Dright)
  .withDimensions(AbstractMotor::gearset::green, {{2.75_in, 13_in, 2_in, 2.75_in}, quadEncoderTPR})
  .withGains(
    {0.001, 0.001, 0.001}, // Lateral error
    {0.001, 0.001, 0.001}, // Turning error
    {0.001, 0.001, 0.001} // Straight drive assist error
  )
  .withSensors(
    okapi::ADIEncoder{'B', 'C'}, // left encoder
    okapi::ADIEncoder{'D', 'E', true}, // right encoder
    okapi::ADIEncoder{'F', 'G'}  // middle encoder
  )
  .withOdometry()
  .buildOdometry();

and in void autonomous():

odom->moveDistance(12_in);

The okapi odometry functions (driveToPoint(), turnToAngle()) do not work either. Any help with this problem would be greatly appreciated.

#2

I would recommend first setting the default Logger to the terminal. They have a tutorial on how to do that. If Okapi comes across an error that it realizes, then it will say so. Also make sure that you use the builder in the right scope, as the builders delete the objects when the parent task is complete. Also a complete file would make it easier to help.

#3

After changing the scope of the declaration of the chassis builder, it now moves. However, it now does not stop moving.

I put the logger into my program, and the terminal is now outputting:
ERROR: ThreeEncoderOdometry: A tick diff (2147483647) was greater than the maximum allowable diff (1000). Skipping this odometry step.

Also, the full code is available on github

#4

21474836427 is the int max. This suggests that something is wrong with one of the encoders. As such, the robot will probably not think it has gotten to it’s destination. You may want to declare them outside of the builder and pass them through and check to see which one it is.

#5

Part of your problem could be that you are defining your chassis model inside a header file.

1 Like
#6

Passing already declared encoders yielded the same error, and after printing the values of the three encoders to the terminal, they are all at that value. I tested new encoders and a new brain, and the same values occurred.

#7

I have an idea. I’m think I recall seeing sometime back that PROS is only designed to used quad encoders when their first wire is on an odd port (A, C, E, G or 1, 3, 5, 7) with the second wire being on the next port. This may still be the case.

#8

Yes that is the case. So those encoders wouldn’t work. It’s also entirely VEXos fault not PROS. They only support those 4 port options.

1 Like