Talk about inverse dynamics solver

[JoeJ]

now I can see why nature favor 6 and 8 leg in the insect world, a small brain does not have to coupe with that

Maybe that's mainly so they can still have stable orientation when crawling on walls or ceilings.

I completely disagree there. but we will see.

I think this decides who of us receives a beer in the end

[Julio Jerez]

now following the recommendation from this video,
https://www.youtube.com/watch?v=5sc8JbO1sRs

I made a very simple animation cycle that matches more or less the main key poses.
it is not as good as an animator would make them because, but that the way I am planning to use that this is just stage one of the process.

the prosses I am envisioning is like this. the schematic bellow

Untitled.png (25.76 KiB) Viewed 2405 times

I completer the last two stages, inverse dynamics and rigid body solver, I am still in stage one which at this point I am making a very simple procedural animations. but a more sophisticated system will use inverted pendulum to predict walk or run gait.

stage two (foot place is) and center of mass balance is not in yet, so we expect the model to just topple down.
notice that the system should handle a large amount of perturbations form the environment, provide is work as I expect.

I am just making the initial setting to give each phase in the schematic the best chance of succeed, but dropping the model on the ground and expected to behave natural, is just wishful thinking, I am surpriced it even try to walk at all.

if you sync now, you will see that I place the limb more anatomically correct for a mammal,
one new trick is that animal with long legs, has their ball joint supporting the body, this is animal liek primated, horse, dog, lions, birds etc.

animals with short leg like retiles has their ball joint outside the body, physically this translate to that if your center of mass is high above the ground, like a dog or a horse, lift a leg will generate a high torque whith cause the body to use a lot of energy to counterbalance.
but of you are a reptile like a crocodile, the lift an arm will not move the com too much.

I made the model like a reptile, with the leg to the side, no wonder it was toppling the model it lifted a leg, I now move the limb a lithe more to the inside. so that is better now.
Still more work.

[Julio Jerez]

I now added debug info that shows the projection of the center of mass over the virtual support feature.

I am calling the support polygon in the case a feature because it could be a line, a point or a triangle or a general polygon. right now I only have the line distance.

it you play it you will see that when the model is walking and the feel support to be in contact with the ground touch the ground the feature changes, that the yellow line.
the blue line is the minimum distance to that feature.
therefore phase 3 of the schematic is simply to make sure the center of mass translates to minimize the distance.
there are different way to do this.
one is to bake part of the motion into the keyframes, animator actually do that when the animate.
this way the correction of the controller is there to minimize the environut errors, not to make up for the pose generator. so I will try to add that next. so, as it turns out dog and horse do sway when walking. furthermore, horses sway less because they are taller, they could have a right spine.
Dogs have to have a flexible spine, so they bend it since the com is closer to the floor.
I hope you get the picture.

edit, I now added the leg sway, and the animation start to look more like the real Spot, in fact probably better because we have true spherical joint while it thinks Spot and all those robots have double hinge made out of tow hinges, one on each axis, so their leg lose the swivel plane, while our maintained.
Having the leg moving on a curve path. Is actually a Milestone, so far all the expectations where theoretical, each time I tried in the pass to have a chain to follow a key framed path, it never quite did it to satisfaction. But now this seems to do not only ok, but far beyond expectation.

this starts to look frighting cool man.

[JoeJ]

Ugh, i realize i don't know much about quadruped locomotion. I won't work on this until i have the biped working, but will observe my dogs til then.

notice that the system should handle a large amount of perturbations form the environment

You need a box gun, so we can shoot boxes to the scene from the camera.
Would be nice to have this in all demos.
(And non inverted mouse look would be nice too. You know, for all the regular people which play games usually)

[Julio Jerez]

yes I know I am flooding probably with useless info for most people.
it is just that I am getting excited when seeing the partial results.

now after make a better pose generators and just to see where the model is, I dropped in the scene.

The results may not look impressive to an untrained eye, but knowing how hard this is, the result blew my wildest expectation.

please check it out one more time.

The model starts to walk almost like real robot, but only takes few steps until if falls to the side. This may be my bias, but it think the model a simple as it is, is more organic.
.

[Julio Jerez]

I now made so that the pose generator comes from and normal animation tree blender.

this allows for a modular designed with a lot more flexibility.
now there is a node that generate a Pose, In the demo this is the procedural walk cycle.

but the output of that could them be blend with other poses, for example we can have a stance pose generation and a blender that transition between the two.
these are just standard animation technique used but any animation system.

but here is where the modularity is useful the output of the pose generation can now be the input of
a node that tracks the ground contacts for the joint that are supposed to be in ground contacts.
but since it is on an even floor, we can make that node later.

the next node is the interesting one, it takes the inputs and applies the adjustment to correct the center of mass.
at least that's the general idea.

[Julio Jerez]

The weight shifting movement has a acceleration and deceleration phase, and personally i plan both of this ahead of time at every moment.
That's why i need precise control of COM, and effectors alone don't give me such control.
So you need it at least internally of course.
For the biped this process is very sensible. This is where Newton displacing a contact to the middle of the foot for just one frame caused my ragdoll to tip over.

Oh Joe, my friend I do not think you are getting the full power of this method.
on the weight shifting of the com is given by the partial derivatives of the of it,
in general, is a difficult problem to estimate, but not longer with this method.

we can now basically the derivative is a predictor of a time step in the future.
but now with the solve we can simply do this.

Code: Select all

-calculate position and velocity of the com.
-calculate new pose from the pose generator tree. 
-apply the solver to get the acceleration. 
-while (com is invalid do)
  -integration model in a local vector.
  -calculate new position and velocity of center of mass.
  -determine corrections for effectors positions to reduce com error
  -apply the solver to get the acceleration new acceleration.

that loop uses the integration of the model to the correction without changing anything in the rigid body state. this will produce a new position and velocity of the COM, which is also a good estimator of the is acceleration, so the balance node now simple works to minimize that acceleration as if it was a simple point mass.

Essentially since it work with the velocity and accration that a change of the effector generate one step in the future.
This become a predictor corrector controller.
It is not implicit since we will stigmata the derivative numerically, but preditor corrector integrator are quite good for smoth finction.
In fact until very early newton 3.xx, the integrator was in fact a predictor corrector and it was very good, but requires damping. It was not until late 3.xx and finally full steam ahead in 4 that the only integrator is the implicit.
So not need for damping since those integrator reduce the area under the curve.

The point is that having the ability to determine the state of the object one time step ahead, is a powerfull tool, because we will be operating on the effect that a change on a effector does, rather that stigmatized after the effect happen.
This should be a better that a secund order controller.

[JoeJ]

Oh Joe, my friend I do not think you are getting the full power of this method.

Oh, you can be sure of that. Sinve our discussion is between academic guy vs. self thought amateur, we would not even notice if we tried to say the same things

But i give you an example:
Imagine robot guy is handcuffed to the wall, all wrists and ankles are fixed to that wall.
But he can still swing his ass left and right.

How would you make that happen, if all your effectors are fixed?

[JoeJ]

I was thinking, and i expect this would work:

We move all effectors to the left.
The resulting pose, after compensating for the impossible translation, woould so move the ass to the right.

Would this work? (I kind of do it this way)

[Julio Jerez]

But i give you an example:
Imagine robot guy is handcuffed to the wall, all wrists and ankles are fixed to that wall.
But he can still swing his ass left and right.
How would you make that happen, if all your effectors are fixed?

that a good case to think about, when I know now is that the inv solve does not know anything about effectors, all it seer is a valid set of bodies and joints. and from that calculate the joints acceleration to meet that condition.
my speculations, is that in this case a high-level controller will monitor effectors by types. in this case the hand effector will have either, a contact point joint or an attachment joint.
so that joint will constraint the solve will have to obey.

the high level has to decide if the joint force or the joint impulse is over some value and programmatically select a pose to match that citation.

when we are father alone, this case will be the same as assuming the Quadruped fall because some force what strong that the balance overwhelm the controller.
in a state machine will senso that teh model is no on a walk state, and changes to a stance pose.

so by having a series of stances form different start point, the problem because, so a pose patching from the effectors current positions, to the array of poses,
interpolate effector to the start position and play the stance animation.

I am pretty sure that's what Spot is doing. if you look at some of eth animation of the real Spot when he is standing form the floor, the first few frames look really uncoordinated, which is a sign of the interpolation to a matching start animation.
But that still far ahead.

I now added the template for the balance controller, it does no dos anything yet, but you can check out how will work.

I froze the pose on a key frame that make him stand almost in tow legs, the third leg is just about to make contacts, so it make a very skinning support triangle.
this is ok to see the stability.
in theory if we place the center of mass inside that triangle, it should stay in equilibrium almost for ever and is does es for a few seconds.
this is actually very good. remember we are dealing with an unstable equilibrium.
this is for the point that the com is, any small displacement make lose potential energy.
you can try, see what I mean.

it is difficult but is actually possible, I got it to state put a few times.
It is remarkable that is actually state put because the pick joint is actually quite nasty. the conversation form screen space to ward space value asserts huge forces to the body.

but if you have time check in out and you will see how the system will finally work.

[JoeJ]

my speculations, is that in this case a high-level controller will monitor effectors by types. in this case the hand effector will have either, a contact point joint or an attachment joint.
so that joint will constraint the solve will have to obey.

Sounds similar to what i did when mapping the Inverted Pendulum controller result back to the ragdoll.
Basically the IP controller gives a target COM for the next frame, which respects both the current dynamics and solving the balance control problem.

To get there, i rotated the current pose around the virtual ankle joint point of the IP, to meet the target COM. (You would achieve that by pulling hand / head effectors forward along the arc of desired COM movement)

To keep the feet in place, i use the IK solver to correct them. This causes a small error on the COM, but was good enough and i needed no iterations to improve that. (You would achieve that by contact point effectors at the feet)

Now i thought pulling by hands effectors would give a bad result of just stretching the arms, but i see - due to including a balancing objectice into your IK solver - it should rotate/move the whole body as desired, not just the arms?

My plan to improve my naive IP -> ragdoll mapping currently is to make a whole body IK solver, controlled by the same effectors, but also respecting a given COM target. This would make it much easier to me, because my previous method felt like an ugly hack.

I wonder: Using your method, wouldn't it help to add another effector to the pelvis? It should find the target COM easier, maybe reducing iteration counts, and give better control over the pose to the user.
Would this work, or is an effector at internal bones prohibited?

I am pretty sure that's what Spot is doing. if you look at some of eth animation of the real Spot when he is standing form the floor, the first few frames look really uncoordinated, which is a sign of the interpolation to a matching start animation.

I guess they don't use animation at all.
Personally i get all this from the dynamics. For example the improved walk cycle i made after the video works like this:

Imagine IP of a walking model. As it swings forward, we predict the path of the ZMP both in time and space. We can use that to plan the next step and the motion path of the foot effector to get there in time. As we hit the floor, the IP foot teleports to the new stance position, and we repeat the cycle for the other side.
Here we only care about IP and feet effectors. All the other motion emerges from that and is natural and good looking.
No need for motion capture or machine learning. We only need to understand the dynamics of the IP.

Downside: We need to build understanding for each kind of locomotion individually. Running is different the walking, so wee need to work on that specifically. (Remember my one legged hopper, which serves as a model for running)
If we want to do a backflip, again we need to understand the dynamics and work out a backflip controller.

Mixing multiple such controllers and behaviors requires work on the top level each time we add a new feature.
So we don't need training data and processing, but we need a good engineer who also has to study animation data to understand and implement the stuff.

In the end, the manually crafted approach will be harder to implement, but likely gives us better control overall, and will have better performance. So i think.
It's not that i have a choice. No motion capture equipment, no Keanu Reeves, no Tensor Flow GPU, no budget.

[Julio Jerez]

well will see how will go after we get a solid balance controller,
I now entering that hard part, the com correction. the first test is a total failure, so I am trying to see what is so wrong.

I have the variable to see in slow motion hwo the correct affect the body, in free body diagram
(No gravity and no contacts)

ndFloat32 correctionFactor = 0.01f;
const ndVector step((com - target).Scale (correctionFactor));

I can see a simple desire translation is not enough, it most also account for the upper body to keep it relative orientation.

anyway, I will continue to see what other surprises we find.

[Julio Jerez]

You were right. Hard contact remain a big problem.
Calculation joint acceleration has the effect that entire
the articulation behaving as a single rigid body.

For example say we have two bodies joint by a hinge motor.
If they hit a floor one tip down.

The desire effect is that the first body should recieve the impact. And if is bound the the hinge will flex to dampen the motion.

But what we are getting now is that two body bouncing biliently.
The method used by the system that calculate joint torque with dp has that buil in the process.

I have to think how to solve that.
I think I have an idea, which basically convert the desire acceleration calculated by the ik solver into proportional derivative acceleration .
I very quick hack with be to just filter out tge spikes.
But ther has to be a more correct way.

Yif you look a video of people jumping you will see that when touching the ground they flex the knee.
In fact all superhero move use that famos lending lpose. Or it is not a super hero.
In this system if a model land it doe not flexes at all.
In a way this is too good. But I think that if we allow for example the knee to flex. Them it will adsorve the impacts.

[Julio Jerez]

just for a test I softened the effector, so that is act like a race car stiff suspension.
and is does behave as I expected.

if you test it, you will see that the balancer, try to balance the upper body by moving to the project of the COM t other line that connect the two contacts. it does that quite successfully.

but in doing that we come to a new problem. since this a set of rigid bodies connected by joints.
principle of action reaction is on, so when happens is that with just two legs, the top body only haves two ball socket as contacts, so any angular momentum that generated by the limbs will cause the upper body will roll free in the opposite direction by the same amount.
so as the effect do their work to align the com with the support point, they add angular momentum to the to body, and once they get there the angular momentum does is preserve and the top body keeps the body rotating until some of the joints hi a limit and the range where is applicable is not longer valid.

We need a way to damp that action, which I think in nature this is achieve by extra muscles.
we will have to add that somehow.
But all in all this is not bad. at least all these behaviors are predictable.

if you check it out, tell me what you think.

[JoeJ]

You were right. Hard contact remain a big problem.
Calculation joint acceleration has the effect that entire
the articulation behaving as a single rigid body.

Hmm... the contact problem i had was not about ragdoll being too stiff. Although visually the stiffness did not look right, the balancing worked regardless. (After switching to the new exact joints, iirc)
My problem form the contact moving to the foots middle only gave less deceleration than predicted, which is another problem and not what you currently see i guess.

Tried the demo but looks like you started to try crazy stuff to test things and now it's broken. (No collisions with legs, even external force making it fly upwards it seems.)
So i can't see what your problem actually is.

However, if you're in doubt it is either due to stiffness, but eventually also from a bad strategy to move the com, you could check for the latter by adding visualization of the ZMP.
Usually, if the ZMP goes out of the support polygon, it tips over.
And this can quickly happen even with very gentle movements.
In case you underestimate how sensible this is, seeing this visually would surely be very helpful.
To me, any naive approach to keep in balance by keeping the com in support poly always failed.
Only after i understood this ZMP / COP stuff, i started to make proper progress with balancing.