Walking ragdoll :)

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Walking ragdoll :)

Postby JoeJ » Sun Sep 20, 2015 8:17 am



Not very impressive yet (notice that spine and arms are stiff, so it can't look natural).
I still have problems to control how fast things move accurately and thus i can't do it the way i want to...

As a work around i have set up some hacky walking by manual tweaking.


Simultaion runs at 120 Hz using standart joints.
60 Hz seems too soft to be useable at the moment.
I think hard joints would be necessary for 60 Hz.

Up to now i was not able to get it to work with hard joints, because the contact forces are quite unpredictable. Balancing on moving platforms with both feet works somehow, but as soon as i move the weight on only ony foot, contact forces may suddenly change by a big amount, bringing the ragdoll to fall.
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Walking ragdoll :)

Postby Leadwerks » Fri Apr 07, 2017 1:06 am

That's actually amazing.
User avatar
Leadwerks
 
Posts: 569
Joined: Fri Oct 27, 2006 2:54 pm

Re: Walking ragdoll :)

Postby Julio Jerez » Fri Apr 07, 2017 10:33 am

This is actually quite impressive yes. The reason is that all of the paper that implement physics based controller that I have read, all run the simulation form 1000 to 2400 fps, which defeat the purpose and made then on academic value only.

The commercial one like endorsing natural motion are, as good as the look in demos, they are really atrocious and do no really work in practice, the the reason not one has adopted them.
There are some game like GTA that in the credit they licensed the technology, but they do not really use it, the that only legal contractual obligations, thrust on that me I know that for a Fact. GTA does no use Natural motion for rag doll animation.
I am now starting the final Ragdoll animation with the self balancing controller.
It will be some one similar to Joes model, but will have some differences.

this new system will be base more on extracting pose form low dimensional representation of animation take form eighth motion capture or hand made animation, this will simplified the controller design.

this will be all base on conventions external feeback information to virtual angular displament, that together with the joint angle will be the input to the joint motors.

I already start part one with in the solve of the virtual displament angle, is call the Inverse kinematic system that I committed ladle

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.

so all ideas, suggestion, desired functionality are welcome.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Walking ragdoll :)

Postby Julio Jerez » Fri Apr 07, 2017 10:37 am

I moved the topic to general discussion seems it is now a new research feature.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Walking ragdoll :)

Postby Julio Jerez » Fri Apr 07, 2017 2:15 pm

Joe if you are reading this.
can you talk a little about you approach?
I am now committed to the final controller.
As I remember you are using motors, but the I am still a little confused when you talk about contact forces at the feet.

The way I see it, we should strike to eliminate the use of all forces and move to a motor only approach where torques are only the capacity for the joint to generate torque.

anyway of you are reading this please replay and tell me where you are at since this is quite old and lot stuff had changed since them.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Walking ragdoll :)

Postby JoeJ » Sat Apr 08, 2017 9:45 am

Julio Jerez wrote:As I remember you are using motors, but the I am still a little confused when you talk about contact forces at the feet.


I use the same motorized joint i've added to the joints demo, nothing more.
(I also used motorized distance joints, but no need for them anymore with actual exact joints)

When talking about contact forces, i never modified them directly, i visualize and measure them to proove the center of pressure behaves as intended. But they are not fet back to the controlloer or anything.
So nothing special about contacts. They may be the weakes link in the chain of simulation and so they are interesting.

Julio Jerez wrote:The way I see it, we should strike to eliminate the use of all forces and move to a motor only approach where torques are only the capacity for the joint to generate torque.


Yeah i already did that in the video above.

I have no major progress since that. Still working on realtime GI (still months of work... it's huge).
Some time has passed... my memory is a bit rusty about details.

Later the day i'll write up some overview mixed with feature requests... :)
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Walking ragdoll :)

Postby JoeJ » Sat Apr 08, 2017 12:19 pm

... 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.
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 18 guests

cron