Inverse Dynamics Robot demo questions

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Thu Dec 21, 2017 8:15 pm

ok guys, I found the bug, and it was that I was no connecting the jix joint at the tip of the legs to the Ik solver.
The system was calculation to leg torque, but not hang any ankle point teh leg where just move uninterrupted.
I learn for this that the teh system need a Inverse dynamics contact effector, because contact do no really behave like a kinematic joint, so expecting the to hold the leg like a kinematic joint would is a huge stretch. what happen is that the inverse dynamics sees the joint and calculate the join torque to maintain the leg in place, by the leg effector does no know about friction, so if the friction torque is too strong teh teh joint torque is also too strong and the real contact will simply slide out of control.
if the effector force is too weak, the ik will sleep and teh body will move by it own inertia.
teh solution is to make a user contact joint like the vehicle. that way it will calculate a better approximation.

for now I just lift teh body on the air and fix the leg with a fix joint on each leg.
teh body seem stable which is a pleasant surprise given that teh hole system is extreme over determine.
now I will continue adding the other joint and apply some animation of teh main body and see how it goes. but so far the result are corresponding with the math.
so we keep going to teh next challenge.

No wonder when I try this we the self balancing humanoid, I has so many problems.
I believe once we clear these know how, implementation problems, that teh self balancing character will successful.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Fri Dec 22, 2017 12:43 am

Ok guys I added a quick and dirty demonstration of what it is that I am talking about.

Joe and Sweenie please tell me if you guys think this new technology has potential.
More importantly tell me is a self balancing player that do not required animation and look natural
is possible or not.

I am so glad I decided to takle simpler demos, becaus eit cleared so many thing that I did not considered.
But in the end this method is very similar to what a biological system really work.
one thing that comes to mine, is how a creature like that can be programmed trough a genetic algorithm or any AI. :lol: 8) :o :shock: :) :D :idea: :twisted: :mrgreen:

any way I now need to add the joint limits, because the moment any joint hit a limit, the result are unpredictable, most likle it flips. Is is not really a show stopper issue, I believe we now has those all resolved, I just has not put the time because I wanted to proof that the insight was valid first, before making solver changes again.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby Sweenie » Fri Dec 22, 2017 8:03 am

Hmm, I'm getting an exception.

First I see this...
Image

and when I debug the application it stops at in line 928 in dgInverseDynamics.cpp
Code: Select all
auxiliaryRowCount += node->GetAuxiliaryRows(jointInfoArray, matrixRow);

Image
Image
Sweenie
 
Posts: 492
Joined: Mon Jan 24, 2005 7:59 am
Location: Sweden

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Fri Dec 22, 2017 8:12 am

oh that bug has hunted me over and over.
i thought i have it fixed, but obviously not.
I think my fix only considered pointers size in 32 bit mode, you are compiling in 64 bit.
Could you try the 32 bit configuration build to see if my assumption is right? please.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby Sweenie » Fri Dec 22, 2017 8:22 am

Yep, it works in 32-bit, and the hexapod is AWESOME! :D :D
Sweenie
 
Posts: 492
Joined: Mon Jan 24, 2005 7:59 am
Location: Sweden

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Fri Dec 22, 2017 9:08 am

ah thanks, I found the bug in macro dgAlloca,
I believe its fixed now, Please sync and try the 64 bit again. tell if is fine for you in 64 bit mode
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby JoeJ » Fri Dec 22, 2017 9:20 am

Yeah, awesome! It would be a lot of work to do this entirely myself. This opens up a new way to utilize physics in games... no matter if you succeed extending this to natural balanced bipeds or not. I'm sure this is the kind of technical progress that moved computer games forward in the early days - it's so much more than just walking characters. I'm less sure how long it takes until game designers get used to it, but that's another story.

Julio Jerez wrote:More importantly tell me is a self balancing player that do not required animation and look natural
is possible or not.


I think the jittery look also comes from the behaviour to reach and keep the target as fast as possible. We need some max acceleration / velocity so the whole thing moves slowly. Would this be possible already by adding those limits to the joint code? I guess yes.
User avatar
JoeJ
 
Posts: 1160
Joined: Tue Dec 21, 2010 6:18 pm

Re: Inverse Dynamics Robot demo questions

Postby Sweenie » Fri Dec 22, 2017 12:08 pm

Julio Jerez wrote:ha thank, I found the bug in the macro that does the alloca,
I believe is fix now
please sync and try the 64 bit again. tell if is fine for you in 64 bit mode


64-bit works now as well. :)
Sweenie
 
Posts: 492
Joined: Mon Jan 24, 2005 7:59 am
Location: Sweden

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Fri Dec 22, 2017 12:21 pm

Ok cool. I also tested the double precision and they all seem fine.

It is tenting to move on and try to make the state machine to control different motions, I am sure that will expose some more challenges, but now I need to get the solver to deal with limits, the limb joint now are like this
Code: Select all
      void SubmitConstraintsFreeDof(dFloat timestep, const dMatrix& matrix0, const dMatrix& matrix1)
      {
/*
         dFloat angle = m_curJointAngle.GetAngle();
         if (angle < m_minAngle) {
            dFloat relAngle = angle - m_minAngle;
            NewtonUserJointAddAngularRow(m_joint, -relAngle, &matrix1.m_front[0]);
            NewtonUserJointSetRowMinimumFriction(m_joint, 0.0f);
         } else if (angle > m_maxAngle) {
            dFloat relAngle = angle - m_maxAngle;
            NewtonUserJointAddAngularRow(m_joint, -relAngle, &matrix1.m_front[0]);
            NewtonUserJointSetRowMaximumFriction(m_joint, 0.0f);
         } else {
            NewtonUserJointAddAngularRow(m_joint, 0.0f, &matrix1.m_front[0]);
            dFloat accel = NewtonUserJointGetRowInverseDynamicsAcceleration(m_joint);
            NewtonUserJointSetRowAcceleration(m_joint, accel);
            NewtonUserJointSetRowMinimumFriction(m_joint, -m_torque);
            NewtonUserJointSetRowMaximumFriction(m_joint, m_torque);
         }
*/
         NewtonUserJointAddAngularRow(m_joint, 0.0f, &matrix1.m_front[0]);
         dFloat accel = NewtonUserJointGetRowInverseDynamicsAcceleration(m_joint);
         NewtonUserJointSetRowAcceleration(m_joint, accel);
         NewtonUserJointSetRowMinimumFriction(m_joint, -m_torque);
         NewtonUserJointSetRowMaximumFriction(m_joint, m_torque);
      }


as you can see the do not summit limt at all, you can see this when in some position one or more leg find the alternate IK solution.
This will only get worse as more limb are added because each limb add a permutation of new solutions, so the best elegant way to prevent that is by having the solver obey the limits.

then the next step is to make the legs end effector to mimic friction joints, so that the creature can land on its feets on the ground.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Sat Dec 23, 2017 5:18 pm

Ok I am now working on the limits, hope I can get it today, there are some tricks that need to be resolved but I hope is not a big problem.

Sweeney, on this
Sweenie wrote:How will the kinematic controller for the body be handled? Do you have to calculate the position for the body controller based on the midpoint for each leg?

I suppose you calculate a midpoint based on all feet positions and then allow some limited linear movement to make the body move up/down , back/forth and sideways.


Now that we can see where we are going with this, you can see how the body can move independent of the feet, you can see that all those explanations that people has come up in the pass 20 to 25 years since they try to animate objects with pure IK are just special cases of more general solutions.
These trick of averaging a position based of the location of other positions work only because there are part of the general IK solution. we can use that of course, but I expect a lot better or I will consider the effort a failure.
The problem with those thicks, is that the make the animation look robotic and for good reason.
Then the same people who come up with the trick tell you that IK animation look robotic.
https://www.youtube.com/watch?v=QdQL11uWWcI
I really believe that teh system we are developing now can make Asimo walk like a real human being not like these pathetic robot sequences that we see in the video.

It is my contention that biological locomotion is not as difficult as people think it is. if you think about every living creature that is not a plant has independently evolved a way of locomotion.
we see locomotion with not leg (some reptiles and bacteria), with one leg (the flagellum), with tow legs, with four legs, and with 6 or more legs, even with hundred of legs)
This is telling me that locomotion is not really that complicated.

I also put it there that biped locomotion is way simpler than quadruped, six or more leg locomotion.
the reason I say this is that a biped locomotion has no closed loop since a biped walk really keep both legs on the ground only when resting.
Multiple limbs locomotion is in full on kinematic loop that needs to be resolved perpetually weather these is a biological brain of a digital CPU, a lot of resourses has to be dedicate to calculate the balanced of these loops.
you can see this in the evolution of predator dinosaurs, as they become more intelligent they the traded walking on four leg for walking in two legs.
even today quadruped predators like tigers and cheetahs gallop in two legs when they chase a pray. that's just me speculation and observation.

what I think is that biological locomotion works similar to the way the system we are now developing works. there is a brute force system that is in charge of controlling the limbs, this system is the one that convert desired location to muscle tension and it works by trial and error. so it does not need high level programming, just instinct.
you can see this even on dead animals, the nervous system still react to stimulus even after the animal is dead. In our system this is represented by the physic system.

Then there is another high level system that learn some sequences of motions and this is like a neural net that can be programmed by examples and can even modify its programing. but for these to be effective it needs reproducibility and the only way, in my option to get that is by working on the geometry of the system ignoring the physics of the system.
it will be impossible to program a walk cycle by storing muscle forces because muscle forces varies hugely with the environment, on the other hand is easy to store the sequence and add small variation to adapt to the environment.

so to conclude my rant and speculations, I believe all the mombojumbo we has learned in the pass 25 years is just, or at best a special case of a solution that work on a very narrow range.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby Sweenie » Sat Dec 23, 2017 6:37 pm

So in a way one could say that you are simulating the spinal cord which will handle the muscle control and maybe balancing, and the controller(brain) will just tell the legs to move?

Here is an interesting article about dead animals moving...
http://sciencenordic.com/why-do-headless-chickens-run

Ever heard of the headless chicken that lived for 18 Months?
It wasnt completely headless though because some part of the lower brain was still intact.
Although very interesting its horrible that they let it live for so long.
Sweenie
 
Posts: 492
Joined: Mon Jan 24, 2005 7:59 am
Location: Sweden

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Sat Dec 23, 2017 7:41 pm

oh wow, that article captured precisely what i was trying to say in my long post.
yes basically a motion sequence run on automatic pilot that is controlled by some sub system that keeps doing what is told until the high level change the intruction.

what is new here, is that i believe we now have a was to emulate such systems matematically and sytematically. and it is now clear, at least to me, that the method generalize to all kind of locomotion. that level of simplicyty is what keep me excited.
There not such thing as human locomotion, if anything human locomotion is one the simplest locomotion and all locomotions is natural.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Inverse Dynamics Robot demo questions

Postby JoeJ » Wed Dec 27, 2017 4:34 am

Julio Jerez wrote:teh solution is to make a user contact joint like the vehicle


Yeah, i don't know how the vehicle uses that, and i have no clear vision of how a user contact should look like, but i'll repeat the issues i've seen working on the IP balancing controller:

I use a simple 2 bodies setup, a foot box and a long body box that is upright. Goal is to swing the upper box around the single ankle joint to have control over the COM position relative to the support polygon around the ground contacts. (So the physics system is very simple and IK is not necessary.)

The problem is that for a short period of time it will happen the contacts go from the corner position to the edges, shrinking the effective support polygon. This happens because the foot box gets rotated by very small angles and does not keep perfectly parallel on the ground, which i understand is unavoidable and would happen on non flat ground anyways. Note that i could fix this simply e.g. by attaching small compound spheres to the foot box at the corners, but user contact may offer a better solution.

The result of this is that for short time there is less contact force than the controller predicted, and it gets immideatly impossible to prevent the model from loosing balance in the near future. (This is no problem for walking - you simply can correct your next step, but it is a problem if you stand still and want to move just your upper body. Humans do this a lot.)

This is also the reason why bipeds are much harder to control than other animals: Their COM is very high and the support polygon is small. To do efficient movement, we need to operate very closely to the risk of tipping over all the time, assuming the support polygon remains as large as possible. Try to stand still and swing upper body forth and back: You use high force on the feet edges. Their upper limit is not your strength, it's the laws of physics of the inverted pendulum. So neither Superman can't do this swinging faster than you can, nor a better brain or IK system can help.

To get efficient movement a robust and predictable contact situation is necessary. I think of raycasting from the foot corners downwards and maintain user contacts even if there is a small gap between foot and ground, or to use soft body feet. Sounds hacky but you get what i mean and maybe you can take account for this when designing user contacts.


Also remember my idea of using just a single (user) contact for each foot. If we move it around at will we get direct control over the center of pressure position. The system becomes a huge whole lot easier to control and probably even more responsive and faster to compute. As long as we keep the contact inside the support polygon this would be no cheating, but it's an optimization for games and not suitable for real life robots. Not sure about how to express friction with just one contact, but at least for a 'many robots' scene the idea has potential.
User avatar
JoeJ
 
Posts: 1160
Joined: Tue Dec 21, 2010 6:18 pm

Re: Inverse Dynamics Robot demo questions

Postby JoeJ » Wed Dec 27, 2017 6:40 pm

I looked quickly at the vehicle and so far i assume:
1. You get a list of contacts if as they happen
2. apply custom forces when they get processed.

Would it work it a bit different as well?:
2. Modify their positions but then Newton continues us usual.

Should be already possible, can you give me a quick guide?
User avatar
JoeJ
 
Posts: 1160
Joined: Tue Dec 21, 2010 6:18 pm

Re: Inverse Dynamics Robot demo questions

Postby Julio Jerez » Thu Dec 28, 2017 7:58 pm

that was the quick solution that I implemented to solve the problem of calculation rubber contacts.
IT is no mean to be a definitive solution, by here is how is works. basically you make a material and register a callback that is use to replace the low lever narrow phase for calculation contacts.
you can see the setup in the file
..\sdk\dCustomJoints\dCustomVehicleControllerManager.cpp

Code: Select all
   // create a tire material and associate with the material the vehicle new to collide
   for (int i = 0; i < materialCount; i ++) {
      NewtonMaterialSetCallbackUserData (world, m_tireMaterial, materialsList[i], this);
      if (m_tireMaterial != materialsList[i]) {
         NewtonMaterialSetContactGenerationCallback (world, m_tireMaterial, materialsList[i], OnContactGeneration);
      }
      NewtonMaterialSetCollisionCallback(world, m_tireMaterial, materialsList[i], OnTireAabbOverlap, OnTireContactsProcess);
   }


and the function will put the contact points on the passed buffer
Code: Select all
int dCustomVehicleControllerManager::OnContactGeneration(const dWheelJoint* const tire, const NewtonBody* const otherBody, const NewtonCollision* const othercollision, NewtonUserContactPoint* const contactBuffer, int maxCount, int threadIndex) const

this could be a good solution but is has to be set in a better way.
one for a vehicle for example is not enough to just set material properties in a call back,
the contact generation itself is part of the problem, so what that callback does is that replace the function to calculate the contact point for each tire.

I thick we need to do instead, is the creation of a based class for contact and implement the default contact support like it is now, and then make different custom contact joints like was are doing with the bilateral joint now.
this can not be do but simple making the current joint a contact because they are suppose to allow only 3 dof, while contacts can have more and that just one difference.
I coulded do that differently but it would required a lot of work, so I decided for the quick solution.
Julio Jerez
Moderator
Moderator
 
Posts: 11147
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 3 guests