Simulation step size
Marko Srebre
I was very exicted when I read the paper about "Generalized Biped
Walking Control" and watched Cartwheel-3d presentation videos. So
before anything else, let me thank you for your efforts, publishing
the sources and sharing your knowledge.
As a hobby project (I am otherwise an IT professional, so this is
mosty for my amusement) I also work on some sort of dynamic character
physics based animation, though it is much more alpha quality and
clearly not so well structured yet as your project. I also used ODE as
a forward dynamics simulaton, however, to control the character I
implemented floating-base inverse dynamics (as in R. Featherstone,
RBDA). As of this time, I have yet to implement any advanced balancing
and walking algorithms (I look forward to try some of the ideas about
"Inverted Pendulum Foot Placement" and "Velocity Tuning").
Now, I noticed both in code sources and your paper that the simulation
step is 0.0005s. I have not managed to compile your code (I'm on GNU/
Linux), so I couldn't test other step sizes. I guess this small step
is necessary to ensure correct behaviour of PD controllers.The inverse
dynamics that I use works very well at 0.016s (60hz). Of course, I am
probably missing much of the whole picture (no balancing/walking), so
it just may be that some other algorithms are the ones in need of a
small simulation step. Would you mind commenting on other step sizes
that you used, the results you obtained and the "bottlenecks" for
simulation step size?
Cheers, Marko
Philippe Beaudoin
Thanks for your kind words. It's great to see people using the project.
Our small step size is indeed required to handle most situations. This
is due in part to the PDs, as you correctly identifies. We think
building the PDs into the forward simulation step (as can be done with
ODE) would probably help alleviate the problem. There is a bit of
stiffness in the other feedback components discussed in the paper as
well. We haven't explored the interplay between these components and
have not spend time optimizing the application.
That being said, I think being able to run 50 dynamically balancing
bipeds in real-time will need more than simple optimization. I
encourage you to keep exploring your Feathersone-based approach. If it
lets you crank up the time step even when you add the balancing
feedback components then you very well might be on to something!
Don't hesitate to ask other questions and please keep us updated on
your progress.
Cheers,
Philippe
Stelian Coros
This is a very good question! The PD controllers that we use act like
explicit penalty torques, which pose a constraint on the simulation
time step. Lower frequencies would sometimes lead to numerical
stability issues. That's the reason why we run our code at relatively
high frequencies. With more careful tunning of the PD gains, we could
lower the simulation frequency to about 500Hz, though this may result
in a loss of robustness.
Using inverse dynamics is one way of potentially bypassing this issue.
It is not without problems though. The contact and friction forces
(which are of course influenced by the torques that are to be applied
at the joints) need to be known (or estimated) before running the
inverse dynamics algorithm. The paper Data-Driven Biped Control
(Yoonsang Lee, Sungeun Kim, Jehee Lee) investigates the use of inverse
dynamics for control purposes, though the simulation still runs at
900Hz. This is probably because contact forces are computed using
penalty methods first, and then passed into the inverse dynamics
algorithm. I am wondering if the control framework would still work
well if one just used the (LCP-based) contact and friction forces
computed at the previous time step, in conjunction with much lower
simulation frequencies.
Anyhow, this is an issue well worth looking into. Do let us know if
you make progress on this - we are always happy to talk to other
control enthusiasts.
Cheers,
Stelian
On Tue, Oct 26, 2010 at 1:46 AM, Marko Srebre <marko....@gmail.com> wrote:
Marko Srebre
It's a "cheat" I used and it seems to work well enough (both with
dWorldStep and dQuickStep). When I say well enough I mean that the
character will easily straigten itself if commanded a standing
position, compensating for his own weight (contact forces of the feet/
ground). Of course, without true balancing this is achieved by giving
the character some "god" torque in root node to keep him from falling
aside. However, no god force is applied against gravity, so the
standing stance is the result of inverse dynamics compensating CF.
This also works well if character is fed a premade run-cycle animation
as desired joint-transforms; you can see the character really pushing
off the ground, though the whole locomotion is horribly awkward since
god torque keeps the character upright, not the true running balance.
Of course, it still has to been seen how this wil work (if at all)
with correct balancing. I will certainly keep you posted.
Cheers, Marko
Marko Srebre
I wanted to report on some of the progress. I managed to implement COM
control and some basic foot placement. The character can do two
things: double stance, walk in-place (at least 20 minutes tested :) ).
However, I had to bump the step size to 600hz, which I am not very
pleased with, as I was hoping for a more realtime solution with many
characters. I still have some tricks I wish to try, but have yet to
find the time for that. My poorly "educated" guess for now is that I
won't be able go lower than 200/300hz. The single bootleneck seems to
be external contact force feedback (gathered from previous ODE step).
The lower the frequency, the less stable the foot contacts; oscilation
occours. I was considering some sort of contact force estimation, but
have no idea where to start or if that would be helpful at all. I also
considered CF feedback filtering, but this introduces lag and
uncertainty... Perhaps you have some experiences that might help?
Anyway, your implementation has been of great help. There are some
differences though when using ID. Desired COM can be controlled by
either controlling desired acceleration of stance foot (not so good,
but works), or by controlling the external force on stance foot
(better, more responsive). The latter works so that virtual force on
COM is computed and the opposite applied to stance foot as external
force. The ID algorithm then compensates this "virtual" external
force, which in effect probably works just the same as jacobian
transpose method.
I noted in your code that IPM prediction dx and dz are multiplied by
some constants. I guess this is to better "hit" the target as the foot
may have some delay?
I'm hoping to provide a video, but at the moment I am still strugling
with video capture tools on Linux.
As always, I am glad I have someone to talk about this. It is really a
narrow field, at least it seems to be so here. I still have much to
talk about (the structure, components, API ideas of such a control
framework etc.), but will have to wait for another time.
Cheers,
Marko
Stelian Coros
It's really refreshing to see your enthusiasm on this topic! You are
definitely getting to some topics that we don't know how to solve
properly either, but here are some of my thoughts anyway:
> However, I had to bump the step size to 600hz.
I've gotten as low as 500Hz, using more or less the method presented
in the paper, but the simulation tends to get unstable if we go lower.
Perhaps using a different physics engine would improve things? I've
heard in passing that PhysX uses simulation sub-steps for each main
simulation step
(http://grail.cs.washington.edu/projects/loco/loco_paper.pdf). I don't
know what goes on in there, but it may provide better approximation of
friction forces. An alternative is to try and completely (or to some
extent) ignore the contact forces when doing the ID. By itself, this
wouldn't work, of course, but with the Jacobian transpose control, it
may work well enough. When we compute the torques using PD control, we
ignore the immediate effects that the contact forces have, and treat
it as tracking errors that we attempt to fix at the next time step, so
my guess is that should work ok.
> I was considering some sort of contact force estimation, but
> have no idea where to start or if that would be helpful at all.
This should definitely help. The problem is that I think it's a really
hard. I am sure you can do it well enough for steady state walking,
but that's not really what you need simulations for anyway. I
personally wouldn't want to spend too much time into this, as I don't
see a reasonable solution emerging. I've been wrong in the past
though...
> I also CF feedback filtering, but this introduces lag and
> uncertainty.
This would certainly help, and should be relatively easy to do. I
would filter the net force and net torque due to contact forces on
each foot, instead of the actual forces (this has to do with the fact
that multiple configurations of contact forces may give approximately
the same net result, even though they may look very different). I
think this, coupled with a less-than-perfect ID solve, and then some
Jt control should work pretty well.
> Anyway, your implementation has been of great help. There are some
> differences though when using ID. Desired COM can be controlled by
> either controlling desired acceleration of stance foot (not so good,
> but works), or by controlling the external force on stance foot
> (better, more responsive). The latter works so that virtual force on
> COM is computed and the opposite applied to stance foot as external
> force. The ID algorithm then compensates this "virtual" external
> force, which in effect probably works just the same as jacobian
> transpose method.
Agreed. Our formulation of PD control + Jt control + gravity
compensation is a week form of inverse dynamics. Since that works well
enough, I think there is wiggle room in the approach you take with ID,
where you can either take full system information into account (i.e.
accurate contact forces), or you can ignore some pieces of
information, and treat as results as drift errors that will be
fixed/reduced in the future.
> I noted in your code that IPM prediction dx and dz are multiplied by
> some constants. I guess this is to better "hit" the target as the foot
> may have some delay?
Yes. That's there from the early days when we were experimenting with
the system. There are other ways of ensuring that the swing leg
closely matches the IK prediction (ID, stiffer PD gains, virtual
forces, etc).
> I'm hoping to provide a video, but at the moment I am still strugling
> with video capture tools on Linux.
That would be really fun to see!
> As always, I am glad I have someone to talk about this. It is really a
> narrow field, at least it seems to be so here. I still have much to
> talk about (the structure, components, API ideas of such a control
> framework etc.), but will have to wait for another time.
It's great to hear from you! Definitely let us know if you have other
comments, questions, criticisms or suggestions - we appreciate them
all.
Cheers,
Stelian