After switching from Okapilib’s chassis controller integrated to chassis controller PID (By declaring withgains), the robot can no longer even drive straight, moving forward slightly before veering sharply off in a swing turn infinitely (anti-clockwise, or counter-clockwise for you Americans) when the moveDistance function is called. The PID gains aren’t tuned well yet though so don’t judge the code too much, its very much a test. The odometry reads the correct position after a translation, the same code was used but with .withgains commented and it worked fine (integrated PID controller). Here is the code:
Just to make it clear, I am pretty sure that this is not an issue with chassis scales/dimensions or quad encoders being inverted, I am unsure, therefore, having little okapi PID or odometry experience, about why this issue is occurring.
Ok, so after some more testing, it turns out that my original post incorrectly stated that the robot could drive in a straight line, however I have now identified that it fails to even achieve this! I have updated the original post and title accordingly with the updated issue.
I would greatly appreciate a response on this thread as I have no idea about solving this issue, being inexperienced in Okapilib.
The behavior you describe does seem like one side’s encoders are reversed, though you also indicate that you’ve checked for that.
Could you post your full code, including the turnAngle or turnToAngle calls?
Certainly for the moveDistance calls, the Integrated Chassis Controller does not use the odometry wheels for “course correction” (while the tracking wheels are used for “course correction” in the PID Chassis Controller), so it is plausible that your ADIEncoder declaration for one of the encoders should be flipped. That said, the chassis’ odometry functionality should use them.
Printing out the OdometryState before and after the movement might be instructional and help debugging. I’d suggest starting with the turn movements first.
Also of note, the convention for OkapiLib’s odmetry is for positive Y to be “North” and positive X to be “East” in terms of compass headings.
What is the output of the 3 output lines for each run (PID vs Integrated)? Does the physical robot face “West” (e.g. anti-clockwise 90) with the withGains in while the physical robot faces “East” with withGains removed?
The 540 is the TPR because, as you guessed, the chassis is geared 36:60.
I thought that the set state function blocked until it had set things up, but I will try a delay now with the original (non-integrated) PID controller
With this in mind, I can only assume that the issue must be with the PID controller setup as the odometry worked fine for adjusting the target for each movement when using the integrated controller and driveToPoint seemed to work fine, it seems that simply specifying the non-integrated controller through withgains has somehow messed it all up.
Ok, so after reversing one encoder (I had accidently removed the reverse parameter on one of them somehow), the moveDistance commands appear to work fine, but when given the turnAngle(90_deg) command, the robot rotates approximately 195 degrees clockwise!