We just installed our first swerve drive system this year and are having issues with the robot “chattering”, not moving but vibrating in place when the battery voltage gets a little drawn down, usually with only 30 seconds of driving. It’s not 100% of the time, but primarily when we try to change directions. When this “chatter” happens, we can see the voltage go from ~12v to ~7v on the readout. It’s only a temporary dip and goes back up to the ~12v range but it’s very erratic movement when it does this. Has anyone seen this and have any ideas how to remedy?
1 Like
Can you share your source code (e.g. with a Github link) and Driver Station log files? (Also, the circuit numbers of the swerve motors.)
We are using the code from the Swerve Drive Specialties example. Our repo is here: GitHub - minerbotics/Robot2023
I haven’t had the chance to test it out yet, but I’ve made some updates to the code already based upon this thread here: Our Smart Current Limit and Idle Mode for our CAN SPARK MAX's are automatically being changed when running swerve code - #6 by vargoose84
I don’t have access to the driver station logs until Saturday, which is when I’ll also be testing out the changes made to the module configuration’s current limits. Thank you for your help!
A dip to 7V implies something is drawing a lot of current, and if it’s longer than an instant that would suggest there’s a lot of friction somewhere. The logs will help tell us where, as long as you have the PDP/PDH wired up on the CAN bus (and can tell us which power ports correspond to which motor).
Video of the behavior would also help, as I’m struggling to visualize what you mean. It almost sounds to me as if your modules are fighting each other as they rotate to new positions, but that’s a shot in the dark based on the information supplied.
1 Like
easily proven with the robot up on blocks.
And maybe OP’s batteries are too worn even for practice. Try a new battery but don’t wreck it with a bad drivetrain. Make sure it drives right on blocks
This happened to our team too, with the new MAXSwerve modules. Most of the time though, our issues with this chatter were solved once we replaced our robot with a charged battery.
Another diagnostic test is to watch the status lights on the motor controller when the problem is happening.
Looking at your code, I have some notes:
- Your calculation of MAX_VELOCITY_METERS_PER_SECOND appears to be based on the free speed for the motor. I’d recommend that you try to calibrate the actual max speed of your robot.
- Your current limit of 20A seems low, especially for drive. Could you be hitting that? This may be interacting poorly with your use of voltage compensation. See SparkMAX Voltage Compensation .
- If I’m looking at the right code, the library you’re using is setting the period for Status 0 to 100ms. I believe this status frame is used for a 100ms watchdog, so it shouldn’t be set above 45ms.
1 Like
If you could upload the log file directly, that should help us figure out where the issue is (as long as your PDP/PDH was on the CAN bus for the session the log recorded).
Our coding guy (Phrendoul) found that the current limit wasn’t all the same in the code and made them all 20A I believe. I think one was 20a and the rest were 80a. Thanks you for the help, that was a tricky problem!
Curious, I know some falcon teams use high current limits (for example >= 70A). How do they do this and what’s so special about falcons that makes them capable of using this high current limit while NEOs can’t? Is there anyway to make it so that the NEO can take this higher current limit so this doesn’t hurt a NEO swerve’s pushing power?
The same thing happens to us, we just change out the batteries when it happens. Is this not the expected behavior?
afaik neos can take similar current loads as falcons; the main limit is probably one’s breakers and battery
fwiw neo swerve has comparable if not superior performance to a falcon swerve when geared to the same free speed, due to neos having greater torque at low speeds and normal currents, so im not sure if this is an issue anyways
20A is reasonable for turn motors because they’re never expected to do much work, and if they’re drawing more than that, then something is very wrong. 20A is way too low for drive motors because they’re doing all the work, and will commonly need to draw much more than that.
I wrote some notes on current limiting.
My issue is if you can pull 60A with 4 falcon drive motors but can only do 30A with 4 NEOs something must be off, even if they can both have similar performance at their respective current limits. I’m just not sure why this would happen.
Falcons have an auto thermal disabling mechanism, while NEOs will run until death, this means you can run falcons harder without fearing damage to them, but you’ll still end up with a dead drivetrain.
I see but that sounds like falcons will auto disable if they pull too much current while neos will just keep running which is the opposite of what’s observed. Am I misunderstanding?
We have run neo 550s with 60 amp current limits without issues. it depends on the use case. I don’t think falcons or neos are built to handle high current in a meaningful different way other than software
I’ve ran 4 neos at 60A current limits and have them be fine, even while playing (imo) heavy WCD defense. The battery was very dead at the end of the match, but the motors themselves were fine. I don’t think this is an issue, especially seeing as the motors will only see their max current loads when stalling or at the beginning of acceleration.
1 Like
The roborio has brownout protection that shuts off motors when the voltage dips below a certain threshold. This creates the classic shudder of robots with low batteries. The cycle is: try to draw a low of current and voltage sags very low, rio turns off motors, voltage comes back up to acceptable level, turn motors back on, motors draw a bunch of current right away, repeat.
This is likely a battery issue. When was this battery purchased?