1391 is experimenting with a Swerve Drive test chassis using the 2023 Beta of WPILib and other associated libraries. We’ve noticed that our drive motors occasionally “click” with no associated warning printed to the console. Upon further investigation, we discovered that our Spark MAXes were occasionally setting our motors to 1,0, or -1 when it should be some decimal. It seems to be a random occurrence, though we could be overlooking the cause. When we used print statements to attempt to debug, we did not notice anything that would cause the issue. We’ve come to the conclusion that the problem most likely lies somewhere between the m_driveMotor.set() line and the Spark MAX. Whether it is a library problem or a CAN issue is unknown. Any help would be appreciated. If there are further efforts we should undertake for diagnosis, please let us know. Thank you!
Quick info about our chassis:
(all electronics are up to date firmwarewise)
RoboRIO 2.0 with 2023 Image
SDS MK4i Modules
NEO v1.0
CTRE CANcoders
REV PDH
30" x 30"
WPILib Kinematics and Odometry
PathPlanner 2023 Beta Library for Trajectories
Averaging 36% CAN bus utilization
This isn’t a fix for your issue, but you should know that it is best practice to reset your motor controller to factory defaults and explicitly set all settings in your code. Then, you should burn flash them (maybe not every time, could just do this every so often or when the FMS is connected). This fixes a lot of random spark max issues people talk about, but this seems control related.
I used to have it burn flash each time the code was restarted, but I deleted it in case it was the source of our issues. I’ll put it back in though. Thank you!
I looked at your deadband which is set at. 02. I think you should perhaps try .1 or. 2 (10x more than ur current implementation) unless you’re joystick is virtually noiseless.
Nothing has been a fix yet. Here’s a video with the issue audible and maybe visible. Clicky Drivetrain - YouTube We’re now suspecting it’s a loop overrun issue. When we attempted to have our PID on our Spark MAXes, they spasmed out and we decide to switch to RoboRIO PID to avoid damaging the motors. Any tips for migrating the PID to the Spark MAXes is appreciated.
Put all your PID constants onto shuffleboard (there are FRC docs on this). Start with everything at 0. Make sure you have your position and velocity conversion factors set. Set a button to command the module heading to current heading + 90. Set P to .1. Click button. Keep increasing until you get steady, but small oscillations. Add in D.
Same thing for the wheel turning. Biggest reason your things weren’t working was a units mismatch somewhere leading to the modules to be commanded to some crazy value. You can also just use sysid to get all your constants.
FWIW, we’ve had much better results not using PID, but using motion profiling. This is “profiledPIDController” in WPILib, or this REV example shows doing such control on the SPARK MAX. We use D = 0, I = 0, and measure max. velocity and max. acceleration. This means we only have to tune P. We mainly did this for better turning, but it also helps with drive. Drive might need position or velocity control, depending on what you are trying to do. Also, I would not expect warnings to print in case of most issues which might cause “click”.
I don’t think the theory in your original post is very likely. I’d suggest turning off drive and only running steering, and vice-versa, if you are not certain the clicks are coming from the drive part of the module. I’m also not at all sure clicks would be caused by a badly tuned PID loop, but clicks are kind of a vague symptom. Does this happen when the robot is up on blocks? If you just command percent output, you won’t have any PID in your drive control, so try that and see if it makes a difference. Check to be sure there’s no mechanical issue. Do the clicks always come from the same module?
It’s possible your joystick/controller has some kind of issue which causes it to occasionally send a bad value. So, you might try putting the robot up on blocks and running autonomous, or a test-mode command that makes the drive base do stuff without needing manual control inputs.
Our drive motors are already being driven by percent output, so a PID error is not in consideration. The clicks disruptions do happen on blocks. From graphing the telemetry in the REV Hardware Client, we know that the disruptions are the drive motors occasionally being improperly set to 1, 0, and -1.
We thought it might have been the breakers tripping, but even when limiting the current, the issue persists. The disruptions were shortly thought to be associated with the turn motors, but there is a visible change in chassis velocity each time the disruptions happened, without a change in direction. The disruptions occur in all modules simultaneously.
We have observed the disruptions when running trajectory following tests, indicating it is not a DS side problem. We have had some small connection issues between the DS and the RoboRIO, but those have been few and far between and not correlated with the disruptions. We are currently using the generic Logitech gamepad, but plan on investing in a higher-quality controller closer to kickoff.
Looking at your code, I see a few things I would change, but I don’t think any are actually causing a problem:
I’d put your swerve modules in an array and iterate it whenever possible. You have a lot of code that acts on the four modules in order, and it’s easy to swap the order.
You mix degrees and radians throughout the code. I’d stick to radians throughout if possible.
Your module steer PID controller is controlling the encoder value, not the desired state angle, which seems an odd choice.
I’d check for any lose CAN wiring, and make sure both ends are terminated properly. It may be that your motor controllers are briefly disabling. Other than that, I’m with @bovlb.
Oh man. Thank you for commenting this. This would have completely slipped my radar. Here’s a link to a drive folder with some log files. Connection issues were most definitely not few and far between. However, now we come to a different problem. How do we fix connection issues? We replaced the radio during our meeting today, and it didn’t seem to do anything. We’re powering the radio through the REV Radio Power Module, could that be an issue? Could it be an issue with the 2023 RoboRIO image?
I’m going to rescind my “fixing” questions until I’m able to get back to the chassis tomorrow. I believe that the debug prints were still active on the code today, crowding the connection significantly (3 prints per module per update). I’ve pushed my updates, so no one should have the outdated code.
Let us know when you have updated info. Normally, if there are radio power issues, it’s super obvious – they trigger a radio reboot, which takes more than a minute to come back. If you run on a bench, you can tether via USB or Ethernet, directly to the roboRIO. If you still have connection issues, it’s possible your debug output is saturating the connection…
One approach is to use Shuffleboard for tracking this kind of information. There are also teams that log to a local (on the roboRIO) file. Or, only print every so many iterations to limit the output, or …
Thanks. You seem to have a lot of packet loss, but I’m not seeing an obvious cause. Sometimes this is CPU overload on the driver’s laptop. I don’t think you’re losing power to the radio.
On Sunday you had a lot of brownouts which can sometimes be heard as clicking, but there are other signs. According to the DS log, your voltage is dipping to 8 or 9v, but your total current doesn’t seem to exceed about 30A. You might want to check your power wiring. in particular for the roboRIO, and feel free to share photos (well-lit, power off). Could also be a dodgy battery.
I only see one CAN error message. There are a couple of loop overruns, but I wouldn’t worry about them if they just happen at the start of a mode.