forward-dynamics question
Submitted by qilu on Wed, 05/27/2009 - 13:57
Hi guys.
My project is to compare the human motion with and without a particular facility if the model is driven by the same set of joint torques. I tried to do as following, but it seems not good.
Here is what I did.
1). bulid a model including both human and the facility.
2). input motion data, do static analysis.
3). deactive the facility, do the inverse dynamics, just like a human model w/o the facility, and then train the joint.
4). keep the facility deactive, do the forward dynamics, save the analysis. This is consider as the case w/o the facility.
5). active the facility, re-do the forward dynamics. This is consider as the case w/ the facility.
Since I used the same training data as in step 3), the models in both cases should be driven by the same joint torques. That is what I thought and expected. But it seems not true, because when I check the joint torques in "Results" panel, (I thought they are the same thing as the training data), the torques of two cases did not match.
That makes me think if I can get the joint torques data, and drive the model directly, which is a forward dynamics problems.
However, what I have right now is just some motion capture data. I need to compute the joint torques using these data. I found that (if I'm wrong, pls correct me) LifeMod do this computation through "joint training".
My question are
1). anything wrong with the above procedure?
2). if it is possible to get the joint torques used in training. 3). if yes, how to apply them in the forward dynamics phase?
I realy hope somebody here can help me figure it out. Thank you guys.
Hi guys.
My project is to compare the human motion with and without a particular facility if the model is driven by the same set of joint torques. I tried to do as following, but it seems not good.
Here is what I did.
1). bulid a model including both human and the facility.
2). input motion data, do static analysis.
3). deactive the facility, do the inverse dynamics, just like a human model w/o the facility, and then train the joint.
4). keep the facility deactive, do the forward dynamics, save the analysis. This is consider as the case w/o the facility.
5). active the facility, re-do the forward dynamics. This is consider as the case w/ the facility.
Since I used the same training data as in step 3), the models in both cases should be driven by the same joint torques. That is what I thought and expected. But it seems not true, because when I check the joint torques in "Results" panel, (I thought they are the same thing as the training data), the torques of two cases did not match.
That makes me think if I can get the joint torques data, and drive the model directly, which is a forward dynamics problems.
However, what I have right now is just some motion capture data. I need to compute the joint torques using these data. I found that (if I'm wrong, pls correct me) LifeMod do this computation through "joint training".
My question are
1). anything wrong with the above procedure?
2). if it is possible to get the joint torques used in training. 3). if yes, how to apply them in the forward dynamics phase?
I realy hope somebody here can help me figure it out. Thank you guys.
Good morning,It sounds like ...
It sounds like the joints aren't quite behaving the way you're expecting them to, but they are behaving properly. The torque values generated by the joint controllers will change if you change the forces being applied to the model. Consider an extreme example - walking.
If you build a walking model without any imported ground reaction forces and train the joints after an inverse dynamics run, you will see a very small set of torques since no forces are acting on the model. Now if you apply ground reaction forces, you should see the same kinematics, but much larger torques, similar to what you are seeing in your model.
If you want to drive it with torques directly, you'll likely get unexpected kinematics and a strange solution if the model interacts with any objects.
Have a good one,
Dan
Dan's correct, the way the t...
Dan's correct, the way the trained joints work is to use a PD controller on the joint kinematics from the inverse run; therefore in the forward run the model will exert whatever torque is necessary to maintain the joint angles. So given two different constraint situations (with or without your device), I would expect the torques to differ.
There is no built in method to drive the joint torques directly, though it would be possible to do this in LifeMOD, though it is quite likely you would get unexpected results out. What you can do is:
1-5) Follow the procedure as you've outlined it.
6) Use the Postprocessor to plot the joint torques of the joint(s) you are interested in
7) Save these curves as spline data; there is a button in the postprocessor that can be used to "create a spline data element from a curve"
8) Make your desired joint(s) passive again.
9)Create torque drivers (available through the Adams Toolbox; push the toolbox button at the bottom of the main LifeMOD display window). You'll want to use custom torque definitions, and then use a function like:
akispl(time,0,.World.Rknee_sagittal,0)
where .World.Rknee_sagittal is the name of one of the splines youve created from the postprocessor.
10) run your analysis; now you should have joints driven by the torque curves from the previous run.
Hopefully this makes sense, good luck with your modeling!
Hi guys, Thank you for your ...
The torques generated by the joint controller depend on the inverse dynamics only (right?). That is to say, as long as the inverse dynamics scenario keeps tha same, the resulting joint torques should be identical. Even the scenario is changed in the forward dynamics (say more force is applied), it won't effect the joint torques, but the joint trajectroies.
What Dan said is right if the scenario of both inverse and forward dynamics are changed. But that's not my object.
Regarding Liz's suggestion. I ran the walking trial to check the joint torques. I noticed the toques exported by the result panel after inverse dynamics was extremely larger than that exported after forward dynamics. Why is that? Shouldn't they be the same? Which one is the joint torque generated by the PD controller?
Thank you both. Have a great night.
Qi
Qi Lu,I have a little free t...
I have a little free time and I see that you are perhaps still looking to better understand what is happening.
The touques generated in the forward dynamics simulation are depedent on both the inverse dynamics (recorded joint histories) and the environment in the forward dynamics simulation (PD controller response). This is one of the powerful aspects of LifeMOD. It will enable you to reuse a single motion capture run and within reason, make changes to the boundary conditions, repeat the activity, and look at differences in the body. An example would be lifting weights. In simulation, we can change the weights and see differences in the muscle forces.
However, if your goal is to hold the joint torques the same with and without the facility, then please follow Liz's recommendation. That is the correct method based on what I read in this thread. Best of luck!
Brian
Thank you for your reply and...
Thank you for your reply and suggestion. It does help me to understand better. I will go through the lifting weights example and see if I get more idea from that.
It seems that the definition of the inverse/forward dynamics is a little bit different than what I have learned in class. Suppose a system is governed by the following equation:
M(q)+V(q)+G(q)=T(q)
where q is generalized coordinates. it could be joint angle in the human model. T coresponding to the joint torques.
The inverse dynamics describes the process to compute T with given q; while the forward dynamics is the process to find out q with give T.
With that in mind, the joint torques can be determined as long as the inverse dynamins is done and it is no bussiness with forward procedure.
However, LifeMod seems to use these two terms in a different way. I think that's the main point which makes me confused.
I see the source of your con...
I see the source of your confusion; your definitions are entirely accurate in terms of calculating inverse or forward dynamics of a system.
In LifeMOD, during the inverse dynamic simulation the model is driven kinematically (basically a given set of q's) just as an inverse dynamic simulation would prescribe. Then during the forward dynamics simulation, the model is driven by torques produced by either the muscles or the joints; so, your T matrix on the right hand side of the equation; again according to definition. More info can be found here:
http://www.lifemodeler.com/LM_Manual_2008/modeling_analyze.shtml#j4
The difference, however, between what LifeMOD is doing, and what you are interested in trying in your forward simulation, is in the definition of the controller. The joint angles (for trained joints) or muscle lengths (for trained muscles) are used as the inputs for the controllers on the joints/muscles forces in the forward run. So for the joints, the torque at the joint is calculated as with a PD controller according to:
T = P*error + D*(error)'
P and D are your gain terms, "error" is the difference between the joint angle angle and the target (obtained from the inverse simulation) and the prime denotes a time derivative.
Doing it this way, the user is also able to prescribe additional loads in the forward simulation (ie. the addition of a device or facility, changing the weights being lifted, ground reaction forces added, etc). Then during the simulation these net torques are all used to drive the model. The controllers maintain the kinematics (otherwise these changes would almost always cause the model to fail), and the results of the simulation are the final joint and/or muscle loading patterns, as Brian had mentioned.
Hopefully this clears it up for you! If you do want to maintain the torques go ahead and try the method I suggested the other day, and see how that works. Good luck!
Thank you so much for your c...
Thank you so much for your clarification.
So in LifeMod, the inverse run is just a kinematic procedure, trying to track the MOCAP date as close as possible and generate the joint trajectories. After that, a PD controller is employed to solve the inverse dynamic problem, that is to compute the joint torques. In the forward run, the model is govern by these torques, however, the final result gives the net torques which takes the response to the environment into the consider. Is that right?
Another concern is about the tracker motion agent. It seems that the tracker agent is created in the similar manner as regular motion agent. It will generate additional force/torque in the forward run to make a stable system. However, by doing that, the model is infulenced by this extra force/torque, which does not exist in the real life. Only when the tracker force/torque is small enough, we can consider it as good simulation. The question is how small it should be, and if we can plot and check this extra tracker force/torque. What if we are end up with a large tracker force/torque? Can we do something to reduce it?
Many thanks again.
Qi
Yep, that sounds right for t...
As for the tracker, theres not really a single threshhold of what is "small enough"; a larger tracker force generally indicates that more model refinement is necessary for the model to match the real system. It becomes a measure of the fidelity of the model, because essentially the tracker agent is absorbing the effects of the unmodeled or undermodeled components- adjustments in mass properties, contact parameters, additional muscles or muscle paths, etc.
If you want to decrease the required tracker force, consider various modeling changes: Are there any significant unmodeled components? You can increase the gains on the muscles or joints (whichever is driving the model), and drop the gains to some very small value on the tracker. You could turn the tracker off completely and see the results, to see if this gives any indication of the location of the greatest error, and then modify the joint, muscle, or contact properties (etc...) accordingly.
To get a look at these tracker forces, there is a request called:
.World.Isaac_Tracking_Force
(where Isaac would be replaced by whatever the name of your model is) which should be accessible through the post processor.
Hope this helps, good luck!
Just to be more clear. I dra...
Pls correct me if anything wrong in the diagram. Thanks.
I tried your procedures but ...
I tried your procedures but lost at step 8 and 9.
At step 8, why should we set the desired joints "passive"? We wanna drive the joints using particular spline. So, why not set them to be "driven", and chose the created spline?
At step 9, I didn't get which botton in ADAMS toolbox should be used to creat torque drivers. I noticed, akispl is a function to creat a spline. When the spline is created, how to assign it to a certain joint?
By the way, should I add tracker agent in the simulation also?
Thank you.
Qi
Setting the joints to driven...
http://www.lifemodeler.com/LM_Manual_2008/modeling_joints.shtml#j2
If you want to use this torque driver approach, you'll need to set the joint to passive and then use the additional torque driver, not kinematic driver. For more details on these, take a look at your Adams Help; specifically search for Applied Forces under Adams/View and you should find all the information you need.
Akispl is a function that will interpolate your spline; the spline should be created in the postprocessor (step 7 from previously). When you create the torque driver, you assign it to a joint and then point at the splines with which you'd like to drive it.
Finally, adding a tracker agent is not required, but generally useful in forward analyses; it would be a modeling choice that is up to you.
Hope this answers your questions, good luck with the model!