Team2168 / 2014_Main_Robot

Code for the 2014 FRC season.
Other
2 stars 1 forks source link

Drive Fwd in Auton Wont Stop #94

Closed NotInControl closed 10 years ago

NotInControl commented 10 years ago

We noticed at NE Champs that the driveFwd Command continued to move the robot despite all attempts to stop it.

This caused the robot to run into the wall many times during Auton.

At this point it is unclear why this was happenening at it appears the sensors were working. Need to investigate the calling structor of the command and verify that it is infact ending.

NotInControl commented 10 years ago

After a cursorary code review, I believe the cause of this behavior was due to blanket calls by the drivetrain to the rateLimit function to ramp up/down the drivetrain. All sensors and other Autonomous calls seemed to be correct and in working order.

The rate limit increases or decreases the normalized voltage singal to the motor controller by a constant step size on every function call.

The rate limit expects constant updates, as would be expected while in teleop and using the sticks. Every 50ms a new driverstation packet is sent causing this rateLimit function to be called, and a limit on the drive to be noticed.

However, in autonomous, the rate function only gets called once. (in the end() or interrupted() functions of the driveFwd Command.) When this happens, the ratelimiter decreases the current drive speed by the step size, but then holds that value.

We were driving into the wall because we started at 0.7 and when we called drive(0.0,0.0) it goes through the rate limiter once and gets depreciated by our limiter step size of 0.15. The result is 0.55, and then because the limter function is never called again, the PWM signal latches the 0.55 drivetrain value causing us to drive into the wall.

Once Telop Starts, the sticks send updates to the limiter function, causing the problem to go away.

This problem was likely always present, but because we were only using the driveFwd command with a 0.25 drive, it is likely that the one step size decrease was enough to be in the deadband of the drivetrain. However, the problem made itself known once we started increasing the speed of the drive forward command during competition.

jcorcoran commented 10 years ago

Should be fixed in branch: https://github.com/Team2168/FRC2014_Main_Robot/tree/auto_wall_smash_fix_JMC/src/org/team2168

Just need to revert the auto modes back to using AutoDriveXDistance command, and spot checking all other auto commands.

Any place where we want the drivetrain to stop moving (in a single method call) we need to modify the method call from drive(0.0, 0.0) to drive(0.0, 0.0, false). Don't blindly replace all drive() method calls, since it's a good idea to use the rate limiter when we expect drivetrain motion.