motoman_interfaces
motoman_interfaces defines 13 interface(s).
Messages
DynamicJointPoint
DynamicJointPoint group: # length of this array must match num_groups id: control-group ID for use on-controller num_joints: # of joints in this motion group valid_fields: #bit field for following items # length of the following items must match num_joints, order set by controller. Invalid fields (see bit field above) are not included, resulting in a shorter message. positions[] velocities[] accelerations[] effort[] time_from_start
int16 num_groups
DynamicJointsGroup[] groups
DynamicJointState
group[]: # length of this array must match num_groups id: control-group ID for use on-controller num_joints: # of joints in this motion group valid_fields: #bit field for following items # length of the following items must match num_joints, order set by controller. Invalid fields (see bit field above) are not included, resulting in a shorter message. positions[] velocities[] accelerations[] effort[] position_desired[] position_errors[] velocity_desired[] velocity_errors[] effort_desired[] effort_error[]
int16 group_number
int16 num_joints
int16 valid_fields
float64[] positions
float64[] velocities
float64[] accelerations
float64[] effort
float64[] positions_desired
float64[] positions_errors
float64[] velocities_desired
float64[] velocities_errors
float64[] accelerations_desired
float64[] accelerations_errors
float64[] effort_errors
float64[] effort_desired
DynamicJointTrajectory
length: true message/data length header: sequence: num_groups: # of motion groups included in this message group[]: DynamicJointPoint from DynamicJointPoint.msg
std_msgs/Header header
string[] joint_names
DynamicJointPoint[] points
DynamicJointTrajectoryFeedback
std_msgs/Header header
int16 num_groups
DynamicJointState[] joint_feedbacks
DynamicJointsGroup
DynamicJointsGroup group: # length of this array must match num_groups id: control-group ID for use on-controller num_joints: # of joints in this motion group valid_fields: #bit field for following items # length of the following items must match num_joints, order set by controller. Invalid fields (see bit field above) are not included, resulting in a shorter message. positions[] velocities[] accelerations[] effort[] time_from_start
int16 group_number
int16 num_joints
int16 valid_fields
float64[] positions
float64[] velocities
float64[] accelerations
float64[] effort
builtin_interfaces/Duration time_from_start
Services
CmdJointTrajectoryEx
Description: Send a DynamicJointTrajectory command to the robot. - duplicates functionality of the joint_path_command topic - provides a response-code to verify command was received - returns when trajectory is sent to robot, not when motion completed - return code may NOT indicate successful transfer to robot
# --- Request ---
# DynamicJointTrajectory to be sent to the robot
motoman_interfaces/DynamicJointTrajectory trajectory
---
# --- Response ---
# Return code to verify command was received
industrial_msgs/ServiceReturnCode code
ReadGroupIO
Read (and return) the current value of the Group IO element at ‘address’. Addresses are plain, base-10 integers, as used and displayed by the controller (on the teach pendant for instance). There are no restrictions as to which group IO elements can be read, but they have to exist on the controller and be configured correctly. NOTE: many programming languages will parse literals starting with ‘0’ as octal numbers. Do not add leading zeros to group addresses to avoid specifying the wrong address to read. Refer also the Yaskawa Motoman documentation on IO addressing and configuration.
# --- Request ---
# Address of the group IO element to read
uint32 address
---
# --- Response ---
# Message from the controller
string message
# True if the read was successful
bool success
# Value of the group IO element
uint8 value
ReadMRegister
Read (and return) the current value of the M register at ‘address’. Addresses are plain, base-10 integers, as used and displayed by the controller (on the teach pendant for instance). Only the following addresses can be read from: - 0 to 999 NOTE 1: do not add 1000000 to the address, MotoROS will do this when necessary. NOTE 2: many programming languages will parse literals starting with ‘0’ as octal numbers. Do not add leading zeros to register addresses to avoid specifying the wrong register to read. Refer also the Yaskawa Motoman documentation on IO addressing and configuration.
# --- Request ---
# Address of the M register to read
uint32 address
---
# --- Response ---
# Message from the controller
string message
# True if the read was successful
bool success
# Value of the M register
uint16 value
ReadSingleIO
Read (and return) the current value of the IO element at ‘address’. Addresses are plain, base-10 integers, as used and displayed by the controller (on the teach pendant for instance). There are no restrictions as to which IO elements can be read, but they have to exist on the controller and be configured correctly. Refer also the Yaskawa Motoman documentation on IO addressing and configuration.
# --- Request ---
# Address of the IO element to read
uint32 address
---
# --- Response ---
# Message from the controller
string message
# True if the read was successful
bool success
int32 value
SelectTool
Change the active tool file on the controller. This changes the tool definition used for both (Moto)ROS-controlled motions and manual jogging. ## Controller support This service wraps two distinct (but related) actions: 1. changing the tool file used for execution of (Moto)ROS-controlled motions 2. changing the tool file used for jogging Action 1 is supported by all controllers supported by MotoROS (ie: DX100, FS100, DX200 and YRC1000(u)). Action 2 is NOT supported on FS100 controllers. This is a limitation of MotoPlus, not of MotoROS. In all cases, make sure to read the following sections carefully to be aware of the behaviour of this service and of the Yaskawa controller after calling this service. ## FSU and PFL Tool switches through this service will be taken into account by the FSU and PFL safety systems if the controller has these options and they are enabled. Tool interference files, if associated with certain tool file definitions, will therefore also switch. ## Tool switch timing The active tool will be switched AFTER the controller has completed execution of the last trajectory segment that was sent to MotoROS BEFORE this service was called. The motion queue internal to MotoROS caches a number of segments in a FIFO. Only segments received AFTER this service was invoked will be executed with the new tool. Any segments received before a tool switch was invoked will use the old tool. To ensure motion will be executed using a certain tool, applications should check the ‘in_motion’ field (part of the RobotStatus message published on the ‘robot_status’ topic by the driver) and invoke the service when the robot has come to a stop (and the motion queue of MotoROS is empty). Any subsequent trajectories will use the new tool. ## Effect on trajectory execution As MotoROS currently only executes joint space trajectories, changing tool file with this service DOES NOT affect the execution of those trajectories. As noted earlier though, the active tool file definition will affect FSU and PFL behaviour, as the tool definition is used in calculation of dynamics and safety (see “FSU and PFL” above). To clarify: the TCP definition of the tool file is NOT taken into account when calculating manipulator motion based on incoming ROS JointTrajectoryAction goals (as JointTrajectory goals do not include any Cartesian poses, only absolute joint space coordinates for each axis). Instead, ROS applications should use different TF frames to define tool frames on the ROS side and plan their motions with the appropriate TF frame as the active tool. This service could then be used to notify the controller of other tool characteristics, such as weight, CoG and inertia by switching to a tool file configured with those parameters. ## Retrieving the active tool file MotoROS does not currently support retrieving the active tool file. For more information about tool file configuration, selection and use on Yaskawa controllers, refer to the relevant Yaskawa Motoman documentation.
# Numeric ID of the group the tool file is defined for.
#
# This MUST correspond to a group ID currently defined and active on the
# controller. The ROS service does not check whether the value specified here
# is legal. The MotoROS server will however check this, and will refuse to
# switch to an illegal value and will report this to the ROS driver.
#
# Callers will be notified of such failures by 'success' being set to 'false'
# and an appropriate error message being provided via the 'message' field of
# the service response.
#
# NOTE: this field is 0-based, with 0 corresponding to the first motion group,
# 1 the second, etc.
#
# legal-values: [0, total_nr_of_groups)
# required: yes (absence-causes-service-failure)
# default: no-default
uint32 group_number
# Numeric ID of the tool file to switch to for the specified group.
#
# Identical to 'group_number', specification of illegal values will result
# in failure to invoke the MotoROS service, and an unsuccessful service result
# being returned.
#
# NOTE: this field is 0-based, with 0 corresponding to the first tool file,
# 1 the second, etc.
#
# legal-values: [0, 63]
# required: yes (absence-causes-service-failure)
# default: no-default
uint32 tool_number
# TODO: might want to expose 'sequence_number' here as well
---
# A human-readable error message, or an empty string if there was no error.
string message
# true IFF invocation of the MotoROS service was successful.
#
# NOTE: this is independent of whether the ROS service invocation was
# successful. In absence of any ROS middleware failures, a failed MotoROS
# service invocation will result in 'success' here being set to 'false',
# but a successful ROS service invocation.
bool success
WriteGroupIO
Write ‘value’ to the Group IO element at ‘address’. Addresses are plain, base-10 integers, as used and displayed by the controller (on the teach pendant for instance). Only the following addresses can be written to: - 2701 and up : Network Inputs (2501 and up on DX100 and FS100) - 1001 and up : Universal/General Outputs NOTE: many programming languages will parse literals starting with ‘0’ as octal numbers. Do not add leading zeros to group addresses to avoid specifying the wrong address to write to.
# Refer also the Yaskawa Motoman documentation on IO addressing and
# configuration.
# --- Request ---
# Address of the group IO element to write to
uint32 address
uint8 value
---
# --- Response ---
# Message from the controller
string message
bool success
WriteMRegister
Write ‘value’ to the M register at ‘address’. Addresses are plain, base-10 integers, as used and displayed by the controller (on the teach pendant for instance). Only the following addresses can be written to: - 0 to 559 NOTE 1: do not add 1000000 to the address, MotoROS will do this when necessary. NOTE 2: many programming languages will parse literals starting with ‘0’ as octal numbers. Do not add leading zeros to register addresses to avoid specifying the wrong register to write to. Refer also the Yaskawa Motoman documentation on IO addressing and configuration.
# --- Request ---
# Address of the M register to write to
uint32 address
uint16 value
---
# --- Response ---
# Message from the controller
string message
# True if the write was successful
bool success
WriteSingleIO
Write ‘value’ to the IO element at ‘address’. This service does not return anything. Addresses are plain, base-10 integers, as used and displayed by the controller (on the teach pendant for instance). Only the following addresses can be written to: - 27010 and up : Network Inputs (25010 and up on DX100 and FS100) - 10010 and up : Universal/General Outputs Refer also the Yaskawa Motoman documentation on IO addressing and configuration.
# --- Request ---
# Address of the IO element to write to
uint32 address
int32 value
---
# --- Response ---
# Message from the controller
string message
# True if the write was successful
bool success