simtk.org

Posted: **Thu Jun 27, 2013 11:19 pm**

Hi everyone.
I just noticed some wired results from tugofwar API example. I reckon there is a bug in excitaion-activation dynamics. In the default API example, I changed the linear prescribed excitation with a constant excitation, see below:

Code: Select all

PrescribedController *muscleController= new PrescribedController();
muscleController->setActuators(OsimModel.updActuators());
Constant * cte0  = new Constant(0.1);
Constant * cte1  = new Constant(0.1);
muscleController->prescribeControlForActuator("muscle1"  , cte0);
muscleController->prescribeControlForActuator("muscle2"  , cte1);
OsimModel.addController(muscleController);  //Add the controller

I ran the FD tool for 1 sec (which is much bigger than activation and deactivation time constants) and I expected the activation of both muscle to make a plateau at 0.1 (which is equal to the constant excitation). Surprisingly the activations made the plateau at a different level (0.11 please see the attached graph)
I do believe the same problem makes the error that I mentioned in one of my previous posts. Please see my last reply on this post: https://simtk.org/forums/viewtopic.php?f=91&t=4157
I am pretty sure that OpenSim2.4 did not have this problem.
Any ideas if this is a bug or am I missing sth in my scripts?
Thanks
Sina

Posted: **Fri Jun 28, 2013 8:31 am**

Is it possible that you added a new controller without removing the previous one so that they are both active and their outputs combined?

Posted: **Sun Jun 30, 2013 5:55 pm**

sherm wrote:Is it possible that you added a new controller without removing the previous one so that they are both active and their outputs combined?

Hi Sherm,
I just double checked everything and the answer is no. The model has just one controller. I printed the model into HDD and this is the controller tag in the osim file after adding the controller:

Code: Select all

<ControllerSet name="Controllers">
			<objects>
				<PrescribedController>
					<actuator_list>muscle1 muscle2</actuator_list>
					<FunctionSet name="ControlFunctions">
						<objects>
							<Constant>
								<value>0.1</value>
							</Constant>
							<Constant>
								<value>0.1</value>
							</Constant>
						</objects>
						<groups />
					</FunctionSet>
				</PrescribedController>
			</objects>
			<groups />
		</ControllerSet>

As you can see, each muscle has just one constant controller.

Posted: **Tue Jul 02, 2013 12:54 pm**

Hi Sina,

Please post the full code or the osim file if it reproduces the unexpected behavior and we'll take a look.

Thanks,
-Ayman

Posted: **Thu Jul 04, 2013 5:55 pm**

Hi Ayman
I have attached the osim file and a simple cpp file which has the unexpected results. It seems that the muscle activations in the result.sto file do not follow the constant muscle excitations. I used a constant 0.1 function for the excitation but the activation makes a plateau at 0.11
thanks.

Posted: **Tue Jul 09, 2013 8:55 pm**

Hi Ayman,
I am still struggling with this problem and was wondering if you could understand what the source of error is?
Thanks
Sina

Posted: **Tue Jul 16, 2013 12:06 pm**

In 3.0 the activation dynamics model was reimplemented to guarantee smooth asymptotic settling to a minimum activation level as described by eqns 1-3 in Millard et al. "Flexing Computational Muscle: Modeling and Simulation of Musculotendon Dynamics." Journal of biomechanical engineering 135.2 (2013): 021005-021005. In the Thelen2003Muscle, whose fiber dynamics can become singular at zero activation, the minimum is set to amin = 0.01. That means for a constant control x=0.1 the steady state (adot = 0) activation a = x*(1-amin)+amin = 0.1*(1-0.01)+0.01 = 0.099+0.01 = 0.109, which is exactly what your plot shows. We agree that this is non-intuitive behavior and we have updated the equations so that continuity to amin is assured whilst still capable of reaching a steady state of a = x. This fix will be in the next release of OpenSim. Thank you for bringing this to our attention.

simtk.org

Wired Forward Dynamics results - OpenSim3.0 - Probably a bug

Wired Forward Dynamics results - OpenSim3.0 - Probably a bug

Re: Wired Forward Dynamics results - OpenSim3.0 - Probably a

Re: Wired Forward Dynamics results - OpenSim3.0 - Probably a

Re: Wired Forward Dynamics results - OpenSim3.0 - Probably a

Re: Wired Forward Dynamics results - OpenSim3.0 - Probably a

Re: Wired Forward Dynamics results - OpenSim3.0 - Probably a

Re: Wired Forward Dynamics results - OpenSim3.0 - Probably a