DPRG mailing list archives: [DPRG] When to PID?

Fri Mar 16 09:19:51 CDT 2007

It is a tuning challenge. And implementation approach.

There are many many different ways to do PID. You need to pick the one
you think will work best and that you will understand.

I have a friend who has been doing industrial controls for about 20
years and he does not use PID until he gets close to the results he
wants. It is full on or off or a guess at the right number and when he
is within 10-20% he puts the PID in the equation.

I believe David Anderson has PID going 100% of the time in his
implementation, as most people do. His algorithms and code was available
on his website last I knew. His approach and most implementations I have
seen take PID in a broad way. Like if you are stopped the command will
be go forward at x f/sec, or go to x,y position.

I few years ago I talked to some machine control experts and they said
the approach they would use is to figure out exactly where you want each
wheel at every sample, and try to make it be there with PID. In other
ways it is like building a path for each wheel in SW, and making each
wheel be in that exact position every sample. Your path will take into
account ramping up to speed and ramping down to stop. The difference is
more minute control. If you were sampling at 50 times per second then
you would have 50 positions per second that you want the wheel to be in
to get to your speed and destination.

Play around with different approaches and see what you like.

On Fri, 2007-03-16 at 00:04 -0500, David M Wilson wrote:
> Are there any 'rules of thumb' that can be applied to a design to help
> determine if it is a good / poor candidate for software based PID motor
> control?
> 
> These seem like a significant challenge for PID control of wheel RPM
> (measured using BEMF) or for my tuning ability:
> 
> - Frequent wheel speed changes are needed for steering control, including
> 'immediate' wheel stop and reversal.

Wheels and a robot can not do anything immediately. There is inertia. So
everything ramps up or down, it can be fast ramps but you need to know
what your robot can do and try not to command it to go beyond it.

> 
> - If the requested speed can not be achieved at one wheel, slow the
> remaining wheels appropriately.

Again if you are controlling the robot correctly you should not request
a speed that the robot can not attain. Most people run the robot at
50-80% maximum speed to have margin for control.

> 
> - Motors that accelerate slowly and that require a significant reduction /
> reversal of power to halt that acceleration once acceleration is
> established.  There is a significant 'dead zone' in which the power can be
> reduced with every control loop but the wheel will continue to accelerate
> (but at a decreasing rate of acceleration).

Yes.

> 
> - Motors that respond best (fastest) to intentional power overshoots early
> in each acceleration run.  If a power setting of 150 will maintain an
> unloaded 200 RPM, spiking the motor at a power setting of 200 - 250 and
> decreasing the power to 150 as the target speed is reached provides the best
> performance.

That is what PID does. The P term increases the voltage as the desired
goal is farther, and brings it down as the target speed is reached. The
D term adds the spiking you are thinking about.
> 
> - The PID controller can hit peak power while accelerating but it usually is
> achieved by accumulating lots of error and happens too late to avoid a huge
> overshoot.  Or the P gain is so high that oscillations are a sure thing.

Then you are accelerating too fast for your system.
> 
> - It may be necessary to dump accumulated error before each maneuver in an
> effort to speed up transitions but this could result in choppy control.
> 
> - Dropping the 'I' and creating a PD controller creates a system that favors
> a set point of zero.  By design the PD controller cuts power each time the
> error reaches zero and this does bad things to top speed and torque when I
> often need to run the motors full out.

Running the motors full out is not controlling them. It is open loop,
not closed loop.

> 
> - Adding a constant or computed value as the 'base power setting' to the PD
> formula can shift the natural set point but performance isn't very
> consistent at different power settings or loads.
> 
> 
> For the PID experts - does this sound like a tuning challenge or just a bad
> fit for PID?
> 
> David Wilson
> 
> 
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://list.dprg.org/mailman/listinfo/dprglist
> 