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 .. code-block:: text 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[] .. code-block:: text 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 .. code-block:: text std_msgs/Header header string[] joint_names DynamicJointPoint[] points DynamicJointTrajectoryFeedback ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. code-block:: text 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 .. code-block:: text 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 .. code-block:: text # --- 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. .. code-block:: text # --- 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. .. code-block:: text # --- 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. .. code-block:: text # --- 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. .. code-block:: text # 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. .. code-block:: text # 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. .. code-block:: text # --- 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. .. code-block:: text # --- 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