Generated trajectory not followed, even in simulation

I have very similar issues described in this unresolved thread when trying to make our differential drive follow a trajectory. Namely: the robot is shuddering a lot when trying to follow the trajectory, and doing so, of course, it does not track well.

Interestingly, I can even reproduce this issue in simulation, which baffles me, since simulation is using the same gains given to the trajectory generator!

Here is the result when trying to follow a path in the simulation, after disabling both the Ramsete and the PID controllers. The chassis is not following the reference at all!

What I have done so far:

  • Made sure the odometry is spot on. On the field, it is accurate within a 1-4 centimeters. Angle is accurate too, and all signs are tracking the ones described in the documentation
  • Ran the SysId multiple times to make sure no one-off chance event was interferring. [Results are availabe here].(CaractérisationWestcoast - Google Docs).
  • Troubleshooting page is advising to check measurements, and in particular wheel diameter, which I did several times. We are using 4" wheels, but I measured them as precisely as I could. Also verified the gearing ratio to make sure it matches what the vendor is advertising.
  • Although my best guest would be my sysid settings being wrong, I verified them multiple times:

Full code here. Main classes involved in path following: PathFollowing, WestcoastOdometry, and ChassisId.

I would appreciate a lot any guidance on what to check next :pray:

I am facing the same problem with a Differential Drive. It either overshoots or turns 90 degrees and follows the path incorrectly. If you don’t mind, can you please share your Feedback Analysis in SysID where you find the Kp value?

can you please share your Feedback Analysis

Sure, it is part of the code I shared: GitHub - FRCteam3550/EssaiWestcoastJulien2023: Port de l'essai de programmation de la base Westcoast aux outils 2023

Note however that I am reproducing the problem even when deactivating the PID controllers, so the Kp value is not the issue here.