Hello! My team uses YAGSL with mk4i and Spark Flex for drive and Spark Max for angle. We’re looking for a way to tune PIDs with a graph using software. We have tried using REV Hardware Client, and we were successful with tuning our flywheels on our launcher with the telemetry graph, but when we try the swerves, the data on the graph doesn’t move. We’ve tried lifting up the robot, putting it down, and plugging into the Spark Max instead of Spark Flex, but nothing can get the graph to move. For the graph, we graph the setpoint (velocity version) and the velocity, to try to find the correct PIDs so the velocity quickly gets up to the setpoint. The velocity line is the one that doesn’t move when we control the swerves. We did the exact same thing with our flywheels and it worked, but not for swerve. Does anyone have experience with using REV to tune swerves?
If we can’t get REV to work, is it possible to use FRC Web Components to tune the swerves? I have tried this but with no luck. I have desired states and measured states as the two data points, but the lines don’t move either. I would really appreciate it if someone could give a detailed description of how they tune their swerve PIDs. Thank you!
YAGSL outputs the setpoint and current measurements in NT (except velocity as you have pointed out, oops that will be in the next one), you can also program in a way to set your PID for a single module with SmartDashboard if you want to tune it in the dashboard.
For now you can just tune with the swerve widget, if you want to add your own velocity readings you can modify here, or wait for the next update.
Tuning on the ground is best, for the swerve widget i only have experience with FRC Web Components so i will lean there. The end goal is to get the blue lines (measured velocity) to match up with the red line (desired velocity) as much as possible. I would start with the defaults from the main example project or some known working pidf values and go from there. Move the robot around on the carpet if they are close but not quite good enough, but if they are wayyy to far off to be dangerous don’t test on the carpet.
Using the blue lines as the measured velocities base all of your tuning decisions off of that. If it constantly oscilates to overshoot increase D or decrease P. I would advise you to look at WPILib’s documentation on tuning and reference the chart on mine while youre doing it.
Sure, that would be helpful. We can try FRC Web Components at one of the next meetings and maybe the velocity on shuffleboard as well. I will let you know how it goes. Thanks!
