Refactoring joints

[Julio Jerez]

Has some faith my friend.

If we get the model balance on it two feets, that will be the first mode.
The way this is check is that is after each update
The correctin of moving toward the projection of the c.f is negative and lower than some value, the this trigger the step controller which is move the closer legs effector on the direction of the error so that the c.f. is closer.

[JoeJ]

Oh, so you DO plan to make steps. Ok then - all fine i guess [phew ]
Like i did with the one legged hopper which can hop in place or along a path. But a soon as it stpos hopping it will fall. I found this surprisingly easy in contrast to the IP model moving its com while keeping its foot in place.

Edit: Old video:
This was made using an naive approach, later a made it analytically (which looks the same)

[Julio Jerez]

The step is for when the balance lose equilibrium, like in your video.
You model does it for one or few frames. Because is just one body, but an articulated body can alter it internal joints angles to try to move its com to the support point.
Remember there are tree type of equilibrium.
Stable, unstable and neutral.
We deal with stable and neutral.
Now we are working with unstable.
The idea is that when the model land on the ground
The fact that state up for a few frame, is saying that it is close to the point of unstable equilibrium.

Unstable equilibrium in a dynamic system is a point which any small perturbation is the system parameter translate to a lost of potential energy.
So if we can apply a modification of the parameter in the negative direction, as long as the modification can generate a kinetic energy that is larger than the lost of potential energy, the the system become active stable.
This is now use for controlling vehicles like helicopters and airplane, but is a very powerful is a of calculus of variations.

[JoeJ]

I get you now, but that's something i have not utilized yet. I focused on staying stable (the hopper is the only exception).
I also tried to treat walking as an entire stable state over the full cycle, which works by calculating the support polygon form both feet, even if one is in air. Because it is guaranteed the center of pressure stays on the stance leg anyways this 'lie' is correct if i make sure the swing leg touches ground slightly before the IP model wants to deaccelerate by moving the COP to the swing leg. In fact i have to lie about the support poly so the IP model knows how strong it will be able to deaccelerate. The IP model also knows the time until deacceleration has to happen, so i use this time to plan motion of swing leg. Note that this way the entire walk cycle is defined without any memory, state machine or animation (at least in theory).
That's my idea, i'd need to continue now with the contact problem identified and resolved to see if it finally works. Then i'd move to unstable state for running, like the hopper does.

However, as you plan to utilize unstable state from the beginning i think you get a advantage, simply because your guy does not fall down all the time (which is really annoying to me)

[Julio Jerez]

ok now that we found out what was the bug with the rag dll joint, I will complete all the revision before move one.

the changes are
1-the ability to rate the cone angle, partially done.
2-at the move the motor mode is such the acceleration of the joint is set to zero. this is ok,
however we can no much better. we can set so that the velocity is is to zero.

by doing this a rag doll will add like a real mannequin, because the joint will tend to stop motion, so a use can for example attach the pelvis to a fix joint and pick a drag limbs to create poses, and it will act like a real dummy model, even when the rag doll is in free fall it ill at nice because the limb will move each time the friction limit is broken but it will try to stop the motions.
rigid now the only thing that stop the motion is the internal drag of the rigid body.

3-finally adding the 2 axis hinge and a slider for some kind of special motions.

[Julio Jerez]

Ok Joe if you have time you can check out the part when the ragdoll act as a mannequin dummy.

now you can limbs can be pick an position the to where the use want to save a pose.
this can be use to save animations.
so fat the 2d joint has this features. tonight I will added to all joints.
so now the joint is on motor at all time and the motor off can be used for cool effects say damage.

the resistance is control by the amount of friction which the use can use for tuning the response and strength of a model.
note: will go pass the limit because I have not added the rotated limit check yet, that's no a big problem.

[Julio Jerez]

now the 1 and 3dof joint are setup that the zero the relative velocity.

the solution I found to solve the firs problem break the hexapod demo, resting the motors has to be place on a different place. I will figure that out later, but for now
the rag doll fall and want to keep it shape, the torque are too strong, so I will set the lower for ragdoll
and we can increase the for active rag doll.

now on to the more problematic joint the 3dof

al right I enable the complete rag doll some joint friction is too strong, it nee to be set per joint no a one fix all, by you can see immediately the difference with a stupid passive rag doll.

[JoeJ]

I get an assert (crash in release) when setting dynamic ragdoll demo:

Code: Select all

void dCustomRagdollMotor_2dof::Load(dCustomJointSaveLoad* const fileLoader)
{
   const char* token;
   token = fileLoader->NextToken();
   dAssert(!strcmp(token, "coneAngle:"));
   m_coneAngle = fileLoader->LoadFloat() * 3.141592f / 180.0f;

   token = fileLoader->NextToken();
   dAssert(!strcmp(token, "coneAligment:"));    /// <- token is 'JointEnd:'
   m_limitAligment = fileLoader->LoadMatrix();
}

But i can imagine how it behaves because i did zero vel. posing experiments myself in the past.
And this brings up an important detail to me, that although obvious i did not really realize properly:

So i assume in the inverse dyn. step all you do is performing a temporal simulation driven only by the effectors, but you do NOT any kind of control (like trying to solve an IK problem for an unreachable target, any kind of balancing, anything that requiers some logic or follows some intetion).
Then during regular simulation you try to get that temporal result.
So any kind of control has to be applied just by using effectors. Correct?

To me this turns your system from a promising and interesting black box to something simple i can predict, understand, and so wanna and trust to use even in case i know how to calculate the desired motion myself.

(may your marketing division have some use for this kind of feedback )

[Julio Jerez]

Joe it is no exactly like that, but you get the idea.

you insight is simmilart to mind for many year, util I relice that the Ik or inverse dynamics is a gemetrical problem, no a force problem.
wha thsi mean is that for canculation the inverse dynamic sjoint angle all force has to be set to zero, the teh effector will calculate the accelration tha will move the joint to teh point you want. but the effector are part of the physics solver.
This prosiple is requrrent in many physics equation, and tshi si that the intenal force are alway equa to zero. so if the effectro calculate so joint accelration teh effect on th entire arre of conecet bodies is zero. of course this was causing be all those.
It si quite a repmartkable prociple ince you undertand it.
It is like the idea of the Newton Joints, when you do no knwo how they work they seem like magic, the once you get how the conver teh physics to a genetrical relation ships, the the are intuitive and you sone realice there are more than one way to do teh same thing whi seem obviuos after the fact.

The inverse dinamics, I believe will be even more obvious, once we see how intrutive and poweful it is.

any way I was trying to work on the model that I wrote few moth back, but It was too complex, so I decided to makle a straigh implementation startyon from the ragdoll demo.

I commited the dummy set up, with teh joint but is no doing anything. now I am ready to add the inverse dynamic support. se how that works.

the zero velocity joint angle was a veryu doo idea, if you pick the dummy you cna see hwo it behave noice with mouse picking, and almost all position look human natrural so far. I am sure it will shange once gravity is active, but for now for setting it up is good to set gravity to zero.


it is base of

[JoeJ]

util I relice that the Ik or inverse dynamics is a gemetrical problem, no a force problem.

Yeah, makes sense. Of course IK is a geometrical problem and just dragging a hand would give no useful results
There are however cases where moving the effector just slightly causes a completely different IK solution due to some limits or if the shortest arc goes to the other side. Did you care for this already? I handled this by slowing down the movement the IK solver suggests if i get close to a flipping case up to the point where it just keeps the current pose (No solution is better than jitter).
Later i disabled this because i realized i do not want the IK solver to affect speed. Luckily those flipping cases can't happen during regular locomotion, but i guess they show up more quickly than we want.
This is a point where i assume you might get in trouble because your IK solver only knows about limits if they get violated. Planing to avoid flipping cases requires to be aware if joint limits all the time.

That's one point why i liked the idea your IK is more force driven than trying to provide clever but potential unstable geometric solutions. So i hope your system is dump enough to just get stuck instead provoking oszillations and jitter, which we can see here and there when at the limits. Maybe soft limits become necessary at some time...

2-at the move the motor mode is such the acceleration of the joint is set to zero. this is ok,
however we can no much better. we can set so that the velocity is is to zero.

How is this 'idle' behaviour triggered? I assume it happens if there is no effector attached to the branch, or the effector is turned off?

Does it also affect the solution IK finds if there is an active effector?

Would it make sense to expose it to the user somehow? E.g. we might want to reduce it if the ragdoll is dead. We could just turn off the motor, but the idle behaviour would still create some joint friction so more realistc. Oh, nevermind - we just reduce the max torque

[Julio Jerez]

Oh lot of questions.
yes the ik or inverse dynamics can have multiple solutions, but there is a big difference between IK and inverse dynamics.
IK only consider the current state of a configuration, and from there try to get a new state.
it is possible to refine ik by adding tweak that consider previous positions, but so far I have not seen a successful algorithm that can get it reliable and predictable.

Inverse dynamics on the other hand has a mass matrix distribution and has to obey momentum distribution. So inverse dynamics can't make a huge jumps from one state to another arbitrary state, therefore the possibility of flipping is much smaller and with proper limits, configuration that are holonomic, undesired states can be controlled by design. That was part of all the work I did last month.

For non holonomic configurations yes they are infinite solutions, an example of that is the spine of the model we are using, but it very essay to convert a non holonomic chains to holonomic chains by adding new geometrical equations.
For example in the case of the spine, we can set the effector to the tip, then there are three bones each we 3dof, that's 9 and the IK can only resolve 6. but we can make an spline spine 3dof joint.
this is we set the some spine joints to inforce the joint angle to be is a linear expression of some other spine joint. The the spine will always bend on a arch.
any way that's far away still but I hope you get the idea.


On the biped, I had to do some code refactoring removing all the loading and saving stuff that was casing more problems that what was solving.
Instead I copy and pasted the ragdoll demo, and I will extend that to make it the balancing demo.
I will try to make so that not too much code is on the demo.

[JoeJ]

Makes sense, thanks

[Julio Jerez]

ok now I think I managed to refactor the dCustomArticulaledTransformManager
class so that it can be use for any hierarchical model without having to use code for the demos.

for example the tank and the fork lift use that class by the have so much code implemented in a
class ArticulatedEntityModel: public DemoEntity that it make unusable for many people.

It still used the same becaus eI only chneg stuff to make work, but it can mafuntion, soem time I will red du tha demo using teh new features.

now the Ragdoll and teh biped only use code for teh joint library, like the hexapod and the six axis manipulator.

now I will try to add the balancing code, no sure how much progress I will make, but this step was necessary.

if you thing you will see the model, standing up on his one feed.
whi is better that bnefore when I only has the tip of teh capsule.

now you can see the balancing does really has to do much work. also I am goin to make another outlandish claim
I claim that to make the biped to keep it balance we do no nee to do any ray cast and there is not need to get a support plane.
I will let you think about that for a moment.

[Julio Jerez]

Ok now I got to the point where it builds the skeleton, no effectors yet.

there seem to be a bug somewhere because I beleive that if the ik is called for a change with not effectors, the result should be zero, but I do not remember, I will check that out before moving on.
that does not look right to me.

[Julio Jerez]

ok I decided to get dirty and check out the rag doll joint, they where still incorrect.
I believe I have the right now, please when you have time to sync see if thsi feel ok to you.

I am using 3 dof fo rthe leg, but this is intentional, baically what we wnat is that whne the leg move to teh side like doin a kick, that the foot can only be in one orientation. are if was iw was possible fo rthe leg to have any oriention even whe the joint was a tow axis.

teh rian fo that was that using quat to calculate the offest matrix,m you get the small angle, but that's is wrong for this kind of joint whe wna the con angle to be calcuate from the base matrix.

Edit:
I believe I have the ragdoll preetu good now. now I can start adding the adding teh balancing stuff