simtk.org

Hi,

I want to use the CoordinateActuator as a way of controlling the force at the knee, basically replacing a torsional spring with an actuator to allow more control over how much the knee flexes. I am running a forward dynamics simulation based on the method used in the Dynamic Walker Challenge.

1) If I implement the CoordinateActuator without a control function I can load the model and run it using the ForwardTool, in the OpenSim GUI and in MATLAB, but there is zero force at the knee, and the actuator seems to have no effect (regardless of what value of optimal_force or min_/max_control I use - which makes me think it isn't implemented correctly).

2) When I try and implement the control function and run the forward simulation through MATLAB, a PointConstraint is violated and the force remains constant - in the visualizer you see the contact point and ground are no longer connected. I presume the forces are remaining constant because the control function should act based on the joint angle and since the constraint is violated the joint angle doesn't change.

Does anyone have an idea of where I can start to try and fix these problems?

(1) A CoordinateActuator will have no effect unless you have also specified a controller. The actuator generates a torque equal to the product of the control signal and the optimal_force property. With no controller (and, therefore, no control signal), adjusting the optimal_force property will have no effect because it is still being multiplied by zero. The min_control and max_control properties are used to specify the range of control signal values that can be provided by a controller.

(2) I'm assuming that "the control function" is referring to a controller for the CoordinateActuator. I see that a contact model is being used between the foot and the ground (i.e., the foot and the ground are not "connected"), so it would seem that the model could fall over or become airborne if the control signal hasn't been properly tuned. Your statement "the control function should act based on the joint angle" implies that you are computing control signals as a function of joint angles. If the model is currently behaving erratically, I would suggest first trying simpler control signals (e.g., by multiplying your current control signal by zero or a small constant). If the simulation results still don't make sense, perhaps some additional context would be helpful (which step of the example you are working on, what the error message is, etc.).

Hi Tom,

Thanks for your reply.

1) I understand that the CoordinateActuator needs a controller. However, when running a forward simulation in OpenSim and changing the min_control and max_control properties there is still no change. For example, if I was to set both min_control and max_control to 1 I would expect to get a force output equal to optimal_force, but this isn't the case I am getting zero in the ForceReporter.

2) Yes, by the "control function" I mean the controller for the CoordinateActuator. In the DynamicWalker model, there is a contact model and therefore the foot and the ground are not connected. However, in my model I have a PointConstraint connecting the foot and the ground, and this PointConstraint is being ignored when I run a forward simulation with the Controller. Yes I have set the controller to be a function of joint angle, however I think the problem in this case is that the PointConstraint is being ignored. Is there a reason a PointConstraint would be ignored when implementing a controller?

I am not getting any error messages, but based on the output of the simulation I know it is wrong.

1. My understanding is that the min_control and max_control properties are used to enforce bounds on the control signal; if no controller is present, then there is no control signal, no bounds are enforced, and no force is applied. Strictly speaking, I think the simulation should fail if no controller is present since, as you have found, providing no controller currently has the same effect as providing a controller that holds the control signal at 0, which may be confusing. Another possible design change could be to add default controllers internally if they are missing.

2. No, there is no reason a PointConstraint and a Controller cannot coexist in a Model. Have you inspected the .osim files after adding each component (the PointConstraint, the CoordinateActuator, and the Controller)? Presumably, the models should differ only by the components that were added. You could then try loading each of these intermediate models in the GUI and running short forward simulations to confirm that each is behaving as expected.

Hi, Niamh-

Your model doesn't have a controller. I don't think this is correct. Your code has a control function, that you are using to update the state, but that is not really how it works. The actuator has to have a OpenSim::Controller attached.

Running fwd analysis with your model in the GUI, with a basic controller attached, the constraint is respected.

I think that the way you are updating the state and coordinates in opensim_actuator.m may be overriding the system. You don't realize the new system to position, so I doubt that the constraint calculation is even made.

-j

There are some Matlab examples on GitHub that might be helpful:
- https://github.com/opensim-org/opensim- ... b/examples
- https://github.com/opensim-org/opensim- ... labScripts

jimmy wrote:Hi, Niamh-

Your model doesn't have a controller. I don't think this is correct. Your code has a control function, that you are using to update the state, but that is not really how it works. The actuator has to have a OpenSim::Controller attached.

Running fwd analysis with your model in the GUI, with a basic controller attached, the constraint is respected.

I think that the way you are updating the state and coordinates in opensim_actuator.m may be overriding the system. You don't realize the new system to position, so I doubt that the constraint calculation is even made.

-j

Hi James,

I tried running a fwd simulation with a PrescribedController and StepFunction, and it seems to work. So I guess my question now is: is it possible to customise the controller so that it acts as a function of one of the model states (for example, time or joint angle). I think this is why I was directed to the control function of the DynamicWalker. Furthermore, I based my control function off the control function in the DynamicWalker zip, and the code gives the same output as the original code (Main_WalkerForwardSimulationWithControls.m), so I can't work out why it works for the DynamicWalker and not for my model. The only thing I can notice is that the PointConstraint is being violated, but Tom (above comment) seems to think the PointConstraint and the CoordinateActuator should be compatible.

Do you know of a way to either "force" the system to recognise the constraint? Or maybe there is an alternative way to create a custom control function?

Niamh

The point constraint and the actuator are compatible. You are not enforcing the constraint when you just update all the coordinates and states and not rebuild the system — thereby not computing the constraint forces.

Hi James,

Is there a simple way to rebuild the system within this set up so that the constraint is being enforced? Or am I better off trying to create a customized controller?

Niamh

If you are manually updating states, you may need to call one of the "realize" methods afterwards (e.g., realizeAcceleration(); see https://simtk.org/api_docs/opensim/api_ ... onent.html). Alternatively, you could try prescribing the motion of the coordinates using an OpenSim Function (see Coordinate::setPrescribedFunction() https://simtk.org/api_docs/opensim/api_ ... 7fd0c5f78d).

If you are repeatedly calling Coordinate::setValue() to set the value of each coordinate in your model, note that the last argument should be set to "true" only when setting the last coordinate; otherwise, the assembler will attempt to satisfy the constraints after each coordinate has been set (i.e., in each intermediate pose). https://simtk.org/api_docs/opensim/api_ ... 0004213229