Thread: PID Tuning Help
View Single Post
  #19   Spotlight this post!  
Unread 23-02-2015, 07:57
Ian Curtis Ian Curtis is offline
Best Available Data
FRC #1778 (Chill Out!)
Team Role: Engineer
 
Join Date: Feb 2005
Rookie Year: 2004
Location: Puget Sound
Posts: 2,521
Ian Curtis has a reputation beyond reputeIan Curtis has a reputation beyond reputeIan Curtis has a reputation beyond reputeIan Curtis has a reputation beyond reputeIan Curtis has a reputation beyond reputeIan Curtis has a reputation beyond reputeIan Curtis has a reputation beyond reputeIan Curtis has a reputation beyond reputeIan Curtis has a reputation beyond reputeIan Curtis has a reputation beyond reputeIan Curtis has a reputation beyond repute
Re: PID Tuning Help

Quote:
Originally Posted by jwhite View Post
Again, for more completeness, where should you start? We mostly gave up on trying for PI controllers, because we found that even apparently small values of I led to instability. (The 1114 guide to PID tuning suggests PD; a bunch of smart people I know swear by PI. I have no real experience other than sitting with students trying this for a few nights in a row).

We successfully tuned one with I, but only when our I was several orders of magnitude less than the P term.

Is there a rule of thumb? Start with an I that is X of P, and then increase slowly?

As a side note, if you're tuning I, one of the challenges you may face is that the smart dashboard allows a tiny number of significant digits. (Afair, the lowest we could go was 0.001). We ended up making a scaled pid output just to get around that problem.

And, again, any rule of thumb? As we were tuning PD, we tended to start D at the P value, or perhaps below, and then gradually increased from there.
The great thing about PI controllers is that they will drive your error to zero, and are relatively robust. Imagine trying to stay 100 feet behind another car using a P or PD controller to press the accelerator pedal. You will never reach a steady state -- when you have zero error and zero acceleration you won't be pressing on the accelerator! On top of that, real world signals are noisy - differentiating them makes them even noisier, and filtering slows them down. This doesn't make them unworkable -- just not always desirable.

I stay on the mechanical side of FIRST robots, so I am somewhat clueless as to the implementation in the default code. What are the units on the integrated error? Is it error*frame or error*second? error*frame would be a much larger value, and explain why you need such a small value for Ki.

The answer is often integrator management. This means, when the integrator is not helpful, you turn it off. The great thing about integrators is that they will do everything in their power to satisfy the command. The bad thing about integrators is that they will do everything in their power to satisfy the command. A step command of the full length of the field is going to wind up the integrator. Your robot can't satisfy the command of being 54 feet away in .1 second. One way to avoid this is to not command 54 feet in .1 second, instead ramp it in over several seconds. See this post by Ether. Another way to is to shut off the integrator for most of the travel -- just start counting when you are close to the final value to make sure you achieve the commanded position. Or you limit the integrator's authority to some fraction of the maximum command.
__________________
CHILL OUT! | Aero Stability & Control Engineer
Adam Savage's Obsessions (TED Talk) (Part 2)
It is much easier to call someone else a genius than admit to yourself that you are lazy. - Dave Gingery