Page Comparison

robot_name: The name of the robot you would like to move.

goal: Where the robot will move to, either a target or pose. Goal is a placeholder key, and the acceptable keys are either pose or target . When additional robot axes are present, the goal does not include them. Unless the external axes value is provided as an argument, external axes will either remain fixed during a move, or switch to different setpoint values defined by roadmap moves. Valid key values are as following, pose: [x,y,z,r,p,y] or target: target_name .

speed: The speed at which the robot will move on a scale from 0.01 to 1.0. This scales max velocity but not acceleration or jerk. For planning move types, the speed is capped at 0.1.

external_axes:

If a robot's external axes remain fixed during a move, or switch to different setpoint values defined by a target, external_axes should be left unspecified.

• external_axes is defined as {<axis name>: active} or {<axis name>: <value>}. The names of the external axes must match what is already defined in the RapidPlan Create project.

• use {<axis name>: active} if an external axis is used by RapidPlan software when solving a move to a goal pose.

• use {<axis name>: <value>} if an external axis is used for a move to a goal pose with a specific external axis position value.

move_type:

• 0 or direct

• 1 or roadmap

• 2 or planning

smoothing:

interp:

• 0 or J (default)

• 1 or L

collision_check:

collision_check_dsm:

timeout:

relative:

ref_frame:

preset_name:

trigger:

• name: Only one trigger can be included for each move command, or each move segment of a combined move command. The trigger should have a user defined, stateless, globally unique name, to identify the signal for the receiver of the trigger.

• output: The trigger output should be configured during runtime as part of a move command, to turn on or off the output signal as an 1-shot event, until the signal is overridden by either another Move command, or a different control device, e.g., a PLC. If the output key is not specified, this trigger is disabled and trigger time is ignored. If output is specified, trigger time must be defined and cannot be omitted.

  • 0 or false: output is off

  • 1 or true: output is on

• time: Specifies the timing of the output, i.e. the time before the target position is reached, or after the move has started. The unit is in seconds and whose absolute value must be greater than 0.1.

  • time must be a none-zero value, and should always be >= 0.1 or <= -0.1. The move command will return an error code if 0.1 < time < 0.1.

  • A positive value ( time>=0.1) indicates the time after the move starts, ie., a "time-after trigger".

  • A negative value (time<=-0.1) indicates the time before reaching the goal, ie., a “time-before trigger”.

  • If time is longer than the actual move time, a time-after trigger will turn on when reaching the goal, a time-before trigger will turn on when the move starts. The MoveFeedback response message for the trigger will arrive before the MoveResult message for the move.

  • If alternate location is used(mode=0 in SetAlternateLocation), and if complete_move = true:

    • Only a time-after trigger will apply to the move to the alternate location, a time-before trigger will take no effect to this move.

    • From the alternate location, only a time-before trigger will apply to the move that reaches the next goal, a time-after trigger will take no effect to this move.

  • If alternate location is used(mode=0 in SetAlternateLocation), and if complete_move = false:

    • Only a time-after trigger will apply to the move to the alternate location, a time-before trigger will take no effect to this move.

  • If partial execution is used(mode=1 in SetAlternateLocation), for time-after triggers:

    • if robot is blocked for a duration > computed trigger time, trigger will be activated at the computed trigger specified time value.

    • if robot is unblocked before computed trigger timeexpires, trigger will be activated at the distance corresponding to the trigger timevalue of the original non-blocked move.

  • If partial execution is used(mode=1 in SetAlternateLocation), for time-before triggers:

    • Before reaching the final goal, if time is less than the duration from the partial execution position to the final goal, trigger will be activated at the specified time as normal.

    • If the specified trigger time is more than the duration from the partial execution position to the final goal, trigger will be activated immediately after the robot is unblocked.

Formerly there were blind moves, MoveToXXX, and OffroadtoXXX commands. We would end up with a minimum of 9 different move commands based on if you wanted to move to a target, coordinate (pose) or a joint configuration. With this new generic Move command and the key value syntax, you can specify any of those moves with this one command.
A direct move moves the robot directly from it's current position to it's goal position with a given interpolation type. This command is efficient, but can easily be blocked by other robots. It is very useful for final motions, especially if collision checking needs to be disabled.
A roadmap move will follow the edges defined in the RPC project. This is expected to be the most common move type since the robots will use the roadmap to dynamically avoid obstacles. If pose is specified, and there is no target in the roadmap as that pose, the robot will leave the roadmap to reach the actual pose. The off-roadmap portion will be collision checked, and will use the interpolation type specified (or joint interpolation by default).
A planning move calculates a path for the robot at runtime to reach the goal. This is primarily used to put a robot on the roadmap in the beginning of a task. When called, the requested robot must not be executing any current requests, otherwise it will immediately return an error. If any other robots are currently executing requests when this request is called, the other robots will pause their executions, allowing the given robot to plan and move, before automatically continuing their motion afterwards. If no collision free path to the hub can be found, the server will return an error by the end of the given timeout period.

Caution: There are risks involved with mixing RTR moves with non -RTR moves(for example, native moves from a robot teach pendant program). The user must make sure that a RTR move has completed successfully if the completion of that move is necessary for the next non-RTR move to be collision-free.

Caution: There are collision risks involved with stopping a robot from a robot teach pendant program when multi-robot moves are controlled by a RapidPlan controller. The user must make sure that all RTR move commands and stop signals from a different command source are programed and processed in a coordinated fashion, for collision-free operations in a multi-robot workcell.

Caution: When a roadmap move is issued, how far the robot can be away from the roadmap is defined as the distance tolerance to the roadmap node, offroad_tcp_tol. This parameter, in meters, is saved in ApplianceGraphSearchConfig.xml under /var/lib/rtr_appliance_app/appliance_data/<Project Name>/. The default value is 5.0 meters. This parameter can be modified by a user and will take effect after the xml file is saved and after the project is reloaded.

• If a roadmap move to target command is issued when the robot is off the roadmap, and if the TCP distance between the current robot config and the closest node in the roadmap is greater than offroad_tcp_tol, then the roadmap move to target will return failure.

• If a roadmap move to pose command is issued when the pose is off the roadmap, and if the distance between the goal pose and the closest node in the roadmap is greater than offroad_tcp_tol, then the roadmap move to pose will return failure.

When a Move request is received, path planning occurs before a response is sent. If a path is found, this command will return a response code to acknowledge the command has been received, the name of the robot that this move is for, and a unique sequence ID for this specific move. If planning fails, an appropriate error code will be returned, and no delayed response will be sent.

{topic: Move,type: Response,data: {robot_name: <value>,seq: <value>}}

If a path was found, the system will send a MoveResult message along with a response code to indicate when the move completes. The name of the robot that the move was for, and the unique sequence ID for that move will be returned in the message. If the move is interrupted, the delayed response will contain an appropriate error code.

{topic: Move,type: DelayedResponse,data: {robot_name: <value>,seq: <value>}} 

or, for a trigger a feedback response will be sent to indicate that trigger output is activated to on, or off. The trigger feedback responses will include the same seq as the Move it is a part of.

{topic: Move,type: Feedback, data: {robot_name: <value>,seq: <value>, trigger: {name: <value>, output: <value>}}}