Identifying Oscillation

I currently have a semi-working solution for a gyro algorithm for my biped bot.

The system works by working out how far from the stable position the bot is and sending a command to bring the bot back into correct range. Pretty standard stuff.

Occassionally, as I have seen others mention, it goes into an oscillation which amplifies till the bot falls over…

Has anyone a suggestion as to how to identify in code that it is in an oscillation.

I have considered tracking the last few corrections to see if it is alternating between forward and backward but it seems too simplistic.

Perhaps simply looking at “forwards” and “backwards” might be too simple, as you suggest, in that it would detect successive dampening as an oscillation as well, and kill off its own potential corrections. If you compared the intensities of the forward and backward corrections on successive cycles, or over a longer period, you might be able to distinguish positive feedback (tending to knock it over) from negative (tending to correct), and only damp off the oscillations if positive feedback is detected, while leaving negative alone, to self-correct.

Each time I take a reading it is recorded in the form of an offset to the stable position which results in a seqeunce of numbers either pos or neg.

The larger the number, the greater the correction.

I have covered the obvious ones i.e.

if the pattern is ±±±+ or -±±±± then its oscillation

The problem is that a slow servo movement gives a good resistance to oscillation but fails to respond to quick changes on angle. A quick servo movement responds well to changes in angle but causes oscillation.

While writing this (very therapeutic) a thought has occured. The solution may be to apply a dampening movement automatically, regardless of whether oscillation is occuring.

The oscillation is caused by the servo stopping suddenly after a severe movement. Answer: don’t make severe movements. Only send a partial correction and let it make successive movements to build up the correction.

Your comments are right on the mark Seamus, without keeping an exact record of what each movement was for, the dampening movements become part of the problem.

I may also keep a track of peak intensities both pos and neg and see if the corrections are increasing.

I have deliberately set “STABLE” as being a value close to but not quite what the bot normally stands at, so that normal servo chatter doesn’t trigger a movement.

That is a thoughtful and worthy attempt for a solution via software.

Any chance you can lower the center of gravity either through downward frame shift or perhaps added lower mass? This will also dampen any oscillations.

I was just reading about oscillations in closed loop control systems and PID (Proportional Integral Derivative) controllers (Wikipedia also has a pretty decent intro to them), they might be the kind of thing you’re after. The parallel form is easier to implement and ‘tune by feel’.

If you google for “Heater Project by Mike Pearce” (I can’t post a link in my delurking post), you’ll find some C code for a simple PID (main.c, Calculate() function) which might be a useful start.

PIDs do need a bit of tuning to avoid oscillations (Loop tuning on Wiki) as well.

Cheers, and best of luck!

I’m gonna get back onto this ASAP. Due to a quirky problem, my Atmega128 fuse bits got locked out and I couldnt program it. Thanx to the guys at AVRFreaks Ive managed to unlock it and can get back to some more serious stuff soon.

Nice adjective. 8) :laughing:

Another snippet on PID

societyofrobots.com/programming_PID.shtml

The oscillation, or “Hunting” is something I had with my RC chopper. What about deceleration with the correction algorithm? Perhaps you can add a small deceleration before the bot reaches the “stable zone” to Keep it from over shooting.

I have seen videos of large biped like ASIMO be pushed but it had a sort of “denounce” reaction causing it to be smooth.