[ODE] hexapod walking example

[Kenneth Holmlund]

I remember Karl Sims writing that his creatures were specialists
in exploiting imprecision, errors and bugs in the code.
It seems that such problems often propagate and become enhanced
in an evolutionary algorithm.

I would suspect that a toolkit like ODE (or Vortex/Karma) that
focuses on real-time performance could run into problems with
this. I know Karma has been used in "virtual creature" projects
(was it Tom Ray?), but I don't know much about the results of that.
Perhaps someone can provide me with a pointer to those articles?
Does MathEngine still have people working on these things
(i.e. Colm Massey)?

/Kenneth

Nate W wrote:

>On Thu, 27 Dec 2001, Adam Rotaru wrote:
>
>>  Those who are interested in using ODE to simulate articulated
>>creatures might be interested in my first little attempt, and, might
>>be able to help me with some problems I'm having.
>>
>
>That's exactly what I'm using ODE for.  Or what I will be using ODE for in
>a week or so, if all goes well.  Right now my articulated creatures have
>no muscles.  They do collapse in a very believable fashion, though. :-)
>
>>The desired position of each leg is modified according to the pattern,
>>and torques are applied proprtional to the deviation from the desired
>>position.
>>
>
>In a nutshell, something like this?
>
>error = (desired_position - actual_position)
>torque = gain * error
>
>That feedback function is something I expect to be adding to my app in a
>day or two.  If that doesn't work for my app, I am considering integrating
>the error over time, so the feedback function will have a proportional
>term and an integral term, like this:
>
>prop_error = (desired_position - actual_position)
>int_error = int_error + prop_error
>torque = (prop_gain * prop_error) + (int_gain * int_error)
>
>The "int_error" variable needs to be preserved across calls to the
>function, and there needs to be a separate int_error for each joint.
>
>The idea behind the integral term is to make the feedback increase over
>time if the joint remains deviated from the desired position.  Tuning
>feedback functions is basically a matter of trial and error, but the
>integral gain should probably be about 1/10th of the proportional gain, to
>start with.
>
>>- I had to apply large torques to support the weight of the body.
>>However, when a leg is unsupported, it moves very quickly due to the
>>large torques.  Sometimes the bug falls apart, which I attribute to
>>the large torques.  Smaller steps help here.
>>
>
>Stick with the proportional feedback fuction and try this... set two gains
>for the feedback equation, a small and a large.  When applying torque in a
>direction that would lift the body, use the large gain.  When applying
>torque in a direction that would left the foot, use the small gain.  
>Hopefully this will keep the legs from flailing too much when they're
>being lifted, but you'll still have enough power behind them when they're
>being pushed downward to lift the bug's "torso."
>
>Like I said, I haven't gotten to this point in my own app yet.  I can only
>tell you what I'm going to try, so I dunno if these will actually help.  
>If all goes well I will be adding feedback control to the joints of my own
>critters early next week.  If you get a chance to try these ideas sooner,
>I'm VERY interested in hearing how they work for you.
>


-- 
Kenneth Holmlund
Director VRlab
HPC2N, Umeå University, Sweden
holmlund@hpc2n.umu.se
T: +46-90-786 9655
C: +46-70-631 5520