Universal_robot: breaking changes planned for Melodic

In the context of the Deprecation of ur_modern_driver, the maintainers of ros-industrial/universal_robot would like to notify the community about upcoming breaking changes as part of an initial Melodic binary release.

Refer to ros-industrial/universal_robot#448 for the details, but in short: the ROS Melodic release of universal_robot is going to introduce quite a few breaking changes. Most of those will be updates to packages, including package names, locations of files, changes to the contents of .launch and .yaml files and various other things (such as packages being merged with other packages).

This will almost certainly affect current users of ros-industrial/universal_robot on Melodic, especially if you’re currently building kinetic-devel from source (or melodic-devel, which tracks kinetic-devel for now) and are using any of the .xacro macros as part of a composite model, if you’re (still) using ur_driver, if you’re using any of the packages for the e-Series robots and/or if you’re using Gazebo with UR robot models.

Breaking changes are never convenient, but we feel our rationale for introducing them now makes sense.

Please take a look at ros-industrial/universal_robot#448 and comment on the issue with any thoughts or if/when you identify any potential problems.

2 Likes

Some of the planned changes (from ros-industrial/universal_robot#448):

  • replace universal_robot (the metapackage) with universal_robots
  • remove ur_driver
  • merge description packages for regular and e-Series robots
  • change ur_description to:
    • contain only a single _macro.xacro parameterised by xacro’s yaml support
    • support kinematic calibration data extracted from the controller (for ur_robot_driver)
    • no longer include joint_limited variants (but permanently update limits of affected joints)
  • update all MoveIt packages (add new planner configurations)
  • move all Gazebo URDF contents to ur_gazebo and switch to simulated effort interfaces for all robots
  • move out ur_msgs to its own repository
1 Like

Why do breaking changes have to happen in a stable and long term supported ROS distro? This happens to other parts of ROS (like MoveIt) too and it is very annoying.

It is very good to see official support for ROS drivers. But I do not see why the old driver has to be removed. Can’t this removal wait until noetic?

Unless I’m misunderstanding you, I believe we are actually not breaking anything in any particular ROS release.

Nothing will be removed in Kinetic. It stays as it is.

ros-industrial/universal_robot has never been released into Melodic. No binary packages have ever been made available. There is only a melodic-devel branch which does not come with any guarantees of stability or backwards compatibility.

That is not to say we don’t try, but announcing these changes now, before the first actual release is exactly to avoid having to introduce breaking changes in an LTS.

ur_driver will remain available in Kinetic. It will not be released into Melodic.

If you need to use ur_driver on Melodic, you are most likely building it from sources in a/your workspace right now. You can continue to do that, even after it has been removed from melodic-devel. Just include a copy of the kinetic-devel version in your workspace.

Finally: ur_driver has not been updated since 2015 (almost 5 years ago now) and has never been compatible with anything but CB1 and CB2 controllers since it was written. It cannot be used with CB3 nor e-Series controllers. For those, the new ur_robot_driver should be used, and even with CB2 controllers you may want to look at ur_modern_driver instead.

And just to clarify (but you are probably aware): ur_driver != ur_modern_driver.

Hey, thanks for the awesome and continuous work. We are currently using ur_modern_driver, but we would like to always have the latest and greatest driver for our robot. What is the best time to make the switch?

Thanks,

George

@gstavrinos: I believe your question would fit better in Deprecation of ur_modern_driver.

Again: ur_driver != ur_modern_driver. The breaking changes mentioned here do not affect ur_modern_driver (or ur_robot_driver, the new driver) directly.

Thanks for the heads-up, @gavanderhoorn.