ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Announcement: Universal Robots launches ROS driver

Hi ROS enthusiasts,

We are delighted to announce, that we have launched a Universal Robots backed ROS driver!

Robot Operating System (ROS) is widely used within the industrial research and educational field, for exploring robot technology, or for developing advanced systems. Since the beginning of UR, clever minds in the research field have developed 3rd party drivers, enabling the ROS community to communicate with UR robots for various purposes. Impressively, more than 200 different forks of UR-compatible drivers filled up the ROS landscape. However UR has never supported nor developed any of these drivers. Until now!

With so many community developed ROS-drivers in the landscape, it became difficult to find out which fork had the latest features, supported the right version of your UR software, or utilized the UR functionality in the best way. To mitigate these issues, and ensure that a solid driver utilizing all the best feats of the UR was available, we partnered with the German research institute FZI to cooperate on the development of an ROS driver that is backed by UR to ensure its stability and robustness.

Overview

The new ROS driver provides a number of key benefits:

  • Ease of use
    For ROS users, the driver provides an easy and plug’n’play use of UR robots.
  • Performance
    The ROS driver utilizes all the key features of the UR robot to achieve state of the art performance.
    It provides an industrial grade interface to the best extent allowed by current ROS practice.
    The driver includes the specific robot’s factory calibration data for improved accuracy.
  • Stability
    The driver is built on stable and versioned API’s, and is integrated into UR’s continuous testing engine for assured quality.
  • Community
    The driver will remain open-source and rely on future community contributions.

The ROS driver is provided through UR’s GitHub account, which allows for open collaboration within the ROS community.
There are two modes of operation for the driver:

  1. Remote Control
    Target Audience: easy programming research, embedding in OEM systems.
    In this mode, the driver works like classic ROS drivers, assuming full remote control of the robot without interaction on the teach pendant.
  2. ROS usage in URCap
    Target Audience: Developers of vision systems, force/torque control, picking algorithms or similar products, which integrate with ROS.
    In this mode, a sample URCap enables ROS control only where it is needed in the UR program. In this way it enables easier integration with ROS compatible devices into UR applications. It further enables commercialization of cutting edge technologies based on ROS.

Get started

Go check out the new ROS driver today;

Furthermore, you can check out the two accompanying URCap implementations;


What’s new?

@fmauch wrote up a good summary comparing the ur_modern_driver to the new driver:

Support and issues

If you encounter issues or bugs using the ROS driver, please use the Issue-reporting system for the respective GitHub repository.
Should you have questions to using the ROS driver, or general support requests, please use the ROS category in the Universal Robots+ community.

Happy development,

Your Universal Robots team :robot::computer:

14 Likes

Great achievement, lets hope that other manufacturers follow!

Does that include a way to calculate ik for the calibrated robot in an efficient way? We once had to resort to seeding a numerical ik-solver (trak-ik) with the solution from ikfast for the ideal robot as build quality was so bad.

The xacro itself is updated (via a .yaml file), so anything that uses the urdf to initialise the IK solver benefits.


Somewhat off-topic, but:

Congratulations to FZI & UR of course for this release, and we’ve supported them gladly, but there are already quite a few (industrial) robot manufacturers that have released publicly supported ROS drivers. I won’t name them here though, as this it not the place, but it is only fair to acknowledge their support as well.

1 Like

Ok, but nothing ur specific that could work in cases where ikfast fails?

I’m not sure what you mean by this, but there are currently no updates to ur_kinematics to take the calibration into account, if that is what you were asking.

That would not be impossible though, I believe. But out of the scope for the FZI & UR collaboration at this point. Community contributions are most likely welcomed.

Well I assume they have something akin to ur_kinematics implemented on the controller which works event though the calibration might (?) break geometric assumptions made when deriving ur_kinematics? But that is most likely considered IP I guess.

This might be a question best asked on the issue tracker.

I can’t really understand what you’re writing here, but that’s probably on me.

To be clear: all control is still joint space based. There is no Cartesian interface (yet). It’s a standard ros_control based hardware_interface which exposes the 6 revolute joints of the robot over RTDE in position mode. There is an experimental PR adding a velocity interface and the secondary and primary interfaces are also still used for some things (but not motion).

That is at a very high level. As always there are many more details influencing this, but for those I’d suggest posting either on the tracker or the UR support forum (which is behind a login).

What @jbm wrote applies to FK based on joint states: that will now take per-robot calibration into account, leading to orders of magnitude more precise results. On-controller compensation for things like gravity and link deflection is not part of that.

However, as MoveIt (fi) for planning Cartesian goals is also using the same IK solver, it should affect control of the robot’s EEF and positioning of that as well (as more accurate IK -> more accurate joint space goals).


But I’ll leave the rest to @jbm, UR and FZI :wink:

1 Like

Thank you @gavanderhoorn for summing this up very well. Our focus was indeed on joint-based control and correct forward kinematics.

Currently, we don’t plan further developing ur_kinematics though.