Our robot for this year is done, other than some last-minute tuning. One problem we have been running into is decelerating the robot. When we stop, the robot stops instantly and almost tips over. We are planning to add weight to lower the center of gravity, but is there anything we can do to mitigate this on the programming side? We use SlewRateLimiter for acceleration, but when we stop, it goes straight to the motors and stops them. When we try to set the desired speed to 0 instead, the wheels start moving in random directions without input.
This if statement will get evaluated as false when you release your joysticks, calling the drivetrain stop function, which ignores the slew rate limiters you have in place.
Forgot to elaborate clearly. We know that’s why the issue is happening. The problem is that we can’t find an alternative. We have tried running the drive method with 0 for xspeed, yspeed, and rotation, but that causes the wheels to act sporadically before we even give an input on the joystick. How would we go about implementing it properly?
The if statement asks, “are the joysticks currently pushed away from their center/home positions?” If so, drive with the rate-limited joystick percentages.
This works at the beginning; the joysticks move, then the rate-limited values ramp up. But it doesn’t work at the end; the joysticks return to home, then the rate-limited values slowly return to home. Before the rate-limited values get there, the if statement says “joysticks are centered” and the program says “stop!”
To get the desired result, you want to ask, “are the rate-limited joystick percentages beyond their center/home positions?” That way, when the joysticks return to center, the robot continues to drive until the rate-limited values catch up.
The stick positions are being modified by deadbands before they get fed to the rate limiters. Because of this, the info you’d want to build your if statement on isn’t available; it’s sliced out of the rate-limited outputs and it’s timed incorrectly on the non-rate-limited inputs. Maybe consider calculating the deadband on the output of the rate limiters?
Part of your problem might be that the drives are set to brake mode so the motor will stop allowing movement the second it stops, you can change this to coast and it’ll pause for the stop but then keep rolling forward for a little.
Update for future teams: applying the deadzone
to the SlewRateLimiter worked perfectly after a bit of tuning. The one downside is that the robot doesn’t decelerate enough when you instantly turn around, but this is largely due to our robot being decently top-heavy (we had it tip during a match ). Thanks for the help!
). Thanks for the help!