Swerve drive base Brownout Issue

Hey my team is trying to get a swerve drive base going and ready for potentially this season if not the next, we have a square drive base and are using Swerve Drive Specialties MK4i swerve modules with the L1 configuration. I have been tasked with programming. Since SDS already has a sample code to help get started I based my code on that. I am currently having some issues where once the battery is not fully charged I get a brownout and the wheels start to “fight each other” basically it starts making loud noises and then for some reason the wheel directions flip. I also noticed that the terminal is saying:

CTR: CAN frame not received/too-stale.
Pigeon IMU 17 Get Yaw
CTR: Firm Vers could not be retrieved. Use Phoenix Tuner to check ID and firmware(CRF) version.
Pigeon IMU 17

I have tried switching batteries, which helps a little but once the battery drops below about 12.1v it starts having this issue again.
what could I do to fix this?

1 Like

To help you diagnose issue, it would help to see if the wheels fight each other before the brown out or after.

If you elevate the wheels off the ground and run it, do you experience the same issue ?

The easy stuff (that usually has nothing to do with the problem) - check your CAN utilization and packet loss, check that you wired the Pigeon to 12 v PDH and not 5 v, check the roboRIO CPU utilization. We run to about 11.9 v before seeing what you see so there isn’t much headroom. Your battery might be weak and of limited capacity even when reporting seemingly high enough voltage - try your best battery from this year.

How is your pigeon wired?

Thanks for the reply, and yes this Issue seems to continue even when the wheels are elevated. I think it might be because I have the max velocity in my programming set to the max velocity under perfect conditions, so I will run Sysid and get the actual velocity to see if maybe that can help.

1 Like

Got it, what would be considered a high CAD and roboRIO CPU utilization, and how would I go about trying the decrease it?

I’m no expert on CAN and there are threads on CD about CAN. My team approached 100% all the time and we had trouble with our I2C/USB gyro so we got a Pigeon and CANivore.

Set the motor controllers’ frame status update rates as slow as possible to work for you.

If you aren’t getting the 0.02 second print loop overrun messages you should be okay. We had occasional poor roboRIO response for some actions at over 80% CPU utilization.

If your wheels are in the air, there is almost no load on the motors and there shouldn’t be brownouts unless the battery is in poor condition or maybe it’s that max velocity - telling it to do something that is impossible but it tries anyway (but I have no idea how that could be).

1 Like

We found we didn’t have much visibility into each module using the SDS code as a base. So we looked into several teams code where the module is a separate subsystem, and went that way.

You’re using field relative mode. Switch to robot oriented mode and eliminate the gyro effect.

To add to this, try hand turning and twisting the modules when the robot is off. It should move like butter.

I didn’t look too into it when I started because I wanted to get the robot running, but I see why this would be a good idea. Could you tell me which teams you looked into, because I am assuming there will be good amount more PID tuning done to get this right? Thanks.

My team tried the SDS code and it worked okay without additional PID tuning. We decided to use the WPILib SwerveBot example for the season and that had to be tuned to work at all. Rudimentary tuning on just the bare chassis turned out to be good enough for the whole season as we didn’t have time for further tuning unless essential and it wasn’t.

1 Like

The main problem is you want Talons but are using Mk4iSwerveModuleHelper.createNeo(…) which gives SparkMax.
You need to pick the correct createFalcon combination.

Another thing I would recommend is to switch your Drive Command to ChassisSpeeds for initial testing as indicated in the commented out portion of that command.

You have 8 - CANCoders declared. You only need 4. They are needed on the turn axes to restore the startup wheel angles.

Sorry for not clarifying, but my team is using spark max w/ Neos. I completely overlooked the CANCoders, which would explain the increase in CAN utilization. Thanks! I will try commenting them out to see what happens.

Sorry I was looking at the CTRE and thinking Talons.

This is our swerve using sparkmax with neos. It uses NavX instead of Pigeon otherwise it seems to fit what you have.

Found the issue: The Swerve Specialties lib was automatically setting the current limit in the CANsparkmax. Had to make a different config with custom configurations.

1 Like

Another item for @bovlb gotchas for CSAs.
Current limit at least one swerve module then it’s not tracking with the others. The dueling modules cause brownouts with otherwise well-charged batteries…

1 Like

With swerve, the modules can sometimes briefly be pointed in a set of directions that mean the drive motors will be mostly fighting each other. This can cause these motors to draw a lot of current, which can make it slower to get the modules pointing in the desired directions.

One thing you can do is to current limit the drive motors pretty aggressively and then see if this clears up the brownouts. If so, you can either find a reasonable current limit and go this way, or try to introduce code to handle this case. For example, you might lower the commanded power to a drive module when the desired module angle is far away from the actual angle. This way, if the modules are facing the right way, you can still get more power, but won’t stall motors at full power (or tear up the carpet) when the modules are 90° off angle.

We multiply the drive power by cos() of the angle error to do this and it seems to work pretty well.

Also, this is a case where you want to carefully check the quality of your wiring – materials and techniques – to be sure your robot is set up to best handle high current draws.


This looks like the same issue.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.