Development of self balancing biped with inverse Dynamics

[Julio Jerez]

I set the first test that exposed the difference.
I set the horizontal limit to 5 units, the robot can reach about 3.8

if you move the slider in ndSimpleIndustrialRobot you will see that the arm start to vibrate,
and after retrieving it, is a guess if is going to move in the desired direction, in fact almost every time picks the wrong one because gravity favors it. So the odds are not even.

if you run ndAdvancedIndustrialRobot you will see that the behavior is far different, for one, the vibration is almost gone, and the chances of ppicking the right direction are fact more favorable.

if does dismember, but that is quite expected. the immediate solver is telling the joint to apply that acceleration, so it will just do that. but that's the whole point of this, we now can inspect that acceleration and see that it will violate the joint limit, so will simple clamped and try again before sending to the general solver.
So it is an iterative process.

if you sync you can try that test now. later I will add the code to make those corrections.

[JoeJ]

but that is quite expected. the immediate solver is telling the joint to apply that acceleration, so it will just do that. but that's the whole point of this, we now can inspect that acceleration and see that it will violate the joint limit, so will simple clamped and try again before sending to the general solver.
So it is an iterative process.

Seems i don't need to worry about compatibility with my stuff.
All that changes for me is, instead giving acceleration to joint motors, i give my accelerations to the general solver.
And it will work much better than using joint motors i guess.

Also no need to go to details with joint limits for you, as users can still do their custom joints within the clamping process you mentioned.

Flexible and neat

But how do we handle torque limits, or min/max friction as you called it in your joints?

[Julio Jerez]

All that changes for me is, instead giving acceleration to joint motors, i give my accelerations to the general solver.

you still give the joint motors accelerations and torque limits, the difference is that now we have a tool that calculate them for us using the physics system. Again, an IK systm could get the same results, but IK deal with kinematic giving you real displacement and from that you need to get the accelerations, The immediate solver uses the system internal derivatives to get that accelerating to achieve a goal. the physics has some advantage and disadvantages.
one advantage is that the solution considers momentum, this is important when over and under constrained systems.
few huge disadvantages are: is more expensive, is harder to use, it can be more unstable.
I tried the IK and I found it not attractive, but I also accept that it was my bias.

But how do we handle torque limits, or min/max friction as you called it in your joints?

all the information is provided, class ndJointBilateralConstraint
has these functions.
ndVector GetForceBody0() const;
ndVector GetTorqueBody0() const;
ndVector GetForceBody1() const;
ndVector GetTorqueBody1() const;

say you have a motor that can only deliver a max torque.
you read the torque applied by that joint, and you check again the joint limit.

it does far more than just setting the limit, when you have a motor that is spinning, the torque is a measure of the maximum that can excerpt on a load until it reaches nominal speed.
but once it reached that speed, them not torque is applied.

What we do is, we set the torque limit the solver gives you as the actual max toque been applied by the motor.
if it was a simulation of an actual physical model, that value can be used to set the motor actual input, voltage or a gas. In fact, I use that trick to model an internal combustion engine for the vehicle.

later when we have the full model. I will place objects in the scene for the robot to pick up.
objects will have different weights so that the robot picking objects that do not break any internal motor limit and will struggle with heavy objects.

[JoeJ]

So i could call the joint solver for the skeleton as a test run, then iterate joints and get torques from there and clamp if needed, finally call the update with those torques?

At this point, i could also do this to get the joint torques as requested in the other thread, for example?

Or, if the clamping triggers some illegal state i do not want, i could also refine the initial accelerations and restart the whole process for an alternative solution i guess.

That's very nice. A while back you said Newton provides the tools to solve problems or something similar. I see this would be an example for doing so.
Details will become clear as you proceed with the demo, but i think i get it.

[Julio Jerez]

So i could call the joint solver for the skeleton as a test run, then iterate joints and get torques from there and clamp if needed, finally call the update with those torques?

yes, and that is exactly what the demo does now. I am doing only one limit for now.

Details will become clear as you proceed with the demo, but i think i get it.

in that case you are in luck, my friend.
I just put it a quick hack to test one limit, and the results are impressive sive. no jitter at all so far. if in teh simple robot I just set the joint limit and let the solver figure it, it jitters really bad. I will add that later so that is show the difference without ambiguity.

check it out, it is committed.

the answer to all the question is yes.
A naive clamping could cause a side effect, and it and it was bad, I simply try to clamp the joint that violate the limit.
the problem is that the other joint keep getting the huge accel that counter the violation, so without retrying the solver the arm snaped really bad, it is not a slam-dunk, but it does work.
so I just did an all or nothing. if a joint break the limit, freeze the robot canceling all the momentum.
it works really nice. but this the final.

[Julio Jerez]

Now set all the limits.

you can see that is very simple, if a joint hit a limit, it stops them all, this work well for a basic robot like this because the use can simply back up the step.

it will not be practical for something like a leg. for example, is a leg is taking a forward step, the knee will hit the limit, but if we freeze all joint then it will not move.

so when it needs to do is freeze the joints the limit and do another solve pass. and keep doing that until no more joint break the limit, or until it reached a max number of iterations, and in the case does the freeze all joint fall back.

in the case of a leg. the firs pass will freeze the knee, then the secund pass will recalcine a new acceleration for the thigh bone which just move the entire leg as if it was a single rigid body attached to the pelvis. at least that the goal.

if this works, then we can have robots that can walk full standing up not like the current one that what withe the leg flexed like asimo and atlas
https://www.youtube.com/watch?v=QdQL11uWWcI

[JoeJ]

Looked it up yesterday with the single limit.
It's quite clear from the talk, but i would need to look up some details, e.g. what the joint is doing with the acceleration override flag. Or what the jacobian AddHorizontal() function is doing.
Also my physics math became a bit rusty in general.
At the moment, i would not say it's easy to use. So i propose you later add tooling functions to automate things like this:

in the case of a leg. the firs pass will freeze the knee, then the secund pass will recalcine a new acceleration for the thigh bone which just move the entire leg as if it was a single rigid body attached to the pelvis. at least that the goal.

Then the user does not need to know about such details. Just setup skeleton with standard joints, add effector and 'animate'. I guess the usual gamedev could be overwhelmed form dealing with accelerations directly.
Surely you plan to do this anyway after it proofs working as expected, but just to give some feedback.

[Julio Jerez]

Then the user does not need to know about such details. Just setup skeleton with standard joints, add effector and 'animate'. I guess the usual gamedev could be overwhelmed form dealing with accelerations directly.

Yes that is the idea, we are still in the process of formalizing the system. Some of the stuff in the update function are probably too low level, but I am tented to leave at some kind of low level so that it does not become a cooky cuter feature.

I am using the arm robot to devote the system because is the simplest functional case of a ik manipulator that people can identify.

Hopefully when the system is used with the self balancing ragdoll that funtionality will be hidden. And the end user will see as you say. Rig the skeleton, place the effectors and animate.

I actually had a good stable balancing ragdoll, but many problem happens the moment I start moving the effector.
So I concluded that effector has to be virtual, they can't be part of the rig.

Think about, even key framed animations and motion capture use effectors as intermediate helpers. The final animation is just key frame and the skeleton.

[Julio Jerez]

ok I tried to add the support to the basic's joints, but that is making them too complicated.
It seems this will work better with a set of special joints.

for example, for a hinge, we subclass form the basics hinge and we ass the support for immediate solver to that class. this way the immediate solver can access internal data.
this will probably keep it simpler with less interference.

we can give these special joints a moniker a name like ndHingeIK
then when I go back to the self-balancing I will make very, very simple. the model will fist have onle the lower leg as limbs, something like this

Untitled.png (11.71 KiB) Viewed 11145 times

all the upper body will be fix, and the leg will articulate, then after that is stable, we move to make the upper body part also articulated.

[Julio Jerez]

so Joe, I was thinking about this some more.
let see if we agree.
basically, what you are saying is that the system should be as simple, as
the app set the effectors positions and call the immediate solve to figure out the joints set up.

I think I like that idea.
I already start moving the skel solver to its own folder, there, there will be a couple of joints that are subclasses from the base one.
the complete loop will be executed in the solver call.
this way it will not affect or pollute any of the existing joints with mysteries functionality.
them the app can queried the results of the solver for feedback.

something like this

Code: Select all

   void Update(ndWorld* const world, ndFloat32 timestep)
   {
      ndModel::Update(world, timestep);

      ndSkeletonContainer* const skeleton = m_rootBody->GetSkeleton();
      dAssert(skeleton);

      if (m_effector && !m_invDynamicsSolver.IsSleeping(skeleton))
      {
         PlaceEffector();
         m_invDynamicsSolver.AddEffector(skeleton, m_effector);
         m_invDynamicsSolver.Solve(skeleton, world, timestep);
      }
   }


[JoeJ]

Yeah, agree to all that.
Separation of kinematic joints is good i think. Basically we only need hinge and ball socket. Maybe slider as well, if that does not break your IK stuff.

Update looks good too. Question may be how to deal with multiple effectors. Intuitively, i would like to create an effector for each limb while setting up the skeleton.
At runtime i'd like to use a flag in the effector joint to turn it on and off.
So all i had to do would be to animate effectors and enable / disable them. You could implement such default Update functionality without bothering the user at all, and it would work for simple stuff.

If it's not simple, users ofc. need to do some low level things themselves. But if the entry barrier is low, they will try simple stuff first, and then they are motivated to invest some more time on complex ideas.

(I somehow think you need to lure and guide game devs, and kick their asses, so they finally start to come up with new games. I'd really like to play some games, you know? But any AAA game i try is no fun anymore, and there is no progress over a decade. They are stuck and waste their money on the wrong things. I'm very disappointed, and i'm not alone. )

Btw, there is one thing bothering me since the start, and i still don't know how to deal with it.
I kept my upper body stiff as well and never made it to the point where this should change.
Actually it worked to grab a target with hands if needed, but that's not what arms usually do while walking.
Usually, the arms dangle. To get such dangling, i could just disable joint motors. But likely there should be some smooth transition from passive dangling to active action. So i would need to predict hand motion, set effector to that, use the motors with very low max torques. Not sure how well this would work.

That's surely not a big problem, but it does not fit easily into our early approach of controlling motion only at will. So we might need to consider this early.

[Julio Jerez]

more coolness.

I now completed phase two, enabled all of the arm 6 degrees of freedoms. And it is a full black box.
all worked as expected without major problems.

there are some minor implementation problems that can be made better like the rotation can go into gimbal lock, but nothing that could not be addressed.

other that, that the arm works as expected and we can now move to phase three, making the gripper move and pick objects.

we are now one more step closer to start experiment with more sophisticated rigs.

[MeltingPlastic]

what is regularizer in ndJointIkEndEffector::SetAngularSpringDamper(ndFloat32 regularizer...) ?

[JoeJ]

Just saw this:

I wonder if Ubisoft is already using this in current games?
It's good, and i guess it becomes the AAA way of dealing with the problem.

[Julio Jerez]

a regularizes is a trick use in linear algebra that let you deal with numerical error.

say you have a 1 x 1 matrix.

A x = b

the solution is x = b / A

that's the simple linear system you can form.

say that now A is a 2 x 2 matrix

now the solution of that system is
x = A^-1 * x

but inverting matrices is very expensive and numerically unstable, many systems what the so is that the factorize the Matrix A into a product of matrices that are easier to deal with numerically. Ans solve the system.

A = A0 * A1 ... An

Them
A0 * A1* ...An * x = b

And now we can say.

Let
A1* ...An * x = x0
...
An * x = x1

And we get A0 * x0 = b

If A0, A1, .. An are easy to invert matrix, or that allows a solution by inspection, them the system be solved
By solving a series of simple systems without inverting the generic matrix.

Good candided for factorization the ones that factor the matrix into products of triangular matrices, orthogonal, diagonals, block diagonals etc.

some factorizations are: LU, RQ, LDLt, DDt (Cholesky), USV (singular value decomposition)
you can look that up in Wikipedia.

in physics of rigid bodies, matrix A belong to a class knows Positive Semidefinite.
this is, matric A, which has nice properties one of which is that it can be factored as LDLt or as DDt,

Here is the problem. When factoring a matrix in the form of DDt or LDL, the main diagonal has to be always positive. That's the big problem because every time we have a system where small changes of the right-side vector b lead to big changes on vector x, this means the diagonal will have large values and small values and the process of pivoting will lead to the large numerical error and an partial diagonal can become negative.

for more than 70 years, since people are trying to solve this kind of system using computers, people has tried to figure out how to solve that problem and one of the solution of is the regularization of matrix A.
This adding a small positive constant to the main diagonal of A so that it never becomes negative.
this is, solve

(A + r) x = b

when r is a diagonal matrix of positive values.

this now bring a different problem because it means the solution now an approximation, since it made the diagonal bigger.
so the second trucj is to also add a penalty to the right size of the equation, therefore the final equation is now

(A + r) x = b + p

where r is the regularizer value, and p is a penalty vector

now is just happen that is you have a spring damper system, and you calculate the forward implicit derivatives for the solution the equation is almost identical to the one about and each term can be mapped, to that extended linear system.
so in the end r and p can be made equal to the terms that made an unconditional stable spring damper system that can be made very strong.

you can interpret it as follows,
you let the solution to have some error on the left side, and then you make up for the error with an implicit spring damper on the right side.


Joe, I think that neural net training. Nothing really spetial.
The problem with this system is that they are not that cheap to run. The need some kind of representation of the environment, which could be in the form of rendering par of the scene, or sampling it with a ray cast and feed that to the neural net.

My point is that I believe if we separate the physics from the
Leaning, the traing is way simpler.
But let us see how we do with this new tool.