|
| 1 | +# ur_controllers |
| 2 | + |
| 3 | +This package contains controllers and hardware interface for `ros_control` that are special to the UR |
| 4 | +robot family. Currently this contains |
| 5 | + |
| 6 | + * A **speed_scaling_interface** to read the value of the current speed scaling into controllers. |
| 7 | + * A **scaled_joint_command_interface** that provides access to joint values and commands in |
| 8 | + combination with the speed scaling value. |
| 9 | + * A **speed_scaling_state_controller** that publishes the current execution speed as reported by |
| 10 | + the robot to a topic interface. Values are floating points between 0 and 1. |
| 11 | + * A **scaled_joint_trajectory_controller** that is similar to the *joint_trajectory_controller*, |
| 12 | + but it uses the speed scaling reported by the robot to reduce progress in the trajectory. |
| 13 | + |
| 14 | +## About this package |
| 15 | +This package contains controllers not being available in the default `ros_control` set. They are |
| 16 | +created to support more features offered by the UR robot family. Any of these controllers are |
| 17 | +example implementations for certain features and are intended to be generalized and merged |
| 18 | +into the default `ros_control` controller set at some future point. |
| 19 | + |
| 20 | +## Controller description |
| 21 | +This packages offers a couple of specific controllers that will be explained in the following |
| 22 | +sections. |
| 23 | +### ur_controllers/SpeedScalingStateBroadcaster |
| 24 | +This controller publishes the current actual execution speed as reported by the robot. Values are |
| 25 | +floating points between 0 and 1. |
| 26 | + |
| 27 | +In the [`ur_robot_driver`](../ur_robot_driver) this is calculated by multiplying the two [RTDE](https://www.universal-robots.com/articles/ur/real-time-data-exchange-rtde-guide/) data |
| 28 | +fields `speed_scaling` (which should be equal to the value shown by the speed slider position on the |
| 29 | +teach pendant) and `target_speed_fraction` (Which is the fraction to which execution gets slowed |
| 30 | +down by the controller). |
| 31 | +### position_controllers/ScaledJointTrajectoryController and velocity_controllers/ScaledJointTrajectoryController |
| 32 | +These controllers work similar to the well-known |
| 33 | +[`joint_trajectory_controller`](http://wiki.ros.org/joint_trajectory_controller). |
| 34 | + |
| 35 | +However, they are extended to handle the robot's execution speed specifically. Because the default |
| 36 | +`joint_trajectory_controller` would interpolate the trajectory with the configured time constraints (ie: always assume maximum velocity and acceleration supported by the robot), |
| 37 | +this could lead to significant path deviation due to multiple reasons: |
| 38 | + - The speed slider on the robot might not be at 100%, so motion commands sent from ROS would |
| 39 | + effectively get scaled down resulting in a slower execution. |
| 40 | + - The robot could scale down motions based on configured safety limits resulting in a slower motion |
| 41 | + than expected and therefore not reaching the desired target in a control cycle. |
| 42 | + - Motions might not be executed at all, e.g. because the robot is E-stopped or in a protective stop |
| 43 | + - Motion commands sent to the robot might not be interpreted, e.g. because there is no |
| 44 | + [`external_control`](https://github.com/UniversalRobots/Universal_Robots_ROS_Driver#prepare-the-robot) |
| 45 | + program node running on the robot controller. |
| 46 | + - The program interpreting motion commands could be paused. |
| 47 | + |
| 48 | +The following plot illustrates the problem: |
| 49 | + |
| 51 | + |
| 52 | +The graph shows a trajectory with one joint being moved to a target point and back to its starting |
| 53 | +point. As the joint's speed is limited to a very low setting on the teach pendant, speed scaling |
| 54 | +(black line) activates and limits the joint speed (green line). As a result, the target |
| 55 | +trajectory (light blue) doesn't get executed by the robot, but instead the pink trajectory is executed. |
| 56 | +The vertical distance between the light blue line and the pink line is the path error in each |
| 57 | +control cycle. We can see that the path deviation gets above 300 degrees at some point and the |
| 58 | +target point at -6 radians never gets reached. |
| 59 | + |
| 60 | +All of the cases mentioned above are addressed by the scaled trajectory versions. Trajectory execution |
| 61 | +can be transparently scaled down using the speed slider on the teach pendant without leading to |
| 62 | +additional path deviations. Pausing the program or hitting the E-stop effectively leads to |
| 63 | +`speed_scaling` being 0 meaning the trajectory will not be continued until the program is continued. |
| 64 | +This way, trajectory executions can be explicitly paused and continued. |
| 65 | + |
| 66 | +With the scaled version of the trajectory controller the example motion shown in the previous diagram becomes: |
| 67 | + |
| 69 | + |
| 70 | +The deviation between trajectory interpolation on the ROS side and actual robot execution stays minimal and the |
| 71 | +robot reaches the intermediate setpoint instead of returning "too early" as in the example above. |
| 72 | + |
| 73 | +Under the hood this is implemented by proceeding the trajectory not by a full time step but only by |
| 74 | +the fraction determined by the current speed scaling. If speed scaling is currently at 50% then |
| 75 | +interpolation of the current control cycle will start half a time step after the beginning of the |
| 76 | +previous control cycle. |
0 commit comments