One of the primary goals of ROS-I is facilitating interoperability among robots from different vendors by integrating their control with the common ROS framework. These different ROS control nodes all utilize a common set of interfaces for control and feedback. Also, ROS-I has provided the guidelines for specific ROS interfaces to ensure maximum compatibility.

First of all, we will discuss how the robot should be expected to respond to high-level operational activities:

• Initialization: The ROS node should automatically initialize all connections to the robot controller, and the robot startup should make the controller program run automatically.
• Communications: Both the ROS node and the robot controller program must handle the communications-loss scenarios so that they can implement a heartbeat message between them.

Next, we are going to discuss specific ROS interfaces—topics, services, and parameters. These interfaces must be provided by the robot controller program, which might be a single node or multiple nodes, as required by the robot communications architecture. The robot controller program must incorporate the following parameters:

• robot_ip_address (string): IP address of the robot
• robot_description (urdp map xml): The URDF description of the robot

Further, a robot controller program should publish the following topics:

• feedback_states (control_msgs/FollowJointTrajectory): Provides feedback on the current and desired joint state, which is used by joint_trajectory_action
• joint_states (sensor_msgs/JointState): Provides feedback on the current joint state, which is used by the robot_state_publisher node to broadcast kinematic transforms
• robot_status (industrial_msgs/RobotStatus): Provides the current status of the robot, which is used by application code to monitor and react to different fault conditions

In addition, the robot controller program which controls the robot's movement should subscribe to the following topics:

• joint_path_command (trajectory_msgs/JointTrajectory): Executes a pre-calculated joint trajectory on the robot and is used by ROS's trajectory generator's joint_trajectory_action to issue motion commands
• joint_command (trajectory_msgs/JointTrajectoryPoint): Executes a dynamic motion by streaming joint commands while in motion, which is used by client code to control the robot's position in real time

Finally, there should be service interfaces provided by the robot controller such as:

• stop_motion(industrial_msgs/StopMotion): Stop current robot motion
• joint_path_command(industrial_msgs/CmdJointTrajectory): Execute a new motion trajectory on the robot

To implement real-time motion planning and collision avoidance, the node should provide robot-specific inverse kinematics (IK) solutions. However, a generic numerical solver is provided in ROS that works with most cases, but it operates too slowly for collision-avoidance path planning. It is possible to have a custom version of IK-solver (http://wiki.ros.org/Industrial/Tutorials/Create_a_Fast_IK_Solution). In the next section, we will discuss how to generate an IK solver plugin using IKFast, a powerful inverse kinematics solver.

The ROS path planners and collision checkers implement a high-order smoothing algorithm for trajectories following waypoints. However, the resulting trajectory, as executed by the robot controller, might not exactly match the ideal planned trajectory. Therefore, the ROS path planners add a specified amount of padding to the robot models to account for differences between the planned and actual paths. The amount of padding has to be calculated experimentally, which results in collision-free motion mostly; however it increases the level of padding and reduces the chance of collision.

Although appropriate integration between path planners and robot controllers would reduce both the path-execution error and the collision-padding requirement, it requires more effort from specific robot controller developers.

As discussed in the previous section, a reference implementation of an ROS-I node implementing these capabilities can be seen at http://wiki.ros.org/industrial_robot_client. This uses a simple message-based socket protocol to communicate with the industrial robot controller. We can also refer to the ABB and Motoman implementations for examples, which have been described in the previous section. The example programs at abb_driver or ur_driver describe how to integrate a robot-side server application with an ROS-I client node derived from these reference implementations.