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
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.
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.
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).
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.
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.
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.