ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I believe your question is based on a misunderstanding of my comments (I'm not a native speaker, so there is a good chance this is a fault on my side).

You write:

During that development process it's come to my attention that my development is apparently following the "old" (Simple Message) interfaces mostly by way of comments about the documentation being out of date. For example, these questions all have answers or comments that mention that the Simple Message interface is old but don't point to the updated info [..]

and:

Unfortunately, I've been unable to find any documentation/tutorial/webpage that specifically details what the most up to date Robot Support Package interfaces are [..]

I believe the specific comment that confused and caused you to (eventually) post this question was (by me in #q330389):

Finally:

I'm working on creating a ROS-i robot support package based upon reading their FAQ/Tutorials (http://wiki.ros.org/Industrial/Tutorials).

as the approach that was taken for the older drivers (ie: using Simple Message et al) is not something that is still often being used, those tutorials have gotten a bit stale. They should be updated, or at least their status should be made more clear.

What I meant to say here was (and still is) that using Simple Message itself could be considered "old". Not that there is an "old and new way" of interfacing with robot controllers that are both "part of ROS-Industrial".

Simple Message was really only created as a stop-gap measure, in a time (around 2010/11) where external motion control interfaces to industrial robot controllers were not ubiquitous (or at least not on the controllers targetted at that point in time). It is a very simple, primitive protocol that just serves its purpose (because of the very limited programming and runtime environments these controllers have), until you have something better available to you.

For most industrial robot controllers, "something better" has been available for quite a few years. KUKA has (and has had) RSI, FRI, SmartServo, DirectServo, EKI and some others. ABB has EGM. Fanuc has Stream Motion. Mitsubishi has MXT. Universal Robots has RTDE. Denso has b-CAP. Kawasaki has KRNX. Etc. Etc.

All of those interfaces support external motion control orders of magnitude more comprehensive and performant than would ever be possible using Simple Message (between 100 to 1kHz position, velocity and sometimes even force/torque control). And best of all: all of those interfaces are supported by their respective manufacturers.

From that perspective it doesn't make much sense to keep using a custom, primitive protocol -- if you'd target those kinds of controllers.

If you don't, and you don't have a good, performant external motion interface available, then using Simple Message (at least as the layer 7 protocol) could still make sense.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes the joints (and other resources) of your robot in a real-time safe way, allowing you to reuse the provided controllers to control the robot in real-time and to the maximum of its abilities (or write new controllers and do things that can't be done by the robot controller itself).

I believe your question is based on a misunderstanding of my comments (I'm not a native speaker, so there is a good chance this is a fault on my side).

You write:

During that development process it's come to my attention that my development is apparently following the "old" (Simple Message) interfaces mostly by way of comments about the documentation being out of date. For example, these questions all have answers or comments that mention that the Simple Message interface is old but don't point to the updated info [..]

and:

Unfortunately, I've been unable to find any documentation/tutorial/webpage that specifically details what the most up to date Robot Support Package interfaces are [..]

I believe the specific comment that confused and caused you to (eventually) post this question was (by me in #q330389):

Finally:

I'm working on creating a ROS-i robot support package based upon reading their FAQ/Tutorials (http://wiki.ros.org/Industrial/Tutorials).

as the approach that was taken for the older drivers (ie: using Simple Message et al) is not something that is still often being used, those tutorials have gotten a bit stale. They should be updated, or at least their status should be made more clear.

What I meant to say here was (and still is) that using Simple Message itself could be considered "old". Not that there is an "old and new way" of interfacing with robot controllers that are both "part of ROS-Industrial".

Simple Message was really only created as a stop-gap measure, in a time (around 2010/11) where external motion control interfaces to industrial robot controllers were not ubiquitous (or at least not on the controllers targetted at that point in time). It is a very simple, primitive protocol that just serves its purpose (because of the very limited programming and runtime environments these controllers have), until you have something better available to you.

For most industrial robot controllers, "something better" has been available for quite a few years. KUKA has (and has had) RSI, FRI, SmartServo, DirectServo, EKI and some others. ABB has EGM. Fanuc has Stream Motion. Mitsubishi has MXT. Universal Robots has RTDE. Denso has b-CAP. Kawasaki has KRNX. Etc. Etc.

All of those interfaces support external motion control orders of magnitude more comprehensive and performant than would ever be possible using Simple Message (between 100 to 1kHz position, velocity and sometimes even force/torque control). And best of all: all of those interfaces are supported by their respective manufacturers.manufacturers. Some will even let you use those interfaces "on the factory floor".

From that perspective it doesn't make much sense to keep using a custom, primitive protocol -- if you'd target those kinds of controllers.

If you don't, and you don't have a good, performant external motion interface available, then using Simple Message (at least as the layer 7 protocol) could still make sense.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes the joints (and other resources) of your robot in a real-time safe way, allowing you to reuse the provided controllers to control the robot in real-time and to the maximum of its abilities (or write new controllers and do things that can't be done by the robot controller itself).

I believe your question is based on a misunderstanding of my comments (I'm not a native speaker, so there is a good chance this is a fault on my side).

You write:

During that development process it's come to my attention that my development is apparently following the "old" (Simple Message) interfaces mostly by way of comments about the documentation being out of date. For example, these questions all have answers or comments that mention that the Simple Message interface is old but don't point to the updated info [..]

and:

Unfortunately, I've been unable to find any documentation/tutorial/webpage that specifically details what the most up to date Robot Support Package interfaces are [..]

I believe the specific comment that confused and caused you to (eventually) post this question was (by me in #q330389):

Finally:

I'm working on creating a ROS-i robot support package based upon reading their FAQ/Tutorials (http://wiki.ros.org/Industrial/Tutorials).

as the approach that was taken for the older drivers (ie: using Simple Message et al) is not something that is still often being used, those tutorials have gotten a bit stale. They should be updated, or at least their status should be made more clear.

What I meant to say here was (and still is) that using Simple Message itself could be considered "old". Not that there is an "old and new way" of interfacing with robot controllers that are both "part of ROS-Industrial".

Simple Message was really only created as a stop-gap measure, in a time (around 2010/11) where external motion control interfaces to industrial robot controllers were not ubiquitous (or at least not on the controllers targetted at that point in time). It is a very simple, primitive protocol that just serves its purpose (because of the very limited programming and runtime environments these controllers have), until you have something better available to you.

For most industrial robot controllers, "something better" has been available for quite a few years. KUKA has (and has had) RSI, FRI, SmartServo, DirectServo, EKI and some others. ABB has EGM. Fanuc has Stream Motion. Mitsubishi has MXT. Universal Robots has RTDE. Denso has b-CAP. Kawasaki has KRNX. Etc. Etc.

All of those interfaces support external motion control orders of magnitude more comprehensive and performant than would ever be possible using Simple Message (between 100 to 1kHz position, velocity and sometimes even force/torque control). And best of all: all of those interfaces are supported by their respective manufacturers. Some will even let you use those interfaces "on the factory floor".

From that perspective it doesn't make much sense to keep using a custom, primitive protocol -- if you'd target those kinds of controllers.

If you don't, and you don't have a good, performant external motion interface available, then using Simple Message (at least as the layer 7 protocol) could still make sense.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes the joints (and other resources) of your robot in a real-time safe way, allowing you to reuse the provided controllers to control the robot in real-time and to the maximum of its abilities (or write new controllers and do things that can't be done by the robot controller itself).

If you'd still like to conform to the ROS-Industrial driver specification, that is still possible, with and without ros_control. Most can be made compliant by remapping.

I believe your question is based on a misunderstanding of my comments (I'm not a native speaker, so there is a good chance this is a fault on my side).

You write:

During that development process it's come to my attention that my development is apparently following the "old" (Simple Message) interfaces mostly by way of comments about the documentation being out of date. For example, these questions all have answers or comments that mention that the Simple Message interface is old but don't point to the updated info [..]

and:

Unfortunately, I've been unable to find any documentation/tutorial/webpage that specifically details what the most up to date Robot Support Package interfaces are [..][..] Does anyone have any links or otherwise to information or documentation (or at a minimum a example repo) that details the newer ROS-I Robot Support Package interfaces?

I believe the specific comment that confused and caused you to (eventually) post this question was (by me in #q330389):

Finally:

I'm working on creating a ROS-i robot support package based upon reading their FAQ/Tutorials (http://wiki.ros.org/Industrial/Tutorials).

as the approach that was taken for the older drivers (ie: using Simple Message et al) is not something that is still often being used, those tutorials have gotten a bit stale. They should be updated, or at least their status should be made more clear.

What I meant to say here was (and still is) that using Simple Message itself could be considered "old". Not that there is an "old and new way" of interfacing with robot controllers that are both "part of ROS-Industrial".

Simple Message was really only created as a stop-gap measure, in a time (around 2010/11) where external motion control interfaces to industrial robot controllers were not ubiquitous (or at least not on the controllers targetted at that point in time). It is a very simple, primitive protocol that just serves its purpose (because of the very limited programming and runtime environments these controllers have), until you have something better available to you.

For most industrial robot controllers, "something better" has been available for quite a few years. KUKA has (and has had) RSI, FRI, SmartServo, DirectServo, EKI and some others. ABB has EGM. Fanuc has Stream Motion. Mitsubishi has MXT. Universal Robots has RTDE. Denso has b-CAP. Kawasaki has KRNX. Etc. Etc.

All of those interfaces support external motion control orders of magnitude more comprehensive and performant than would ever be possible using Simple Message (between 100 to 1kHz position, velocity and sometimes even force/torque control). And best of all: all of those interfaces are supported by their respective manufacturers. Some will even let you use those interfaces "on the factory floor".

From that perspective it doesn't make much sense to keep using a custom, primitive protocol -- if you'd target those kinds of controllers.

If you don't, and you don't have a good, performant external motion interface available, then using Simple Message (at least as the layer 7 protocol) could still make sense.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes the joints (and other resources) of your robot in a real-time safe way, allowing you to reuse the provided controllers to control the robot in real-time and to the maximum of its abilities (or write new controllers and do things that can't be done by the robot controller itself).

If you'd still like to conform to the ROS-Industrial driver specification, that is still possible, with and without ros_control. Most can be made compliant by remapping.

I believe your question is based on a misunderstanding of my comments (I'm not a native speaker, so there is a good chance this is a fault on my side).

You write:

During that development process it's come to my attention that my development is apparently following the "old" (Simple Message) interfaces mostly by way of comments about the documentation being out of date. For example, these questions all have answers or comments that mention that the Simple Message interface is old but don't point to the updated info [..]

and:

Unfortunately, I've been unable to find any documentation/tutorial/webpage that specifically details what the most up to date Robot Support Package interfaces are [..] Does anyone have any links or otherwise to information or documentation (or at a minimum a example repo) that details the newer ROS-I Robot Support Package interfaces?

I believe the specific comment that confused and caused you to (eventually) post this question was (by me in #q330389):

Finally:

I'm working on creating a ROS-i robot support package based upon reading their FAQ/Tutorials (http://wiki.ros.org/Industrial/Tutorials).

as the approach that was taken for the older drivers (ie: using Simple Message et al) is not something that is still often being used, those tutorials have gotten a bit stale. They should be updated, or at least their status should be made more clear.

What I meant to say here was (and still is) that using Simple Message itself could be considered "old". Not that there is an "old and new way" of interfacing with robot controllers that are both "part of ROS-Industrial".

Simple Message was really only created as a stop-gap measure, in at a time (around 2010/11) where when external motion control interfaces to industrial robot controllers were not ubiquitous (or at least not on the controllers targetted at that point in time). It is a very simple, primitive protocol that just serves its purpose (because of the very limited programming and runtime environments these controllers have), until you have something better available to you.

For most industrial robot controllers, "something better" has been available for quite a few years. KUKA has (and has had) RSI, FRI, SmartServo, DirectServo, EKI and some others. ABB has EGM. Fanuc has Stream Motion. Mitsubishi has MXT. Universal Robots has RTDE. Denso has b-CAP. Kawasaki has KRNX. Etc. Etc.

All of those interfaces support external motion control orders of magnitude more comprehensive and performant than would ever be possible using Simple Message (between 100 to 1kHz position, velocity and sometimes even force/torque control). And best of all: all of those interfaces are supported by their respective manufacturers. Some will even let you use those interfaces "on the factory floor".

From that perspective it doesn't make much sense to keep using a custom, primitive protocol -- if you'd target those kinds of controllers.

If you don't, and you don't have a good, performant external motion interface available, then using Simple Message (at least as the layer 7 protocol) could still make sense.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes the joints (and other resources) of your robot in a real-time safe way, allowing you to reuse the provided controllers to control the robot in real-time and to the maximum of its abilities (or write new controllers and do things that can't be done by the robot controller itself).

If you'd still like to conform to the ROS-Industrial driver specification, that is still possible, with and without ros_control. Most can be made compliant by remapping.

I believe your question is based on a misunderstanding of my comments (I'm not a native speaker, so there is a good chance this is a fault on my side).

You write:

During that development process it's come to my attention that my development is apparently following the "old" (Simple Message) interfaces mostly by way of comments about the documentation being out of date. For example, these questions all have answers or comments that mention that the Simple Message interface is old but don't point to the updated info [..]

and:

Unfortunately, I've been unable to find any documentation/tutorial/webpage that specifically details what the most up to date Robot Support Package interfaces are [..] Does anyone have any links or otherwise to information or documentation (or at a minimum a example repo) that details the newer ROS-I Robot Support Package interfaces?

I believe the specific comment that confused and caused you to (eventually) post this question was (by me in #q330389):

Finally:

I'm working on creating a ROS-i robot support package based upon reading their FAQ/Tutorials (http://wiki.ros.org/Industrial/Tutorials).

as the approach that was taken for the older drivers (ie: using Simple Message et al) is not something that is still often being used, those tutorials have gotten a bit stale. They should be updated, or at least their status should be made more clear.

What I meant to say here was (and still is) that using Simple Message itself could be considered "old". Not that there is an "old and new way" of interfacing with robot controllers that are both "part of ROS-Industrial".

Simple Message was really only created as a stop-gap measure, at a time (around 2010/11) when external motion control interfaces to industrial robot controllers were not ubiquitous (or at least not on the controllers targetted at that point in time). It is a very simple, primitive protocol that just serves its purpose (because of the very limited programming and runtime environments these controllers have), until you have something better available to you.

For most industrial robot controllers, "something better" has been available for quite a few years. KUKA has (and has had) RSI, FRI, SmartServo, DirectServo, EKI and some others. ABB has EGM. Fanuc has Stream Motion. Mitsubishi has MXT. Universal Robots has RTDE. Denso has b-CAP. Kawasaki has KRNX. Etc. Etc.

All of those interfaces support external motion control orders of magnitude more comprehensive and performant than would ever be possible using Simple Message (between 100 to 1kHz position, velocity and sometimes even force/torque control). And best of all: all of those interfaces are supported by their respective manufacturers. Some will even let you use those interfaces "on the factory floor".

From that perspective it doesn't make much sense to keep using a custom, primitive protocol -- if you'd target those kinds of controllers.

If you don't, and you don't have a good, performant external motion interface available, then using Simple Message (at least as the layer 7 protocol) could still make sense.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes the joints (and other resources) of your robot in a real-time safe way, allowing you to reuse the provided controllers to control the robot in real-time and to the maximum of its abilities (or write new controllers and do things that can't be done by the robot controller itself).

If you'd still like to conform to the ROS-Industrial driver specification, that is still possible, with and without ros_control. Most can be made compliant by remapping.


Edit:

ROS-I seems to have a goal to accelerate adoption into industry. Industry likes to have common interfaces (among countless other things) and this seems to be the exact opposite. A custom, proprietary, interface on everything. Seems counter intuitive, what am I missing (maybe a topic for another question)?

you appear to equate "use the external motion interfaces provided by the manufacturer" to "don't use any standardised interface on the ROS side".

That is not what I wrote, nor what I suggest. Most (if not all) of these interfaces support a handful of control modes, most of which can be abstracted by / encapsulated in standardised infrastructure we already have in ROS. If using ros_control for example, the joint_trajectory_controller could be used in combination with your custom hardware_interface to provide a ROS-standard FollowJointTrajectory Action interface which in the end makes use of manufacturer-specific transports and infrastructure. But your ROS application would never see that.

That's what the abstraction we call hardware_interface allows us to do: control an external system using whatever is available to us, but do so in a way that we can layer ROS-standard interfaces on-top of that.

(note that ros_control is not needed at all for this: it's perfectly possible to write a driver that exposes a standard FollowJointTrajectory Action interface without it. You'd just end up doing a lot of the work yourself)

And I would argue this is no different from how we integrate different SLAM or sensor-fusion algorithms or libraries in ROS nodes, or how we integrate with OpenCV and PCL. It's all custom -- but appropriate in those contexts and/or domains -- but we wrap it in a ROS API to make our lives easier.

I believe your question is based on a misunderstanding of my comments (I'm not a native speaker, so there is a good chance this is a fault on my side).

You write:

During that development process it's come to my attention that my development is apparently following the "old" (Simple Message) interfaces mostly by way of comments about the documentation being out of date. For example, these questions all have answers or comments that mention that the Simple Message interface is old but don't point to the updated info [..]

and:

Unfortunately, I've been unable to find any documentation/tutorial/webpage that specifically details what the most up to date Robot Support Package interfaces are [..] Does anyone have any links or otherwise to information or documentation (or at a minimum a example repo) that details the newer ROS-I Robot Support Package interfaces?

I believe the specific comment that confused and caused you to (eventually) post this question was (by me in #q330389):

Finally:

I'm working on creating a ROS-i robot support package based upon reading their FAQ/Tutorials (http://wiki.ros.org/Industrial/Tutorials).

as the approach that was taken for the older drivers (ie: using Simple Message et al) is not something that is still often being used, those tutorials have gotten a bit stale. They should be updated, or at least their status should be made more clear.

What I meant to say here was (and still is) that using Simple Message itself could be considered "old". Not that there is an "old and new way" of interfacing with robot controllers that are both "part of ROS-Industrial".

Simple Message was really only created as a stop-gap measure, at a time (around 2010/11) when external motion control interfaces to industrial robot controllers were not ubiquitous (or at least not on the controllers targetted at that point in time). It is a very simple, primitive protocol that just serves its purpose (because of the very limited programming and runtime environments these controllers have), until you have something better available to you.

For most industrial robot controllers, "something better" has been available for quite a few years. KUKA has (and has had) RSI, FRI, SmartServo, DirectServo, EKI and some others. ABB has EGM. Fanuc has Stream Motion. Mitsubishi has MXT. Universal Robots has RTDE. Denso has b-CAP. Kawasaki has KRNX. Etc. Etc.

All of those interfaces support external motion control orders of magnitude more comprehensive and performant than would ever be possible using Simple Message (between 100 to 1kHz position, velocity and sometimes even force/torque control). And best of all: all of those interfaces are supported by their respective manufacturers. Some will even let you use those interfaces "on the factory floor".

From that perspective it doesn't make much sense to keep using a custom, primitive protocol -- if you'd target those kinds of controllers.

If you don't, and you don't have a good, performant external motion interface available, then using Simple Message (at least as the layer 7 protocol) could still make sense.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes the joints (and other resources) of your robot in a real-time safe way, allowing you to reuse the provided controllers to control the robot in real-time and to the maximum of its abilities (or write new controllers and do things that can't be done by the robot controller itself).

If you'd still like to conform to the ROS-Industrial driver specification, that is still possible, with and without ros_control. Most can be made compliant by remapping.


Edit:

ROS-I seems to have a goal to accelerate adoption into industry. Industry likes to have common interfaces (among countless other things) and this seems to be the exact opposite. A custom, proprietary, interface on everything. Seems counter intuitive, what am I missing (maybe a topic for another question)?

you appear to equate "use the external motion interfaces provided by the manufacturer" to "don't use any standardised interface on the ROS side".

That is not what I wrote, nor what I suggest. Most (if not all) of these interfaces support a handful of control modes, most of which can be abstracted by / encapsulated in standardised infrastructure we already have in ROS. If using ros_control for example, the joint_trajectory_controller could be used in combination with your custom hardware_interface to provide a ROS-standard FollowJointTrajectory Action interface which in the end makes use of manufacturer-specific transports and infrastructure. But your ROS application would never see that.the manufacturer's side, only the ROS API of the controller.

That's what the abstraction we call hardware_interface allows us to do: control an external system using whatever is available to us, but do so in a way that we can layer ROS-standard interfaces on-top of that.

(note that ros_control is not needed at all for this: it's perfectly possible to write a driver that exposes a standard FollowJointTrajectory Action interface without it. You'd just end up doing a lot of the work yourself)

And I would argue this is no different from how we integrate different SLAM or sensor-fusion algorithms or libraries in ROS nodes, or how we integrate with OpenCV and PCL. It's all custom -- but appropriate in those contexts and/or domains -- but we wrap it in a ROS API to make our lives easier.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes

On the diagram on the ros_control page the hardware_interface::RobotHW block (orange) seems to be operating on the SimpleMessage paradigm.

I'm not sure I completely understand what you mean by "the SimpleMessage paradigm". So just to clarify: the read()/write() pair of functions can do whatever it wants. It doesn't need to use any particular transport or means to communicate with the hardware. That is completely left to the implementor. I've written hardware_interfaces where simple uint32 registers were used, and others where an entire Ethercat fieldbus was between me and the device that was being controlled. There are even hardware_interfaces that use regular ROS topics (even services) to communicate with a node that happens to expose the necessary functionality (I wouldn't recommend to do that, but it illustrates my point).

(JointEffort/JointState messages) This is where I get confused as I wrote a hardware_interface against these messages.

I'm also not entirely sure what you mean by this, but again, to clarify: the diagram shows possibilities, it's not prescriptive. Note the e.g.. This may be something you want to take up with the ros_control maintainers, as the diagram could certainly be improved.

Similar to my comment above: read()/write() are free to do whatever they need to convert ROS-standard input (ie: angles in radians, velocities in rad/s, effort in N or Nm) to what the hardware needs. The hardware_interface is responsible for exposing the correct resources for the control modes that should be supported (ie: create the right JointHandles and registerInterface(..) the correct interfaces).

Not all robots support an effort interface (I would almost say: almost no robot supports it). But that is OK. At a minimum a (joint) position interface would be required.

If you'd still like to conform to the ROS-Industrial driver specification, that is still possible, with and without ros_control. Most can be made compliant by remapping.

So the simple answer here is Yes, that's exactly what I want to do. Problem is that I'm still confused as to what exactly defines compliance, where that information is, and what I have to do to get there from a bare robot that has it's own command/control API.

Adherence would mean that the specified topics, services and actions are provided by the driver (ie: the ROS API). This is specced in wiki/Industrial/Industrial_Robot_Driver_Spec. For ros_control specifically, this means you'd have to remap some of the topics and action servers, as those typically don't use those names or are namespaced differently.

Some specifics are not supported by the standard controllers offered by ros_controllers (such as the joint_command topic, but configuring a JointGroupPositionController implements the same semantics (although the message type is different).

In my personal opinion (so not of the "project" ROS-Industrial) the driver specification should be revised. There has been a lack of momentum though, both on the OSS side as well as the consortium side, as interests appear to be elsewhere at the moment.

I believe your question is based on a misunderstanding of my comments (I'm not a native speaker, so there is a good chance this is a fault on my side).

You write:

During that development process it's come to my attention that my development is apparently following the "old" (Simple Message) interfaces mostly by way of comments about the documentation being out of date. For example, these questions all have answers or comments that mention that the Simple Message interface is old but don't point to the updated info [..]

and:

Unfortunately, I've been unable to find any documentation/tutorial/webpage that specifically details what the most up to date Robot Support Package interfaces are [..] Does anyone have any links or otherwise to information or documentation (or at a minimum a example repo) that details the newer ROS-I Robot Support Package interfaces?

I believe the specific comment that confused and caused you to (eventually) post this question was (by me in #q330389):

Finally:

I'm working on creating a ROS-i robot support package based upon reading their FAQ/Tutorials (http://wiki.ros.org/Industrial/Tutorials).

as the approach that was taken for the older drivers (ie: using Simple Message et al) is not something that is still often being used, those tutorials have gotten a bit stale. They should be updated, or at least their status should be made more clear.

What I meant to say here was (and still is) that using Simple Message itself could be considered "old". Not that there is an "old and new way" of interfacing with robot controllers that are both "part of ROS-Industrial".

Simple Message was really only created as a stop-gap measure, at a time (around 2010/11) when external motion control interfaces to industrial robot controllers were not ubiquitous (or at least not on the controllers targetted at that point in time). It is a very simple, primitive protocol that just serves its purpose (because of the very limited programming and runtime environments these controllers have), until you have something better available to you.

For most industrial robot controllers, "something better" has been available for quite a few years. KUKA has (and has had) RSI, FRI, SmartServo, DirectServo, EKI and some others. ABB has EGM. Fanuc has Stream Motion. Mitsubishi has MXT. Universal Robots has RTDE. Denso has b-CAP. Kawasaki has KRNX. Etc. Etc.

All of those interfaces support external motion control orders of magnitude more comprehensive and performant than would ever be possible using Simple Message (between 100 to 1kHz position, velocity and sometimes even force/torque control). And best of all: all of those interfaces are supported by their respective manufacturers. Some will even let you use those interfaces "on the factory floor".

From that perspective it doesn't make much sense to keep using a custom, primitive protocol -- if you'd target those kinds of controllers.

If you don't, and you don't have a good, performant external motion interface available, then using Simple Message (at least as the layer 7 protocol) could still make sense.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes the joints (and other resources) of your robot in a real-time safe way, allowing you to reuse the provided controllers to control the robot in real-time and to the maximum of its abilities (or write new controllers and do things that can't be done by the robot controller itself).

If you'd still like to conform to the ROS-Industrial driver specification, that is still possible, with and without ros_control. Most can be made compliant by remapping.


Edit:

ROS-I seems to have a goal to accelerate adoption into industry. Industry likes to have common interfaces (among countless other things) and this seems to be the exact opposite. A custom, proprietary, interface on everything. Seems counter intuitive, what am I missing (maybe a topic for another question)?

you appear to equate "use the external motion interfaces provided by the manufacturer" to "don't use any standardised interface on the ROS side".

That is not what I wrote, nor what I suggest. Most (if not all) of these interfaces support a handful of control modes, most of which can be abstracted by / encapsulated in standardised infrastructure we already have in ROS. If using ros_control for example, the joint_trajectory_controller could be used in combination with your custom hardware_interface to provide a ROS-standard FollowJointTrajectory Action interface which in the end makes use of manufacturer-specific transports and infrastructure. But your ROS application would never see the manufacturer's side, only the ROS API of the controller.

That's what the abstraction we call hardware_interface allows us to do: control an external system using whatever is available to us, but do so in a way that we can layer ROS-standard interfaces on-top of that.

(note that ros_control is not needed at all for this: it's perfectly possible to write a driver that exposes a standard FollowJointTrajectory Action interface without it. You'd just end up doing a lot of the work yourself)

And I would argue this is no different from how we integrate different SLAM or sensor-fusion algorithms or libraries in ROS nodes, or how we integrate with OpenCV and PCL. It's all custom -- but appropriate in those contexts and/or domains -- but we wrap it in a ROS API to make our lives easier.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes

On the diagram on the ros_control page the hardware_interface::RobotHW block (orange) seems to be operating on the SimpleMessage paradigm.

I'm not sure I completely understand what you mean by "the SimpleMessage paradigm". So just to clarify: the read()/write() pair of functions can do whatever it wants. It doesn't need to use any particular transport or means to communicate with the hardware. That is completely left to the implementor. I've written hardware_interfaces where simple uint32 registers were used, and others where an entire Ethercat fieldbus was between me and the device that was being controlled. There are even hardware_interfaces that use regular ROS topics (even services) to communicate with a node that happens to expose the necessary functionality (I wouldn't recommend to do that, but it illustrates my point).

(JointEffort/JointState messages) This is where I get confused as I wrote a hardware_interface against these messages.

I'm also not entirely sure what you mean by this, but again, to clarify: the diagram shows possibilities, it's not prescriptive. Note the e.g.. This may be something you want to take up with the ros_control maintainers, as the diagram could certainly be improved.

Similar to my comment above: read()/write() are free to do whatever they need to convert ROS-standard input (ie: angles in radians, velocities in rad/s, effort in N or Nm) to what the hardware needs. The hardware_interface is responsible for exposing the correct resources for the control modes that should be supported (ie: create the right JointHandles and registerInterface(..) the correct interfaces).

Not all robots support an effort interface (I would almost say: almost no robot supports it). But that is OK. At a minimum a (joint) position interface would be required.

If you'd still like to conform to the ROS-Industrial driver specification, that is still possible, with and without ros_control. Most can be made compliant by remapping.

So the simple answer here is Yes, that's exactly what I want to do. Problem is that I'm still confused as to what exactly defines compliance, where that information is, and what I have to do to get there from a bare robot that has it's own command/control API.

Adherence would mean that the specified topics, services and actions are provided by the driver (ie: the ROS API). This is specced in wiki/Industrial/Industrial_Robot_Driver_Spec. For ros_control specifically, this means you'd have to remap some of the topics and action servers, as those typically don't use those names or are namespaced differently.

Some specifics are not supported by the standard controllers offered by ros_controllers (such as the joint_command topic, but configuring a JointGroupPositionController implements the same semantics (although the message type is different).

Section 1.4.1 (Essential Capabilities) can be completely adhered to by supporting a FollowJointTrajectory Action interface (which would be trivial once you have a working hardware_interface).

In my personal opinion though (so not of the "project" ROS-Industrial) the driver specification should be revised. There has been a lack of momentum though, both on the OSS side as well as the consortium side, as interests appear to be elsewhere at the moment.

I believe your question is based on a misunderstanding of my comments (I'm not a native speaker, so there is a good chance this is a fault on my side).

You write:

During that development process it's come to my attention that my development is apparently following the "old" (Simple Message) interfaces mostly by way of comments about the documentation being out of date. For example, these questions all have answers or comments that mention that the Simple Message interface is old but don't point to the updated info [..]

and:

Unfortunately, I've been unable to find any documentation/tutorial/webpage that specifically details what the most up to date Robot Support Package interfaces are [..] Does anyone have any links or otherwise to information or documentation (or at a minimum a example repo) that details the newer ROS-I Robot Support Package interfaces?

I believe the specific comment that confused and caused you to (eventually) post this question was (by me in #q330389):

Finally:

I'm working on creating a ROS-i robot support package based upon reading their FAQ/Tutorials (http://wiki.ros.org/Industrial/Tutorials).

as the approach that was taken for the older drivers (ie: using Simple Message et al) is not something that is still often being used, those tutorials have gotten a bit stale. They should be updated, or at least their status should be made more clear.

What I meant to say here was (and still is) that using Simple Message itself could be considered "old". Not that there is an "old and new way" of interfacing with robot controllers that are both "part of ROS-Industrial".

Simple Message was really only created as a stop-gap measure, at a time (around 2010/11) when external motion control interfaces to industrial robot controllers were not ubiquitous (or at least not on the controllers targetted at that point in time). It is a very simple, primitive protocol that just serves its purpose (because of the very limited programming and runtime environments these controllers have), until you have something better available to you.

For most industrial robot controllers, "something better" has been available for quite a few years. KUKA has (and has had) RSI, FRI, SmartServo, DirectServo, EKI and some others. ABB has EGM. Fanuc has Stream Motion. Mitsubishi has MXT. Universal Robots has RTDE. Denso has b-CAP. Kawasaki has KRNX. Etc. Etc.

All of those interfaces support external motion control orders of magnitude more comprehensive and performant than would ever be possible using Simple Message (between 100 to 1kHz position, velocity and sometimes even force/torque control). And best of all: all of those interfaces are supported by their respective manufacturers. Some will even let you use those interfaces "on the factory floor".

From that perspective it doesn't make much sense to keep using a custom, primitive protocol -- if you'd target those kinds of controllers.

If you don't, and you don't have a good, performant external motion interface available, then using Simple Message (at least as the layer 7 protocol) could still make sense.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes the joints (and other resources) of your robot in a real-time safe way, allowing you to reuse the provided controllers to control the robot in real-time and to the maximum of its abilities (or write new controllers and do things that can't be done by the robot controller itself).

If you'd still like to conform to the ROS-Industrial driver specification, that is still possible, with and without ros_control. Most can be made compliant by remapping.


Edit:

ROS-I seems to have a goal to accelerate adoption into industry. Industry likes to have common interfaces (among countless other things) and this seems to be the exact opposite. A custom, proprietary, interface on everything. Seems counter intuitive, what am I missing (maybe a topic for another question)?

you appear to equate "use the external motion interfaces provided by the manufacturer" to with "don't use any standardised interface on the ROS side".

That is not what I wrote, nor what I suggest. Most (if not all) of these interfaces support a handful of control modes, most of which can be abstracted by / encapsulated in standardised infrastructure we already have in ROS. If using ros_control for example, the joint_trajectory_controller could be used in combination with your custom hardware_interface to provide a ROS-standard FollowJointTrajectory Action interface which in the end makes use of manufacturer-specific transports and infrastructure. But your ROS application would never see the manufacturer's side, only the ROS API of the controller.

That's what the abstraction we call hardware_interface allows us to do: control an external system using whatever is available to us, but do so in a way that we can layer ROS-standard interfaces on-top of that.

(note that ros_control is not needed at all for this: it's perfectly possible to write a driver that exposes a standard FollowJointTrajectory Action interface without it. You'd just end up doing a lot of the work yourself)

And I would argue this is no different from how we integrate different SLAM or sensor-fusion algorithms or libraries in ROS nodes, or how we integrate with OpenCV and PCL. It's all custom -- but appropriate in those contexts and/or domains -- but we wrap it in a ROS API to make our lives easier.

If you do: I would look into writing a ros_control compatible hardware_interface that exposes

On the diagram on the ros_control page the hardware_interface::RobotHW block (orange) seems to be operating on the SimpleMessage paradigm.

I'm not sure I completely understand what you mean by "the SimpleMessage paradigm". So just to clarify: the read()/write() pair of functions can do whatever it wants. It doesn't need to use any particular transport or means to communicate with the hardware. That is completely left to the implementor. I've written hardware_interfaces where simple uint32 registers were used, and others where an entire Ethercat fieldbus was between me and the device that was being controlled. There are even hardware_interfaces that use regular ROS topics (even services) to communicate with a node that happens to expose the necessary functionality (I wouldn't recommend to do that, but it illustrates my point).

(JointEffort/JointState messages) This is where I get confused as I wrote a hardware_interface against these messages.

I'm also not entirely sure what you mean by this, but again, to clarify: the diagram shows possibilities, it's not prescriptive. Note the e.g.. This may be something you want to take up with the ros_control maintainers, as the diagram could certainly be improved.

Similar to my comment above: read()/write() are free to do whatever they need to convert ROS-standard input (ie: angles in radians, velocities in rad/s, effort in N or Nm) to what the hardware needs. The hardware_interface is responsible for exposing the correct resources for the control modes that should be supported (ie: create the right JointHandles and registerInterface(..) the correct interfaces).

Not all robots support an effort interface (I would almost say: almost no robot supports it). But that is OK. At a minimum a (joint) position interface would be required.

If you'd still like to conform to the ROS-Industrial driver specification, that is still possible, with and without ros_control. Most can be made compliant by remapping.

So the simple answer here is Yes, that's exactly what I want to do. Problem is that I'm still confused as to what exactly defines compliance, where that information is, and what I have to do to get there from a bare robot that has it's own command/control API.

Adherence would mean that the specified topics, services and actions are provided by the driver (ie: the ROS API). This is specced in wiki/Industrial/Industrial_Robot_Driver_Spec. For ros_control specifically, this means you'd have to remap some of the topics and action servers, as those typically don't use those names or are namespaced differently.

Some specifics are not supported by the standard controllers offered by ros_controllers (such as the joint_command topic, but configuring a JointGroupPositionController implements the same semantics (although the message type is different).

Section 1.4.1 (Essential Capabilities) can be completely adhered to by supporting a FollowJointTrajectory Action interface (which would be trivial once you have a working hardware_interface).

In my personal opinion though (so not of the "project" ROS-Industrial) the driver specification should be revised. There has been a lack of momentum though, both on the OSS side as well as the consortium side, as interests appear to be elsewhere at the moment.