Show EOL distros: 

industrial_core: industrial_deprecated | industrial_msgs | industrial_robot_client | industrial_robot_simulator | industrial_trajectory_filters | industrial_utils | simple_message

Package Summary

industrial robot client contains generic clients for connecting to industrial robot controllers with servers that adhere to the simple message protocol.

industrial_core: industrial_deprecated | industrial_msgs | industrial_robot_client | industrial_robot_simulator | industrial_trajectory_filters | industrial_utils | simple_message

Package Summary

industrial robot client contains generic clients for connecting to industrial robot controllers with servers that adhere to the simple message protocol.

Overview

The industrial_robot_client package provides a standardized interface for controlling industrial robots, based on the ROS-Industrial Specification. This package includes a C++ reference implementation of the specification, using the simple_message protocol to communicate with a compatible server running on a standalone industrial robot controller.

Primarily, this package provides the industrial_robot_client library. The intent is for robot-specific implementations to reuse code from this library using standard C++ derived-class mechanisms, to avoid much of the copy/paste duplication in current industrial-robot driver implementations. Modification to adapt the library to new robot needs is discussed in more detail below.

This package also provides generic nodes exposing the base industrial_robot_client functionality. If a robot does not require any specific client-side code, then it may be sufficient to run these standard nodes. This page describes this usage in more detail.

Protocol documentation

A ROS-Industrial REP describing the Simple Message protocol is currently being reviewed. See ros-industrial/rep#20.

Modification for Robot-Specific Needs

Often, differences between manufacturer interfaces and robot designs will require changes to the basic reference implementation provided in the industrial_robot_client library. Joint-coupling, velocity scaling, and communications protocols are all potential reasons for robot-specific control code.

Rather than make a new copy of the entire ROS client codebase, it is recommended that the integrator use a derived-class approach to only re-implement the minimal functionality required. Wherever possible, the new code should call the base class reference-implementation functions to avoid code duplication and maintain consistent operations. It may be helpful to review the library's design to determine which functionality may need replacing. Simple joint reordering and renaming can be handled through existing capabilities, as described here.

Example

The following example shows how to replace the reference velocity calculation (0-100% of max-velocity) with an absolute velocity algorithm.

  1. Create a new derived class, based on JointTrajectoryDownloader (or JointTrajectoryStreamer)

       1 class myRobot_JointTrajectoryDownloader : JointTrajectoryDownloader
       2 {
       3 ...
       4 }
    
  2. Override specific functionality. In this case, the velocity calculation.
       1 class myRobot_JointTrajectoryDownloader : JointTrajectoryDownloader
       2 {
       3 
       4 public:
       5   bool calc_velocity(const trajectory_msgs::JointTrajectoryPoint& pt, double* rbt_velocity)
       6   {
       7     if (pt.velocities.empty())
       8       *rbt_velocity = SAFE_SPEED;
       9     else
      10       *rbt_velocity = std::min(pt.velocities.begin(), pt.velocities.end());
      11 
      12     return true;
      13   }
      14 }
    
  3. Implement a new node, using an instance of the appropriate derived-class.
       1 int main(int argc, char** argv)
       2 {
       3   // initialize node
       4   ros::init(argc, argv, "motion_interface");
       5 
       6   myRobot_JointTrajectoryDownloader motionInterface;
       7   motionInterface.init();
       8   motionInterface.run();
       9 
      10   return 0;
      11 }
    

Further examples

Further examples of creating robot-specific interfaces may be found in the following code samples:

Nodes

Besides the reusable libraries, this package also provides default implementations of a set of generic nodes. The following is the ROS API of those generic nodes.

robot_state

Connects to a robot state server program on a controller and publishes joint states.

Action Feedback

feedback_states (control_msgs/FollowJointTrajectory)
  • Provide feedback of current vs. desired joint position (and velocity/acceleration).

Published Topics

joint_states (sensor_msgs/JointState)
  • Joint state for all joints of the connected robot.
robot_status (industrial_msgs/RobotStatus)
  • Aggregate controller/robot status (ie: drives enabled, motion possible, etc)

Parameters

robot_ip_address (str, default: none)
  • IP address of the controller to connect to. If this is not set the node will exit.
~port (integer, default: 11002)
  • TCP port the robot state server program is listening on.
robot_description (str, default: none)
  • The urdf xml robot description.
controller_joint_names ([str, str, str, ..])
  • (optional) A list containing all joints the driver should assume control over. If this parameter is not found, the driver will try to extract this from the robot_description parameter, but this will result in all joints in the urdf to be included. If the driver should only publish joint states for a subset of the joints in the urdf, the controller_joint_names parameter must be set.

motion_download_interface

Connects to a motion relay server program on the controller and uploads trajectories. Note: this is the download version of the interface, which means the entire trajectory is uploaded to the motion relay server program before motion is started.

Subscribed Topics

joint_states (sensor_msgs/JointState)
  • Joint state for all joints of the connected robot.
joint_path_command (trajectory_msgs/JointTrajectory)
  • Execute a pre-calculated joint trajectory on the robot.

Services

joint_path_command (industrial_msgs/CmdJointTrajectory)
  • Execute a new motion trajectory on the robot.
stop_motion (industrial_msgs/StopMotion)
  • Stop execution of the current motion at the earliest time possible.

Parameters

robot_ip_address (str, default: none)
  • IP address of the controller to connect to. If this is not set the node will exit.
~port (integer, default: 11000)
  • TCP port the motion relay server program is listening on.
robot_description (str, default: none)
  • The urdf xml robot description.
controller_joint_names ([str, str, str, ..], default: none)
  • (optional) A list containing all joints the driver should assume control over. If this parameter is not found, the driver will try to extract this from the robot_description parameter, but this will result in all joints in the urdf to be included. If the driver should only control a subset of the joints in the urdf, the controller_joint_names parameter must be set.

motion_streaming_interface

Connects to a motion relay server program on the controller and streams trajectories. Note: this is the streaming version of the interface, which means trajectories are relayed piecewise to the motion relay server program and motion is expected to start immediately (or: as soon as possible).

Subscribed Topics

joint_states (sensor_msgs/JointState)
  • Joint state for all joints of the connected robot.
joint_path_command (trajectory_msgs/JointTrajectory)
  • Execute a pre-calculated joint trajectory on the robot.

Services

joint_path_command (industrial_msgs/CmdJointTrajectory)
  • Execute a new motion trajectory on the robot.
stop_motion (industrial_msgs/StopMotion)
  • Stop execution of the current motion at the earliest time possible.

Parameters

robot_ip_address (str, default: none)
  • IP address of the controller to connect to. If this is not set the node will exit.
~port (integer, default: 11000)
  • TCP port the motion relay server program is listening on.
robot_description (str, default: none)
  • The urdf xml robot description.
controller_joint_names ([str, str, str, ..], default: none)
  • (optional) A list containing all joints the driver should assume control over. If this parameter is not found, the driver will try to extract this from the robot_description parameter, but this will result in all joints in the urdf to be included. If the driver should only control a subset of the joints in the urdf, the controller_joint_names parameter must be set.

Contact us/Technical support

For questions about this package or ROS-Industrial in general, please contact the developers by posting a message in the ROS-Industrial category on ROS Discourse.

Reporting bugs

Use GitHub to report bugs or submit feature requests. [View active issues]

Wiki: industrial_robot_client (last edited 2021-06-15 19:47:44 by GvdHoorn)