URGENT! Advanced API, Actuator, Plugin, SO

[Erik Dijkstra]

Hi support,

I am trying to implement a new type of PointActuator (I call it: PointGRFActuator) that has an extra position and velocity factor that adjusts the amount of force it can produce. The position factor is from an exponential function using the vertical distance between the PointGRFActuator's 'point' and the ground body origin. The velocity factor is using the velocity of the 'point'. The purpose is to 'predict' the ground reaction forces in one routine with the muscle activations/forces in the static optimization. Thus the new PointGRFActuators will act to get the required foot-ground contact forces.

I wrote a plugin and tested the new actuator on the arm26 model where I added the PointGRFActuator to the end of the forearm. For the arm I have a motion where the elbow is in 90 deg flexion and the shoulder is moving from zero up to about 120 degrees of flexion. Since the arm26 model is fixed to the floor at the trunk, the 'point' of the PointGRFActuator gets out of its working range (set by the exponential functions) after some time. Running the Static Optimization(SO) does not give problems untill the muscles start to be too weak where no solution can be found. But in the timespan before that occurs I can observe the change in activation of the PointGRFActuator due to the change of its position w.r.t. the ground which to me was an indicator(activation went to zero when it came out of range) that it worked.

To see if it would work for standing posture or gait I decided to test to implement it on a gait model, attaching PointGRFActuators at 7 points under each foot. Now running the SO for both standing posture and gait motion results in a crash of OpenSim where it closes down. Only one time I got to see that it started to test some activations as the muscles changed colors but also here OpenSim closed down when the SO was at 0%.

Now I am lost; the optimization with the PointGRFActuators worked in the arm model but not at all in the gait model.

Am I overlooking something fundamental here? I was expecting it to at least try to find solutions to the optimization problem as with the arm model.

Any help and suggestions are welcome.

Best regards,
Erik

[Ayman Habib]

Hi Erik,

StaticOptimization removes all actuators in the model except for muscles, residuals & GRF since it assumes you want muscles to account for all actuation, if you're adding your custom actuators to the model directly then they're likely not used in StaticOptimization altogether.

If you use one of the add-in force files, the actuators are added but it'd be hard to debug your custom code remotely. Maybe you can create a main program (following the tug-of-war example) and exercise your Actuator class and then we can help you troubleshoot in a simple environment or help answer specific questions you have.

Hope this helps,
-Ayman

[Erik Dijkstra]

Hi Ayman,

Thanks for your reply.

About the removal of all actuators except muscles, residuals and GRF; How come PointActuators do appear in the results of a StaticOptimization? Are they then somehow considered as residuals? The New Actuator was only added in the model file. I did not specify anything special when running SO, yet it seemed to share load with the muscles in the model. Also what I remember seeing in the StaticOptimization code there was no obvious selection that only muscle actuators were taken into account.

I will have a go at creating a Tug of War like testing simulation and get back when I run into problems.

Best regards,
Erik

[Erik Dijkstra]

Hi,

I made a simple environment of a block moving on the floor with the new actuators on the four base corners. At first I tested a forward simulation and this looks good. Next I ran some static optimizations of motions resulting from the forward dynamic simulation and some self made motions. This also worked well.

Then I figured that it would be good to test the new actuators together with some muscles so I took the tugOfWar model and added my actuators and introduced gravity. Here the forward simulations work fine but when I try to perform a static optimization on the resulting motion the analysis suddenly stops, like i mentioned in my first post.

A thing I noticed was that the analysis halts earlier when the mass of the block is lower. This makes me think it might have something to do with singlarities and thus possibly an ill-posed problem...

The optimizer failed because it detected an infeasible problem. Would this only be a problem of the wrong initial conditions?

see below an example of an "out" log.

Code: Select all

ANALYSES (1)
analysis[0] = StaticOptimization

BODIES (2)
body[0] = ground (mass: 0) (inertia: 1 0 0 0 1 0 0 0 1)
body[1] = block (mass: 5) (inertia: 0.0333333 0 0 0 0.0333333 0 0 0 0.0333333)

ACTUATORS (22)
actuator[0] = muscle1
actuator[1] = muscle2
actuator[2] = GRF_A
actuator[3] = GRF_Ax
actuator[4] = GRF_A_x
actuator[5] = GRF_Az
actuator[6] = GRF_A_z
actuator[7] = GRF_B
actuator[8] = GRF_Bx
actuator[9] = GRF_B_x
actuator[10] = GRF_Bz
actuator[11] = GRF_B_z
actuator[12] = GRF_C
actuator[13] = GRF_Cx
actuator[14] = GRF_C_x
actuator[15] = GRF_Cz
actuator[16] = GRF_C_z
actuator[17] = GRF_D
actuator[18] = GRF_Dx
actuator[19] = GRF_D_x
actuator[20] = GRF_Dz
actuator[21] = GRF_D_z
numStates = 17
numCoordinates = 6
numSpeeds = 6
numActuators = 22
numBodies = 2
numConstraints = 0
numProbes = 0

STATES (16)
y[0] = blockToGround_xRotation
y[1] = blockToGround_yRotation
y[2] = blockToGround_zRotation
y[3] = blockToGround_xTranslation
y[4] = blockToGround_yTranslation
y[5] = blockToGround_zTranslation
y[6] = blockToGround_xRotation_u
y[7] = blockToGround_yRotation_u
y[8] = blockToGround_zRotation_u
y[9] = blockToGround_xTranslation_u
y[10] = blockToGround_yTranslation_u
y[11] = blockToGround_zTranslation_u
y[12] = muscle1.activation
y[13] = muscle1.fiber_length
y[14] = muscle2.activation
y[15] = muscle2.fiber_length
No external loads will be applied (external loads file not specified).

Loading coordinates from file tugOfWar_GRFActuator_states.sto.
Storage: file=tugOfWar_GRFActuator_states.sto (nr=4750 nc=17)
Found 4750 state vectors with time stamps ranging from 0 to 2.
Executing the analyses from 0 to 2...
SimTK Exception thrown at InteriorPointOptimizer.cpp:261:
  Optimizer failed: Ipopt: Infeasible problem detected (status 2)
OPTIMIZATION FAILED...

StaticOptimization.record:  WARN- The optimizer could not find a solution at time = 0

The model appears too weak for static optimization.
Try increasing the strength and/or range of the following force(s):
   muscle1 approaching upper bound of 1
   GRF_A approaching upper bound of 1
   GRF_Az approaching lower bound of 0.0001
   GRF_A_z approaching upper bound of 1
   GRF_Bz approaching lower bound of 0.0001
   GRF_B_z approaching upper bound of 1
   GRF_C approaching upper bound of 1
   GRF_Cz approaching lower bound of 0.0001
   GRF_C_z approaching upper bound of 1
   GRF_Dz approaching lower bound of 0.0001
   GRF_D_z approaching upper bound of 1


time = 0 Performance =10.3444 Constraint violation = 467.334
Bounds for muscle1: 0 to 1
Bounds for muscle2: 0 to 1
Bounds for GRF_A: 0.0001 to 1
Bounds for GRF_Ax: 0.0001 to 1
Bounds for GRF_A_x: 0.0001 to 1
Bounds for GRF_Az: 0.0001 to 1
Bounds for GRF_A_z: 0.0001 to 1
Bounds for GRF_B: 0.0001 to 1
Bounds for GRF_Bx: 0.0001 to 1
Bounds for GRF_B_x: 0.0001 to 1
Bounds for GRF_Bz: 0.0001 to 1
Bounds for GRF_B_z: 0.0001 to 1
Bounds for GRF_C: 0.0001 to 1
Bounds for GRF_Cx: 0.0001 to 1
Bounds for GRF_C_x: 0.0001 to 1
Bounds for GRF_Cz: 0.0001 to 1
Bounds for GRF_C_z: 0.0001 to 1
Bounds for GRF_D: 0.0001 to 1
Bounds for GRF_Dx: 0.0001 to 1
Bounds for GRF_D_x: 0.0001 to 1
Bounds for GRF_Dz: 0.0001 to 1
Bounds for GRF_D_z: 0.0001 to 1

Best regards,
Erik

[Ajay Seth]

A couple of things:
1. There are no actuators controlling the Y (vertical) direction as far as i can tell from your naming convention. What is preventing the block from falling since you enabled gravity?
2. It is also possible that after filtering and/or splining the coordinates (which SO does), that the estimated accelerations (particularly in Y) are not identical to the forward simulation and small corrective force is required, but there is no actuator that can generate that Y force.

[Erik Dijkstra]

1. Sorry that is my bad. The actuators without a direction specification are for the vertical Y direction. If there where no actuators acting for the vertical direction the forward simulation would have shown the block falling through the 'floor', which is undesirable.

2. I am not sure I understand what you mean by the corrective force required. Isn't SO used to get the forces of the actuators such that the resulting accelerations match those of the input motion?

[Ajay Seth]

That is good that you have vertical forces. My second comment was referring to the requirement for actuators during SO/CMC for otherwise unactuated DOFs because of small errors introduced by processing the input data. For example, if I drop a block with no forces other than gravity and feed the coordinate data to SO, it would ideally estimate no vertical actuator force, but since the data is potentially filtered and splined and differentiated, acceleration estimates are likely to have errors that cause forces to be applied, albeit small. If no actuator is present SO could fail because it is not able to achieve the desired acceleration.

This does not seem to be the problem in your case. You have actuators present. In your case, it appears that the actuation is insufficient. You have a block that weighs ~50N (5kg) but the four vertical actuators have limits of 0.0001 to 1 on their control. If their max force is also 1, then then your actuators can only produce 4N of vertical force not the 50 needed to support the block. Perhaps that is the problem?

[Erik Dijkstra]

The four vertical force actuators are able to generate the 50N each. For other motions it might be that the 'force-length' and 'force-velocity' relations make the maximum force an actuator can generate zero, but looking at the motion i use now they are within their force producing ranges. I guess for safety it would be good to let each actuator produce at least a small amount of force for models without 'residual' actuators.