point velocity not obeying constraint - bug?

[Marc Carmichael]

Hello,

I am using the API to calculate the linear/angular velocity of a point in a body. In a certain model pose the values opensim returns are incorrect and I am wondering if it is a bug. Perhaps my implementation is incorrect.

I set the model state by setting generalized coordinate values and speed values. I then use the simbodyengine to do the velocity calculations as follows:

osimModel.getSystem().realize(si,SimTK::Stage::Velocity);
osimModel.getSimbodyEngine().getVelocity(si,body,ptBodyJ,vel_linear);
osimModel.getSimbodyEngine().getAngularVelocity(si,body,vel_angular);

The problem is that when I put the model into a certain pose the results I get are wrong. In this pose, two of the model's axis of rotation align. A model constraint applies the opposite of the first coordinate value to the second coordinate. The end results is that the two coordinates cancel out each other hence movement of the first coordinate results in zero model motion. However when I calculate the velocity of the body points as above, the results show the same velocity as if the constraint was not applied.

Could this be a bug? Perhaps I am not using the functions correctly? Could it be that I am not using the "realize" function up to the correct stage? or do I need to do another step, like use the projectConfigurationToSatisfyConstraints() function or similar?

Any help is greatly appreciated. This has had me stumped for quite some time.

Cheers

Marc

[Ajay Seth]

Hi Marc:

Which version of OpenSim are you using?
Pre-2.2 you will need to call projectConfigurationToSatisfyConstraints() to satisfy constraints when not performing a dynamical simulation- as in posing the model if you are setting q's and u's directly on the system state. A requirement of project() is that the provided state be close to satisfying the constraints (it is primarily meant to keep the state on the constraint manifold during integration) and thus it might not be robust. You need to realize velocity AFTER calling project.

In 2.2 onwards you can call assemble() on Model which will satisfy the constraints given a starting state. A weight option allows you to get as close as possible to satisfying the constraints if they cannot be satisfied exactly. The default behavior is to satisfy the constraints exactly. Using assemble() is recommended since project() is no longer being used as a method of satisfying the constraints for posing or simulation initialization.

I hope this clarifies.

[Ajay Seth]

Apologies Marc. assemble() is in 2.3 (currently under alpha testing). You will need to use projectConfigurationToSatisfyConstraints() as described above (first option) but we hope you will switch to using assemble() in 2.3 when it is released. Sorry about that. Let us know how it goes.

[Marc Carmichael]

Thanks Ajay. I tried projectConfigurationToSatisfyConstraints() and it worked!! Brilliant

Cheers

Marc

[Marc Carmichael]

Just a quick follow up question. What is the effect of the cTol value in the function projectConfigurationToSatisfyConstraints(SimTK::State & s, const double cTol) ?

Does having a smaller value tighten the constraints, ie force the model to better meet the constraints at the expense of extra computation time and possible failure? What is the default value for this number?

Cheers

Marc