Swerve motors stuttering

Our team has started swerve drive, and I notticed a couple of things with the code.

Essentially, whenever we do some aggressive things, such as driving forward then suddenly driving reverse fast, and when we try pathplanner, the motors seem to stutter.

In addition, when the motors do stutter, battery warnings start to flash on the screen of the driver station computer.

As of now, all voltages set to the motors are coerced between -12 volts and 12 volts; this currently isn’t corrected by robotcontroller’s voltage.

Do you guys think that this is caused by overt acceleration, setting voltages above the robot’s currently limit, or something else?

Thanks a lot: this issue has been puzzling me for quite some time.

Steering motors are likely doing full Reverse slams. Search on the forum here, lots of similar issues that have been solved.

Possibly PID loop is too hot.

We’ve seen this issue a lot, it happens when a battery is running low. Essentially, the motors pull high amounts of current, and the battery voltage drops below a certain threshold (around 8V or so I think?). Then, the RoboRIO detects low voltage and goes into “brownout protection” mode which disables all the motors. However, with the load of the motors removed the battery pops back up above the threshold voltage, and the RIO re-enables everything. This happens rapidly creating the stutter.

Make sure your batteries are fully charged, and also in good health would be my recommendation.

3 Likes

6.8V actually: roboRIO Brownout and Understanding Current Draw — FIRST Robotics Competition documentation

Interesting… Thanks for the tip!

It doesn’t seem to appear on the steering motors; and it happens when there’s only open loop control as well.

Could drive motor stuttering could be caused by the problem you listed?

Yeah, that seems reasonable.

Would clamping the voltage based off of current battery voltage do the trick?

Charge your batteries fully. Don’t expect to get more than 3 minutes or off them if you are driving aggressively.

1 Like

Setting current limits on your motor controllers will likely prevent this problem.

1 Like

Yeah, I should have mentioned that. Generally keeping your diversity under approximately 200 amps is a good idea. Test to find out where your threshold is.

I agree with the other posts, make sure you have good, full-charged batteries, and current limits on your drive motors.

Something else to consider is that you might be pushing the robot too hard, based on its mass and the gearing. Are you using a slew rate limiter, or other means to limit the rate of change applied by the driver? You don’t want to directly be driving your robot forward at full speed and allow an immediate reverse operation. For PathPlanner, you could consider lowering your acceleration.

On this note also consider a ramp rate on your motor controller too.

Are you using Rev motors at all?

If it is indeed a battery issue, you can treat the symptoms by enabling voltage compensation to ensure that the motors receive sufficient voltage even when the battery dips. Try setting it to 12.6.

I am not as familiar with the CTRE API. It is possible there is an equivalent.

Yeah, we did have a slew rate limiter, and that prevented strong forward accel.

However, we made it so that the limiter only limited forward accel; this way, the robot wouldn’t continue traveling when we lifted our hands off the controller. This, however, caused stuttering when driving forward and suddenly reversing it.

For pathplanner however, our robot still stuttered when we set the max velocity and max accel to 0.5(I’m pretty sure). However, at that time the battery was at a pretty low voltage, which might explain things.

Yeah, we’re using spark maxes atm.

I looked at 6328’s code and realized that they did use voltage compensation; it was a relatively quick add for us.