Real-Time Physics Simulation Forum

http://web.t-online.hu/archee83/sumotori/

http://www.youtube.com/watch?v=I6obJWruwk0
http://www.youtube.com/watch?v=pVujJz8oTb0

Self balancing characters look very funny and wonderful in the same time
Is there any description of the techniques involved in the demo?

I'm pretty interested in how it was implemented myself.

It appears to be using "controllers" to try to keep balance. Those aren't too tricky to code. Really tricky to tune, though.

The goal of the controler is to create a manifold with the feet, such that the center of gravity of the creature projected straight down ( maybe anticipate ahead in time a bit too ) lies inside that manifold. You want to create contact points with your feet, so the convex hull of them contains that balance point.

You do this with a stepping controller to lift the foot a bit, blend that with an IK goal solver to get the foot to the desired location. That will give you position/velocity goals, which you feed into your the motors that act at the joints. Best to have those motors as a constraint in your solver rather than applying forces externally. You'll have a simple PID controler for each motor that tries to achieve it's goals determined by the higher-level stepping and IK controllers.

then you spend weeks tuning. Or use a neural network to speed up the tuning process ( as I believe endorphins literature claims ).

Big feet and a low centre of gravity help

The Get Up off The ground controller was really neat. Seemed to try to match a series of poses to eventually that would lead it to the final standing up from face down animation. But all the animations were really driving the PID controllers.

I had a simple balance controller working. Didn't take that long to code. My stepper didn't really do much, but I had the IK goal solver working to keep the character up for a few drunken steps. Anyone have much experience with this stuff?

mewert wrote:Big feet and a low centre of gravity help

Making the feet really heavy also helps; however it can tend to throw the rest of the character from left to right while walking. I've cheated for now by locking the feet to a controller like a skateboard. I'll go back to walking later when I get it smoothed out. See http://neurolife.com

I'm going to try throwing the foot forward and leaving it in ragdoll mode until it again touches the ground. If that works I'll tie it into the rest of the AI.

The balancing in Sumotori is pretty cool and fun to watch, and the getup is impressive. Anyone know what engine is being used (or is it all homegrown)?

I'm starting some work on "advanced ragdolls" (ie. not just floppy rigs, but more à la natural motion), and I'm trying to decide on a physics engine. How do they compare when it comes to constraint stability, joint limits, motor control, etc. Any experience/thoughts out there?

I've played with and expanded upon the Havok demos, and clearly they're way ahead in terms of "out of the box" ragdoll solutions. But I may not be able to use Havok for this project (cost + Mac support).

PhysX recommends using their 6DOF joint for ragdolls. (In their documentation. But their demo uses unpowered spherical joints.) Anyone have experience trying to drive these? Or with their joint limits?

Bullet recommends using ConeTwist constraints for hips/shoulders. Any experience driving these?

ODE provides little documentation on this, and no demo. (Though I see that http://www.magix.ucla.edu/dance/ and http://www.droidlogic.com/ put it to good use.)

Anyone have any experience or advice on the stability and control of these systems?

Thanks,
Eddy

Personally I would try a stiff subsolver (solve the whole joint tree with a direct solver) for the whole ragdoll with motors to drive it towards your target pose and simply relax (sequential impulses) on the contact constraints. So one option would be to use the ODE Dantzig solver for your ragdoll including motors and limits (you can think of this like one "big" constraint) and then simply relax on the contacts. This doesn't lead necessairly to a better global solution, but emphasizes your ragdoll joint tree. Another way is to implement Baraffs linear time solver for the constraint tree. Erin Catto just implemented this and this gives fantastic results. I haven't implemented Baraffs extension to deal with limits and motors though, which would be another option to Dantzig that already can deal with limits and motors and is not restricted to equality constraints. Another option would be to implement a Featherstone constraint, but I don't have any experience with this. I just could imagine that you might get problems with Featherstone in combination with CCD since Featherstone can't recover from separation at the joints. At least not to my knowledge.


HTH,
-Dirk

Thanks for your suggestions, Dirk. I'll keep them in mind...

That said, I'd rather benefit from an existing engine if it can (be minimally adapted to) support my needs. Anyone out there with experience/suggestions on getting there with Bullet, ODE or PhysX?

Thanks,
Eddy

All engines you mention have the constraints you need. I think Erwin is working on a Featherstone solver, but I don't know how far he is with this. If you are looking for motors I know for sure that Ageia and ODE support them. For Bullet I can't say. So from this perspective all engines are more or less equal, though I would favor Bullet since it has the most active community if you might need help. An advantage of ODE is that it has the direct Dantzig solver. As long as you can guarantee that you system is solveable here you would have at least the option between a direct and an iterative LCP solver. Personally I doubt that a pairwise relaxation solver will give good enough quality for physic based animation, but I don't know what you consider "advanced ragdolls". So it might be good enough for your needs.

Dirk Gregorius wrote:All engines you mention have the constraints you need. I think Erwin is working on a Featherstone solver, but I don't know how far he is with this. If you are looking for motors I know for sure that Ageia and ODE support them. For Bullet I can't say. So from this perspective all engines are more or less equal, though I would favor Bullet since it has the most active community if you might need help. An advantage of ODE is that it has the direct Dantzig solver. As long as you can guarantee that you system is solveable here you would have at least the option between a direct and an iterative LCP solver. Personally I doubt that a pairwise relaxation solver will give good enough quality for physic based animation, but I don't know what you consider "advanced ragdolls". So it might be good enough for your needs.

i agree it depends on what kind of behaviours we are talking about. Featherstone is a stiff solver _only_ for joints, but typically you also want stiff motors and stiff contacts against the enviroment so you would need to write other stiff solvers for motors/contacts. Some simple behaviours like a catch fall may still work with less strict requirements. I dont know too much about Ageia, the most tested engine for such applications is ODE, this mainly because of the dantzig solver(stiff for motors, contacts and joints), i also believe that at least initially Endorphine was using either ODE or something similar(Karma solver etc.). Then you could also try to extract the Dantzig solver from ODE and use it within Bullet, given that this has already been done with the ODE's quickstep it seems a feasible option. Clearly you would not want to use the Dantzig solver for the entire scene but in the worst case only the for body motors,joints and contacts against the enviroment and solve the rest in a iterative fashion.
If you have enough time you could have an abstract layer so that in the future you will be able to switch engines without too much pain.

cheers,
Antonio

From reliable but anonymous sources Natural Motion and Dance both work with joints and motors using an iterative solver like Bullet's sequential impulse or quickstep. So Featherstone or direct pivoting LCP solvers like Dantzig seem not strictly necessary, although it might help.

(EDIT: made it more clear to add forces/comment about outside constraint solver)
Natural Motion powers joint motors, and 'Dance' directly interacts with velocities/forces (outside of the constraint solver, so not using motors).

It would be good to setup a testbed, to test and improve the quality of Bullet's existing motors for ragdoll constraints like the twist-cone and generic 6dof constraints.

Thanks,
Erwin

Erwin Coumans wrote:From reliable but anonymous sources Natural Motion and Dance both work with joints and motors using an iterative solver like Bullet's sequential impulse or quickstep. So Featherstone or direct pivoting LCP solvers like Dantzig seem not strictly necessary, although it might help.

Natural Motion powers joint motors, and 'Dance' directly interacts with velocities, not using motors.

i was referring to Endorphine and to and old version like i mentioned. I have seen only a video of Euphoria and from that alone is a bit difficult for me to make general statements about a systemt that i cannot inspect/observe.

accordingly to a recent publication Dance is not setting directly the velocity but it is using PD controllers, see formula 2 of :

http://www.cs.ucla.edu/~ashapiro/Sandbo ... oolkit.pdf

note that if we exclude damping from formula 2, the maximum allowed force is implied in the formula by the maximum possible difference of 2 angles multiplied by the controller gain constant.

on setting the angular velocities directly: i dont think it would work in general. suppose you have a character performing a push up animation(couldn't find any girl sorry):



at every frame we would be setting the angular velocities directly as they come from the animation. Now suppose you add a weight on the top of the character's back, the animation would look exactly the same no matter what the weight is. If motors are used instead, we are able to specify realistic force limits for each joint and the animation will be modified in accordance to both the added weight and its location relative to the body, so it will adapt to the extra weight. In both cases we would have a behaviour but the latter is much more adaptive. Many other similar cases can be built. If we can safely says that such effects are irrelevant for the kind of behaviours we want to model, we can go for setting the angular velocity directly. The main point is that we must aware of what we are doing. If there is no prior information we must assume the most general case and go for motors. We could also cheat a bit and scale the angular velocity, in the example above for example we could scale down the velocities in proportion to the applied applied weight and its location relative to the joints. It's cheating a bit and may give plausible result for that _specific_ case. An analisys could tell us that for all the behaviours and situations, we can solve the problems with similar hacks, if we are lucky enough it could even work. Any ideas for a general solution based on setting the velocities directly that is also adaptive?

in regard to iterative solvers for motors to me the minimum requirement is the following:
a solver should be able to follow an animation as close as possible without any visual artifacts. This is required because we want to extend the animation playback with some adaptivity provided by the use of logic and physics. If we have a behaviour and we cannot even playback an animation it would be very limiting. We would be loosing features and gaining others when in reality we want to extend what is possible in terms of animation.

So a simple test is to set up a skeleton and try to follow a fast moving animation in empty space without gravity. Setting directly the velocities satisfies this requirement but it violates some other requirements(see previous discussion)
From my experience iterative solvers need many iterations in order to track a fast moving pose. Animations in games can change very fast from one pose to the other. Reaching a fixed pose instead seems quite feasible with an iterative solver without many visual artifacts(it will just take longer ). There is an interesting Havok demo where a ragdoll tries to follow an animation and you can select different solvers where you can see the difference yourself. Of course we can still write some behaviours based on lower requirements. The problem is that we must be able to predict which behaviours would work given such limits and when they work if the will meet the high standards of quality usually imposed by animators.We could still exclude behaviours that dont work nicely.

another problem is that in a realistic humanoid there are big mass differences, just compare the mass of a foot against the mass of the heaviest part. So it depends on what simplification we can tolerate here. If we aren't very tolerant we know that iterative solvers dont like big mass differences.

so although i think it is possible to get something out of iterative solvers, stiff sub-solvers seem the safest bet.
Then yes we can see what behaviours we need in practive and how adaptive they must be, how we can get around the limits of the solver, for example by just not using behaviours that would not work well, maybe we can cheat a bit etc...
but then it becomes more an art than a science.

i'd like to know about other people experiences ....

cheeers,
Antonio

in regard to iterative solvers for motors to me the minimum requirement is the following: a solver should be able to follow an animation as close as possible without any visual artifacts.

This requirement has always bugged me. The motors must be very strong to follow the animation, often much stronger than a real human. So how can we see realistic interaction with the environment with these super-heroes that can flip over a train with a flick of the wrist? Along these lines, I wonder if the motor torques can have reasonable maximums for mo-cap animations. I know that hand animated movement has absurd accelerations (I've seen 20 x gravity).

I think that applying velocities is adaptive. Imagine a stack of two boxes. Asynchronously I apply an upwards impulse to the lower box. Then I proceed to take a time step. The upper box will react and absorb some of the momentum, and the lower box will slow down. Or are you thinking that the velocities are applied at each iteration?

Erin Catto wrote:I wonder if the motor torques can have reasonable maximums for mo-cap animations. I know that hand animated movement has absurd accelerations (I've seen 20 x gravity).

in games animations can indeed be much faster than in reality, one idea could be to see them as having the same torque limits but with a warped time. If animations are not realistic they would at least be consistent with the inputs. We would need to pick the torque limits based on some error defined on how close we want to follow the animation. By changing the allowed error we would end up with different limits. If we have a solver that is stiff enough, we have this flexibility. There is also a continuity problem, if we want to go from an animation to a behaviour and we want a smooth transition we must start from playing back the animation as it is. This is not strictly required, it depends on the behaviour and what level of quality we are expecting. We could just use the last pose/velocity and start the behaviour(eg catch fall) or fade out the animation(so we need good motors here) while the behaviour is enabled.

We can choose the torque limits based on the various factors that come into play: desired realistim, ability to follow the animation etc... If the solver is the limit we can't so we have a smaller space of possibilities that we can use/explore.

Erin Catto wrote: I think that applying velocities is adaptive. Imagine a stack of two boxes. Asynchronously I apply an upwards impulse to the lower box. Then I proceed to take a time step. The upper box will react and absorb some of the momentum, and the lower box will slow down. Or are you thinking that the velocities are applied at each iteration

i think we mean something different here. By applying the velocities i meant reading the target velocities from the animation at everytime step, instead of using such velocities as a target for the motors just set such velocities directly for the joint state and then call the solver. Basically the body is kinematically driven by setting the state at everyframe and then the solver is called.

cheers,
Antonio

Basically the body is kinematically driven by setting the state at everyframe and then the solver is called.

Wouldn't the solver overwrite the angular velocities in this case or can we assume that the velocities will satisfy the constraints - at least more or less?