Development of self balancing biped with inverse Dynamics

[JoeJ]

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

Well yes, but legs don't have sliders or any form of shock absorbers, so i was referring to your comparison of 'sloppy soft joints' vs. accurate stiff joints, with the former giving an unintended advantage.

my guess is that are using generalize coordinate system solvers

I saw a short YT video where they showed one of their computer simulations. It showed a simple robot visualization of ZMP, support polygon, things like that. Sadly i can't find it anymore.
The quality of the simulator was terrible. It did jitter like hell. Any shitty game is way better. I was pretty surprised.
Now i think the kind of quality we would expect did not matter to them, and making it looking nice was no goal either.
My own experience did kind of confirm this later. Details did not matter. I did not predict in which frame the foot would hit the floor as proposed above (that was just a game of thought to spur some inspiration eventually). Also things like unique joint / body states did not matter. My way of calculating a pose from pendulum was just hacks and lacked any accuracy. But it worked regardless to keep the ragdoll in balance.

All that mattered for balance is the summed COM of all bodies, and precise control of that. Small errors or perturbations coming from collisions have little effect on this.
But Newton moving the contact from the toe to the middle of the foot for just one frame was enough to make the ragdoll fall a moment later. That's a small error too, but this one had a huge impact on diverging from the prediction of the controller under motion with unstable balance. The only way to compensate such error would be to make a step, but i did not want to do this without prior understanding the true cause of the problem.

Maybe my method is more global, while yours is more about local detail. Thus we face different problems. I don't know. But what i try to say is: To me, the true cause and solution of a problem always turned out to be completely different from what i had expected. And i would not wonder if this happens to you too, although you are an expert on physics already.

[Julio Jerez]

Well, I am making too many predictions.
It's time to get the feature working and see the potential.

If it gets half of what I say, I will be a happy camper.

[Julio Jerez]

I now have the immediate solve going.

does not do anything yet because the result are no being applied to the joint, I will do that later.
but is seems to work wigh any different in behavior.

this is how is used.

Code: Select all

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

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

      ndSkeletonImmediateSolver solve;
      solve.Solve(skeleton, world, timestep);

      // use solver result to set joint motors
   }



then after the call to solve.

the function will iterate over the result using them to set the joint motors. here it could check for limits, or thrown the results out and try again use a different setting, all kind of

for this case what I will do is make a RobotHinge, that will set the motor off on the called, them use the result form the call to enable the hard motors.
the cool part if that now the app has all of the result before the solver.
I will try that tonight.

[Julio Jerez]

I am now back on this.
I completed the solve last weekend, but does not work for one reason.

In 3.xx the solver work based on island.
Each island was separated from other island,

The solver operat on an array of joint an bodies.
But it need some vector of values for each body.

So in the preporces face, ieach body get an indirect index to where the solve data will be placed.

When working g with island two bodies in two separate island can point to the same index, but the data is in separate array. Share bodies can only be static, so each island had a sentinel proximity tha represented all the static bodies.

For 4.00 the solver is global, so each index is unique.
This mean that even when two island are resolve in paralleled, the only only static bodies can be shared, but the solver has no effect on them.

This is now a big problem for the immediate solver, each model is it own island, so the body index die not match the index in the vector array.

I need to some how made changes on the Skelton solver similar to 3.xx do that it uses a double Indirection.

What I am doing is that I am copying the functions that uses the body index a d editing them, because I do not want to touch the current solver.

After I get the working, maybe I unify them with a couple of template driver funtionto read the index that map from a body to the advance arrays.

[JoeJ]

Ha, i have quite the same problem currently. I hate resolving indirections. There is no good way to do it. >:(

Off topic, but saw this nice work on building destruction. That's what i have in mind. I intend to add more detail like cracks with some post process maybe.
https://youtu.be/TCJq_2-q34k
Is this like what you plan to add?
Otherwise i think i could make some flexible / breaking joint myself. I only need this offline, so issues like jitter would not matter.

[Julio Jerez]

oh, the good knew is that I forgot that rigid joint was the root of the problem that I had in the pass.
and her I was try again with same rigid joint again.

Code: Select all

m_effector = new ndJointKinematicController(parentBody, m_rootBody, pivotMatrix);
....


that joint is very good for simple thing scene, like moving around stuff, of fix some object to a scene with friction and braking forces, stuff like hanging pictures, lamps, land post, picking objects and sop on.

when using as an effect to calculate precise forces, is simple brake down, because the joint work in the friction limit, basically it is a ramp, it applies a force until it can't any mode.

so that why when attached to a forward dynamic change, is simple fail because too strong friction make apply strong forces, but that strong force is applied as long as the error between target and current location, is not zero.

so for debug I edit the robot making 3 dof, and the fail was still there.
them I try with a different joint

Code: Select all

ndJointAttachmentPoint* joint = new ndJointAttachmentPoint(pivotMatrix, parentBody, m_rootBody);

and voila, is it very stable.

them I remember that I did make that kind of joint based on PD for the balancing rag doll.

Code: Select all

ndJointKinematicChain* joint = new ndJointKinematicChain(m_rootBody->GetMatrix().m_posit, pivotMatrix, parentBody, m_rootBody);

and all that jitter went away.
The reason that the PD, succeed, is that it takes time to apply the force, so it filters small errors, this is because a PD joint has a Damper, a Damper * kinetic energy from a system and burn it away, while the kinematic joint is a "not error no force applied", "but if error, then apply two equal and opposite forces", therefore the energy is conserved, but conserve energy as oscillations.

Another cool thing about using PD joints is that they deal better with under and over determined systems, and that's always tricky to get right.

anyway, with this rig I can now go on to calibrate the immediate solver.
I fixed the indirection for the immediate solver but to my surprise, it kept failing until I realized I were making that same all big mistake again.

on that, that destruction thing, the joint is there, and I have a demo, but run too slow for real time so I commented it out until I get the GPU version.
but that's going to take some time. until I get the Sych thing if is going to even work.

[JoeJ]

on that, that destruction thing, the joint is there, and I have a demo, but run too slow for real time so I commented it out until I get the GPU version.
but that's going to take some time. until I get the Sych thing if is going to even work.

I did some uncomment, renames and includes, but i still lack types like dVector or dInt32, e.g. in ndBasicFracture_0.cpp.
Are those still there in Newton4, or should i better use 3 instead to reactivate the demo?
Does not have to be realtime for my offline needs, so i could use it. Not really in a hurry, though.

[Julio Jerez]

Oh, yes I commented them out before renaming the basic types and classes.
I will un comment them a make sure they are working tonight.

I just realized that the robot demo is actually two demos.
It is too difficult to have the demo with the effector driving the robot then using the forces to calculate the joints accel.

So will save it, rename it and first make the moder using the effector, and once we have that one going, the we make the secund, and use the first as the control to compare to.

This allows for separating the source of error.

[Julio Jerez]

ok new update.
set up the demo using the immediate solver, ...\ndSandbox\demos\ndAdvancedIndustrialRobot.cpp

and I am very happy with the result so far, and so surprised that it seems too good to be true so I double check to make sure there was not a mistake.
now Joe and anyone following this you can check the update function and see how is work.

it is no even doing anything special just mimicking the one with the effect attached as part of the robot and already seem to work so much better.

the solver sees the robot with just forward IK joint that happen to have the correct acceleration set on them but an expert animator.
this is so early, and I am sure there will be few bugs and modification, but the potential seems very powerful.

[JoeJ]

Yay, looks very good!
The final hand bone keeps twisting and doesn't settle at the target in both demos currently, but upper/lower arm show perfectly responsive and natural movement. Game changer confirmed

Btw, instead of a GUI, personally i use a 3D gizmo to set targets for testing. Dragging this with mouse is more intuitive, allows to find failures more quickly, and can map my natural human motion to the application.
Though, making a good gizmo is a lot of work. Even after decades i'm never happy and keep improving it. There are multiple libs out, e.g. this here: https://github.com/CedricGuillemet/ImGuizmo (not tried any myself)

Not really necessary ofc., but may be worth it.

[Julio Jerez]

Oh wow, those inguinal gizmos look very cool.
I have to upgrade to the latest inguinal, and I see if I can integrate those new tool.
I like the gizmos, the time line and the node system.
They seem a good fix for many of the stuff I am planning.


On the head of the robot not tracking. That's not been controlled yet. That's phase two.

I know you said that the limits are rarely hit. And I also seeng how animators rig Skeletons in such way that limits are avoid.
But in reality a limb like a human leg or arm operates must the time at the limits.
Take for example an arm. When is full extended, the elbow is always hitting the limit.

So the next step is setting a series of joint limits and add the code to handle that. In particular I am interested in handling the cases when the arm in fully extended and multiple solution are mathematically valid but only one is of interest. That has proven to be quite a difficult challenge.

But fir a balancing character that is meant to look human like, this is important.
If you look at almost all of the humanoid robots out there, you will noticed that alway the leg are flexed even when standing tall.
What the engineer do is that same animators do, tge set the limit in such way that the knee angle is never zero.

The difference is that an animator can hide tge Skeleton, so that when standing the angle at about 10 degrees. But a practical robot, they can't do that so the robot walk funny as if they where lifting a heavy weight.

I want a system that can operate just as well on the limit as it does when inside the limits.

[Julio Jerez]

My goal is to achieve something like this.
https://youtu.be/fn3KWM1kuAw

[JoeJ]

Take for example an arm. When is full extended, the elbow is always hitting the limit.

In this case we are at the limit, but at the same time we usually have no reason to violate it.
E.g. we grab for an object out of reach. We will fully stretch the arm, then we notice it is not long enough - no need to rotate the elbow further because this would only shorten the arms total length.

Also, for tasks like walking and running, we may slide at the limits, but we never intend to violate them. Because evolution made bodies a good design for the things we usually do.

That's what i meant with 'we can ignore limits for basic locomotion'. I was referring to the motion planning, not so much to what is actually happening physically.

Still, my recent work on IK is all about planning with respecting the limits. It's needed for many actions. Pointing with a gun, lifting up objects, etc. Not to mention complex tasks like repairing a car with stuff being hard to reach. Ideally we can do this while avoiding the characters looking stupid.
Melee combat is probably a very hard challenge too, but one we really want to support.
We will see how far we get. Initially, having simple locomotion is enough to revolutionize how games are made.

My old IK solver is dumb. In case violation would be needed, it just slides on the limits and fails to reach the target, but it tends to improve over time and will still find it later.
The new IK solver is clever and finds a working solution if it exists in one step, but in practice the old one still is better.
The problem is: With multiple solutions there is a lot of flipping between them. If i move the target just a bit, the closest solution may vary wildly. Minor perturbations on input can cause huge variance on the output. Behavior in such cases is much dumber than just sliding on the limit and not reaching the goal.

I'll keep trying, but lacking any higher order system to control behavior i'm not sure if a low level IK solver can deal with this well.

What adds to the confusion is the multiple objectives we might have to plan the motion of reaching some target. I tried with those objectives, iirc:
Minimizing change from current state
Minimizing energy to hold the pose (e.g. elbow points down due to gravity)
Minimizing energy to reach the pose (elbow might end up more horizontally)
Respecting target orientation of hand, or just focus on target position to plan for upper / lower arms.

Eventually i could weight all those objectives, reject outliers given the current state, and so get a more robust selection of the best solution.
This might work without higher order control, but it will increase the costs as well.

So a t the moment, i'm very unsure if my work on a smart IK solver is worth it.
The dumb one is fine for very most things and has none of those problems.

You know other people try to get there using Machine Learning. This surely works, but may lack the precise control we need for games. It may also miss the goal to get rid of expensive motion capture.
At some point we might need to join forces with ML community, but initially i'm convinced we can have the better start with traditional engineering.

[Julio Jerez]

What machine learning does is that it figure out the work space of the effector.

I would not want to dedicate an enormous amount of processing to that.

To me if you get a robot that does the proper physics.
Then adding a neural net or a genetic algorithm can do a far better job because it will code data for the motion and not for sorting out bad physics randoness.

Right now all the demo, I'd seen of simulation of walking robots using machine learning, what the machine learning code does is making up for the bad physics.
I want to avoid that

[JoeJ]

It's probably important to talk about the joint limit itself.
I guess you want to start with a cone limit, but you have to keep in mind that's not enough. So if your solvers end up limited to that, we have a problem we should realize early.

Maybe you remember the debug visuals of my joint which i had submitted as a sandbox demo years ago.
I always thought this is modeled by two cones, bounded by two planes to connect them.
But recently i figured out that's not it. There are no planes at all, the bound is also modeled with cones.

What we really want is an elliptical limit. But because this lacks closed form solutions, the cones method seems a good compromise.

However, there is also a common cones solution which i see often, for example here:
http://docs.autodesk.com/3DSMAX/13/ENU/Autodesk%203ds%20Max%202011%20Help/index.html?url=./files/WSf742dab041063133364ce93112a1ceaa7a-7fde.htm,topicNumber=d0e221286
But this is very bad as it creates sharp minima where the joint might get stuck. (Havok also used this)
By tilting the cones properly we can avoid this, and the cross-section has a nice pill/capsule shape without minima or sharp discontinuities.
You could look up my old stuff if you don't know what i mean, and i can post some images / code if you want.