My team and I are currently in the process of PID tuning our flywheel on our shooter and needed some assistance with the process. For reference, our flywheel is controlled by two neo motors that are attached to CANSparkMax’s. We wanted to tune our PID using the Rev Hardware Client using the telemetry graphs, however we found the graphs slightly confusing as we have never used them before. We also did research online about how to tune a PID and some folks recommended tuning your feedforward gain to the maximum RPM of the Neos and then tuning your PID of that. We were able to tune the feedforward to a maximum RPM of about 5500 on the neo’s but when we tried to tune the PID loop, we found ourselves struggling as to how to do it and also to see the values since the graphs on the REV Hardware Client didn’t allow us to zoom in.
If any team/individual on how to best tune our flywheel from the Rev Hardware Client and the process they went through to do it, that would be great. Any help is always appreciated.
Keep in mind that you’re not going to see great success with PID control of a flywheel using the NEO integrated encoder, due to the hardcoded measurement delay.
I am doing PID control using a NEO integrated encoder. The only way to tune that PID control is through the REV Hardware Client which I need help with using in order to tune the PID.
Our team is using NEO integrated encoder for our flywheel shooter and it is working fine. We used SysID to tune the values, and although the actual RPM reading may be inaccurate or delayed it is very consistent and that’s what matters, right?
Stable feedback gains for the integrated NEO encoder are small enough to be almost negligible; you’re running nearly pure feedforward.
An external encoder hooked up to the limit switch pins per the instructions on REV’s instructions, or hooked up to the RIO (this will require running PID control on the RIO, as well).
SysID can be found using the launch tool menu in VSCode. For the flywheel you probably want to use the general mechanism config, Configure your SparkMax with CAN id, invert, and gearing (make sure encoder port is selected, not data port for encoder). Deploy and run all the tests as instructed. You can then analyze that data by loading the JSON file that was just created. The documentation page is very helpful while doing this (especially because I probably missed something). Those values then can be used with the SimpleMotorFeedforward class and PIDController in WPILib. You can change this to the onboard PIDF but you would have to do some unit conversion.
Thank you so much for this help, it really means a lot to me and my team.
I just have two questions if you don’t mind:
Does sysid automatically generate the PID values for us or do we have to manually go through and change each value until we get the proper PID Values.
If I want to set the PID values generated from SysID into the revsparkhardware client or using the CANSparkMAX PID controller would I have to do a unit conversion? If I do, do you know how I would do the unit conversion?
Once again, thank you so much for the help, it really means the world to me that your helping us out.
Yes it does. The P value may require a bit of tuning however but in my experience it has worked “out of the box”.
Looking at it I think it would just be dividing by 12 for the feedforward values as it is in volts and SparkMaxPID uses -1 to 1 but I haven’t tested it. I’m sure @Oblarg would know this as he is one the developers for SysID.
Thank you so much ohowe! I’m sorry for all the questions but I just have two more questions:
To set up SysID, am I able to launch it via VScode like the same way you can deploy code to the robot?
We have two NEO motors attached to the flywheel so do you think that would affect our PID tuning? If so do you have a recommendation on how we can go about this?
Thanks so much for the help, I truly appreciate it
If that’s the case, could I get away with characterizing our shooter with external encoders to get accurate feedforward constants but then using the internal neo encoders during the actual match with a small kP?
There’s no need for external encoders for the characterization routine. You can shrink kP to make the response stable but the kP that works is so small that it does very little.
External encoders will fix the problem if you use them for feedback.
@Oblarg, could you elaborate a little bit more about what you mean by “due to the hardcoded measurement delay”? PID control of a flywheel using the NEO integrated encoder was exactly what we were aiming for.
p.s. I’m a professional software developer, but do not deal with hardware/robotics outside of FRC. Thanks.
The SparkMAX has a hardcoded firmware filter that it uses to process the signal from the NEO’s internal hall effect sensor for the reported velocity readings. That filter introduces ~110ms of measurement delay.
If you hook an external encoder up to the limit switch pins on the SparkMAX you can reconfigure the filtering settings (they default to ~80ms of delay) to reduce it down to as low as 1ms (though encoder resolution may make this impractical).
In my own words: a flywheel spins too quickly for the internal encoder to be used as a reliable feedback sensor. Because of the filter, the velocity readings using the internal encoder is probably off by a medium-to-large factor.
But the internal encoder is fine for position closed-loop control.
Yep, that’s pretty much it. SysId can estimate the time constant of your flywheel so you can compare it to the signal delay (it estimates the signal delay, too).
