|Language:||English • 中文（简体）|
This article describes the inverse dynamic model (IDM) feature is used to compensate friction and dynamic effects for motion elements, otherwise leading to positioning errors and suboptimal settling behavior.
The motivation of the IDM feature is to use additional knowledge about the motion than just the position – i.e. velocity and torque – to offset the command values of the torque controller in order to make them react faster and thereby reduce the final positioning error and improve the settling behavior.
The term inverse dynamic model (IDM) means that the softMC takes a cartesian motion of a motion element and not only computes the joint position for the next Cartesian setpoint, but also the joint torque required for the motion. In order to be able to do that, it needs a dynamic model – i.e., a model of the masses and inertias – of the motion element. The joint velocity and torque are then sent to the drives as additional torque command data.
The page Dynamic Models lists all available dynamic models and also describes all necessary parameters.
Axis / Robot Motions
To understand the difference in behavior between single axes and robot dynamics it is necessary to first understand the way these objects are implemented in the softMC firmware.
After the reset all command there are only axes objects active in the softMC. That means that the position, velocity and other drive commands are calculated cyclically by these axes objects, no matter if an axis is moving or if it is standing. Also the additional torque command is calculated cyclically according to the dynamic models of the axes, which for a standing axis can be a constant value for gravity compensation.
Groups or robots objects instead only become active in the moment they are attached and are deactivated again on detach. As soon as a group is activated, it takes over the control of all axes, which belong to it. That means that the position, velocity and other drive commands are now calculated by the group object, which also includes computation of dynamics. Note: When a group motion command is issued at the terminal, the corresponding group is automatically attached to the terminal for the time period of motion.
As a conclusion of this design, axes of groups with gravity compensation need special treatment. Because at drive power enable the axis object computes the torque command, the gravity compensated axis need single axis dynamics configured. On the other hand, during group motion, the group to which the axis belong to need group dynamics enabled.
Single Axes Dynamics
Dynamic computation for a single axis is activated by assigning an available model to the property DynamicModel. The corresponding dynamic parameters are provided to the array DynamicParameter. Friction parameters are handled separately by the properties axis.ViscousFriction and axis.CoulombFriction.
|With the property axis.AxisType rotary and linear axes are distinguished by the Firmware.|
Friction parameters for all the axes belonging to the robot are set in the axes friction properties axis.ViscousFriction and axis.CoulombFriction. To consider friction compensation in robot dynamics, it is not necessary to select a dynamic model for its axes.
A special case in robot/group dynamics is the axes based dynamics.
When selected, the robot/group computes its dynamics according to the dynamic models of its axes.
The main purpose of this mode is to enable dynamics for non robot groups and Cartesian robots.
Axes based dynamics is activated by assigning
-1 to DynamicModel.
Robot/Axis payload significantly influences the motion dynamics and is considered in all dynamic models. Applications should adjust the values in PayloadMass and axis.PayloadInertia each time the payload changes.
Torque Error Monitoring
Collision detection is a very important topic in the field of modern robotics. Servotronix offers dynamic models for several kinematic types, which compute needed joint torques during robot motion.
On the other side joint drives provide actually needed torque feedback. The idea is to compute the torque error by comparing commanded torque feedforward with returned torque feedback to detect abnormal behavior.
The torque error exception is thrown in the instant the torque error exceeds axis.TorqueErrorMax. The stopping behavior in this case is configured with the properties axis.TorqueErrorStopType and axis.TorqueErrorDisableType.