Universal_Robots_ROS_Driver: a ROS 1 interface to UR arms, now unmaintained

The problem: a stable interface between ROS and a UR arm

Universal Robots have become a dominant supplier of lightweight robotic manipulators for industry, as well as for scientific research and education, and their arms came with a real-time control interface that is not what a ROS user wants to talk to directly.

The Robot Operating System has developed from a community-centered movement to a mature framework and a de facto standard, providing a rich set of powerful tools for robot engineers and researchers working in many different domains. This driver is the layer between the two: it provides a stable and sustainable interface between UR robots and ROS, and the stated goal is to strongly benefit all parties.

The scope is stated in the repository description: a Universal Robots ROS driver supporting CB3 and e-Series, and the feature list specifies the versions it works with, all CB3 robots with software version 3.14.3 or above and all e-Series with software 5.9.4 or above, using the RTDE interface for communication whenever possible.

The audience is a robotics engineer or researcher with a UR arm who wants to drive it from ROS, and the success criteria the project sets for itself are about ease of use, stability and power, so that the community can reach its goals in research and automation without struggling with unimportant technical challenges, instability or missing features.

The provenance is worth noting, because it explains a lot about the code. This driver is forked from ur_modern_driver, and it was developed in collaboration between Universal Robots A/S and the FZI Research Center for Information Technology, with support from ROSIN, the ROS-Industrial quality-assured robot software components effort, and European Union Horizon 2020 funding under grant agreement no. 732287.

The end of life notice, which is the first thing in the documentation

The documentation opens with a callout marked important, and it changes how the repository should be read.

ROS 1 is End Of Life since the end of May 2025. The repository is not further developed any more. Bugfixes may or may not be added to it. There are no further binary releases for any ROS 1 distribution from the ROS repositories. And if you want to use a newer version than the last one released, you should either build from source or use the binary packages from the ROS-O project.

That is a specific and unusual set of instructions, and each clause has a consequence. The lack of further development means the driver will not be updated for new ROS or new robot firmware. The absence of binary releases means that apt will not give you a newer package, so a deployment that needs a fix has to compile it. And the pointer to ROS-O tells you where the maintained binaries actually live now, which is a different organisation from the one that published the original releases.

The release history is consistent with that account. The published tags are v2.4.1 from 2025-05-20, v2.4.0 from 2025-05-13 and v2.3.0 from 2025-04-24, so the last tagged releases came in a burst in the spring of 2025, shortly before the end of ROS 1 support. The last push was on 2026-10-05, which indicates the repository is not abandoned in the sense of being read only, but it is not where new driver work is going.

For an adopter, the practical response is to treat this driver as a frozen dependency. If you run ROS 1 today, you pin a version, you vendor the source, and you plan for the day you move to ROS 2, which the notice implicitly points to even though it does not name a successor here.

The three packages, and what each one is for

The repository is not one package, and the split is the clearest guide to how the driver is used.

ur_robot_driver is the actual driver package, and it is where most of the documentation lives, with the doc/ directory holding the real-time setup guide, the ROS interface reference, the feature list and the initial setup images. ur_calibration is a package around extracting and converting a robot's factory calibration information to make it usable by the robot_description, which is a small but essential job, because the accuracy of a Cartesian move depends on the calibration data being right and the robot_description being generated from it. ur_dashboard_msgs holds the message definitions used for interacting with the dashboard node.

The dashboard is worth a second look, because it is the point at which the driver stops being a set of trajectory controllers. The teacachet of the UR arm runs a program on the robot that handles control commands sent from the ROS side, and the dashboard node exposes the controls that the arm's own web interface would normally offer. The documentation says the robot can be started, stopped, and even have its recovery from safety events handled, using ROS service and action calls, without touching the teach pendant at all.

That is a genuine design decision rather than a convenience. A robot whose control loop can only be entered through a physical pendant is a robot that needs a human standing next to it, and turning the pendant's functions into ROS services is what turns a UR arm into something you can put behind an automation system.

The repository also carries the per-distro rosinstall files for Melodic and Noetic, the .clang-format and .clang-tidy configurations, a GitLab CI configuration alongside the GitHub Actions one, and the three package directories.

Realtime communication, and the kernel you need for it

The e-Series runs a 2 millisecond control cycle, and the driver is built around that number rather than around it.

The feature list describes a realtime-enabled communication structure to robustly cope with the 2ms cycle time of the e-Series, and to use it you have to compile and run the driver on a kernel with the PREEMPT_RT patch enabled, with the real-time setup guide in ur_robot_driver/doc/real_time.md explaining how to achieve that.

That requirement is worth taking seriously, because it is the difference between a driver that keeps up with the robot and one that does not. A ROS node that is scheduled too coarsely will miss its window, and the symptom appears as jitter in the arm's motion rather than as an error message. The requirements section says as much in plainer terms: the driver requires a system setup with ROS, Ubuntu 20.04 with ROS noetic is recommended, and to make sure that robot control is not affected by system latencies it is highly recommended to use a real-time kernel.

The other half of the performance story is the on-the-robot interpolation. The driver supports it for both Cartesian and joint-based trajectories, and the documentation explains when it helps: if your application cannot meet the real-time requirements of the driver, the robot itself can interpolate between the waypoints instead. Special passthrough controllers forward the trajectories directly to the robot, which then handles the interpolation to achieve the best performance.

The trade is that you give up control of the interpolation and therefore of the trajectory's exact timing, and the arm's own motion planner becomes part of your loop. For a pick and place that has to be smooth, that is a good bargain. For a trajectory whose shape matters, it is not.

Speed scaling, the teach pendant, and the caveats worth reading

Two features of the driver interact with the robot's own safety and control behaviour, and the documentation is unusually explicit about the limitations.

The first is speed scaling. When speed scaling is active, because of safety constraints or because the speed slider is used, this is correctly handled on the ROS side, slowing down trajectory execution accordingly. The caveat is that other ros-controllers based on a position interface can be used with the driver but may behave wrong if the speed slider is not set to 100% or if speed scaling slows down the robot. The pausing function can only be used if the default scaled trajectory controller is used.

That is a class of bug that does not announce itself. A position interface controller that assumes the robot executes the trajectory it was given will produce a mismatch whenever the arm is running slower than commanded, and the result is a position error that grows with the distance and the slowdown.

The second is teach pendant integration. Using the URCaps system, a program runs on the robot that handles control commands sent from the ROS side, and with that the robot can be paused, stopped and resumed without restarting the ROS driver. The documentation also says that this will in future enable the usage of ROS components as part of a more complex UR program on the teach pendant, and that ROS control of the robot can be quit using a service call to continue program execution on the teach pendant.

The transparency here is the point. Rather than hiding the pendant behind the driver, the driver makes the pendant's behaviour visible and controllable, and the feature list points to an external feature list for the full set.

Where to get help, and what the repository does not tell you

Two support routes are named in the documentation. For using the driver, the ROS category in the UR+ Developer Forum is the place to ask. For reporting a bug, the issue board on GitHub, using the default template, after looking at the troubleshooting section of the documentation first.

That last instruction is a sign of how the project is run. A robotics driver produces bugs that depend on the robot firmware version, the ROS distribution, the network configuration and the realtime settings, and a report without those is a report that cannot be acted on.

The repository also points out where the detail lives. The features list at ur_robot_driver/doc/features.md is the reference for what the driver supports, the ROS interface document covers the dashboard services and the robot_state_helper node, and the real-time setup guide is the document for the kernel configuration. The requirements section is cut off in the published README, so the specific minimum versions for the realtime and network configuration are in the installation documentation rather than in the summary.

The licence is Apache-2.0, which is the standard permissive choice for a driver that hardware vendors and research groups both build on, and it means a company can modify it for its own arm configuration without publishing the change.

And the judgement on the project as a whole is that it was a good piece of work for its time, and it is now a frozen dependency rather than a living one. It solved the interface problem well enough that ROS 2 users are still relying on the same design, and the honest advice to anyone starting fresh is that the end of life notice is not a footnote but the first fact.

Editorial conclusion

Adopt the Universal Robots ROS driver only for an existing ROS 1 system that has to keep running, and pin the version you already validate against, because the project states plainly that it is no longer developed and that binary releases have stopped. Do not start new work on ROS 1 with it. Before you rely on it, read the feature list and the real-time setup guide in ur_robot_driver/doc, and check the position interface caveat, because other ros-controllers can behave incorrectly when the speed slider is not at 100% and the pausing function only works with the default scaled trajectory controller.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. UniversalRobots/Universal_Robots_ROS_Driver on GitHub