... so my approach can be divided to those systems, using the example of the ragdoll standing and balancing on a moving platform:
1. measure contact velocities do determinate the platform velocity.
2. Create a virtual Inverted Pendulum (IP) from the ragdolls physical properties.
3. The Controller calculates how the IP should react to keep balance, returning a new virtual IP pose for the next timestep.
4. Map the target IP pose to a new target ragdoll pose using IK.
5. Calculate joint angles to achieve this pose.
Most of the interesting bits happen inside the Controller. It is the only step where real physics calculations happen. The IP results in a system of position dependent acceleration leading to complex equations. Worth it's own discussion and research...
In my experience controlling a simple IP is hard and took most of my time. I'm still note done with it.
Step 4 introduces error.
The need to map from one virtial leg to two real legs is the most obvious reason.
Other things are: The IP can't change it's height, so i handle this with hardcoded transformations and hope additional error is small enough to converge over time.
I thought on extending the IP model with 2 legs or the ability to change height, but i'd not be able to handle the math.
But all those errors have no noticeable impact on tasks like balancing on moving platforms and walking in place (transfer weight over left foot and lift right foot then the other way around).
I can do this stuff as there are closed form solutions on how to do it most efficient.
I'm not sure why i failed on proper walking for now.
Either it's because walking is an underconstrained problem (you can do it in many ways, there is no obvious exact most efficient solution) and i hve not found the proper procedural approach to plan it,
Or the errors become too large and my system is too simplified to do it right.
Some thoughts about your upcoming work:
You know i'm no fan of using animation data, so i'd try to generate procedural animation instead using mocap and feed your system with this.
Now someone might think: Procedural motion results in unnatural animation, but i don't think so.
The video uses a simple procedurally animated state machine thingy. But even the spine is stiff the motion looks quite natural (imagine some Frankenstein guy).
If you agree, all this natural looking comes from the balancing, and balancing is math and not intelligency or personality.
We don't need to use machine laerning or analyze mocap for balancing, we only need to figure out the math. I believe this can be extended to walking and running with some simple additional given input.
Example is the one legged hopper i've made. I give additional input like: In air target height of upper body and also for the foot, max and min leg length, etc., and the entire controller is a closed form solution based only one physical state of bodies. There is no state machine, there are no values the robot needs to remember for the next frame, there is no manual tweaking. It's only math.
(not sure the term 'closed form solution' really means what i try to say)
So i guess at some point you might decide to ditch mocap as a requirement and keep it only as an option. If so you should prepare your initial code design to make later transitions easier.
Julio Jerez wrote:This is what I am focusing all my attention now, I hope we can all work together in one system an combine all the ideas rather that each trying to do separate system.
Agree. Problem is i have 1% of your math knowledge, and i can't communicate properly because i'm completely self-taught. Rarely i know exactly what the hell you talk about
Also maybe what you have in mind is completely differnt to my approach and just better.
So i'll try to follow, may do suggestions and you ask if you wanna know something specific.