New UR driver for ROS coming soon

Drivers
1

Hi all, as we received questions around some corners whether the new UR driver developed as part of the ROSin project (http://rosin-project.eu/ftp/universal-robots-ros-industrial-driver) is abandoned.

I can assure you, that it has not died and in fact will be released soon, hopefully. Currently, there are only one or two minor issues being resolved and there’s still some documentation to write before we will make the code available to the public.

We received mainly positive feedback from our closed beta group, so we are eagerly looking forward to open the project to a wider audience soon.

So, when will it be released?

Please understand, that we don’t want to give a fixed deadline to not disappoint anybody. However, we do have an internal deadline not too far away, that we are confident to meet.

How can I help?

There is a lot going on around the driver development. Other improvements going on in the universal_robots repository are closely related to this topic. For example, the following issue is related to a urdf description helping to get a calibrated robot representation. Contribution there is very welcome :slight_smile:, especially if you are a bit more familiar with gazebo than I am.

Feature comparison and roadmap

To give you an estimate on what to expect from the new driver, we prepared a small feature comparison and roadmap listing the new driver’s features. If that list is to some extent wrong, please let me know. Any errors are not intentional.

Feature ur_modern_driver this_driver
position-based control yes yes
scaled position-based control - yes
velocity-based control yes planned
reporting of tcp wrench yes yes
reporting of tcp wrench in tcp link - yes
pausing of programs - yes
continue trajectories after EM-Stop resume - yes
continue trajectories after protective stop - yes
panel interaction in between possible no1 yes
get and set IO states yes yes
use tool communication on e-series - yes
use the driver without a teach pendant necessary - planned
support of CB2 robots yes -
trajectory extrapolation on robot on missing packages no2 yes
use ROS as drop-in for TP-programs - yes
extract calibration from robot - yes
send custom script commands to robot yes yes
ROS 2 support ? (planned)3
Reconnect on a disconnected robot yes yes

1 Depending on the mode the driver is running the panel won’t react or using the panel
will stop the program without notifying the ROS user.

2 In velocity mode this is implicitly given.

3 There is no specific plan to do this inside of the first driver development. However,
it is structured in a way so that a ROS2 driver should be developed as easy as possible by keeping
as much as possible in a ros-independent library.

7 Likes
2

could you explain quickly what that means? Generally I’m wondering if that implies that I could use the new driver in a ros_control like position controlled way without the need for a real-time kernel?

3

…that implies that I could use the new driver in a ros_control like position controlled way without the need for a real-time kernel?

Not exactly. While the real-time kernel requirements are in fact important to assure that the control cycle on the ROS machine runs in the required time windows, extrapolation on the controller is a separate layer on top meaning that the robot will continue its current movement using a constant velocity model.

Basically, this is another layer to make sure that the robot is not showing any “hickup” motions due to missing packages. Except from a non-real-time kernel those could be generated by delays in the TCP stack or network communication.

Whether a real-time kernel is a really hard requirement for your usecase depends on a couple of factors:

  • With a CB3 robot with a control rate of 125 Hz you could get away without using a real-time kernel
  • If your control-pc is not running anything else than the driver chances are lower that the controller gets interrupted by other processes meaning that you could also get away with a non-real-time kernel
  • If your only concerns are smooth motions, the controller extrapolation could be enough. However, the robot will not be following the desired path necessarily, as it is doing linear extrapolation only.

With this all being said, let me state, that we highly recommend using a real-time kernel. During initial tests we checked that without a real-time kernel a significant amount of cycles took more than twice the time intended.