[ODE] Servo to reach a target position

[Royce Mitchell III]

> I realize that the P parameter only affects how fast you are going.  The
> question is whether that speed is measured in units per *step* or units
> per *second*.  Without ever factoring in dT, there's no way it can be in
> units per second.  And being in units per step means that you get
> different results with different step sizes, what using dT was meant to
> avoid in the first place.

Actually it is in units per second. I actually made a mistake in the
example code I sent you, now that I think about it.

It should have been this:

velocity = pid.StepPosition ( ... );
position += velocity * dT;

Of course, that's not taking into account things like Fmax, which
would be easy to simulate. You'll notice that make that change to the
sample code doesn't break the position control. It might make it
unstable, though, which means Kp is too high.

After reading Russ's e-mail, I agree with him almost completely.
However, there is an area that PID control would help in ODE that I
don't think Russ has a provision for: controlled stopping. Please
correct me if I'm wrong, but I don't think there's a way of telling
ODE "I want to stop at exactly position X". A PID control algorithm,
feeding desired speed into the joint parameter, would allow you to do
that. FMax will cause your acceleration to look realistic, and the PID
will cause the deceleration to look realistic. In RL, I never worry
about the equivalent of FMax, because there's a physical factor
limiting the output of the device from achieving my requested output
instantaneously. I give it the output I want it to have, and the
machine gets there as fast as it can. If it turns out I'm asking it to
get there too fast, that's not a failure of the PID loop, it's a
failure of my Kp parameter being too high.

I would write a demonstration app, but I'm currently in the middle of
a huge project ( the reason I haven't had a chance to play with ODE
more, yet ). Perhaps if someone could throw together a test app that
causes a car to drive forward X units and stop on the dime without
lurching every time you hit the space bar...

> Yeah, I looked at the joint source again and fmax doesn't affect stops, so
> this probably won't work well for most situations, since there are no
> limits at all.  Not being able to limit speed was already pretty bad as
> you pointed out.

For controlling the speed and position of your tires, I wouldn't
suggest an external P, as Russ's code does a perfect job, I'm sure.
For controlling the position of your car ( using those tires ), I
think you'd probably need the P to stop exactly where you want. For
the human player you likely don't need the P loop, since the human
player is controlling the object, but for AI objects, you might find
the P loop very handy.

Now that I think about it, it's not speed, generally, that's limited.
We have a maximum output that we can send, which equates to a specific
maximum speed that we can achieve. I know this is a fine point, but
there are situations where this is not limiting the machine to an
exact speed. For example, if there's a clutch in between the motor and
the load, then the maximum output will result in different speeds
based on the clutch's position. Hmm... this is an interesting thought.
If you're doing a racing sim, you might want to have a manual
transmission, including the varying levels of power at different
combinations of RPM & gear.