My team is attempting to tune a PID on a Falcon 500 using Phoenix Tuner. Our problem is that, for whatever reason, it either oscillates or doesn’t move at all. Numbers above ~0.01 oscillate and numbers below it cause the motor to not move at all. Are we missing something?
First, you need to see the ‘applied output’ that is being provided to the motor. Depending on your units and factoring, you might be talking about having to have a P of .0009222. The size of the P depends on the units.
THEN you can start tuning your pid by starting tiny and increasing it. Watch the applied output (the actual output the pid controller is sending to the motor).
You may want to also include a static friction term to your PID output, so that you add a small voltage in the direction of your target position to overcome friction.
Typically this might look like V(\epsilon) = k_{\text{friction}} \text{sgn}(\epsilon) + \text{other PID terms} (where \epsilon is your error)
I’m not sure I understand what you’re talking about. We’re tracking the applied output and it oscillates with the position of the motor, just as you’d expect. Also, P is just a constant, it doesn’t have a unit, right?
We have never had to account for friction before and it seems like that would be negligible. Also, we’re not doing the math ourselves, so I don’t think that’s within the scope of possibilities. I feel like this problem is just being caused by us overlooking something, not a problem with the math.
A P gain has units of “output/error”. For example, volts per RPM.
CTRE, for example, chooses units which make these gains quite small for most applications.
I wouldn’t actually expect the applied output (“control effort”) to oscillate too much. Assuming you are tuning by hand, Keep dividing P by 2 until it stops oscillating.
Additionally, to help rule out hardware issues, how does your measured sensor signal look? Does it increase with positive control effort? Is it smooth, not noisy? Is it numerically correct to what you are observing?
Gerth explained it well. P for one mechanism might be 1. P for a dissimilar mechanism might be .000001.
I suspect you are changing your p values by too much when you are tuning.
What you’re saying makes sense, but we’ve tuned these before and we haven’t had to go anywhere near that many decimal places. Maybe that was just luck. We’ll try being more precise when we go in tomorrow.
When you refer to the measured sensor signal, I want to assume you’re referring to the Falcon’s internal sensor, but I am beginning to see that my knowledge in this area is extremely limited. As we tuned the P value we watched the graph on the plot tab which showed us that the sensor reflected what was actually happening, which was that the motor was oscillating. When the motor was in motion, it appeared relatively smooth. Is that what you’re asking?
You are using a feedforward, right? If not, you need to. It cannot be omitted for velocity control.
If you don’t change the default velocity filtering settings you’re going to have a hard time finding a feedback gain that is both stable and provides substantial disturbance-rejection.
Granted that I don’t know what a feedforward is, I doubt we’re using it, although we’re using this for position control, not velocity. I also don’t know what velocity filtering is. This has all been very humbling.
Ah, if you’re doing position control you can disregard that. You should still learn what a feedforward is.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.