[Documentation] [TitleIndex] [WordIndex

ROS-Industrial Robot Driver Specification (Final)

Provides guidelines for ROS node functionality, to improve cross-platform compatibility. All ROS nodes that provide an interface to an industrial robot controller should adhere to the specification.

Comments/Questions on this specification can be sent to the ROS-Industrial mailing list.

Motivation

One of the primary benefits of ROS-Industrial is that it enables interoperability between robots from different vendors, by integrating their control with the common ROS framework. Even though ROS integration is a good start, better compatibility is achieved when these different ROS nodes all utilize a common set of interfaces for control and feedback.

This page attempts to provide some guidelines on what specific ROS interfaces should be provided by a ROS-Industrial robot to ensure maximum compatibility. It is expected that vendor-specific implementation details may require compromises in some areas, but this will hopefully provide a “gold standard” implementation description. See below for details on a Reference Implementation following these guidelines and a Hardware Compatibility List that provides platform-specific information.

Operation

This section describes how the robot is expected to respond to high-level operational activities (e.g. startup, shutdown, etc.).

Initialization

Communications

ROS API

This section describes specific ROS interfaces (topics, services, and parameters) that the robot should provide. These capabilities may be provided by a single node or multiple nodes, as needed by the robot communications architecture.

It is also possible that different nodes may be used to provide the same capabilities with different assumptions, communications methods, etc. ROS launch files can be used to control which nodes are appropriate to run for a given application.

General

Parameters

State Feedback

Published Topics

Motion Control

This node implements methods to control the robot's movement.

Several different types of control may be implemented (trajectory download, streaming points, force-control, etc.), and may not all be compatible with each other. The robot implementation can provide these methods in a single "master motion node", or as discrete single-purpose nodes. It is up to the implementation to ensure that conflicting input from different motion controllers is handled properly. in general, only one controller should be commanding robot motion at a time. For complex systems, it may be appropriate to have a "motion manager" node that aggregates and prioritizes competing commands coming from different motion controllers.

Subscribed Topics

Services

Kinematics

To enable real-time motion planning and collision avoidance, the node should provide robot-specific inverse kinematics solutions. A generic solver is provided in ROS, but it operates too slowly for collision-avoidance path planning. As described here and here, the ikfast tool can be used to generate the required kinematics files for any 6-DOF serial manipulator. These files should be integrated with ROS as a plugin, not a service, to avoid expensive communications-related overhead. This involves creating a launch file to connect your plugin with the ROS arm_kinematics_constraint_aware node, as described here.

Path Accuracy

The motion interfaces outlined above do not specify the required accuracy for following a particular trajectory. The level of path accuracy achieved will depend on limitations of the specific robot, controller, and ROS-interface driver.

Collision Padding

The ROS path planners and collision checkers use high-order smoothing of trajectories between waypoints. The resulting trajectory, as executed by the robot controller, will follow a similar “smooth” trajectory, "but may not exactly match the "ideal" planned trajectory". For this reason, the ROS path planners add a specified amount of “padding” to the robot models to account for differences between the planned and actual paths. This results in a very high probability of collision-free motion. Increasing the level of padding reduces the chance of collisions.

A closer integration between path planners and robot controllers would reduce both the path-execution error and the collision-padding requirement. However, this level of integration is beyond the scope of current ROS-Industrial efforts and may require robot-specific solutions.

Implementation

This section provides details on current implementations of ROS-Industrial, and how closely they follow these guidelines.

Essential Capabilities

The following capabilities are essential for robots to interact smoothly with other ROS-Industrial components:

Reference Implementation

A reference implementation of a ROS-Industrial node implementing these capabilities can be found here. This implementation uses a simple message-based socket protocol to communicate with industrial robots.

New robot implementations are encouraged to consider using this client, if appropriate, for their robot. See the ABB and Motoman implementations for examples of how to integrate a robot-side server application with a ROS-Industrial client node derived from this reference implementation.

Hardware Compatibility List

The Hardware Compatibility List documents which features outlined in this page are supported by various robot-specific implementations. Consult this list before developing your application, to determine whether your target robot platform supports all the necessary ROS interfaces.

Future Plans

The Future Plans page lists a few ideas we have for expanding the functionality of ROS-Industrial nodes. These items still need some refinement/discussion, so are not specified above. We welcome your suggestions on any of these items. Or, feel free to suggest more features!


2018-06-18 22:56