I’m planning to enable voltage compensation on our shooter motors (TalonFX) to ensure we don’t lose huge amounts of power if we drive slightly while shooting. We’re not yet running PIDV, just simple PercentOutput.
What are the disadvantages of compensating to 10 volts vs. say, 11? Our drivetrain generally eats up 2-3 volts when rotating so 10 is where I’m looking to go. I’ve not yet seen talks of ill effect from voltage comp so I’m confident it won’t affect anything but I’m not super sure
If you use SysId, you should turn voltage compensation on. The specific choice of saturation voltage doesn’t matter much - you should generally not be saturating your control outputs to begin with.
I think it is pretty standard to use voltage compensation with flywheels for both sysid and consistent control.
One note is that there appears to be a filter applied prior to voltage compensation (configVoltageMeasurementFilter()). If you are really trying to tighten the control loop you could conceivably come up against the filter’s bandwidth.
I could not find what the default filter window is, but I would guess it is in the tens of ms, which is probably going to be faster than your flywheel’s spinup. Just something to be aware of and another knob to play with.
I am curious if anyone actually has experience with this voltage compensation filter being a problem or even having any noticeable effect.
One side effect of enabling “10 V” voltage compensation is that you’ll at most get 10 V. If your spinner design is at the limit and really needs 12V to hit the target, that would be a problem. But in practice, the robustness of getting 10V no matter here the battery is between 10 and 13.7V tends to make up for that.
The other issue is that your feed-forward and maybe other PID gains need to be adjusted as you change the voltage compensation. So drive the robot around, check how far the battery tends to drop, then use the lower voltage for the voltage compensation and tune the shooter PIDF with that in place.
I’m not running PIDV yet, so we don’t need to retune (in fact, our only values are for the practice robot which has a physically different shooter). We are also literally running 3 Falcons so needing the full 12V is generally not a thing.
This is getting to the crux of what we’re trying to figure out. We have characterized our flywheel, and then turned on voltage compensation to 10v to allow for the inevitable battery depletion.
Unfortunately we don’t know what to add to our kv in order to compensate.
We used the phoenix tuner to dial in a kF feed-forward gain to get the readback close to the setpoint, then tweaked the remaining PID gains to get it to match to 1% or better. Then we decided to use 10V voltage compensation and had to re-do the gain settings. … and then we decided to use 11V, and had to do it once more … Live and learn, but it doesn’t really take that long, there’s nothing to it but to do it 
Did you not use sys ID at all? This should provide you your optimum kf depending on the demand
Used sysId the very first time around when the speed was controlled with a wpilib PIDController and SimpleFeedForward. That worked OK, but figured the PID built into the falcon would be faster and save a few CPU cycles. Couldn’t quite get good numbers from sysId for that, so manually tweaked the gains in phoenix tuner. Do you get perfect numbers from sysId for the Falcon-based PID?
We get 10% of the setpoint with kf. And use kP and kd to get the rest of the way.
If your feedforward is in terms of voltage, you don’t have to add anything, as long as you send volts (or convert volts → output %) to the controller.
Does the voltage compensation work the same for the spark max? What voltage do you recommend?
Yes the voltage compensation works the same for the spark max.
We actually don’t use voltage compensation at the moment. The ‘arbitrary feedforward’ input to the onboard PID controller is already in the unit of ‘volts’, so we let the feedforward do most of the work using characterization data. That means any small variation in the robot voltage may cause some inconsistency from the PID controller, but its such a small fraction of the total control effort.
It looks something like:
sparkmax.setReference(kVelocity, setpoint, feedforward.calculate())
I attempted this using a 10v saturation on each Falcon and the shooter consistently undershot by like 3 feet–we’re just running VBus. Is it a manner of multiplying vbus commands by e.g (12 / 10) to account for this, or turning off the Talons’ “saturation” entirely as I believe @Oblarg mentioned?
Would turning off the “saturation” option, but still enabling the compensation itself aid in helping with voltage drops from Swerve?
How are you computing the values to pass to the motor controller’s set method? If your saturation is set to 10V, then the values you send to the motor controller in percent vbus mode should be the fraction of 10V that you want to command.
I see, so I should be multiplying by 1.2 in that case–all our table values are in units of (% of 12V).
How well would voltage compensation do with no saturation at all–e.g if the battery dropped down to 10V temporarily, how well would the Talon do in keeping it at its intended speed?
The voltage compensation can only go as high as the current bus voltage- if you have the saturation voltage set at 10 and Vbus drops below 10, then the talon will just output the best it can do which is Vbus.
I’m feeling to see the point of voltage compensation below 12v I thought it would be helpful in tuning but if one is doing sys ID I don’t see the benefit.
Voltage compensation gives you a consistent way to set the motor output in a way that relates to the physical attributes of the motor.
You want to set the saturation voltage low enough that the battery voltage won’t drop below it when you need motor output to be consistent (autonomous).
Setting the output without voltage compensation just sets the voltage to the motor to a percent of the input voltage, which can fluctuate wildly.
Sysid relys on, and assumes that, you will be using voltage compensation.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.