Drivetrain acceleration limits causes significant lag

[ProfessorAtomicManiac]

https://github.com/DeepBlueRobotics/RobotCode2024/blob/2c604e3998adb25a7d3ed465ea64cbd714c459f9/src/main/java/org/carlmontrobotics/commands/TeleopDrive.java#L98-L103

If only the else statement runs, then there is no lag. The if statement is meant to limit the acceleration of the robot to avoid tipping over. It is suspected that the lag is caused by acceleration/velocity limits that don't allow it to deaccelerate fast enough.

Please see Constants.java to see all the variables used to calculate the acceleration limit. The mu variable is meant to account for the friction of the carpet. Increasing mu which should increase the acceleration limit should reduce lag, but the reduction of lag is not significant. https://github.com/DeepBlueRobotics/RobotCode2024/blob/2c604e3998adb25a7d3ed465ea64cbd714c459f9/src/main/java/org/carlmontrobotics/Constants.java#L43

Based on current observations, it seems like the if statement is running as intended. Would suggest calculating a better acceleration limit using better physics calculations or "guess and check" a better value.

[brettle]

Per my mattermost post, the acceleration limit isn't actually causing the lag per se. It is preventing the driver from using the stick to manually do what the velocity PID should be doing for them. The real bug is that velocity PID is not responding quickly enough.

The current calculation of autoMaxAccelMps2 is correct. To verify, follow the steps in this post.

While removing (or sufficiently raising) the acceleration limit will make the lag go away, it will force the driver to do what they shouldn't need to do and could also cause them to develop driving habits that will not be appropriate when the underlying bug of slow velocity control is fixed.