I am interested in techniques used to calculate the F coefficient when you have a system you can’t run at full speed or constant speed for very long (like you can a drive system). An arm or a lift system, for example. I have ideas, but I wanted to get inputs from those who have done it before so I’m not re-invent the wheel.
I’m by no means an expert on PID, but from my experience and from what I’ve seen on CD usually FRC teams only use a F coefficient for velocity loops, not position loops. I’m sure someone from 971 or 254 can give you a better answer that covers exactly when you want to use one, but that’s the general pattern that I’ve seen around these parts.
A feedforward gain is useful if you are doing velocity control, motion profiling, or compensating for some known external force (e.g. gravity). The latter two applications are applicable to an arm or elevator system.
While a constant velocity test is the simplest way to calculate this gain, it isn’t the only way. The first step is an initial guess. This is usually pretty easy…All you need to do is figure out the free speed of your mechanism by looking at your motor specs and effective gear ratio (and compensating for efficiency losses if you want). Kf = Full power / free speed. Once you have this guess, come up with a couple reference motion profiles to test and use a controller to follow them using only feedforward gain. This won’t be precise or robust of course, but it should give you a way to figure out if you require more or less. Iteratively tune your feedforward gain until you are tracking various profiles closely. Remember, it doesn’t have to be perfect…That’s why we use feedback.
1 Like
When the range is limited, I like to manual throttle the mechanism (arm) up and down while plotting both throttle(motor-output) and sensor velocity. The first guess for fgain is then just me ball parking the ratio between the two from the plot. Also it’s cool way to watch the sensor work.
If I remember right, your team uses LabVIEW, so throwing in a plot in the relevent VI should be pretty quick if you wanted to try this out.
Thanks for the pointer Jared!
I was trying to remember where I had seen that information before so I could translate it into something I had a good grasp on.Then I remembered where, in the Software Guide for the Talon SRX. Here is a quote of the actual text from section 12.4.2 (for Java) on page 76.
12.4.2. Velocity Closed-Loop Walkthrough – Calculating Feed Forward– Java
Now that we’ve confirmed that the position/speed moves in the positive direction with forward
(green throttle), we can calculate our Feed-forward gain. According to Section 17.2.1, our
selected sensor uses 4096 native units per rotation. That means our measurement of 1366RPM
scales to 9326 native units per 100ms. This is also calculated for you in the Self-Test.
Velocity is measured in change in native units per TvelMeas= 100ms.
(1366 Rotations / min) X (1 min / 60 sec) X (1 sec / 10 TvelMeas) X (4096 native units / rotation)
= 9326 native units per 100ms
Now let’s calculate a Feed-forward gain so that 100% motor output is calculated when the
requested speed is 9328 native units per 100ms.
F-gain = (100% X 1023) / 9326
F-gain = 0.1097
I also wondered where the “1023” came from and then I realized it is the resolution of step in the drive signal.
When you are doing this tuning with the feedback off, make sure to do some short and long moves, especially on systems (like drivetrains) with lots of friction or other nonlinearities. You want to make sure you aren’t over-fitting some specific motion. I worry more about making sure the shape of the acceleration is correct than making sure it matches perfectly.
It is possible to do the entire feed-forwards tuning and calculation from models, but that takes more math. That’s how we did all the feed-forwards this year, and it worked really well.
Thanks to all. Just the kind of input I was hoping for. Very useful. We’ll be working this next week at practice.