Universal Robots ROS2 Driver

The Universal Robots ROS2 Driver is a manipulator driver built on top of the Universal_Robots_Client_Library. It provides low-latency, secure communication with UR robots and supports key cobot functionalities such as:

• Pause at emergency stop
• Safeguard stop
• Automatic speed scaling (to avoid violating safety settings)
• Manual speed scaling from the teach pendant

By using the externalControl URCap, you can integrate ROS2 behaviors directly into the robot program. The driver is compatible with the entire UR robot line (3 kg to 30 kg payload) and supports robots with PolyScope X, PolyScope 5, or CB3 controllers.

The ur_calibration package allows you to extract factory calibration data from a Universal Robots robot. This data provides exact forward and inverse kinematics determined at the factory. By applying this calibration to ur_description, you can obtain a more accurate URDF model.

While not strictly required for basic operation, performing this calibration is highly recommended when using the universal_robots_ros2_driver. Without it, end effector positions may deviate from the expected model by several centimeters.

Controlling a Universal Robot via ROS requires strict cycle times. To ensure stability and performance, follow these hardware and software recommendations:

• Kernel: Use a lowlatency or PREEMPT_RT-patched kernel.
• Network: Use a direct network connection between the ROS PC and the robot controller. Avoid using a network switch if possible.

The UR hardware interface is the core component of the ROS driver, responsible for communicating with the robot controller to send commands and receive status updates. It is implemented using the ros2_control framework.

Key Concept: Hardware Interface vs. Controllers

• The Hardware Interface provides the low-level communication and exposes interfaces (like position, velocity, or effort).
• The Controller (e.g., JointTrajectoryController or ForceModeController) defines how the robot's motion is actually controlled using those interfaces. To move the robot, you must load and use a controller that utilizes the hardware interface.

The controller_stopper node ensures that ROS motion commands are only sent when the robot is actually running a program. It monitors the /io_and_status_controller/robot_program_running topic.

When the robot program is not running, the controller_stopper automatically deactivates all motion controllers (unless they are explicitly marked as 'consistent'). This behavior provides two main benefits:

1. Transparency: Callers attempting to send commands to an inactive controller are immediately informed that the controller cannot accept commands.
2. Safety/State Management: Any running actions on the ROS controller are aborted when the program stops.

Once the robot program starts running again, any previously active motion controllers are automatically reactivated.

The SetMode action includes two boolean flags to manage the program lifecycle during a state change:

• stop_program: If true, the currently running program is stopped before the robot state changes. When used with the controller_stopper, this deactivates any motion controller and stops any active ROS actions on those controllers.
• play_program: If true, the program is started after the robot state has been set.

Warning: A protective stop (P-Stop) or emergency stop (E-Stop) only pauses the program. If the program is resumed after the fault is cleared, it will continue from where it left off. It is recommended to use stop_program: true and then restart the program when recovering from a fault to ensure a clean state.

The ur_robot_driver manages two control loops: the ROS driver loop (reading state and sending commands) and the robot's internal control loop. If these loops run at different clocks, a phase shift occurs, which can cause instability.

Setting blocking_read:=true (the default) forces the ROS driver to wait for new robot state data before proceeding with the next control cycle. This synchronizes the ROS control loop to the pace of the robot's control loop, which is the recommended configuration for most single-robot setups.