OpenServo.com

[dsandber]

Looking at the pid.c file, I noticed that the IGAIN doesn't seem to be used. The relevant lines seem to be:

pwm_output += (int32_t) p_component * (int32_t) p_gain;
pwm_output += (int32_t) d_component * (int32_t) d_gain;

Am I looking at the wrong file or are we really ignoring the integral component of the PID loop? Isn't that necessary for the absolute position to be accurate ( lest the PWM doesn't ramp up enough from the P and D components )?

-Dan

[ginge]

Dan,

You are correct, there is no I calculation on the controller, making it a PD controller.

When Mike wrote the algorithm I believe he had some problems with using the integral term in the calculations.

I have started a new -dev branch of OpenServo in CVS that will be looking at these issues in due course.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[dsandber]

Eeks, I'm surprised people haven't found this to be a problem. This makes it very hard to avoid little positioning errors unless the P term is very large. And if it is, it's hard to avoid crazy oscillations. Hmm.

[ginge]

It hasn't been a major problem up to now because the servos don't generally carry a massive load over large distances. Hobby servos also move so fast as to not be a problem.
You might see some oscillation around the destination point unless you tune the PID nicely, but there is a deadband that takes care of some of that.

Integral windup is also a rather annoying problem when trying to tune the servos, so the I term was omitted for tuning sanity.

There will be a new, more advanced algorithm in the V3 code base that I will backport when ready,

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[DavidCary]

[robotjay]

DSandber,

Like Barry said, the I value will have little impact on the loads that a hobby servo can carry, but we are still working on making it a useful value to set.

Here's the way I've been tuning the OpenServo (Barry please comment on this method):
-Set P, I, and D to zero.
-Set P to a small number and command the servo to move to an arbitrary position.
-Typically, the servo will move to the commanded position (slowly, when the P value is low.)
-Continue to increase the P value until the servo begins to oscillate around the set point indefinitely. (Basically, find the lowest P value that causes the servo to go into indefinite oscillations.)
-Increase the D value until the servo settles in an appropriate amount of time after a move. (The higher the D value, the slower the servo moves, so you will have to determine an acceptable level of trade-off.)

David,

A perfect auto-tuning algorithm seems to be the holy grail of motion control. You are certainly welcome to investigate further, but even high-end, industrial servo controllers with so-called auto-tuning, don't work accurately under all loads. This has actually been discussed in another thread here. The consensus from that thread was that the best solution to implement was to use look-up tables for certain conditions, and adjust the gain values accordingly. I don't know your technical background, but maybe you can shed some new light on the subject... For my limited applications of the OpenServo, using the above tuning method seems to get the servo to work consistently across most small loads, even vertically against gravity.

-Jay
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."

[ginge]

Jay, David,

The Tuning of the servo is relatively simple. The method the Jay posted above is appropriate and correct. There are several ways to go about tuning, and the method above uses no complex math to get it right, and often gives the best results.

David,
Yes, autotuning would be nice. Jay is correct in saying that it is difficult to do this automatically for each application and load.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[jharvey]