# [ODE] Better way to find 'Desired Velocity'

Andrew Schroeder schroe2a at gmail.com
Fri Jan 28 13:47:19 MST 2005

``` Before you mentioned it, i'd never heard of a PID controller at all.
I've spent the past couple hours reading up.
Maybe some of you who understand both ODE and PID controllers could
help me relate what I've learned about PID's to how they could be
useful in ODE Joint control...
I think the controller in the servo approach in the ODE Wiki FAC:

DesiredVelocity = -Error * Gain

is like a PID controller where only the 'I' part is set to Gain, and
the 'P' and 'D' params are 0.  This makes sense because the above
equation is what they give for a 'I' only controller, and the behavior
typical of a PI controller what we see from the above servo model.
The problem with a PI controller is most evident when the 'deadtime'
is high.  For us this means that the max-force is low and it takes
awhile to get up to speed. (or to stop) To deal with this a PID
controller would set a 'D' or Derivative control element which removes
another term to the servo approach:

DesiredVelocity = -Error * iGain + dGain * (Error-ErrLast*2+ErrLastLast)

or something like that.  Here the new dGain value would be the 'D'
part of a PID and would serve to slow down the body sooner by keeping
track of how much the error is changing.
Does this make sense, and is it consistent with the your
understanding of a PID controller?  Anyone have a better guess at the
correct way to do the above equation?

Further clouding the issue for me is the fact that our Process
Variable is Position of the body, but we only actually effect the
Velocity, (and even that indirectly by setting a desired velocity and
letting the joint motor bring it to speed.)

Finally, if I am on the right track with adding the dGain term to the
DesiredVelocity equation, wouldn't a good value for dGain be related
to the maxForce of the joint?

Thanks,
Andy

On Fri, 28 Jan 2005 10:15:30 -0600, Royce Mitchell III <royce3 at ev1.net> wrote:
> Andrew Schroeder wrote:
>
> >Hey ode'ers,
> >I'm beginning to think that the key to creating believable simulations
> >of living beings (non-mechanical stuff) is realistic motion control.
> >By that I mean that it comes natural to create believable cars, robots
> >& other machines using a physics engine like ODE, but when I create a
> >person it behaves like a robot because the motion is controlled by
> >simple joint motors.
> >  I think I need to come up with a better way to figure out what to
> >set Desired Velocity (setparam(vel)) to.  Better I mean than the
> >"servo" section in the ODE Wiki FAC.  I'm finding that I want to have
> >my simulated joints move bodies to a desired position-as fast as
> >possible-without overshooting(much)-using only the max force allowed
> >to do it.  Thats what a real person does when he/she moves an arm to a
> >desired spot, for instance.  I'm having real problems figuring out
> >what to set desired velocity to get to that position.
> >  In the servo model from the FAC if your 'gain' is to low, you're
> >bodies move to slow,(like a robot)  but if you set it higher they
> >overshoot the target back and forth before settling in the desired
> >position. (which looks like your person is intoxicated or something)
> >I keep coming back to the problem: "How fast can I go toward my target
> >and still be able to stop when I get there using the max force i am
> >allowed?"
> >
> >My approach has been to use joint motors and calculate the desired
> >velocity to get to the desired position. Here are the problems I run
> >into when I try to do the math for this...
> >1) I can't always figure out "current angle around given axis." or
> >"distance from target."  When using uJoint, hinge or aMotor in Eular
> >Mode I can use dGetAxisAngle, but if I have an aMotor in usermode I'm
> >not sure how to figure out how much I've rotated around a given axis.
> >works fine unless you want attach a body to the static environment....
> >2) The math requires knowing the "max force" you're allowed to use,
> >and you can get this from the getparam(Fmax), but this is the force,
> >not how much you can accelerate/decelerate factoring in Mass,
> >rotational inertia, and whatever other forces are going on at the
> >time.
> >3) I run into a special case for: if you can get there in one
> >timestep, you can overshoot in one step and then overshoot back then
> >next step, and you get jitter.
> >
> >Has anyone else developed an approach to these challenges?  Am I going