Development of self balancing biped with inverse Dynamics

[Julio Jerez]

I will start adding this feature in the next few days.
It is amassing that is almost impossible to find a free model of an industrial robot, that can be use royalty free.

I once took a free turbo squid model, and few months later I had a notice that I could no use any of the assets in commercial product in any way or format.
Newton is free but I refrain from getting anything from them, that stuff come with very strong strings attach to them.

I usually get fbx model from, 3dpaint, but they do not have any industrial robot plus their stuff requires a lot of authoring.
if anyone has a free robot model that want to donate, I could use it.

[Julio Jerez]

I found a free robot model at free3d.com
They had a lot of coll stuff there and not string attache to them, so the is very nice.
so we are going to have this baby for demonstration

Untitled.png (69.55 KiB) Viewed 4626 times

I am authoring a little in Max because is all global space, and hard to use.
then after that it will be our test case.

of course, I could make it with boxes, but it always going in the situation of how close is to the real deal. with a realistic model, this reduces problems like the correct assignment of the dof.
plus it looks more impressive and nicer.

[Julio Jerez]

ok I now authored the robot.
-reduced the polygon complexity
-rigged the parts to a skeleton and saved as a fbx file that can be view by any editor.

in the sandbox side, I now start to make the model. so far only make the root body.
but I saw that I posted her so that anyone following this can see how the ndModel world.

I had taken me more than 10 years to introduce this concept of modeling of complex articulated bodies. But like almost every idea that showed in Newton first, it has gone ignored by even the most hardcore users. So I thought I try one more time, and maybe people can see how the project develop.

anyway, if anyone sync, you will find that the robot mesh is loaded, create a model, and place two instances of the robot in the world.
The robot now is just the root body, this is intentional to have a record of the progress.

Notice that these robots, are not fixed to the world, they could be placed anywhere,
and the end app can just fix them to world or something else, with a fix joint.

The cheap trick of making the root body mass static will not work for the inverse dynamics we plan to do next, we have to start moving away of these cheap tricks of playing with masses.

exit:
I now added all of the arm body part. and it all work as expected.

at the point we already have a mechanical robot. that rival many of the so call high end high falutin robot system simulator our there, and it is just one simple script.

now the next step is to read the effector.

and her is where is becomes interesting Joe, if you read this.

with the model, we can form the arrangement of bodies and joints. and we have them all at once.
the end has them too but at a lower level,

how the new feature what will allow us to do is things like. we add the effector to the Model, but not to the world,

in the Model Update, we connect the effector as a close loop joint and we solve to the bodies accelerations to reach a desire target.
we can do all the manipulation until we are satisfied.

then we calculate the Joint accelerations form the model solver update and we set that as the joint motor accelerations.
the engine solve will never see the effector because is not part for the world.
so what the engine solver sees is normal joint with motors.

you can easily check the validity of what I am saying by just grabbing the tip of the robot and place it around anywhere on the workspace of the robot, so if that works, then the effector is not much different.

[MeltingPlastic]

Following along!: https://youtu.be/-Pw69lVXbrU

[JoeJ]

in the Model Update, we connect the effector as a close loop joint and we solve to the bodies accelerations to reach a desire target.
we can do all the manipulation until we are satisfied.

Have you implemented this already?
Looking up the code it seems not. But i may miss it due to my noob OOP C++ skills

[Julio Jerez]

No, it is not there yes.
I only have the interface to make the call and that the prepare seen.

What come next is the call to the skel solver, and the loop the will iterate over the results, calculation the precise motor for each joint.

I am working on that part next.
But the point of the post was to show how to set up the scene.

BTW melting plastic your scene is very cool, an assortment of Robots, let us set if we can make them do a choreographed dance

[JoeJ]

It would be nice if you add the fixed joint to one of the two robots, so we can try that quickly.
As a first use for this, i would like to make dynamic platforms, connected to the static world and moved by simple robotic chains of 2-3 bodies. That's nice predictive gameplay like Super Mario had, and i need dynamic levels to showcase my GI stuff.
I don't want to use simple animated kinematic bodies for that. Using robotics, the player gains the the option to cheat / exhaust the game, e.g. by blocking the robot segments with some rock so they can't move anymore. That's kind of the stuff i expect from future games backed by proper simulation instead static animation.

I think of many such platforms. Something like 20-100. Each consisting of 3-4 bodies.
Do you think this makes sense considering performance?

I could also implement this on my own using simple IK solvers and joint motors.
But i don't think that would be faster, and using your system this would be no work to implement.

[Julio Jerez]

It would be nice if you add the fixed joint to one of the two robots, so we can try that quickly.

good point, request granted, if you sync, one of the two robot is now fixed to the sentinel body.
this is actually very good for writing the feature.

I think of many such platforms. Something like 20-100. Each consisting of 3-4 bodies.
Do you think this makes sense considering performance?

I am not really worried about performance. as it stands I believe we are in the ball part with any engine while having a generic solve that handle joint, contacts indifferently.

I could also implement this on my own using simple IK solvers and joint motors.
But i don't think that would be faster, and using your system this would be no work to implement.

yes this could be implemented with IK, and could be even faster, but it is not without problems.

for once, IK system will give you the position or angle, if you want any velocity changes you have to apply many tricks.
Ik can only agree with momentum based systems when the IK chain is a holonomic closed loop with a unique solution. ex the six dof robot.
this is not the case for over and under determined systems.

in these cases, the inverse dynamics is far superior because it consider the momentum and the masses distribution of the arrangement of bodes and joints.

you may think this is not a big deal, you only use closed holonomic systems, but that is in fact the exception of all cases. take for example a leg, on a humanoid body.

if you just consider the hip, leg, calf, and foot,
it is the same as the six dof Robot.
But when we consider leg connected to the hip alone with the other leg and the upper body, it is not longer a closed holonomic system. If it was, them every biped would walk exactly the same way, and as you know that is not the case.

finally, I do not want to deal with two different kinds of solutions. I want one that is generic enough and fix all.

[Julio Jerez]

if you sync. you can try picking the robot in the front with the mouse.

them you can see what I mean by the inverse dynamics been capable to deal with under and over determine system.

only when you gap the tip of the robot (last body the system is holonomic, but you can grab it by any point and you can position it at any location that the DOF allows.

that is just a kinematic joint that make the close loop.

so in a nut shelve what the feature will do is that the app will get the skeleton.
add the effector as a loop joint.
call for the solution,
them use the asccelertion to set the joint motors, and send them to the solver.

the solve see open loop joint chains with motors

basically this is the opposite to what the solver does.
the solve take the joint and calculate reaction forces generate by joints.
then add then to each body, and integrated them

here we calculate the bodies accelerations and use them to calculate the joint motors.

we can also goes a step beyond.
we can integrate the local solve to get the precises joint velocity and position, and use that to set
PD joints.
this will make no rigid solution but flexible ones like we expect for an organic articulation.
this will be the approach I will try with the self-balancing character.
one of the huge problems with the self-balancing character is how to dissipate the large amount of momentum in the body parts when ethe foot hit the floor.

in a huge or a living creator this is solve because the joints are elastic, so the energy is dissipated by the deformation of the legs when the hit the floor.
maki hard motors make them alike a single rig body and the body always bounce.
also even if you have a firm foot on the floor, and movement of the upper body part cause the same problem.

I tried the soft body hack, and that did not work at all. because I did not have at better understanding of the problem.

but anyway, let us see if we get this solver going with rigid accelerations first.

[JoeJ]

Tried it. Looks good till yet. Picking the fixed base body causes an assert.

one of the huge problems with the self-balancing character is how to dissipate the large amount of momentum in the body parts when ethe foot hit the floor.

This was no big problem for me, although i expected it would be one.
My controller based on the inverted pendulum assumed the ragdoll to be a single rigid body for the current moment of time, and the foot hitting the ZMP roughly as planned did not cause instability regarding balance. Even i noticed the ragdoll appearing too rigid (or too soft using old joints) in detail, as a whole it behaved well.
Back then i considered to model the visual skeleton more springy than the physics if necessary.

Maybe it already helps to model the foot with two bodies (toes and heel). I did this initially but at some point switched to a single body for simplicity.
It's an interesting difference between bipeds and quadrupeds. Not really essential, but surely two bodies are needed for high quality natural appearance.
Quadrupeds on the other hand differ from us because their back legs do not form a straight line. Their knees always have a bend, so the knee damps contact impulse.
The two body foot could do this at least for a short time until the heels gets in contact too.

Edit: I just took a walk and it seems my heels and toes always get in contact at the same time, and if not heel gets in contact first. So my idea won't help.
Seems the two body foot is only important to push the body forward from teh back foot with good friction.

[Julio Jerez]

Picking the fix base will cause an assert yes, this is new.

The base is attacked to the sentinel body by a fix joint, but the pick joint also attach the same body to the sentinel.

That's a no, no in newton, except when the other body is static. I added that assert recent to warn the user of that bad configuration.

I will problem made the check that assert only when the other body is not static.

[Julio Jerez]

Also Joe the body getting the strong impulse is a real inevitable problem when using strong rigid joints.

It is amazing how a good thing can becomes a bad thing when applyed incorrectly. We went for a robust solver, and it turn out that many of the app you see out there work, but they has not idea it works because many wrongs combi t to make a right.

Here is what happens.

Imagine a ball hitting the ground with some velocity.

At the moment of the impact, the ball receive an impulse that makes that make weightless for one frame.

If you do not believe me, maybe you can find in youtube video that show a classical experiment in physic 101, that consist on a heavy weight hanging from a weak string with another string on the bottom side.
If you pool the bottom string fast, you expect to break the top string, but the one the breaks is the bottom one.

That's because the principle for equal accion and equal and opposite reaction.

In the character, when the body part that are not the foot keeps moving constantly, the foot get all the forces with not dissipation in one tick.
Each velocity component that goes toward the ground is resolved back with an impulse that make the top body almost weightless for a many frames.

The reason for this is that time is not involved.
One way to I introduce time is to make the limps strong proportional derivative joints.

In that sence the people that do this using physic engines but appling ahoc spring damper, get good results, and the majority of them aren't even aware of that problem.

But tell you this, I rather have this problem and figure out ways of resolving it, than the bad physic and adjust spring danger parameter constantly in the same way a broken clock is right twice a day.

The pd joint are implicit by nature. So once they are strong enough, they will support the body while flitting onto tge violent impacts.

Of course all this we need to test.

[Julio Jerez]

Tried it. Looks good till yet. Picking the fixed base body causes an assert.

this should not happen anymore.

[JoeJ]

Also Joe the body getting the strong impulse is a real inevitable problem when using strong rigid joints.

It's not that i disbelieve you, or that i'm unaware about the things you say.
But what you describe as a problem could be seen as a property instead, and maybe from that perspective the solution is more obvious.

Some game of thought...
The impulse propagating through the system is happening no matter if joints are rigid or soft.
So the stiffness can't be the problem.
The problem must be the impulse, or the topology of the system.
But no - can't be true - we could not walk if our bodies were bad design, or if we had no contact with ground.
So you might conclude the subtle differences of rigid bodies vs. elastic flesh and blood is enough to cause the problem, but that brings me back to the first thought so we are stuck.
And i would give the example of Boston Dynamic robots which can walk fine even if rigid.

That's why i argue the impulse is no problem, but a property of the system we try to model.
But this system does not only consist of physics. There also is the choice and planning of motion.
It's a control problem. To avoid an impulse being too hard, we have to predict when and where the contact will happen, then we can counteract and turn the impulse into nice resting contact.

Obviously we can not get lively creatures out from only reacting to the current state of physics, we have to control physics by prediction and planning.

I guess you agree and know this, but maybe you did not consider this is already necessary now, if only to model contact for a very simple machine.

[Julio Jerez]

The impulse propagating through the system is happening no matter if joints are rigid or soft.
So the stiffness can't be the problem.
The problem must be the impulse, or the topology of the system.

no that's not true, just imagine two bodies connected but a slider falling on a floor.

if the joint is rigid, them both bodies will act as if there were a single solid and will be subject to the restitution.

if there are connected with a PD slider then the body hitting the floor will add and under restitution, the other body will experience the restitution impulse not as an impulse but as a reaction and will slow down for a few frames depend on how stiff the PD is. is this feature that will give the character the different behaviors properties.
It comes down to a very simple principle Joe. Conservation of momentum, the hard joint will
conserve momentum coming in, so the velocity of both bodies will be equal to the incoming velocity minus the restitution lost.
while the PD joint the damper of the PD will consume momentum and will be thrown away from the system. but is a controllable and adjustable faction.

What happen is that with some solvers the joints are soft, and the behavior comes out as a spring damper but not is a controllable, which look good but for things like ragdolls but no for making predictions which is the whole idea of this feature.

As for Boston Dynamic, my guess is that are using generalize coordinate system solvers. those solve deal with forces on the DOF. so is not too complicated to put implicit mass / spring/ dampers solvers that one work on the free dofs.
I believe those solvers are far harder than reduces coordinate systems. but who knows I am just speculating; their systems do look quite impressive.