Attention off-season roboteers… I’m a mentor for Team 554. Last season, we were experiencing some extremely frustrating inconsistencies with our swerve drive, most specifically with our autonomous repeatability. I’m looking to “borrow” a team’s 2024 code to reference and test on our robot to see if it’s somehow our code having the issues, or if we are having a mechanical issue like wheel slippage, weight distribution, or battery voltage. We also think we could maybe need some PID tuning, because the robot is veering on paths in real life and also displaying the exact veering on the Pathplanner telemetry visualizer. It doesn’t have errors every time, but maybe only have 1 out of 5 perform successfully to the intended path. Related issue we have issues with our robot delaying for a short unpredictable duration upon AutoInit. The easiest way to do our troubleshooting is to find a team with similar specs to our robot so we can just change some CAN assignments to get some quick troubleshooting results. Our 2024 robot has the following specs:
SDS MK4s (Colson Wheels) with NEOs and CTRE Encoder
SparkMax Drive Controllers with Internal Velocity PID
SparkMax Turn Controllers with Code PID
Pathplanner
If any teams out there has extremely high levels of success/repeatability during autonomous using this setup (with or without Colson wheels), I’d love to reference their code and possible upload and run the code on our robot for some trial run comparisons. Thanks so much in advance for any suggestions or possible teams to reach out to!
Before running a different code base, I’d suggest deeper troubleshooting on your code/tuning. If you aren’t already, log the wheel speed setpoints and actuals as well as the module turn setpoints and actuals. Drive the robot in teleop on some simple paths (straight, L, U, etc.). Vary the commanded speed. Look at your logs and see how well the actuals are following the setpoints. There will probably be some disconnect on the wheel speeds due to inertia and the physical inability to track rapid setpoint changes. However, during periods of slow setpoint change, the tracking should be close. Turning should track pretty closely all the time.
You could also look at logs of the same values recorded during an auto run to look for significant differences between setpoints and actuals, but I’d personally feel better about starting with insight from some simple paths, especially those that have some 90 degree changes of direction that should be a very revealing test for the turn tuning.
You mention that your drive controllers are using PID in the Sparks. Are you also using feedforward? Your drive control effort should be coming like 90%+ from feedforward with just a little feedback (PID) correction where needed.
Not sure what kind of issues you had, we used This Code made using the YAGSL library. Our autonomous had issues due to a damaged gyro early on, but we replaced it and it worked during our 2nd competition.
Hey Everyone! Thanks again for the help! Here is a link to our code. We are using the navX2MXP gyro. And it seems to work pretty well and doesn’t accumulate much error over time. Most of the issues are with path repeatability, and with strange time delays between sequential and parallel commands in Pathplanner. We did change our wheels from the Colson Wheels to the new Billet wheels and we already see some drastic improvement on wheel slippage during tele-op control, but haven’t tested our auto paths with the new wheels yet (will do that next week). Let me know if you see anything obvious in our code that is redundant or non-needed (that could explain why we may be missing some commands on loops, etc.) Thanks again!!!
We will try increasing the feed forward term and use the PID for error adjusting. We are doing most of our auto testing next week so we should have some more info after we test these out. Thanks again!