Revision history [back]

To start: the documentation stating compatibility of the available drivers with the various controllers should be improved. However I believe some of the things you describe / ask about in your question are not just caused by this not being clear.

My first target was to control a simulated UR5 using the MoveIt, Gazebo, RViz and my test application using the Moveit C++ API.

Just to clarify: are you trying to use a driver with a robot in Gazebo? Because that is not needed nor possible.

My current implementation fails when I try to execute move(), a known problem.

Without more information this is not something we can act on. There can be various causes for this, but again, if you're using a simulation no drivers would be needed so I'd first like to get that cleared up.

The ur_modern_driver adds ros_control required for move() support when simulated.

Can you clarify where you read/found this? Because it is certainly not true (or at least not as you phrase it here).

Why has the ur_modern_driver not replaced the ur_driver? Surely everyone will fall at the first hurdle and have to find the above thread?

Because ur_driver still has its uses.

For all intents and purposes ur_modern_driver has replaced ur_driver. See the wiki for ur_driver for instance, Compatibility section:

The ur_driver package has been successfully used with system versions ranging from v1.5.7849 to v1.8.23117. Newer versions seem to have introduced various incompatible changes, and can at present not be used with the ur_driver package.

We recommend users with newer system versions (v3.x and up) to use the ur_modern_driver package.

And the Driver Compatibility notice in the Prerequisites section of the Getting Started with a Universal Robot and ROS-Industrial tutorial.

If your question was actually "why is ur_driver still part of the universal_robot repository?" then the answer would be: because it is still used by many users with a CB1 or CB2 controller and just removing or replacing packages (in repositories) that are still being used is not something that we do.

In fact: ur_modern_driver will never be integrated with the universal_robot repository. See ros-industrial/ros_industrial_issues#49 for the rationale.

As to your other concerns:

(1) UR5 and ROS The universal robot package ( http://wiki.ros.org/universal_robot ) is shown as experimental and use in production systems not recommended. This greatly concerns me as a non starter, we have this powerful framework available but experimental drivers?

All the code in that repository -- and in fact all drivers available for UR robots -- have been written by community members (as is also clarified by the support level: community badge in the repository readme and the top-level wiki page). Some while being part of a company, but that doesn't mean that the company guarantees the quality of the code. Everything is best effort. The software status label that you refer to is there to tell you -- up front -- that this code may not have received as much testing as it should have, that some things may not work fully yet and that components may contain code that has only been tested against the robot(s) that the developer has access to.

The community (still) hasn't come up with certification programs for (robot) drivers, so this subjective 'stamp' if you will is a stop-gap measure, but it at least gives you a heads-up.

See Production Ready solutions for a related discussion on ROS Discourse.

Is this assertion reasonable or is this driver package really not suitable for production? Am I missing something or are universal robots not considered for production systems? Before I put in more effort, I wanted to confirm the suitability of my configuration?

Please note this sentence on the Software Status label wiki page:

This status by design is not based on any quantitative evaluation, [..]. Rather, the status is merely the author/developer/maintainer's informed opinion on whether the code is production ready.

The last time that status label was updated for the universal_robot packages the maintainers and/or authors determined that there was still enough to improve to warrant the experimental label. That is all that label tells you. For the packages in universal_robot it could be upgraded to developmental in my opinion, and perhaps even production for the description packages. But as the status is generally applied to the whole repository it is generally best to be conservative.

To start: the documentation stating compatibility of the available drivers with the various controllers should be improved. However I believe some of the things you describe / ask about in your question are not just caused by this not being clear.

My first target was to control a simulated UR5 using the MoveIt, Gazebo, RViz and my test application using the Moveit C++ API.

Just to clarify: are you trying to use a driver with a robot in Gazebo? Because that is not needed nor possible.

My current implementation fails when I try to execute move(), a known problem.

Without more information this is not something we can act on. There can be various causes for this, but again, if you're using a simulation no drivers would be needed so I'd first like to get that cleared up.

The ur_modern_driver adds ros_control required for move() support when simulated.

Can you clarify where you read/found this? Because it is certainly not true (or at least not as you phrase it here).

Why has the ur_modern_driver not replaced the ur_driver? Surely everyone will fall at the first hurdle and have to find the above thread?

Because ur_driver still has its uses.

For all intents and purposes ur_modern_driver has replaced ur_driver. See the wiki for ur_driver for instance, Compatibility section:

The ur_driver package has been successfully used with system versions ranging from v1.5.7849 to v1.8.23117. Newer versions seem to have introduced various incompatible changes, and can at present not be used with the ur_driver package.

We recommend users with newer system versions (v3.x and up) to use the ur_modern_driver package.

And the Driver Compatibility notice in the Prerequisites section of the Getting Started with a Universal Robot and ROS-Industrial tutorial.

If your question was actually "why is ur_driver still part of the universal_robot repository?" then the answer would be: because it is still used by many users with a CB1 or CB2 controller and just removing or replacing packages (in repositories) that are still being used is not something that we do.

In fact: ur_modern_driver will never be integrated with the universal_robot repository. See ros-industrial/ros_industrial_issues#49 for the rationale.

As to your other concerns:

(1) UR5 and ROS The universal robot package ( http://wiki.ros.org/universal_robot ) is shown as experimental and use in production systems not recommended. This greatly concerns me as a non starter, we have this powerful framework available but experimental drivers?

All the code in that repository -- and in fact all drivers available for UR robots -- have been written by community members (as is also clarified by the support level: community badge in the repository readme and the top-level wiki page). Some while being part of a company, but that doesn't mean that the company guarantees the quality of the code. Everything is best effort. The software status label that you refer to is there to tell you -- up front -- that this code may not have received as much testing as it should have, that some things may not work fully yet and that components may contain code that has only been tested against the robot(s) that the developer has access to.

The community (still) hasn't come up with certification programs for (robot) drivers, so this subjective 'stamp' if you will is a stop-gap measure, but it at least gives you a heads-up.

See Production Ready solutions for a related discussion on ROS Discourse.

Is this assertion reasonable or is this driver package really not suitable for production? Am I missing something or are universal robots not considered for production systems? Before I put in more effort, I wanted to confirm the suitability of my configuration?

Please note this sentence on the Software Status label wiki page:

This status by design is not based on any quantitative evaluation, [..]. Rather, the status is merely the author/developer/maintainer's informed opinion on whether the code is production ready.

The last time that status label was updated for the universal_robot packages the maintainers and/or authors determined that there was still enough to improve to warrant the experimental label. That is all that label tells you. For the packages in universal_robot it could be upgraded to developmental in my opinion, and perhaps even production for the description packages. But as the status is generally applied to the whole repository it is generally best to be conservative.