Deprecation of ur_modern_driver

ROS-Industrial
1

All,

with the public release of ur_robot_driver the ROS community finally gained an OEM supported driver for Universal Robots controllers. Find the official announcement here: Announcement: Universal Robots launches ROS driver.

Both CB3 and e-Series controllers are fully supported and ur_robot_driver provides some nice improvements over both ur_driver and ur_modern_driver. This is especially the case for e-Series controllers, with full support for the 500 Hz update rate and integration of new functionality such as the embedded RS485 port in the robot flange.

To avoid fragmenting the ROS & ROS-Industrial communities, we, the maintainers of ur_modern_driver and universal_robot, announce the deprecation of ur_modern_driver. It will not see further development nor addition of new features. It will also not be made compatible with e-Series controllers, nor with newer Polyscope/system software versions. Issues and PRs reporting incompatibilities and attempting to fix them will be closed.

We encourage everyone with a CB3 or e-Series controller to start using ur_robot_driver. It is the future of ROS integration with UR products, and we feel it has received sufficient maturity to start migrating our user base to it.

If you haven’t already, please visit UniversalRobots/Universal_Robots_ROS_Driver to review system requirements and features. Issues with the new driver should be reported on the ur_robot_driver issue tracker.

On our side, we’ll be updating the readmes of various repositories, wiki pages, tutorials and FAQs to point to ur_robot_driver whenever and wherever it is appropriate. If you come across a reference to ur_driver or ur_modern_driver that you believe should be updated, please let us know here.

Note that we are aware of the fact that feature-parity has not yet been reached between ur_robot_driver and ur_modern_driver. In particular, the “low bandwidth mode” or ur_modern_driver is not available. Where possible, missing features will be ported, but we cannot do this without the community (ie: you). If you have the impression something is missing from ur_robot_driver, open an issue on the tracker to discuss it. It could already be on the roadmap or could have been replaced by an alternative.

Finally, we would like to take this opportunity to thank all community members who have contributed to either ur_driver or ur_modern_driver (or both) with code, by reporting issues or in any other way: without those contributions it would not have been possible to create or maintain these software components.

In particular, we’d like to thank @Felix_Messmer (long time maintainer of ur_driver), Thomas Timm Andersen (author of the original ur_modern_driver) and Simon Rasmussen (contributor of the large “Kinetic refactor”).

on behalf of the maintainers,

@gavanderhoorn

14 Likes
2

Reposting this as a separate comment as I’ve received quite a few questions about this:

ur_robot_driver does not support CB1 or CB2 controllers (up to and including Polyscope version 1.8.x). For those controllers users would still need to use one of the older drivers or alternatives.

3

I’d like to take the opportunity to thank @gavanderhoorn, ThomasTimm and everyone else who has contributed to the community-developed drivers - I have used ur_modern_driver in multiple applications with great success :100:

6 Likes
4

Hi.
In these days, I’ve controlled a universal robot(UR-3) using the ‘ur_modern_driver’ on ROS Kinetic. But, now, I changed a version from 16.04 to 18.04. So, I also modified a version of ROS from Kinetic to Melodic.
I installed a ur_robot_driver because of Melodic. And I succeed that “rostopic echo /joint_states” as below figure.

Screenshot%20from%202019-11-27%2018-22-05
Screenshot%20from%202019-11-27%2018-22-05734×481 53.2 KB

Could I use a example code for moving a universal robot on ‘ur_robot_driver’ like that “test_move.py” on ‘ur_modern_driver’?

Thank you for my question.

5

First: please ask these sort of questions on either ROS Answers, or the issue trackers of the respective packages (and don’t post screenshots of code or terminal output, just copy-paste the text).

But to quickly answer your question: both ur_modern_driver and ur_robot_driver expose a FollowJointTrajectory action server (ie: it’s the same interface). Code that creates a client for that should work on both drivers.

1 Like
6

I wonder if this thread is still maintained?

I have recently been trying to control UR(5e/16e) robots over wireless TCP/IP (arms mounted on mobile base) with the new ros_driver. It involves running a URCap program node on the UR robot controller computer.and run ur_bringup,launch on remote ROS host. But it gives error :“Could not get fresh data package from robot”, which seems to be due to low communication bandwidth. (My ping rate is ~2-5ms). It doesn’t happen on wired connection. My observation (guess) so far is the recent ur robot ROS driver used RTDE and closed the loop at 500Hz for e-series and it gives the error at lower communication. I tried to lower the communicaton freq (e.g. the older CB3 controller is set to 125Hz, and there is a method in RTDE API), but I cannot resolve such in the new ROS driver.

I posted for help in the Universal Robot Forum, but the reply was not to use in wireless configuration’. I wonder the previous ‘low bandwidth’ mode mentioned in the first message could have served such purpose?

So my question is what would be the best approach to achieve wireless ROS configuration based on ROS control framework? (I believe there are many UR robots on mobile robots, and assume this should have been implemented.) Some suggestions include disable wifi coalease, place an on-board host to fake time-stamp, get an ultra-fast wifi router…

Any help and insights would be appreciated.

7

Hi @anlyoung,

From your description, I assume that you are trying to connect UR controller and PC running ros_control through WiFi. Is this correct?
If so, this is really not recommended architecture. I also assume that you have some PC already running on your mobile platform. Then you should also use the same PC to run UR control node and connect it with a wire to UR controllers.

If you want to, then control from an external computer, e.g., stationary station, then you run there MoveIt, rviz and other high-level components. Remember that you always want to run your control nodes as close as possible to hardware. Although wireless connection could theoretically work, you will probably have a off stability issues because of unpredictable latencies and gitter. So the answer from UR forum is correct. Don’t do this.

All use-cases of UR robot on a mobile platform I know of are using PC in the platform to control the arm, i.e., run ros_control node.

8

Dear sir, Thank you for the good advice on architecture. I haven’t placed an on-board computer on mobile base yet, but I was planning to place a rasberry pi for sensory integration (3D camera, etc.). Would this be powerful enough for loading UR ros driver? If not, any advice on how should I remotely power on an on-board computer?

I also have implemented a gazebo simulator, which also relies on UR ROS driver. With your suggested architecture, I plan to run it on a remote host PC (that also runs high level MoveIt, RViz, etc.) - has its own bringup.launch in gazebo directory. With this architecture, shall I use the ROS driver (and robot-description directory) launched from the on-board computer, or should it be possible to run them duplicate ROS driver and robot description on the host machine?

Thank you in advance for any advice.

9

Hi,

one Rasberry PI could be too week to do both, image / point cloud processing and robot control. In the worst case another Rasberry- PI would be needed for robot control. This should be sufficient if you are only running driver and controller (JointTrajectoryController) on it. Maybe you will have to play with RT_PREEMT kernel, but it should work.

I don’t fully understand the question. You will need description package on both computers. It is OK if it is duplicated. But will run driver only on the on-board machine connected to the robot.