Skip to content

rep-I0005.rst

Latest commit

 

History

History
173 lines (144 loc) · 6.8 KB

rep-I0005.rst

File metadata and controls

173 lines (144 loc) · 6.8 KB
REP: I0005
Title: Cartesian Motion Extensions for the Simple Message Protocol
Authors: Fred Proctor <proctor@nist.gov> and Tre Harrison <william.harrison@nist.gov>
Status: Active
Type: Process
Content-Type: text/x-rst

Outline

  1. Abstract
  2. Motivation
  3. Message Specifications
  4. Cartesian Move Request
  5. Cartesian Move Reply
  6. Cartesian Move State
  7. References
  8. Revision History
  9. Copyright

Abstract

This REP documents extensions to the Simple Message protocol that support Cartesian motion.

Motivation

The Simple Mesage protocol defines a low-level interface to robot controllers that can easily be implemented. Together with reference implementations of Robot Operating System (ROS) trajectory planners, Simple Message provides a way for robot vendors to quickly provide baseline ROS functionality to their systems.

Simple Message is a joint-level interface that requires the external system to perform the inverse kinematics calculations. Robot controllers typically provide this function internally, and the proposed extensions enable external systems to benefit from the vendor's built-in kinematics.

Recognizing that robot controllers have limited computing power, data representations have been chosen to reduce the burden of converting between non-native representations, and reducing the need to to convert between different data sizes.

Assumptions

  1. Messages are fixed length, so that robot controllers do not need to dynamically allocate storage for variable length messages.
  2. Integer numbers are 32-bit 2's complement, little-endian. Floating-point numbers are 32-bit little-endian following the IEEE 754 standard. See [2].
  3. Units are SI units (meters, radians, seconds).
  4. Message identifiers are unique for each message type.
  5. Sequence numbers associate replies with requests. Replies are send upon receipt of commands, and when they complete, either successfully or with an error. The type of error is not reported.
  6. State feeback messages are sent continuously at a period determined by the robot controller. If a Cartesian move request is executing, or was the most recent request to complete, Cartesian state feedback will be sent. Joint state feedback messages may also be sent, depending on the controller.
  7. Poses are with respect to the robot's world frame. Motions that are specified relative to other frames, like the tool frame, should be done in the application, and converted into the world frame.
  8. Cartesian move requests will not alter the configuration flags that resolve ambiguities between Cartesian space and joint space. If a change in the robot configuration is desired, that change should be made with joint move request. [Note: the situation is reversed for parallel kinematic mechanisms.]
  9. Multiple Cartesian motion groups are not yet supported.
  10. Tolerances on the path and final pose are not yet supported. Applications can inspect the Cartesian state feedback upon the reported completion of the move to determine if the motion completed within the application's tolerance.

Message Specifications

Cartesian Move Request

A Cartesian move message requests that the robot move to the specified Cartesian position and Euler ZYX orientation along a straight line and about a fixed rotational axis. The sequence number provided will be used in subsequent messages from the robot controller to associate replies and status with the move request. The translational speed applies to the motion along the straight line. The rotational speed applies to the motion about the fixed axis. Translational and rotational motion should finish at the same time, and in general one of these speeds may be slower than specified to ensure simultaneous arrival. The duration is the time for the move. If positive, the duration is used instead of the speeds. At least one of the translational speed, rotational speed, or duration values must be positive.

Format of a Cartesian move request:

int length: 4 bytes, constant value 13 x 4 = 52
int message_type: 4 bytes, constant value 31
int comm_type; 4 bytes, constant value 2, REQUEST
int reply_type: 4 bytes, ignored, any value, typically 0
int sequence: 4 bytes, identifying this request
float x, y, z, ez, ey, ex: 4 bytes each, for the requested
Cartesian position and Euler ZYX rotation
float translational_speed: 4 bytes, the speed to be applied to the
translational part
float rotational_speed: 4 bytes, the speed to be applied to the
rotational part
float duration: 4 bytes, the time in seconds for the move

Cartesian Move Reply

The robot controller should reply to each Cartesian move request with a reply that the request can be initiated. Immediately upon receipt of the move request, the robot controller should reply with this message with the reply_type set to 3 (EXECUTING), or 2 (FAILURE) if the move request is not possible. When the motion has finished, the robot controller should reply with the reply_type set to 1 (SUCCESS), or 3 (FAILURE) if the move did not finish where requested.

Format of a Cartesian move reply:

int length: 4 bytes, constant value 4 x 4 = 16
int message_type: 4 bytes, constant value 32
int comm_type; 4 bytes, constant value 3, REPLY
int reply_type: 4 bytes, 1 = SUCCESS, 2 = FAILURE, 3 = EXECUTING
int sequence: 4 bytes, identifying this request

Cartesian Move State

The robot controller should continually send back Cartesian move state messages as the move progresses, with the current pose and either speeds or time into the move as set by the request.

Format of a Cartesian move state message:

int length: 4 bytes, constant value 13 x 4 = 52
int message_type: 4 bytes, constant value 33
int comm_type; 4 bytes, constant value 1, TOPIC
int reply_type: 4 bytes, ignored, any value, typically 0
int seq_number: 4 bytes, identifying the most recent request
float x, y, z, ex, ey, ez: 4 bytes each, for the requested
Cartesian position and Euler ZYX orientation
float translational_speed: 4 bytes, the current speed of the
translational part
float rotational_speed: 4 bytes, the current speed of the
orientation part
float duration: 4 bytes, time into the move

References

[1]ROS-Industrial simple_message package, ROS Wiki, on-line, retrieved 1 June 2014 (http://wiki.ros.org/simple_message)
[2]Simple Message Tutorial, ROS Wiki. (http://wiki.ros.org/Industrial/Tutorials/create_joint_position_streaming_interface_using_tcp_socket_libraries)

Revision History

:: 2015-07-13 Updates after first round of comments 2015-05-20 Initial revision

Copyright

This document has been placed in the public domain.