OpenServo.com

[mpthompson]

For the last two days I've been working on an alternate, but related, algorithm to PID for possible use in the OpenServo. It's known as ""pseudoderivative controller"" and was invented by Richard Phelan who described it in his book ""Automatic Control Systems"", Cornell University Press, 1977. Unfortunately I don't have the book, but I've read a number of descriptions of it on the web.

The algorithm claims to have some nice features such as resistance to overshoot , smoother response to command inputs and better response to load variations. The specific implementation below is based on the description at this web page:

http://users.erols.com/jyavins/servo.html

Is anyone else familiar with the ""pseudoderivative controller"" algorithm? I would very much like to compare notes to validate my understanding of the algorithm.

Below is a link to my initial implementation of the algorithm. Unfortunately, it suffers from some problems that still need to be ironed out, but I thought it would be useful for others to look over the code if they are familiar with the algorithm.

http://www.openservo.com/code/ipd_example.txt

Comments welcome...

-Mike

[mpthompson]

Ahhh. Major conceptual breakthrough tonight allowed me to finally understand all the knobs and levers of the ""pseudoderivative controller"" algorithm. A one line change to multipy the command_error by the position_gain fixed one of the major issues I was running into. I updated the link below with the latest code for this algorithm.

http://www.openservo.com/code/ipd_example.txt

Another big remaining issue is my specific implementation has far too much 32-bit arithmetic in it. This is a big no-no on the AVR which only has 8-bit ALU instructions. This makes 16-bit math slow and 32-bit math painfully slow as well as bloats the code. This is what I'll be fixing next.

Onward...

-Mike

[guru]

How is the servo response/performance for this algorithm? Do you find it is better than the PID implementation.

C

[mpthompson]

I'm still gathering data to determine the response of the servo using this algorithm. With PID, it was pretty easy to tune the algorithm to a specific loading on the servo, but when the loading characteristics changed (i.e. more intertia) the servo had to be re-tuned for acceptable performance. I'm assuming this is why auto-tuning features of PID gains are an important feature of commercial digital servos.

My hope is the IPD algorithm responds better to a broader range of loading characteristics because a kind of ""self-tuning"" is inherent in the algorithm. The gains aren't dynamically changed, but the servo is entirely driven by the integral component with the goal being to ramp up the integral component just enough to hold the load. PID is actively driven by all three components -- proportional, derivative and integral.

This IPD algorithm is noted for the fact that it will be a bit slower responding to large command changes because the output isn't immediately driven to saturation, but this is supposed to be made settling quicker to the command position than PID. There are also feedforward techniques to compensate for this which I have yet to explore.

-Mike

[dsandber]

Hey Mike,

Any news with this alternative algorithm? I'm about to start playing with OpenServos to see if I can fix my ""humming under load"" problem I have with standard servers.

My intuition is that the hum is caused by the 30Hz refresh. I'm guessing if I can make the refresh rate fast enough I won't hear any hum. I'd imagine an OpenServo tuned with the correct PID parameters will fix the problem.

Any thoughts?

Thanks,

-Dan

[wurpfel]

Hi Dan

the ""humming"" comes from the low refresh-rate: a force on the servo deflect the position between the refreshs, then the servo react. that`s generate a nose with 50Hz..

the new ""digital"" servos use a simple trick: the generate additional refreshs. that`s all about digital
this ""brute-force-way"" has some negativ sides:
the servo make MORE noise/humming as a analog one: the digi-servo-fellas use PWM with 4-8kHz, that can you hear better than 50Hz
the currentdraw is exponently higher than analog servos
often a to aggressiv PID-setting of the motorcontroller will overheat the device, also the servos can overswing the target-position

in my RCsystem I use the half, 8-10ms, of the standard 20ms refresh-rate without backdraws. It`s a quick`a`dirthy methode.


for ""no"" noise under load you have to use:
PWM with 20-30kHz
addapted PID-controller
monitor the motor-temp
maybe a deadband or a selfstopping gear, like a screw



I`m new on open servo and think most of this features are included



maybe a hint for 32bit arithmetics
in older days people used logarith-tables.
simple methode: you look in the table for the difficult part of the quotation.
often a lookup-table in the AVRmemory solves time- and performanceproblems
_________________
not to old to play with scrap

[ginge]

Hi all,

You are indeed correct saying that most of the features are implemented in OpenServo. In CVS there is IPD support, although I have not tried it personally.

There are also deadband support features, and also on the fly PID tuning.
There is no motor monitor temp support (yet?) but you can monitor current draw and voltage levels to get a feel for the motor loading.

There has been some discussion about the PID algorithm which is currently in review. http://openservo.com/Forums/viewtopic.php?t=226

Anything you could bring to this would be great.

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

[dsandber]

Hi Ginge,

Thanks for the reply.

I don't see why a higher refresh rate would lead to the motor overheating. To keep the motor at a constant place with a 25 Khz refresh rate should require a constant, but small amount of current, like .25A or so, no?

Anyway, I'll let you know if the OpenServo melts

Happy New Year Everyone!

-Dan

[wurpfel]

hi folkz

most of the servomotors consume at low rpm`s a huge rate of amps, due of the weak counter EMF.
a ""goofy"" configuration will melt the motor
servos that`s act against gravity, like a mass on a lomg arm, are prone to fail. the servo has to by oversized..


Happy New Year Everyone too!



PS
25kHz is not the refresh rate but maybe it`s helps to limit the holding current.
_________________
not to old to play with scrap

[dsandber]

Because of the gearing, it seems like the average current needed to keep a servo arm still against gravity can be quite low, like .25A. I don't think a current this low would overheat the motor, but we'll see. I know people use servos as drive wheels for robots, which require continuous operation...

Anyway, I'll experiment and If I melt it I'll let you guys know

-Dan

[Zeddicus]

Hi all,

just wanted to say that the IPD (or pseudoderivative) algorithm is described in my theory document. Its resitance to overshoot stems from the fact that the derivative is taken from the position, and not the error. That means that a change in reference, which would mean an abrupt change in the error and its corresponding peakage in the derivative, will not occur, which is good. The down side is that it is a bit slower to follow the reference (which also helps its resistance to overshoot).

Personally, I don't really like it cause of its slowness. I rather use the DPID or ZPID equations, and in my experience they give better results and behaviour (specially the ZPID).

Cheers,
ZZZ

----------------------------------------
Zedd? Zedd's busy working right now

[dsandber]

Ok, I'll bite

What's ZPID? Yes, I checked google.

Thanks,

-Dan

[ginge]

ZPID normally refers to Zone PID. I don't know how it works, but there is some info here:-

http://www.motionsystemdesign.com/Zone/Article/25021/Tuning_servomotors_with_PID_loops.aspx

It's actually a pretty good article

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

[dsandber]

Cool!

Thanks for the response on this as well as on the 3.3V to 5V I2C shifting.