My team experimented with the different control modes on the TalonSRX, and noticed that driving the robot had a noticable latency with voltage compensation mode enabled.
I am wondering if this is inherent or if it can be fixed somehow.
Can you be more specific? How much latency and under what conditions? How did you measure it or is it just a driver âfeelâ thing? We do this routinely and notice no latency (at least that a human can detect). Maybe post your code? How many motors, transmission ratios, types of size wheels, robot mass etc.
Would you mind posting the settings for the Talon? When we didnât know what we were doing with voltage ramping in early 2017, this was the exact symptom.
1 Like
Weâve never noticed any âlagâ in voltage compensation mode, but one thing we *have *noticed (and which you absolutely must be aware of) is that if you are running closed-loop velocity control and have tuned your feedforward without taking voltage sag into account, turning on voltage compensation will result in significant speed errors. It is not hard to see why this is the case.
How do you tune your feedforward taking voltage sag into account?
By tuning with voltage compensation turned on.
Instead of tuning with voltage compensation turned off, then turning voltage compensation on afterwards.
I think thatâs what he meant.
Almost, but not quite.
So, a typical feedforward tuning procedure for an FRC drive involves running the robot to steady-state speed in open-loop control at max voltage, measuring the resulting velocity, and setting Kv (the feedforward gain) to 1/(max velocity), assuming units of fractional output (where an output of â1â is max voltage). The idea behind this is that the robotâs steady-state voltage-versus-speed curve is linear and passes through the origin, and so can be determined by one point (note that thereâs nothing âspecialâ about running the aforementioned test at max voltage, here - one could ostensibly run the test at any voltage, so long as the math is adjusted accordingly). In practice, effects due to friction cause some problems with this approach - see the whitepaper linked in my signature for further discussion of this - but it is an extremely common approach, regardless.
Ignoring for a moment the problems due to friction, we should immediately note that the value of Kv obtained from the tuning methodology described above varies with the amount of âvoltage sagâ experienced by the robot. If the robot were powered by an ideal voltage source at 12V, the velocity observed during a test at max voltage would correspond to the speed of the motors at 12V. The robot is not powered by an ideal voltage source, however, and so what we measure is the speed of the motors at some voltage less than 12V - enough less, in practice, to make a significant difference.
Now, if we simply set Kv to 1/(max velocity) and then run closed-loop with no voltage compensation, we benefit from something of a âhappy accidentâ - because we are commanding fractional output and not an absolute voltage, and because steady-state motor current (and thus voltage sag) is more or less independent of robot velocity, a given fractional output roughly corresponds to the fraction of maximum voltage applied to the motors including the effect of voltage sag. That is, if due to voltage sag my effective âmax voltageâ as seen by the motors is only 10V (rather than 12V), then an output of â.5â will result, roughly, in an output of 5V (as seen by the motors). Since our feedforward assumption depends on the speed-versus-voltage curve having the form of a line passing through the origin, this is a crucially important fact - it means that if we command a setpoint of 50% of max speed, our feedforward will indeed give the motors roughly 50% of the max voltage, and attain roughly 50% of max speed.
What happens if we now enable voltage compensation? Suddenly, this is no longer the case - a fractional output of .5 will result in a voltage output of 6V, even if our âmax voltageâ was actually 10V! In this case, a velocity setpoint of 50% of max speed will result in feedforward giving the motors a voltage corresponding to 60% of max voltage, and, per our assumptions, we will (incorrectly!) attain a velocity of approximately 60% of max speed.
So, whatâs the solution? Unfortunately, it is not quite so simple as Ether suggests. Simply naively following our original feedforward tuning procedure with voltage compensation turned on would still result in exactly the same problem. Why? Because voltage compensation can only account for battery sag up to the maximum voltage that can be applied to the motors. If a fractional output of 100% results in the motors seeing 10V, there is nothing voltage compensation can do to increase that number. Voltage compensation could only ensure that any commanded voltage below 10V is actually achieved. The result of this is that if we were to turn voltage compensation on, but we still ran the described tuning procedure, the motors would still see the same max voltage, the robot would run at the same speed, and our obtained value for Kv would be exactly the same as if we had not turned voltage compensation on.
So, we would not only need to turn on voltage compensation for feedforward tuning, but also to be certain to run our steady-state test at a voltage low enough that it can actually be attained. Then, and only then, would we obtain a value of Kv that will work properly with voltage-compensation.
An alternate solution is to measure the voltage actually reaching the motors (the Talon SRX library does have a function for this) and to calculate Kv instead as (max measured voltage)/((max theoretical voltage)*(max velocity)) (it should be reasonably clear, I hope, why this math works). A better solution is to follow the feedforward tuning procedures described in our whitepaper, though due to limited software support it may be difficult to implement them in Talon closed-loop velocity mode at the moment.
1 Like
Eli,
Maybe Iâm missing something, but your post seems to significantly over complicate the most effective usage of feedforward (and maybe that is your point).
Voltage compensation is meant to make your input voltage to the motor controllers more consistent, not perfectly consistent, so autons and other function can have a chance to be more consistent. We use voltage compensation on the VEX IQ motor so that teams get more consistent behavior from their motors.
Feedforward (as you know) is meant to take as much load off the rest of the control loop as possible. Having a feedforward gain that perfectly matches free speed in closed loop mode is something I would never recommend. We usually only have a Kf of about 75% of expected and let PID do the rest.
Again, we use a motion profiled input as we have found that is one of the best ways to get motor consistency so we are never putting a step velocity input into the system.
Your post seems to indicate that everything falls apart if your Kf is not perfect and that is simply not the case in my experience.
What am I missing from your post?
âNot perfectâ is a rather significant understatement of the effect of turning on voltage compensation when running a velocity loop with a feedforward determined without voltage compensation. In our experience, the effect is substantial, because voltage sag is substantial. To be more specific: upon turning on voltage compensation for last yearâs robot, the robot simply would not drive straight anymore (before, it had little trouble). This is because the feedback loops were now forced to drive the output down a significant amount from the feedforward, which was erroneously inflated by voltage compensation, and this resulted in significant inconsistency between the two sides of the drive.
I am confused as to why you would recommend intentionally introducing errors into your feedforward, however; the point of feedforward is to get as good a âguessâ at the required output as you possibly can, so that the feedback portion of the loop does as little as possible. A more-accurate feedforward term is strictly a good thing.
Of course, tuning feedforward with a completely different set of input conditions is not at all recommended. This is like tuning feedforward with a 6 volt battery then using a 12 volt battery in the actual application. I am not advocating that at all.
However, because a DC motor drive system is pretty darn non-linear using a linear FF term and assuming it will be perfect is just simply not the right way to do it. You are using one point at free speed at one voltage and saying thatâs better than dialing it back. Letâs just say I disagree with that method completely.
And the point of FF is to take out as much of the SS error as you can, but I have found that when FF induces error on the high side (meaning PID is constantly trying to pull back the FF term command) that DC brushed motors are just not that happy. Having a slightly larger error on the low side (meaning driving the motor slower than perfect) is much better handled by DC brushed motors than trying to always slow them down.
Have you read our drive characterization whitepaper? âPretty darn nonlinearâ is, according to all the data weâve ever taken, not a good description of FRC drives. Theyâre (at steady-state at least) exceedingly linear; the issue is that the intercept of the voltage-speed curve is nonzero. The errors due to this, on our experience, mainly cause issues at low speeds.
And the point of FF is to take out as much of the SS error as you can, but I have found that when FF induces error on the high side (meaning PID is constantly trying to pull back the FF term command) that DC brushed motors are just not that happy.
This, I can maybe believe (Iâve seen things that might suggest this, though Iâm at a loss as to why it might be the case and would rather run actual tests before I come to a firm opinion) - but note that this is exactly the type of error introduced if you turn on voltage compensation with a feedforward that has been tuned without it. Your voltage-compensated feedforward output will be inflated.
On the other hand, using a feedforward that assumes a linear voltage-speed curve that passes through the origin introduces error in the opposite direction; if you tune FF around velocity at maximum voltage, for any velocity setpoint below max your feedforward output will be too low, not too high.
Voltage control mode?
OK, you keep tuning your way and Iâll keep tuning my way. Iâm not really in the mood to get into a CD argument with you over drive tuning.
However, the system of equations that govern actual motion of robots is non-linear. Just because a singular DC motorâs behavior is linearly proportional doesnât mean the system is linear. See the attached Equations of motion for just driving straight if you donât believe me. The Eigenvector solution for the EOM is, by definition, non-linear.
robot EOM derivation.PDF (1.25 MB)
Perhaps, but the steady-state voltage-speed curve of a robot as measured on the ground is, well, very linear:
https://i.imgur.com/r8t3nyq.png
Huh, I never noticed this; I thought there was only PercentVBus - I have only ever used voltage compensation via the ânominal battery voltageâ option in closed-loop control mode. Will edit accordingly.
Paul,
The equations of motion given constant input voltage are definitely nonlinear w.r.t. time. There is no disputing this. But the transfer functions we care about are linear.
The equation we care about for control purposes is the differential equation mapping applied voltage to instantaneous velocity and acceleration. This equation is useful for stabilizing the system (constant velocity and zero acceleration), or for following a feasible trajectory using feedforward terms on velocity and acceleration.
From your notes, the symbols Wmf and Tms, and therefore also Tm and K, are not constant, but rather they are linear functions of the applied voltage. Letâs choose the symbol V(t) for the instantaneous normalized applied voltage factor (where 1.0 = 12V and 0.0 = 0V).
Now we can do a symbol replacement on your equations:
Wmf --> Wmf * V(t)
Tms --> Tms * V(t)
Tm --> Tm(t) --> -Tms / Wmf * Wm(t) + Tms * V(t)
K --> K(t) --> n * GR * Eff * Tms * V(t) / (m * Rw)
If you plug those back into the equations of motion on the end of page 3, you obtain the linear relationship:
(1 + I/(m*Rw^2)) * x_dot_dot(t) + GR*K(t) / (Wmf * V(t) * Rw) * x_dot(t) = K(t) - (Fs + mg*sin(theta)) / m
Let C1 = 1 + I/(m*Rw^2)
Let C2 = K(t) / V(t) = n * GR * Eff * Tms / (m * Rw)
Let C3 = (Fs + mg*sin(theta)) / m
We can re-arrange and get:
C1 * x_dot_dot(t) + GR * C2 * V(t) / (Wmf * V(t) * Rw) * x_dot(t) + C3 =
C2 * Tms * V(t)
The voltages on the left side cancel out:
C1 * x_dot_dot(t) + GR * C2 / (Wmf * Rw) * x_dot(t) + C3 = C2 * V(t)
C1 / C2 * x_dot_dot(t) + GR / (Wmf * Rw) * x_dot(t) + C3 / C2 = V(t)
This is precisely the equation that was revealed by Eliâs empirical testing. The voltage applied to the motor consists of a constant loss, a constant times velocity, and a constant times acceleration. For both the constant velocity stabilization problem and the velocity profile following problem, being able to cancel out the constant term (by applying a voltage offset) is really useful.
Jared,
There is no disputing anything you have said and I have read Eliâs paper.
One point of clarification, though, is that stall torque (Tms) is actually not as linear as free speed (Wmf) is when it comes to its relationship with voltage, especially in real life applications using the FRC motors. Just look at motors.vex.com locked rotor test to see what I mean.
Of course motor voltage as it relates to motor rotational velocity, at a given loading condition, is linear.
This is all well and good at steady state, but not when there are disturbance torques (or forces in the case of drives) and the constant accel and decel during auton specifically.
As I know you know, while the equations of motion are linear, the actual solution for velocity and position over time is not, especially when accelerating and decelerating. Leaving this out for people who donât know these things is a problem for me and I just wanted to highlight it.
I understand that if you just want to use voltage as a measure for robot velocity at relatively steady state in a given loading condition without encoders then the voltage offset is useful. I guess I would never not use encoders and torque control (well, really current control) to better manipulate what I need to make the robot do what I want it to do. To me, the actual current along with the voltage tells the real story.
Like I said earlier, different ways to solve the same problem.
I would like to see in an appendix in the paper Eli published with more detailed data on the tests and test configurations though as the charts in the paper look like they represent summarized results.
EDIT:
The solution for both position and velocity to your reduced EOM is still nonlinear, though.
All data are available in the .zip files linked at the end of the document. The static voltage tests were performed by driving the robot forwards at the voltage given in the file name, then driving back at 30% voltage (we couldnât go fast in reverse or the robot would tip). The quasi-static trials are described thoroughly in the paper, and the acceleration test was performed using a step voltage, which you can get the numbers for in said data.
Now that you describe this, the âwierdâ feeling while driving was probably due to this, and not lag
Apologies for further pushing this thread OT, but why is it significant that the solution to the differential equation is nonlinear? In the context in which it is used (PIDF loops), the equation provides the appropriate instantaneous voltage given a desired instantaneous velocity and instantaneous acceleration.
The simple answer is if you do not size your arm gearbox or drivetrain accordingly, then these equations donât apply as the motor can never get to steady state. I made an Excel Spreadsheet when I did that worksheet I attached. I will clean it up so people can play with it.
To be clear, I am not suggesting that the control schemes are non-linear. I am suggesting the system is non-linear and understanding how the physics relate to how I get this thing moving is important. I should have saved it for a different thread.