1 Answers
Developing a task that can move a KINARM robot from one position to another position is a common request from our end-users. In order to move a KINARM robot automatically, the task must use a position controller. However, using position controllers can be tricky. The following is a list of suggested steps to assist end-users who wish to develop a task for a KINARM robot that involves position control. As with the programming of any new task that involves loads, the operator should always have the emergency stop button in-hand during testing and development in case the system goes unstable due to a programming error.
In the position controller block, set “Inertias to include for feed-forward control” to “None”.
Ensure that data logging is set to be continuous (i.e. do not turn off between trials). This can be done by wiring in a constant value of 1 to the logging_enable input of the DataLogging block.
Wire in the desired position and commanded torques/forces into DataLogging block to be saved as analog signals (i.e. into analog_inputs). Double-check in the Task Protocol that you will be using for testing that these analog inputs are checked to be ‘saved’
Test your task with the motors disabled (i.e. with the Emergency Stop button pressed down).
Examine the desired position in the saved data-file. Does it look correct in terms of the behavior that you are hoping for in the task?
Examine the torque/force commands in the saved data-file. Do they look smooth? If there are jumps in the torque/force commands, there are two common causes:
Something is wrong with the desired position. Look for corresponding jumps in the desired position input (i.e. jumps in desired position at the same time as the jumps in the torque/force command).
The position controller is being turned off/on without a ramp scaling the output forces (note: the position controller does not need to be turned on with a ramp if the position controller's desired_position input is reset to the current position at the same time that it is turned on, AND the e_reset input is triggered so as to ensure zero torque/force initially).
Once the desired position and torque/force command signals look correct, enable the motors. Re-test task, but be sure to have the emergency stop button in-hand in case something is wrong with your code.
Once task is working as expected, in the position controller block set “Inertias to include for feed-forward control” to whatever is desired.
Test your task with the motors disabled (i.e. Emergency Stop button pressed down).
Examine the torque/force commands in the saved data-file. Do they look smooth?
If there are jumps, that probably means something is wrong with the desired position. Look for corresponding jumps in the desired position input
If it is wildly unstable, that probably means that the time step set for the position controller block is incorrect. Unlink the position controller block from the Dexterit-E library, look under its mask and add an xpc Scope to the VELs output of the Get_kinematics block. Set the number of samples to a small value (e.g. 10) and re-run your task with the motors still disabled. If the velocity is oscillating between zero and non-zero values, then there is likely something wrong with the time-step setting. Please refer to the Help for the position controller for details on what this setting should be. (And do not forget to restore the position controller block from the library).
Once the positions and torques/forces look correct, enable the motors. Re-test task, but be sure to have the emergency stop button in-hand in case something is wrong with your code.
Change data logging back to what you want it to be for your task.
Un-wire the desired position and commanded torques/forces from the analog inputs.
Please login or Register to submit your answer