Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Revisions

Revision history from 2.6 onwards

  • 2023/11/14: (2.6) Added IsOnTarget command

  • 2023/11/29: (2.6) Removed MultiRobotMove command

  • 2023/11/29: (2.6) Added support for roadmap + planning moves to configs

  • 2023/11/29: (2.6) Added Move command optional parameter roadmap_mode to define how the robot should use the roadmap + off-roadmap motions for roadmap moves to a pose or joint config

  • 2023/11/29: (2.6) Added new Move goal type route

  • 2023/12/21: (2.6) Added BeginMotionRecording, EndMotionRecording and CancelMotionRecording commands

  • 2024/1/17 (2.7) Added revert_to_roadmap option under the Move command.

  • 2024/02/08: (2.7) Clarify that Move Costs sum is not constrained by the api

  • 2024/03/04: (2.7) Added clarifying details to SetAlternateLocation “timeout” parameter

Goal

The ASCII API is a fundamental component of how a user interacts with the Realtime Controller and ultimately controls a robot. In order to effectively complete a task, the user must be able to retrieve information from the Rapidplan Create project, set behavioral characteristics of the robots, and move the robots either following the offline motion plans or with conventional move types.

The 2.0 ASCII API re-implements commands from the 1.x.x version with simplifications, renaming, and overall improvements. Most importantly, the request syntax changed to inline YAML, so that in future 2.x.x versions more functionality can be added while maintaining backwards compatibility. The key value structure will also make messages more readable, and easier to format. Requests can be returned in the same inline YAML format, or the same CSV response type as 1.x.x. versions.

API Format

Syntax (Inline YAML 1.2 Spec)

The ASCII strings received by the Realtime Controller will be formatted to adhere to the inline YAML format, for robust parsing. Inline YAML allows the API to use key-value pairs (KVPs). KVPs will be comma delimited, much like the current API, but attaching keys to the values will allow parameters to come in any order. Additionally, there can be multiple optional parameters and any combination of them. If the optional parameters aren’t used, they can simply be omitted and a default value will be used. Another benefit is readability, since now the values in the requests can be identified based on their key.

Note: the YAML 1.2 spec requires whitespace between after the : in key value pairs.

  • {my_key: my_value} will parse as an object with a key my_key whose value is my_value

  • {my_key:my_value} will parse as an object with a key my_key:value whose value is null

Command strings will be terminated with CR and LF ASCII characters. The length of the command strings should be less then 2KB. Commands that exceed the 2KB size limit are not forwarded out of the networking layer. They’re simply discarded and the connection is closed.

Requests

Requests sent to the Realtime controller will be formatted according to the inline YAML spec. The function type is set by the topic key and then arguments are passed as key value pairs.

Inline YAML allows the API to be more easily backwards compatible. When arguments are added in the future, they will have a default value, so that existing code will remain functional on newer software versions.

{topic: <value>, type: <value>, id: <value>, data: {key1: value1,...,keyN: valueN}}

topic: The name of the function being requested. Topic values are case insensitive. Eg. GetMode, Move

data: OPTIONAL The arguments for the specific topic if required. See the detailed topic descriptions below for more information.

type: OPTIONAL The type of request being sent. The default value is Command and currently that is the only request type.

id: OPTIONAL A client can provide an id for the message in order to easily match responses to requests. Any id provided in the request, will be returned in the matching responses. The value can be either a string or int. Note: CSV response types omit this field since it is optional.

Formation Rules

All requests made to the Realtime Controller adhere to the following formation rules:

  • The topic values are case insensitive.

  • Any required key must be 100% correct and contain a valid value, otherwise the request is rejected.

  • If an optional key is not specified (either because it was not provided or because the key was malformed) the default value for the key is used.

  • Any optional key that is provided must contain a correct and valid value, otherwise the request is rejected.

  • If irrelevant keys are passed (including malformed optional keys), they are ignored.

  • If a value is valid but out of a range that we specify, the request is rejected.

  • Strings may only contain: numbers, letters, hyphens, and underscores

Boolean Values

When an argument expects a boolean type, the acceptable values are integers or case insensitive strings.

The following are evaluated as True:

  • y|Y|yes|Yes|YES|true|True|TRUE|on|On|ON

  • 1

The following are evaluated as False:

  • n|N|no|No|NO|false|False|FALSE|off|Off|OFF

  • 0

Responses

Responses can be returned in CSV format for easy parsing, or in YAML format for human readability and programming languages that support it. The CSV responses will follow a fixed order with no optional returns, and therefore are more limited than the YAML response type. For any complex types returned in YAML (like an array), the values will be broken out in the CSV response. See GetJointConfiguration for an example.

The default response type is YAML, but upon establishing a connection, a client can immediately specify CSV response type with the SetResponseType command and never needs to parse YAML.

Responses will include an optional error key if a problem has occurred preventing completion of the request. This key data is a dictionary containing code and msg keys, which provide the numeric code and a text description of the error. Note: CSV responses will always contain the error code, with code 0 indicating success. Subsequent result key value pairs depend on the request command that was received.

Commands can have multiple response types. The types are: Response,Feedback, and DelayedResponse.

  • A Response is always returned and it indicates if the request has executed successfully or not.

  • Null values, such as null, ~, '' (empty string), Null, and NULL are interpreted as normal strings. If a user sets an API command argument with a null value, the value will be checked for validity against the target RapidPlan project or RapidPlan settings. If not found, these null values will be rejected by RapidPlan with a “xxxx_NOT_FOUND” error.

  • A DelayedResponse is returned for commands that take time to execute, like a Move or LoadProject. When a Response includes a seq key, that indicates that a DelayedResponse will be returned for that command. Both the immediate and delayed responses will have a globally unique sequence number (referred to as seq) so that the delayed response can be matched to the command it is for.

  • A Feedback response is returned when an intermediate event occurs before the completion of the command. For example, each move segment in a CombinedMove command returns a Feedback response to indicate its completion before the CombinedMove completes and returns its DelayedResponse.

Immediate Responses:

{topic: <value>, type: Response, id: <value>, error: {code: <value>, msg: <value>}, data: {result1: <value>,...,resultN: <value>}}
or in the CSV response,
TopicName,code,result1,...,resultN

Feedback Responses:

{topic: <value>,type: Feedback, id: <value>, error: {code: <value>, msg: <value>}, data: {result1: <value>,...,resultN: <value>}}
or in the CSV response,
TopicNameFeedback,code,result1,...,resultN

Delayed Responses:

{topic: <value>,type: DelayedResponse, id: <value>, error: {code: <value>, msg: <value>}, data: {result1: <value>,...,resultN: <value>}}
or in the CSV response,
TopicNameResult,code,result1,...,resultN

topic: The name of the message type. Eg. GetMode, Move

type: The type of response being provided; either Feedback Responses or Delayed Responses.

data: OPTIONAL The return arguments for the specific topic. If an error occurs, data will not be returned.

error: OPTIONAL If an error occurs, the error code and text description will be returned in the YAML format. In the CSV response the code will be returned in every response.

id: OPTIONAL A client can provide an id for the message in order to easily match responses to requests. If a client provided an id, the same id will be returned in the responses. Note: if the response type is CSV and a id is provided in the request, it will be omitted in all responses due to the no optional returns rule.

Stateful Commands

Commands can now be stateful. Before, a workstate had to be passed in every MOVE command, but now the workcell and robot presets are set, and then subsequent move commands use the active preset.

Commands Stored on Disk

Certain commands are now stored on disk, so when the project is unloaded and reloaded, they hold their previous state. This will reduce the amount of repetitive commands during integration and testing, while also resulting in more predictable behavior.

  • SetDefaultProject

  • DeactivateRobot

  • SetRobotPreset

  • SetObjectState

  • CreateTarget

  • UpdateTarget

  • RenameTarget

  • RemoveTarget

  • AddConnection

  • RemoveConnection

The following API commands are not persistent after a RTR controller is rebooted. These commands must be reissued to ensure the project settings are restored after the project is reloaded.

  • SetMaxLinearAcceleration

  • SetMaxLinearSpeed

  • SetAlternateLocation

  • SetInterruptBehavior

  • SetResponseType

  • SetUnits

  • Scene Modeling commands

Command Determinism

When API commands come from the same source, e.g. a single TCP socket, the API commands are processed in the order of when they are received. In a multi-robot cell, the execution of the API commands for each robot is ordered and deterministic when the response code is confirmed by the source before the next API command is sent.

When API commands come from multiple sources, the API commands are processed by a RTR controller without considering the order of the command execution between robots. As a result, the execution of the API commands between robots may become out of order, due to the timing of when each API command arrives from different sources. Therefore, if consistent API command ordering is required from multi sources, it is necessary for the command sources to synchronize with each other.

Default Units

Unless set by the SetUnits command, all requests and responses with the Realtime Controller assume millimeters for lengths and degrees for angles.

Move Type and Target Type Support

API support for moves without using external_axes argument:

 

direct

roadmap

planning

target

>=2.2

>=2.0

>=2.0

config

>=2.3

>=2.3

Not supported

pose

>=2.0

>=2.0

>=2.2

API support for moves using external_axes argument:

 

direct

roadmap

planning

target

N/A*

N/A*

N/A*

config

N/A*

N/A*

N/A*

pose

>=2.2

>=2.2

>=2.2

*In Rapidplan Create, targets and robot configurations are defined by full joint configuration of the robot, including external axes values.

API Endpoints - Project

SetResponseType

Structure

{topic: SetResponseType,data: {response_type: <value>, set_ip_default: <value>}}

Argument Description

response_type: This indicates which format the Realtime Controller will use when sending responses; either CSV or yaml. The default response type is yaml. The argument can be either case insensitive text or its numeric equivalent.

  • 0 or csv

  • 1 or yaml

set_ip_default: OPTIONAL This optional boolean argument will store the response type based on the devices IP address rather than for the current socket. All new connections from the IP address will use this response type.

Function Description

This command is used to set the response format of the TCP/IP communication with the Realtime Controller. The Realtime controller stores this response type for each client that is connected to it. This command should be called at the beginning of a program to indicate the format in which the responses should be sent. If this command is not sent, the default response type is yaml.

If the set_ip_default argument is enabled, then all new connections from the IP address will use the specified response type. Existing sockets will be unaffected by this change, until they re-establish a connection.

As long as the IP address has at least one open connection, the settings will persist.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: SetResponseType,data: {response_type: csv}}

Example YAML Responses

{topic: SetResponseType,type: Response}

Example CSV Responses

SetResponseType,0

GetUnits

Structure

{topic: GetUnits}

Argument Description

length: This specifies the unit of measure for length. The unit can be specified with a case insensitive string or its corresponding integer value. For example, when a pose is specified this length unit will be used.

  • meters

  • centimeters

  • millimeters

  • feet

  • inches

angle: This specifies the unit of measure for angles. The unit can be specified with a case insensitive string or its corresponding integer value. For example, when a robot’s joint angles are set or when a frame’s rotation is specified, this angle unit will be used.

  • radians

  • degrees

Function Description

GetUnits command returns both units set for the current connection:

  • Length (millimeters, centimeters, meters, feet, inches)

  • Angle (degrees, radians)

Response Details

This command will return a response to show the units used by the loaded project.

Example Request

{topic: GetUnits}

Example YAML Responses

{topic: GetUnits, data: {length: inches, angle: degrees}}

Example CSV Responses

GetUnits,0,inches,degrees

SetUnits

Structure

{topic: SetUnits,data: {length: <value>,angle: <value>, set_ip_default: <value>}}

Argument Description

length: This specifies the unit of measure for length. The unit can be specified with a case insensitive string or its corresponding integer value. For example, when a pose is specified this length unit will be used.

  • 0 or m,meter,meters

  • 1 or cm,centimeter,centimeters

  • 2 or mm,millimeter,millimeters

  • 3 or ft,foot,feet,'

  • 4 or in,inch,inches,”

angle: This specifies the unit of measure for angles. The unit can be specified with a case insensitive string or its corresponding integer value. For example, when a robot’s joint angles are set or when a frame’s rotation is specified, this angle unit will be used.

  • 0 or rad,rads,radian,radians

  • 1 or deg,degs,degree,degrees,°

set_ip_default: OPTIONAL This optional boolean argument will store the unit change based on the devices IP address rather than for the current socket. All new connections from the IP address will use these unit preferences.

Function Description

This command is used to set the unit convention for API calls made to the Realtime controller. On first project load, the default units of millimeters and degrees will be used, and if this command is called, the units will be stored for that specific client. Subsequent loads for that project will use require the client to reinitialize their unit convention.

If the set_ip_default argument is enabled, then all new connections from the IP address will use these unit preferences. Existing sockets will be unaffected by this change, until they re-establish a connection.

As long as the IP address has at least one open connection, the settings will persist.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: SetUnits,data: {length: in, angle: deg}}

Example YAML Responses

{topic: SetUnits,type: Response}

Example CSV Responses

SetUnits,0

GetMode

Structure

{topic: GetMode}

Argument Description

None

Function Description

This command retrieves the current mode of the Realtime Controller.

Response Details

This command will return a response code, followed by the current state of the system. The states of the system are: Config mode, Operation mode, Calibration mode and Fault mode.

Example Request

{topic: GetMode}

Example YAML Responses

{topic: GetMode,type: Response,data: {mode: CONFIG}}
{topic: GetMode,type: Response,data: {mode: OPERATION}}
{topic: GetMode,type: Response,data: {mode: CALIBRATION}}
{topic: GetMode,type: Response,data: {mode: FAULT}}

Example CSV Responses

GetMode,0,CONFIG
GetMode,0,OPERATION
GetMode,0,CALIBRATION
GetMode,0,FAULT

ClearFaults

Structure

{topic: ClearFaults, data: {reset_connection: <value>}}

Argument Description

reset_connection: [ OPTIONAL ] This indicates whether a ClearFaults command will reconnect to the robot controller after the command is issued. The default value is true.

Function Description

If a robot error/fault state occurs for one of the robots in the currently loaded deconfliction group, the Realtime Controller will enter a fault state. Examples of reasons may be: lost connection to a robot due to an E-stop, or the robot entering a fault state due to excessive speed or force. The ClearFaults command will attempt to recover any faults that the OEM controller allows allows to be cleared programmatically, and transition the Controller back into Config mode if possible. It will fail if there are still active, unresolvable faults.

If reset_connection is true(default value), the Realtime Controller will attempt to reconnect to the robot controller after recovering from a fault state. If reset_connection is false, an explicit Connect ASCII call would be required prior to entering Operation mode.

Response Details

This command will return a single response code as a result value.

Example Request

{topic: ClearFaults}

Example Responses

{topic: ClearFaults,type: Response}
{topic: ClearFaults,type: Response,error: {code:1004,msg:FAILED_TO_CLEAR_FAULTS}}

LoadProject

Structure

{topic: LoadProject,data: {project_name: <value>, upgrade: <value>}}

Argument Description

project_name: The name of the project installed on the control panel that you want to load.

upgrade: [ OPTIONAL ] A boolean value that decides if the installed RPC project is from an earlier release version, it will be upgraded for compatibility. Default value is True.

Function Description

This function loads an RPC project. A load result will be returned once the process has finished and then RapidPlan will be in configuration mode.

Response Details

This command will return a response code to acknowledge the command has been received.

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

Delayed Response Details

Once the load is completed, the system will send a delayed response to indicate the project has finished loading.  

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

Example Request

{topic: LoadProject,data: {project_name: DemoProject}}

Example YAML Responses

{topic: LoadProject,type: Response,data: {seq: 128}}
… load executes … 
{topic: LoadProject,type: DelayedResponse,data: {seq: 128}}

Example CSV Responses

LoadProject,0,128
… load executes … 
LoadProjectResult,0,128

GetLoadedProject

Structure

{topic: GetLoadedProject}

Argument Description

None

Function Description

This command retrieves the currently loaded project on the Realtime Controller.

If a project is not currently loaded, an error code will be returned {code: 3009,msg: PROJECT_NOT_LOADED}

Response Details

This command will return a response code, followed by the currently loaded project or an appropriate error code.

Example Request

{topic: GetLoadedProject}

Example YAML Responses

// Response when a project is loaded
{topic: GetLoadedProject,type: Response,data: {project_name: WeldCell}}
// Response with no project loaded
{topic: GetLoadedProject,type: Response,error: {code: 3009,msg: PROJECT_NOT_LOADED}}

Example CSV Responses

// Response when a project is loaded
GetLoadedProject,0,WeldCell
// Response with no project loaded
GetLoadedProject,3009

UnloadProject

Structure

{topic: UnloadProject}

Argument Description

None

Function Description

This command brings the Realtime Controller out of operation mode and unloads the project. Current motions will be cancelled, and no new motion requests will be accepted. Duplicate calls have no effect. Connection to robot controllers will be terminated.

Response Details

This command will return a response to acknowledge the command has been received.

{topic: UnloadProject,type: Response}

Example Request

{topic: UnloadProject}

Example YAML Responses

{topic: UnloadProject,type: Response}

Example CSV Responses

UnloadProject,0

SetDefaultProject

Structure

{topic: SetDefaultProject,data: {project_name: <value>}}

Argument Description

project_name:[ OPTIONAL ] This indicates which project will be made the default project. If this argument is omitted, any previous setting will be cleared and no project will be the default.

Function Description

This command is used to define which project is the Default project that will automatically be loaded when RapidPlan powers on or is otherwise not in Operation Mode.

Sending a SetDefaultProject command without specifying the project_name parameter will clear any previous setting.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: SetDefaultProject,data: {project_name: DemoProject}}

or

{topic: SetDefaultProject}

Example YAML Responses

{topic: SetDefaultProject,type: Response}

Example CSV Responses

SetDefaultProject,0

EnterOperationMode

Structure

{topic: EnterOperationMode, data:{connect: true}}

Argument Description

connect [ OPTIONAL ]: this boolean argument, if true, will attempt to connect to all robots before attempting to enter Operation mode. Default is false.

Function Description

Attempts to put the controller into Operation mode. This call is blocking. Once all participating robots have indicated readiness, return messages will be sent, and subsequent Move calls will be accepted.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: EnterOperationMode}

Example YAML Responses

{topic: EnterOperationMode,type: Response}

Example CSV Responses

EnterOperationMode,0

EnterConfigurationMode

Structure

{topic: EnterConfigurationMode}

Argument Description

None

Function Description

This command brings the Realtime Controller out of operation mode back into Config Mode. Current motions will be cancelled, and no new motion requests will be accepted. Duplicate calls have no effect. Connection to robot controllers will be maintained when returning to CONFIG mode.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: EnterConfigurationMode}

Example YAML Responses

{topic: EnterConfigurationMode,type: Response}

Example CSV Responses

EnterConfigurationMode,0

Shutdown

Structure

{topic: Shutdown}

Argument Description

None

Function Description

This command issues an asynchronous system call, systemctl poweroff -i, which shuts the appliance down, if in Fault or Configuration Mode.
Should the appliance be in operation or in calibration mode, this command will be rejected.

Between this call and the system shutting down, the appliance will be in a “Shutdown” state and refuse any further ASCII commands.
If this system call results in an error, rather than shutting down the following will occur:

  • An additional delayed response will be returned, with the command and error status

  • The controller will enter Fault mode

Response Details

This command will return a response to acknowledge the command has been received and queued for execution.

Delayed Response Details

If the shutdown command fails during execution, a delayed response will be sent with the command’s error status.

Example Request

{topic: Shutdown}

Example YAML Responses

{topic: Shutdown,type: Response,data: {seq: 162}}
And if the shutdown fails...
{topic: Shutdown,type: DelayedResponse,error: {code: 2019,INVALID_SHUTDOWN_STATE}}
or
{topic: Shutdown,type: DelayedResponse,error: {code: 2020,APPLIANCE_SHUTDOWN_FAILED}}

Example CSV Responses

Shutdown,0,162
And if the shutdown fails...
ShutdownResult,1001,162

UserLog

Structure

{topic: UserLog,data: {message: <value>}}

Argument Description

message: A string to be written to the RapidPlan logs. Must be less than 500 characters and may only contain letters, numbers, - and ..

Function Description

This function allows the user to write a simple string to the RapidPlan logs.

Response Details

This command will return immediately with a response indicating whether or not the string could be written to the log.

Example Request

{topic: UserLog,data: {message: CYCLE_START}}

Example YAML Responses

{topic: UserLog,type: Response

Example CSV Responses

UserLog,0

BeginInterlockRecording

Structure

{topic: BeginInterlockRecording}

Argument Description

None

Function Description

This command indicates to RTR that for the upcoming cycle, RTR should record motion data for interlock calculations. This command is only accepted in CONFIG mode. To generate an interlock report, issue BeginInerlockRecording, execute all the robot motions, call EnterConfigMode, and then call GenerateInterlockData to retrieve the result.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: BeginInterlockRecording}

Example YAML Responses

{topic: BeginInterlockRecording,type: Response}

Example CSV Responses

BeginInterlockRecording,0

GenerateInterlockData

Structure

{topic: GenerateInterlockData}

Argument Description

None

Function Description

This command indicates to RTR to that the simulation tool wishes to retrieve the interlock data for the preceding cycle. This command is only accepted in CONFIG mode.

Response Details

The response is a report of interlock data for each edge taken by a robot while interlock recording was active in YAML format. The report contains keys for each robot, and for each robot there is a key for every motion it takes.

  • Each motion taken by the robot is represented as a sequence_number

  • For each sequence_number, a path is provided which contains a list of waypoints.

    • The first waypoint is always the starting position of the robot during the move.

    • The last waypoint is always the position the robot when the move finishes.

  • For each sequence_number an interlock list is provided.

    • Each interlock is given a unique name.

    • An empty list indicates that no interlocks are required for that motion.

    • The begin_interlock key indicates the furthest point the robot can proceed to before it is required to obtain the specific interlock.

    • The end_interlock key indicates which point the robot must reach in order to release the interlock.

    • It is possible for the end_interlock key to be achieved through a different move.

    • Sometimes, the interlocks starting position is the first waypoint of the move which means the robot cannot move at all until the interlock is obtained.

    • Interlocks are not robot specific, so the same interlock can appear for multiple robots motions.

    • A null value for end_interlock indicates that the robot was still in a position that required an interlock when the recording was terminated.

Example Request

{topic: GenerateInterlockData}

Example YAML Response

For each robot, the information of the robot motion and interlock is returned.

{
topic: GenerateInterlockData,
type: Response,
data: {
  rtr_interlock_report: {
    version: 0.0.1,
    robots: {
      Robot1: [
        {sequence_number: 1, path: [[0, 0, 0, 0, 0, 0], [0.866353, 0.676527, 0.235204, 1.375235, -0.889543, -1.26606]], interlocks: [{interlock_id: 0, begin_interlock: {sequence_number: 1, waypoint_index: 0}, end_interlock: "null"}, {interlock_id: 1, begin_interlock: {sequence_number: 1, waypoint_index: 0}, end_interlock: "null"}]},
        {sequence_number: 4, path: [[0.866353, 0.676527, 0.235204, 1.375235, -0.889543, -1.26606], [0, 0, 0, 0, 0, 0]], interlocks: [{interlock_id: 2, begin_interlock: {sequence_number: 4, waypoint_index: 0}, end_interlock: "null"}, {interlock_id: 3, begin_interlock: {sequence_number: 4, waypoint_index: 0}, end_interlock: "null"}]}],
      Robot2: [
        {sequence_number: 3, path: [[0, 0, 0, 0, 0, 0], [-0.790681, 0.486338, 0.122411, 1.691136, 0.798099, -1.742254]], interlocks: [{interlock_id: 0, begin_interlock: {sequence_number: 3, waypoint_index: 0}, end_interlock: "null"}, {interlock_id: 2, begin_interlock: {sequence_number: 3, waypoint_index: 0}, end_interlock: "null"}]},
        {sequence_number: 5, path: [[-0.790681, 0.486338, 0.122411, 1.691136, 0.798099, -1.742254], [0, 0, 0, 0, 0, 0]], interlocks: [{interlock_id: 1, begin_interlock: {sequence_number: 5, waypoint_index: 0}, end_interlock: "null"}, {interlock_id: 3, begin_interlock: {sequence_number: 5, waypoint_index: 0}, end_interlock: "null"}]}]
      }
    }
  }
}

Example CSV Response

None, only the YAML response type is supported for interlock generation.

API Endpoints - Robot

ActivateRobots

Structure

{topic: ActivateRobots,data: {robot_names: <value>, project_name: <value>}}

Argument Description

robot_names: [ OPTIONAL ] An array specifying which robots should be activated. If not passed, all inactive robots in the project will be activated.

project_name: [ OPTIONAL ] The name of the project you’d like to activate the robot in. This is required if the robot you want to deactivate is not in the loaded project.

Function Description

This command will re-activate a robot. After this command, when Connect is called, the activated robot will be connected to, and when in OPERATION mode this robot will be controlled by RTR.
This command must be called when the controller is in CONFIG mode.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: ActivateRobots}
{topic: ActivateRobots, data: {project_name: Proj1, robot_names: [Robot2]}}

Example YAML Response

{topic: ActivateRobots,type: Response}

Example CSV Response

ActivateRobots,0

DeactivateRobot

Structure

{topic: DeactivateRobot,data: {robot_name: <value>, treat_as_obstacle: <value>,joint_config: <value>,target_name: <value>,preset_name: <value>}}

Argument Description

robot_name: Specifies which robot should be deactivated.
project_name: [ OPTIONAL ] The name of the project you’d like to deactivate the robot in. This is required if the robot you want to deactivate is not in the loaded project. If the project is not loaded robot_name is the only other valid key.
preset_name: [ OPTIONAL ] A string specifying the preset of the robot to be used in the inactive state. The preset will determine the collision geometry as well as the number of joints. If not specified, the active preset will be used.

treat_as_obstacle: [ OPTIONAL ] A boolean value that specifies if the deactivated robot should be treated for collisions by the other robots in the work cell. Default value is true.
If treat_as_obstacle is enabled, then the following keys are mutually exclusive to specify the behavior of the deactivated robot:

  • joint_config: An array of floats specifying the angle for each joint of the robot. If the robot’s preset includes user defined joints, they must be provided as well, sorted by the driver index.

  • target_name: A string specifying the name of the target that the robot will be positioned at. A user is also able to update a deactivated robot position using DeactivateRobot command with a new target specified by target_name: <new target> and treat_as_obstacle: True.

  • use_last_known_config: Default option. A boolean flag that specifies the last known joint configuration of the robot should be used. A robot must have been Connected at least once for there to be known joint angles. These values are saved to disk, so on project reload, this option can still be used.

Function Description

This command ‘deactivates’ a robot which means the RTR controller will ignore it when connecting to the robots within a project. Subsequent Connect commands will only connect to activated robots, and when in Operation mode, only the activated robots will be controlled by RTR. In order to prevent collisions, the deactivated robots can be configured for collision checking by setting the appropriate preset and joint angles. Optionally, the robot can be ignored during collision checking if it is not present in the workcell.
This command must be called when the controller is in CONFIG mode.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: DeactivateRobot, data: {robot_name: Robot2}}
{topic: DeactivateRobot, data: {robot_name: Robot2, preset_name: gripper_open, treat_as_obstacle: true, use_last_known_config: true}}
{topic: DeactivateRobot, data: {robot_name: Robot2, project_name: Project1}}

Example YAML Response

{topic: DeactivateRobot,type: Response}

Example CSV Response

DeactivateRobot,0

Connect

Structure

{topic: Connect,data: {robot_name: <value>}}

Argument Description

robot_name: OPTIONAL Specify which robot should be connected to. If not passed, all active robots in the project will be connected.

Function Description

This command connects to all active robots in the loaded project, or optionally a single robot. After this command executes, the Realtime Controller will begin monitoring the position of the robot/s.

This command should normally be called near the beginning of a robot program, before attempting to make any Move commands. If the robot/s have already been connected, this command will return successfully.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: Connect}

Example YAML Responses

{topic: Connect,type: Response}

Example CSV Responses

Connect,0

Disconnect

Structure

{topic: Disconnect,data: {robot_name: <value>}}

Argument Description

robot_name: OPTIONAL The specific robot to disconnect from.

Function Description

This command disconnects from all robots in the project (unless a robot is specified) and returns them to the Initialized status. Disconnect can only be called successfully when in CONFIG mode.
This command is useful for saving time by keeping the project loaded on the controller while allowing the robots to perform tasks independent of Realtime control like rebooting.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: Disconnect}

Example YAML Responses

{topic: Disconnect,type: Response}

Example CSV Responses

Disconnect,0

AcquireControl

Structure

{topic: AcquireControl,data: {robot_name: <value>,preset_name: <value>}}

Argument Description

robot_name: The name of the robot to acquire control of.
preset_name:OPTIONAL Switches the active robot preset when acquiring control.

Function Description

This command allows the user to signal that they are done with an operation that required RTR to release external control of the robot, and the Realtime Controller should resume control, with the last active robot preset or a specified preset.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: AcquireControl,data: {robot_name: robot_1}}

Example YAML Responses

{topic: AcquireControl,type: Response}

Example CSV Responses

AcquireControl,0

ReleaseControl

Structure

{topic: ReleaseControl,data: {robot_name: <value>,preset_name: <value>}}

Argument Description

robot_name: The name of the robot to release control of.
preset_name:OPTIONAL Switches the active robot preset when releasing control.

Function Description

This command is intended to enable the user to take temporary control of the robot to get/set IOs, or execute a portion of their robot program that is not suitable for RTR control at this point. This may be gluing, welding, or some other time-dependent, sensitive process. 
While a robot is in Released mode, the rest of the Realtime Controller system will use the last known joint state of the paused robot as an obstacle, and will use the robot preset that was active (or optionally set) when that call was made. 
After completing the desired operation, the user should call AcquireControl. Until that call, the robot will not accept any Move commands from this API.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: ReleaseControl,data: {robot_name: robot_1}}

Example YAML Responses

{topic: ReleaseControl,type: Response}

Example CSV Responses

ReleaseControl,0

SetMaxLinearAcceleration

ℹ️ Note: This command will apply to both activated and deactivated robots. If sent to a deactivated robot, the settings will apply when reactivating the robot.

Structure

{topic: SetMaxLinearAcceleration,data: {robot_name: <value>,max_accel: <value>}}
{topic: SetMaxLinearAcceleration,data: {robot_name: <value>,reset: <value>}}

Argument Description

robot_name: The name of the robot this command is for.
max_accel: A value from 1mm/s^2 to 10,000,000mm/s^2 that defines the maximum acceleration allowed for the specified robot. The clients active units will be used, or the default units of mm/s^2.

reset: OPTIONAL A boolean flag that indicates the Linear Acceleration limits should be reset to the default values. The only accepted value for this flag is one that evaluates to True. Note: if max_accel is also provided, its value will be ignored, and the acceleration limits will be reset.

Function Description

This command limits the linear acceleration of a robots TCP. A user can specify the max acceleration allowed for a robot using this command, or reset to the default value using the reset flag. This command can only be sent when the specified robot is stationary, and all subsequent motions will adhere to the provided limit.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: SetMaxLinearAcceleration,data: {robot_name: robot_1,max_accel: 10000}}
{topic: SetMaxLinearAcceleration,data: {robot_name: robot_1,reset: True}}

Example YAML Responses

{topic: SetMaxLinearAcceleration,type: Response}

Example CSV Responses

SetMaxLinearAcceleration,0

SetMaxLinearSpeed

ℹ️ Note: This command will apply to both activated and deactivated robots. If sent to a deactivated robot, the settings will apply when reactivating the robot.

Structure

{topic: SetMaxLinearSpeed,data: {robot_name: <value>,max_speed: <value>}}
{topic: SetMaxLinearSpeed,data: {robot_name: <value>,reset: <value>}}

Argument Description

robot_name: The name of the robot this command is for.
max_speed: A value from 0.1mm/s to 100,000mm/s that defines the max linear speed allowed for a specified robots TCP. The clients active units will be used, or the default units of mm/s.

reset: OPTIONAL A boolean flag that indicates the Linear Acceleration limits should be reset to the default values. The only accepted value for this flag is one that evaluates to True. Note: if max_accel is also provided, its value will be ignored, and the acceleration limits will be reset.

Function Description

This command limits the max linear speed of a specified robot. In following move commands, the speed parameter will move the robot at a percent of this specified speed. For example, if this command is called and 500 (in mm/s) is passed for the max_speed parameter, a move command with a speed parameter of 0.5 will move the robot at up to 250mm/s.

A user can specify the max linear speed allowed for a robot using this command, or reset to the default value using the reset flag.

This command can only be sent when the specified robot is stationary, and all subsequent motions will adhere to the provided limit.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: SetMaxLinearSpeed,data: {robot_name: robot_1,max_speed: 500}}

Example YAML Responses

{topic: SetMaxLinearSpeed,type: Response}

Example CSV Responses

SetMaxLinearSpeed,0

SetAlternateLocation

ℹ️ Note: This command will apply to both activated and deactivated robots. If sent to a deactivated robot, the settings will apply when reactivating the robot.

Structure

{topic: SetAlternateLocation,data: {robot_name: <value>,enabled: <value>,target_name: <value>,complete_move: <value>, timeout: <value>}}

Argument Description

robot_name: This indicates which robot this call pertains to .
enabled: Accepts 0 to disable alternate behavior or 1 to enable alternate behavior at the specified goal. If enabled is being set to 0, no other arguments are required.

complete_move: [ OPTIONAL ] Default value is 1 or true. This Boolean specifies if the robot should continuously try to plan a motion to the original goal after it has successfully moved to the alternate location. If true, a robot for which a move timed out will first move to the alternate location. If this alternate move is successful it will continuously try to plan a motion from the alternate location to the original move request location. If False, a robot for which a move timed out will move to the alternate location and wait there for the next command.

mode: [ OPTIONAL ] Specifies what the robot should do if the original motion fails.

  • 0: Default behavior. Move to a different, specified, position.

  • 1: Partial Execution. If this option is selected, the robot will move along its path as far as it can before a robot-based obstruction is present. If the obstruction is removed before deceleration, the robot will not stop at this point and continue smoothly towards the goal. If the obstruction is still present, the robot will come to a stop and automatically resume motion when the robot-based obstruction is removed. This behavior does not trigger for static-obstacle obstructions. When Partial Execution is enabled, complete_move is always set to true.

  • multirobot: If this option is selected, the robot will automatically be entered into a multi robot plan to try to get out of deadlock. Only other robots that are also configured to use multirobot avoidance will be used in this planning.

goal: [ OPTIONAL ] If mode is set to 0, this argument specifies the position that will act as the alternate position for the specified robot. Goal is a placeholder, and the actual key value pair would correspond to the acceptable positions which are:

  • target_name: <target_name>

  • pose: [x,y,z,r,p,y]

timeout: [ OPTIONAL ] -1 or 0.05 to 1000. Default value is -1. A value of -1 indicates infinite time. This value indicates how long the Realtime Controller should continue planning to find a alternative path if a path can not be found. When Partial Execution is enabled, this value specifies the time a robot waits to finish the partial move.

Function Description

This command is used to enable and set the alternate location for a robot. With this feature enabled, in the event a Move command fails or is interrupted, the Realtime Controller will not return a response code immediately, and will instead automatically plan to the specified alternate position. Depending on the behavior of complete move the Realtime Controller will either return a response Error code indicating the robot reached the alternate location, or continue to plan to the location that was first specified in the move command.
Only one target can be set as the alternate location, so if that target does not exist in all of the robots presets, when a preset it changed, the alternate location should be updated.
Enabling the alternate location behavior changes the way a robot will execute a move, therefore a SetAlternateLocation command can only be sent while a robot is stationary and while the Realtime Controller is in either CONFIG or OPERATION mode.
When this behavior is enabled, the robot will execute motions using the same parameters as the original move. For example, if a move is sent using move_type: roadmap then the robot will make a roadmap move to the alternate location. If the original move is a move_type: direct then a direct move will be made to the alternate location.
When partial execution is enabled (mode: 1) or the default behavior (mode: 0) with complete move enabled, the timeout value is used.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

// To enable an alternate position for the robot to move to in the event the original move fails
{topic: SetAlternateLocation,data: {robot_name: robot_1,enabled: 1,target_name: pounce, complete_move: 1}}

// To enable the partial move behavior where a robot will move as far as it can and then wait until the path is free
{topic: SetAlternateLocation,data: {robot_name: robot_1,enabled: 1,mode: 1}}

// To enable multi robot move behavior
{topic: SetAlternateLocation, data: {robot_name: robot_1,enabled: 1,mode: multirobot}}

// To disable any alternate location behavior
{topic: SetAlternateLocation,data: {robot_name: robot_1,enabled: 0}}

Example Responses

{topic: SetAlternateLocation,type: Response}

Example CSV Responses

SetAlternateLocation,0

SetInterruptBehavior

ℹ️ Note: This command will apply to both activated and deactivated robots. If sent to a deactivated robot, the settings will apply when reactivating the robot.

Structure

{topic: SetInterruptBehavior,data: {robot_name: <value>, timeout: <value>, max_replans: <value>}

Argument Description

robot_name: This indicates which robot this call pertains to. 

timeout: -1 or 0.05 to 1000.0. This indicates how long the Realtime Controller should continue trying to find a path if one cannot currently be found. A value of -1 indicates an infinite timeout. Otherwise, any non-zero floating point value specifies the time (in seconds) before a timeout response is sent.
max_replans: OPTIONAL -1 or 0 to 1000. Default value of -1. This parameter specifies how many times a robot will attempt to find a path to the goal if it is blocked or interrupted during its motion. A value of 0 indicates the robot should not attempt to replan if blocked, a value of N indicates that the robot should attempt to replan a maximum of N times before returning failure, and -1 indicates an infinite number of replan attempts.

Function Description

This function should be invoked towards the beginning of a robot program. It sets the behavior for the robot with respect to replanning and timeout behavior. This function must be called when a project is already loaded. If this function is not called, the default behavior for a project will be: timeout = 0 and max_replans=-1.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: SetInterruptBehavior,data: {robot_name: robot_1,timeout: 5}}

Example YAML Responses

{topic: SetInterruptBehavior,type: Response}

Example CSV Responses

SetInterruptBehavior,0

SetRobotPreset

Structure

{topic: SetRobotPreset,data: {robot_name: <value>,preset_name: <value>}}

Argument Description

robot_name: The name of the robot this command is for.
preset_name: Specifies which preset to switch to as defined in RPC.

Function Description

This command changes the active robot preset for a specific robot. When a preset is changed, current robot motions are not re-validated, but new Move commands will respect the new active preset.

A robot must be stationary in order to call this command explicitly. SetRobotPreset commands will be rejected if sent between a user issuing move request to the RTR controller, and the final response being sent from the RTR controller to the user for a given bot . If a preset change is needed, it can be accomplished using the preset_name key within a queued move or combined move request. In the case of switching presets using the preset_name key, there is a requirement that changes in preset during queued moves or CombinedMoves must not change the TCP or the controllable axes. This requirement is in effect if there are any current motions that the user has issued to RTR, that RTR has not yet returned the final API response to the user.

If the new preset has a different number of controlled axes than the current preset, ReleaseControl must be called for that robot prior to the SetRobotPreset command. Once the preset change has succeeded, AcquireControl can be called again.

When called, the selected preset is stored to disk so upon project reload, the last active preset will be used.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: SetRobotPreset,data: {robot_name: robot_1,preset_name: open_gripper}}

Example YAML Responses

{topic: SetRobotPreset,type: Response}

Example CSV Responses

SetRobotPreset,0

GetRobotPresets

Structure

{topic: GetRobotPresets, data: {robot_name: <value>}}

Argument Description

robot_name: Specifies the name of the robot to return the presets for.

Function Description

This command will return a response with a comma separated array of the robot preset names (preset_names) and the active preset name (active_preset). 

Response Details

active_preset: This response will return the name of the active robot preset.

robot_presets: This response will return the names of all presets from the same robot.

For CSV responses, after the acknowledgement codes, i.e., GetRobotPresets, 0, the response code will return with the name of the active preset, followed by the number of the robot presets, and then followed by the name of each robot preset.

Example Request

{topic: GetRobotPresetsdata: {robot_name: Robot1}

Example YAML Responses

{topic: GetRobotPresets,type: Response,data: {active_preset: preset1, robot_presets:[preset1, preset2]}}

Example CSV Responses

GetRobotPresets,0, preset1, 2, preset1, preset2

Queueing Moves

Move commands can be sent to a robot before its current motion has finished. The new Move request will be added to the queue for the specified robot to be executed as soon as its current motion finishes.

  • Only Direct and Roadmap move types can be added to the queue.

  • A maximum of 100 moves can be added to the queue.

  • If received in time, the robot will smooth its current motion into the next in the queue using its smoothing argument.

  • The move queue for a given robot is cleared when:

    • A Move fails

    • A Move is cancelled

  • While a robot is executing a motion, the next move in the queue is planned

    • A robot reserves the swept volume of its current motion and the next move in the queue.

    • A Move is only added to the queue, if a path could be found.

    • Initial responses will be sent for move requests when planning has finished.

  • Delayed responses will be sent when queued move segments terminate (due to completion, cancelling, or interruption).

  • Canceling a robot’s motion with CancelMove will clear the move queue and cancel all moves simultaneously. The delayed responses of these moves are not guaranteed to be in queue order.

  • Queued motions will use the interrupt settings when planning in the background.

  • Queued motions will use the alternate location, if enabled.

  • A robot’s preset can be changed when Moves are queued. The number of controlled axes shall stay the same. The robot TCP could change when a robot’s preset switches in the queue.

  • It is highly recommended to include preset_name in every queued Move command in case a robot’s preset switches in the queue.

  • Smoothing is supported in queued moves. If the new motion is received in time, the robot will use the current motions smoothing value to blend into the new motion.

Move

Structure

{topic: Move,data: {robot_name: <value>,goal: <values>,speed: <value>,move_type: <value>,smoothing: <value>,interp: <value>,collision_check: <value>,collision_check_dsm: <value>,timeout: <value>,relative: <value>,ref_frame: <value>,preset_name: <value>, trigger: {name: <value>, output: <value>, time: <value>}, external_axes: {<axis name 1>: active, <axis name 2>: <value>}, costs: {external_axis: <value>, path_length: <value>, via_points: <value>}}

Argument Description

robot_name: The name of the robot controlled by the Move command.

goal: Where the robot will move to, either a target or pose, joint configuration or along a route. Goal is a placeholder key, and the acceptable keys are either pose or target, joint_config or route. The goal may include external axes that are specified as part of a named target or a joint configuration, or as external_axes of a pose move. Unless the external axes value is provided as an argument in external_axes, external axes will either remain fixed during a move, or switch to different setpoint values defined by roadmap moves.

  • target: target_name

  • pose: [x,y,z,r,p,y]

  • joint_config: [j1, j2, j3, j4, j5, j6] to move robot native joints, or [j1, j2, j3, j4, j5, j6, j7, j8...] to move robot pose + external joints

  • route: route_name, the following error codes may be sent in response

    • ROUTE_NOT_FOUND: If no route with the defined name exists in the project

    • ROUTE_NOT_IN_ROBOT: If the named route does not belong to the specified robot

    • ROUTE_NOT_IN_PRESET If the named route is not in the current (or requested preset, if exists)

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.

move_type: [ OPTIONAL ] The type of move the robot will make. Either direct, roadmap, or planning. Default move type is a roadmap move. The arguments are case insensitive or can use the assigned numeric value.

  • 0 or direct

  • 1 or roadmap

  • 2 or planning

smoothing: [ OPTIONAL ] A value from 0.0 mm to 500 mm indicating how far from a node the robot should attempt to begin smoothing its trajectory. Default value is 0.0 mm. Note that a higher smoothing value does not necessarily mean faster movement.

interp: [ OPTIONAL ] Specifies the interpolation type for the robot when making a direct move, or any time it must leave the roadmap. Use the case insensitive string, or its integer equivalent to specify joint or linear interpolation. This parameter does not apply to a planning move. Default is joint space interpolation.

  • 0 or J (default)

  • 1 or L

collision_check: [ OPTIONAL ] This flag overrides collision checking against the static scene for Direct move types. Robot to robot collisions will always be checked regardless of this flag, but robot self collisions will not be checked. A value of 1 specifies collisions should be checked, and a value of 0 specifies collisions will not be checked. Default value is 1.

collision_check_dsm: [ OPTIONAL ] This flag overrides collision checking against the dynamic scene model for Direct move types. A value of 1 specifies collisions should be checked, and a value of 0 specifies collisions will not be checked. Default value is 1.

timeout: [ OPTIONAL ] This timeout only applies to planning move types when the interrupt behavior is not applicable. This value is the amount of time given to plan a path to the specified goal, in seconds. If not provided, the default value is 10 seconds. The minimum value is 0.01 seconds and the maximum value is 120.0 seconds.

relative: [ OPTIONAL ] A boolean flag indicating that a pose or joint_config move should be performed relative to the last commanded robot pose or joint configuration. Default value is false. All move types are supported when using the relative flag. A reference frame name, ref_frame, can be specified as well for the pose to be in.

A relative move can be performed on all robot joints and external axes if it’s a direct, joint_config or a pose move. A full joint configuration including external axes, e.g., [j1, j2, j3, j4, j5, j6, j7, j8...], or, a full pose including external axes, e.g., pose: [0,0,0,0,0,0], external_axes: {rail: 50}}, should be given to specify a relative direct move. Multi-axis relatives are supported.

ref_frame: [ OPTIONAL ] The name of a frame in the project that should be used as a reference. The goal type should be a pose and relative should be set to false or not specified. The robot will move to the pose relative to the frame specified. The default reference frame is world.

preset_name: [ OPTIONAL ] This argument specifies which preset the robot should switch to before executing the motion. Including this argument has the same effect as calling SetRobotPreset before the Move command. If included, the robot cannot have any moves in its queue with a different TCP or number of controlled axes.

external_axes: [ OPTIONAL ] This argument, including all the related parameters that are defined within this argument, specifies the names of the external axes, the external axes position values for a direct move or a roadmap move to a goal pose.

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 argument is not used when the goal type is joint_config, because joint_config could include all robot native joints and external axes values.

Robot pose value plus external_axes can be used for relative direct pose moves.

  • 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.

roadmap_mode: [ OPTIONAL ] for roadmap moves only, this optional argument defines how the robot should use the roadmap + off-roadmap motions when moving to a goal which is a pose or joint config.

  • 0 or default The robot will use the roadmap as much as possible. (default)

  • 1 or shortest_path The robot uses a shorter path, which typically has a longer off-roadmap segment.

  • 2 or roadmap_only The robot will only move on the roadmap (requires start and goal to be on the roadmap).

shortest_path_only: [ OPTIONAL ] for roadmap moves only, this optional argument only allows the robot use what would be the shortest path through the roadmap. If that path isn’t available, robot would wait, or use partial moves settings if that option is specified.

revert_to_roadmap: [ OPTIONAL ] for move_type: planning moves only (has no effect otherwise), this optional argument, if present and set to true indicates that if the robot happens to already be on a node or edge of the roadmap, it should use the roadmap to get to the goal if possible. This was the default behavior up until 2.6. From 2.7 onwards, the default behavior if this option is not present, or if it is present and set to false, will be to plan from scratch, ignoring the roadmap.

costs : [ OPTIONAL ] for planning moves only, this argument defines the cost penalty values of the individual cost terms. At least one cost term is required for the costs argument.

  • external_axis : [ OPTIONAL ] how much external axes motions are penalized. The default value is 0.0, which puts no penalty on using the external axes. The range of this float-point value is between 0.0 and 1.0.

  • path_length: [ OPTIONAL ] this argument defines the cost penalty value for a planning move using the shortest path. The range of the value is between 0.0 and 1.0.

  • via_points: [ OPTIONAL ] this argument defines the cost penalty value for a planning move using the fewest via points (waypoints). The range of the value is between 0.0 and 1.0.

  • The submitted costs are normalized; it is not an error if their sum is greater than 1.0

constraints : [ OPTIONAL ] for planning moves only, this argument defines an array of user specified orientation constraints that only allow the TCP to rotate along certain axes but not the others between targets.

  • type : Specifies a type of constraint. Currently, only orientation constraint is supported.

    • 0 or orientation

  • axis : an array of 3 integer values that specifies which axis to be constrained. 1 means the robot TCP would not rotate along this axis during the motion, but a deviation of 1 degree will be allowed which gives the planner a bit of "slack" to find solutions quicker without much detrimental effect on output paths. 0 means the robot TCP allows to rotate along this axis. Two axes are required to be constrained. If there is no offset specified, the vector axis [1, 0, 1] represents the x-y-z axis of the TCP frame. Otherwise, they are x-y-z axis of the ref frame from the TCP frame with offset.

  • offset: [ OPTIONAL ] an array of 6 floats that specifies an offset that will be applied to the frame relative to TCP frame. The client's active units and rotation convention are used, or the default of millimeters, degrees, and roll pitch yaw.
    For example, if a gripper holding a cup of water like the following cases:

    the constraint would be:

    a. no offset, and constraints: [{type: orientation, axis: [ 1, 1, 0 ] }]

    b. no offset, and constraints: [{type: orientation, axis: [ 0, 1, 1 ] }]

    c. constraints: [{type: orientation, offset:[delta_x,0,0,0,delta_pitch,0], axis: [ 1, 1, 0 ] }]

trigger: [ OPTIONAL ] This argument, including all the related parameters that are defined within this object, specifies an output based on the timing of a move or a move segment of a combined move. trigger is an object with 3 fields:

  • 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 API command. 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 time-after triggers will apply to the move to the alternate location, time-before triggers will take no effect.

      • Only time-before triggers will apply to the move to the goal, time-after triggers will take no effect.

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

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

    • A trigger will not be re-activated if a Move command is issued when the robot is already at the goal position.

Function Description

With this new generic Move command and the key value syntax, you can specify any of the former Blind Moves, MoveToXXX, and OffroadtoXXX commands with this one command.

A direct move moves the robot directly from its current position to its 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 offroadmap 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 move requests when a planning move request is called, the robot attempting the planning move will be blocked with an Error code. If no collision free path to the goal can be found, the server will return an error by the end of the given timeout period.

Response Details

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>}}

Delayed Response Details

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>}}}

Example Request

{topic: Move,data: {robot_name: robot_1,move_type: roadmap,target: pre_pick,speed: 1.0,smoothing: 1, trigger: {name: output_1, output: 1, time: -0.5}}}

Example YAML Responses

{topic: Move,type: Response,data: {robot_name: robot_1,seq: 312}}
... move executes ...
{topic: Move, type: Feedback, data: {robot_name: robot_1, seq: 312, trigger: {name: output_1, output: 1}}
... 0.5s
{topic: Move,type: DelayedResponse,data: {robot_name: robot_1, seq: 312}}

Example CSV Responses

Move,0,robot_1,312
... move executes ...
MoveFeedback,0,robot_1,312,Output_1,1
... 0.5s
MoveResult,0,robot_1,312

CombinedMove

Structure

{topic: CombinedMove, data: {robot_name: <value>, preset_name: <value>, moves: [{move_type: <value>, goal: <value>, speed: <value> ...},{move_type: <value>, goal: <value>, speed: <value> ...}, ... ,{move_type: <value>, goal: <value>, speed: <value> ...},...]}}

Argument Description

robot_name: The robot that this combined move is for. A combined move, can only included motions for one robot, and therefoer the robot_name key from the individual move commands can be omitted. If the robot_name is included in the individual Move commands, it will be ignored.

moves: An array of up to 10 Move commands to be concatenated together. The move commands can only be direct or roadmap move types, and must adhere to the Move command specification. However, redundant keys from the Move command can optionally be omitted, since they are arguments of the CombinedMove.

preset_name:OPTIONAL This optional argument specifies which preset the robot should switch to before executing the combined move. All moves will then execute using this preset. Including this argument acts exactly like calling SetRobotPreset before the combined move. The robot TCP or the number of controlled axes can not change when the preset switches.

HoldMove is also able to be sent as a segment of a CombinedMove command.

Function Description

CombinedMove allows multiple move commands to be executed as if it was one motion, and the individual segments can optionally be blended together to maintain a higher velocity.

The smoothing argument of each individual move command will specify if it will blend into the next move in the list, and at what distance from the end of the current move.

In the event a CombinedMove is interrupted, an error will be returned in the delayed response. In order to resume the CombinedMove from its current position, it is expected that the user maintains a list of the completed individual moves and then send a new CombinedMove with the moves that didn’t complete.

If move queuing is being used, a CombinedMove can be added to the queue just like any other move.

HoldMove is also able to be sent as a segment of a CombinedMove command to hold before executing a section of movement until a ResumeMove command has been sent.

Response Details

This command will return an initial response to indicate that the command has been processed and a collision free path has been found for all moves, smoothing included. A unique sequence number will be included to identify the CombinedMove responses. When a move in the sequence is completed, a Feedback response will be returned, and upon completion of the full move sequence, additionally a DelayedResponse will be send.

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

Delayed Response Details

For every Move in the CombinedMove a feedback response will be sent to indicate that segment has completed. The feedback responses will include the same seq as the CombinedMove they are a part of, as well as a zero index index key to identify which segment the move result is for.

If a trigger output is specified for a move segment, a feedback message will be sent as soon as the trigger output is activated to on or off. Different segments of the same CombinedMove command are allowed to re-use the same trigger name, if the same trigger needs to be updated for each move segment. The feedback message contains the seq value but no index value.

{topic: CombinedMove,type: Feedback,data: {robot_name: <value>, seq: <value>, index: <value>}}
... additional Move DelayedResults ...
{topic: CombinedMove,type: DelayedResponse,data: {robot_name: <value>, seq: <value>}}

Example Request

{
  topic: CombinedMove,
  data: {
   robot_name: robot_1,
    moves: [
      {move_type: roadmap,target: staging,speed: 1.0,smoothing: 0.25, trigger: {name: output_1, output: 1, time: -0.5}},
      {move_type: roadmap,target: pre_pick,speed: 1.0,smoothing: 0.1, trigger: {name: output_1, output: 0, time: -0.5}},
      {move_type: direct,pose: [0,0.5,0,0,180,0],speed: 1.0,smoothing: 0.0}
    ]
  }
}

Note: the new line (\n) and tab (\t) characters have been added for readability, the actual request format does not include them.

CombinedMove (including a HoldMove segment): {topic: CombinedMove, data: { robots: robot1, moves: [{<move>}, Hold, {<move>}]}}

Example YAML Responses

{topic: CombinedMove, type: Response, data: {robot_name: robot_1, seq: 61}}
{topic: CombinedMove, type: Feedback, data: {robot_name: robot_1, seq: 61, index: 0}}
{topic: Move, type: Feedback, data: {robot_name: robot_1, seq: 61, trigger: {name: output_1, output: 1}}
{topic: CombinedMove, type: Feedback, data: {robot_name: robot_1, seq: 61, index: 1}}
{topic: Move, type: Feedback, data: {robot_name: robot_1, seq: 61, trigger: {name: output_1, output: 0}}
{topic: CombinedMove, type: Feedback, data: {robot_name: robot_1, seq: 61, index: 2}}
{topic: CombinedMove, type: DelayedResponse, data: {robot_name: robot_1, seq: 61}}

Example CSV Responses

CombinedMove,0,Robot1,61
CombinedMoveFeedback,0,Robot1,61,0
CombinedMoveFeedback,0,robot_1,61,output_1,1
CombinedMoveFeedback,0,Robot1,61,1
CombinedMoveFeedback,0,robot_1,61,output_1,0
CombinedMoveFeedback,0,Robot1,61,2
CombinedMoveResult,0,Robot1,61

CancelMove

Structure

{topic: CancelMove,data: {robot_name: <value>, acceleration_factor: <value>}}

Argument Description

robot_name: The name of the robot for which a move is being canceled.
acceleration_factor [ OPTIONAL ] : The acceleration factor at which the robot will move on a scale from 0.5(50%) to 1.0(100%), when the move is being canceled. The default value is 0.8.

Function Description

This function tells the Realtime Controller to abort planning and motion for the specified robot. After calling this, a robot may be left in an off roadmap location and will require a planning move command.
This command is only accepted when the RTR Controller is in OPERATION mode.
If a series of Move commands are queued for the robot in question, they will all be canceled simultaneously. The delayed responses of these commands are not guaranteed to be in queue order.

If CancelMove is called before planning is finished for a Move command, robot preset of the canceled move will still be applied because the preset had changed before planning started.

If a move is canceled mid-motion after a Move command which also sets the robot preset, the robot preset will be maintained.|

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: CancelMove,data: {robot_name: robot_1, acceleration_factor: 0.9}}

Example YAML Responses

{topic: CancelMove,type: Response}

Example CSV Responses

CancelMove,0

HoldMove

Structure

{topic: HoldMove, data: { robot_name: <robot_name>}}

Argument Description

robot_name: Specifies which robot to hold move

Function Description

This command blocks a robot from executing pre-sent or combined moves for a defined robot until a ResumeMove command is sent.

HoldMove is also able to be sent as a segment of a CombinedMove command. 

Response Details

A robot that is holding will return an error while holding.

Example Request

HoldMove: {topic: HoldMove, data: { robot_name: robot1}}

CombinedMove (including a blocked segment): {topic: CombinedMove, data: { robots: robot1, moves: [{<move>}, Hold, {<move>}]}}

Example YAML Responses

HoldMove: {topic: HoldMove, type: Response, data: {}}

Example CSV Responses

HoldMove: HoldMove, 0

ResumeMove

Structure

{topic: ResumeMove, data: { robot_name: <robot_name>}}

Argument Description

robot_name: Specifies which robot to continue move

Function Description

ResumeMove: This command continues robot the through combined or pre-set moves for a defined robot.

Response Details

Example Request

ResumeMove: {topic: ResumeMove, data: { robot_name: robot1}}

Example YAML Responses

ResumeMove: {topic: ResumeMove, type: Response, data: {}}

Example CSV Responses

ResumeMove: ResumeMove, 0

GetTargets

Structure

{topic: GetTargets,data: {robot_name: <value>}}

Argument Description

robot_name: Specifies which robot’s targets will be returned.

preset_name: OPTIONAL Specifies which preset’s targets to return. Default is the active robot preset.

Function Description

This command retrieves the targets for a given robot in a specific preset in the loaded project. The default behavior is to return the targets in the active robot preset, but a different preset can be specified.

Response Details

This command will return a response code, followed by a comma separated array of the target names.

Example Request

{topic: GetTargets,data: {robot_name: robot_1}}

Example YAML Responses

{topic: GetTargets,type: Response,data: {targets:[weld_1,weld_2,weld_3]}}

Example CSV Responses

GetTargets,0,3,weld_1,weld_2,weld_3

CreateTarget

Structure

{topic: CreateTarget,data: {target_name: <value>,robot_name: <value>}}

Argument Description

target_name: Specifies the name of the new target to be created.
robot_name: This indicates which robot will be assigned to the new target.

Function Description

This command creates a target in the active robot preset for the specified robot.

The target is created using the robot’s current joint angles. To ensure consistent joint angle readings, the robot must stay stationary while the target is created. Therefore, the controller must be in CONFIG mode and the robot state must be connected.

No connections will be created automatically for the new target.

Response Details

This command will return an acknowledgement with a status code indicating the command was received and executed. 

Example Request

{topic: CreateTarget,data: {target_name: weld5,robot_name: robot_1}}

Example YAML Responses

{topic: CreateTarget,type: Response}

Example CSV Responses

CreateTarget,0

UpdateTarget

Structure

{topic: UpdateTarget,data: {target_name: <value>, robot_name: <value>, retrigger_autoconnect: <value>, object_states: <value>, pose: [x,y,z,rx,ry,rz]}}

Argument Description

target_name: Specifies which target will have its position updated.
robot_name: This specifies which robots TCP will be used at the new target location.
retrigger_autoconnect: [ OPTIONAL ] This boolean argument specifies if the auto-connect should be regenerated when updating the targets position. If the target is not part of an auto-connect, then this argument will have no effect. The default value is False.

object_states:: [ OPTIONAL ] This argument specifies whether the validation of the updated target position should take consideration of all object states or only the active objects. This argument can be set to either all or active.

If object_states is set to all, path validation will check all object states when updating a target. This is the default setting. If object_states is set to active, path validation of will check active object states when updating a target.

pose: [ OPTIONAL ] , if pose values [x, y, z, r, p, y] are specified, the pose values will be used to update the target position, instead of the specified robot TCP location.

joint_config: [ OPTIONAL ] , the joint configuration values will be used to update the target position instead of the specified robot TCP location, even if the robot is disconnected. The joint configuration values should include all robot links and external axes.

ref_frame: [ OPTIONAL ] , if specified, this frame is used as a reference for the pose value. ref_frame can be either a frame defined in RPC or a DSM frame.

validation: [ OPTIONAL ] , if specified this allows ignoring edge validities when updating a target, accepts values:

  • require_valid or 0 [default]: the command fails if a node or edge that was valid become invalid;

  • allow_invalid or 1: the command succeeds even if a node or edge becomes invalid. A warning message is shown.

Function Description

This command updates the specified targets position to be at the specified robot TCP location in its current preset, or using an optional pose value. The target’s new position will be used for all assigned robots.
The target is created using the robot’s current joint angles which means the controller must be in CONFIG mode and the robot state must be connected.

A target’s position will only be updated, if all of its connections remain valid, otherwise the command fails and returns an error code EDGE_INVALIDATED. This could result from the new position being unreachable, the new position being in collision, or one of the motions to the new position resulting in a collision.

Only one target can be updated at a time. While a target is updating, any subsequent UpdateTarget commands will be rejected.

With the retrigger_autoconnect argument set to true, the targets position will be updated, and then the auto-connect will be re-run using the same parameters as set in RapidPlan Create. With retrigger_autoconnect set to false, just the target’s position will change, and all via point locations will remain the same. The edges leading to the new target location will be validated against the constraints of the auto-connect, and the UpdateTarget command will fail if all constraints are not met.

Response Details

This command will return an acknowledgement with a status code indicating the command was received and is being executed.

Delayed Response Details

This command will also return a delayed response when the update has completed or failed.

Example Request

{topic: UpdateTarget,data: {target_name: weld5, robot_name: robot1}}

Example YAML Responses

{topic: UpdateTarget,type: Response,data: {seq: 154}}
After the target position has been updated and the roadmap has been regenerated...
{topic: UpdateTarget,type: DelayedResponse,data: {seq: 154}}

Example CSV Responses

UpdateTarget,0,154
After the target position has been updated and the roadmap has been regenerated...
UpdateTargetResult,0,154

RenameTarget

Structure

{topic: RenameTarget,data: {target_name: <value>, new_target_name: <value>}}

Argument Description

target_name: Specifies the name of the target to be renamed.

new_target_name: Specifies the new name of the target.

Function Description

This command renames a target. To rename a target, the Realtime Controller must be in CONFIG mode.

RapidPlan Create naming conventions must be followed. Duplicate names are not allowed. Any invalid names will be rejected by the command.

Response Details

This command will return an acknowledgement with a status code indicating the command was received and executed.

Example Request

{topic: RenameTarget,data: {target_name: weld5, new_target_name: newweld6}}

Example YAML Responses

{topic: RenameTarget,type: Response}

Example CSV Responses

RenameTarget,0

RemoveTarget

Structure

{topic: RemoveTarget,data: {target_name: <value>}}

Argument Description

target_name: Specifies the name of the target to be removed.

Function Description

This command removes a target in the active robot preset for the specified robot.

To remove the target, Realtime Controller must be in CONFIG mode.

Removing the target will remove any manually created connections , and any connections created by auto-connect, between this target and other targets.

Response Details

This command will return an acknowledgement with a status code indicating the command was received and executed.

Example Request

{topic: RemoveTarget,data: {target_name: weld5}}

Example YAML Responses

{topic: RemoveTarget,type: Response}

Example CSV Responses

RemoveTarget,0

AddConnection

Structure

{topic: AddConnection,data: {robot_name: <value>, preset: <value>, targets: <value>, type: <value>, autoconnect_name: <value>, validation: <value>}}

Argument Description

robot_name: Specifies which robot to add the connection to.

preset: OPTIONAL The name of the robot preset to add connections to. If empty, the active preset is used.

targets: A list of targets to connect. At least 2 targets must be included. If the type is joint or cartesian then only 2 targets are allowed.

type: Specifies the type of connection to create. Acceptable values are joint (0), cartesian (1), or auto (2).

autoconnect_name: OPTIONAL If type is set to auto (2), autoconnect_name can be specified by the user. If unspecified, a default autoconnect name will be assigned.

validation: OPTIONAL This argument can be set to:

  • require_valid or 0: Run validation and require it to succeed, otherwise the change would be rolled back and an error code returned. This is the default option if validation option is unspecified for a manual connection or an autoconnect.

  • allow_invalid or 1: Run validation but allow it to fail, with no error code.

Function Description

This command creates new connections within a given roadmap. It can be used to create manual connections or auto-connects.

Response Details

This command will return a response code.

Delayed Response Details

This command will also return a delayed response only if type is set to auto and when validation is set to require_valid, or allow_invalid.

Example Request

{topic: AddConnection,data: {robot_name: robot_1, presets: [preset_1], targets: [target_1, target_2], type: cartesian, validation: allow_invalid}}
{topic: AddConnection,data: {robot_name: robot_1, presets: [preset_1], targets: [target_1, target_2], type: auto, autoconnect_name: autoconnect_1, validation: require_valid}}

Example YAML Responses

{topic: AddConnection,type: Response,data: {seq: 154}}
After the connection is created and the roadmap has been regenerated and validated...
{topic: AddConnection,type: DelayedResponse,data: {seq: 154}}

Example CSV Responses

AddConnection,0,154
After the connection is created and the roadmap has been regenerated and validated...
AddConnectionResult,0,154

RemoveConnection

Structure

{topic: RemoveConnection,data: {autoconnect_name: <value>}}
or
{topic: RemoveConnection,data: {robot_name: <value>, preset: <value>, targets: <value>}}

Argument Description

autoconnect_name: this argument is used to specify the name of the auto-connect to remove.

autoconnect_name is mutually exclusive with the following options:

robot_name : Specifies which robot to remove the connection from.

targets : A list of two targets to remove the manual connection between. REQUIRED if robot_name is used.

preset: OPTIONAL Name of the robot preset to remove a manual connection from. If empty, the active preset is used. If an auto-connect is removed, preset is ignored and not checked for validity.

Function Description

This command removes connections in the roadmap. It can remove manual connections between two targets or an auto-connect by name. It can only be run in CONFIG mode.

Response Details

This command will return a response code.

Example Request

{topic: RemoveConnection,data: {autoconnect_name: autoconnect_1}}
or
{topic: RemoveConnection,data: {robot_name: robot_1, preset: preset_1, targets: [target_1, target_2]}}

Example YAML Responses

{topic: RemoveConnection,type: Response}

Example CSV Responses

RemoveConnection,0

GetJointConfiguration

Structure

{topic: GetJointConfiguration,data: {robot_name: <value>, native: false}}

Argument Description

robot_name: Specifies the name of the robot to return the joint angles for.

native: [ OPTIONAL ] This argument, if true, returns only robot native joint configuration. If false, full robot joint configuration including external axes is returned. Default value is false.

with_joint_names: [ OPTIONAL ] This argument, if true, specifies the returned names of the robot joints and external joints in the current active robot preset. The returned names are also based on the status of native.

Function Description

This command retrieves the current joint angles of a specified robot. If the robot has additional axes, they will be included sorted by their driver index. The values will be returned in the client’s units for both revolute and prismatic joints.

Response Details

This command will return a response code, followed by the current joint angles in a comma separated array. This command will always include the robot axes, and by default will include the position of external axes if present.

Example Request

{topic: GetJointConfiguration,data: {robot_name: robot_1, with_joint_names: true}}

Example YAML Responses

{topic: GetJointConfiguration,type: Response,data: {joint_configuration: [j1,j2,j3,j4,j5,j6...jN], joint_names: [<j1 name>,<j2 name>,<j3 name>,...<jN name>]}}

Example CSV Responses

GetJointConfiguration,0,j1,j2,j3,j4,j5,j6...jN,joint1name,joint2name,...,jointNname

GetTCPPose

Structure

{topic: GetTCPPose,data: {robot_name: <value>,ref_frame: <value>}}

Argument Description

robot_name: Specifies which robot’s TCP pose will be returned. The TCP of the active robot preset will be used.

ref_frame: OPTIONAL The reference frame in which to return the TCP coordinates. Default is world. The acceptable frames are:

  • <robot_name>_base: the base frame of the robot as defined in the robot model. This is a reserved frame name in RPC.

  • <robot_name>_default_tcp: the default tcp as defined in the robot model. This is a reserved frame name in RPC.

  • any user created frame in the RPC project

Function Description

This command returns the specified robot’s TCP coordinates in the world or user specified frame for the active robot preset.

The coordinates are returned in the client’s unit and rotation convention.

Response Details

​This command will return a response to acknowledge the command has been received and executed successfully along with the position and rotation of the specified robot’s TCP.

Example Request

{topic: GetTCPPose,data: {robot_name: robot_1}}

Example YAML Responses

{topic: GetTCPPose,type: Response,data: {pose:[1.0,0.5,0.375,90.0,0.0,0.0]}}

Example CSV Responses

GetTCPPose,0,1.0,0.5,0.375,90.0,0.0,0.0

IsOnTarget

Structure

{topic: IsOnTarget, data: { robot_name: <robot_name>, target_name: <target_name> [epsilon]: <epsilon>}}

Argument Description

robot_name: Specifies which robot to check

target_name: Specifies which target to check

epsilon [ OPTIONAL ] : the distance metric to use when determining if the robot is on target.

Function Description

IsOnTarget can be used to detect if the robot is at a specific target. If multiple targets are clustered at the same location it cannot tell you if the robot is at one over the other or which target motion planning will choose when trying to move from that position.

Response Details

{topic: IsOnTarget, type: Response, data: {on_target: <boolean>}}

Example Request

{topic: IsOnTarget, data: { robot_name: robot1, target_name: target2}}

{topic: IsOnTarget, data: { robot_name: robot2, target_name: target5, epsilon: 0.3}}

Example YAML Responses

{topic: IsOnTarget, type: Response, data: {on_target: true}}

Example CSV Responses

IsOnTarget,0,false

BeginRoadmapRecording

Structure

{ topic: BeginMotionRecording }

Argument Description

Function Description

BeginRoadmapRecordingcan be used to start recording motions. This will trigger planning queue to start recording all the robot motions. If Appliance is not in operation state, the command will also try to start the operation. Motion data, including targets and edges, are captured to be saved to a project roadmap once the EndMotionRecording command is sent.

Response Details

Example Request

Example YAML Responses

Example CSV Responses

EndRoadmapRecording

Structure

{ topic: EndMotionRecording }

Argument Description

Function Description

EndRoadmapRecording can be used to stop recording motions and save motion data to the project roadmap. This will stop the robot motion, set appliance back to config mode, and automatically start adding the recording targets and edges into the roadmap.

Response Details

Example Request

Example YAML Responses

Example CSV Responses

CancelMotionRecording

Structure

{ topic: CancelMotionRecording }

Argument Description

Function Description

CancelMotionRecording stops robot motion, sets Appliance back to config mode, and removes any recorded motions from the roadmap.

Response Details

Example Request

Example YAML Responses

Example CSV Responses

API Endpoints - Scene Modeling

In addition to Static Scene Model command SetObjectState, there are Dynamic Scene Model (DSM) commands that allow a user to add obstacles at runtime. A user may need DSM feature if the size or location of the obstacles is unknown offline, and therefore cannot be modeled. A user may also use the DSM object if the number of obstacle variations is unrealistic to model (e.g. in palletizing there may be thousands of obstacle sizes and possible object states).

Any possible DSM obstacle can be modeled with either a Box or CAD Object.

  • CAD objects must be configured in RapidPlan Create ahead of time to reference at runtime.

  • The DSM objects cannot be attached to stateful objects.

GetObjectStates

Structure

{topic: GetObjectStates, data: {object_name: <arg>}}

Argument Description

object_name: the name of the object

Function Description

This command returns information about an object’s state for a loaded project.

Response Details

This command will return a response with the object’s active state and a list of possible object states.

Example Request

{topic: GetObjectStates, data: {object_name: object1}}

Example YAML Responses

{topic: GetObjectStates,type: Response,data: {states: [state1, state2], active_state: state2}}

Example CSV Responses

GetObjectStates,0,state2,2,state1,state2

GetStatefulObjects

Structure

{topic: GetStatefulObjects}

Argument Description

None.

Function Description

This command retrieves the stateful object names for the loaded project.

Response Details

This command will return a response code, followed by a comma separated array of the object names.

Example Request

{topic: GetStatefulObjects}

Example YAML Responses

{topic: GetStatefulObjects,type: Response,data: {objects:[Object_1,Object_2,Object_3]}}

Example CSV Responses

GetStatefulObjects,0,3,Object_1,Object_2,Object_3

SetObjectState

Structure

{topic: SetObjectState,data: {object_name: <value>,state_name: <value>}}

Argument Description

object_name: Specifies which object this call pertains to.
state_name: Specifies which state of the object should be used as defined in RPC.

Function Description

This command changes the active state of a stateful mate. An object is specified as a function argument, and the direct parent’s mate state will be set based on the specified state_name.
When an object state is changed, current robot motions are not re-validated, but new move commands will respect the new active state.

When called, the selected object state is stored to disk so upon project reload, the last active state will be used.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: SetObjectState,data: {object_name: jig,state_name: open}}

Example YAML Responses

{topic: SetObjectState,type: Response}

Example CSV Responses

SetObjectState,0

GetFrames

Structure

{topic: GetFrames}

Function Description

This command retrieves the frames added in RPC and the frames added by DSM commands for a loaded project that can be used as reference frames in Move commands as well as calculating any transforms.

Response Details

This command will return a response code, followed by a comma separated array of the frame names.

Example Request

{topic: GetFrames}

Example YAML Responses

{topic: GetFrames,type: Response,data: {frames:[car,jig,tip_dress]}}

Example CSV Responses

GetFrames,0,car,jig,tip_dress

AddFrame

Structure

{topic: AddFrame,data: {frame_name: <value>,offset: <value>, parent_frame: <value>}}

Argument Description

frame_name: A name that will be associated with the frame being created. The name must be unique.

offset: OPTIONAL An array of 6 floats that specifies the offset between the parent frame and this frame. The offset uses the clients active units and rotation convention, or the default of millimeters, degrees, roll pitch yaw. The default offset is [0,0,0,0,0,0]

parent_frame: OPTIONAL Specifies the parent reference frame. Default value is the world frame. A parent frame must be static and not on a stateful object. Eg. a parent frame cannot be attached to a robot, or an object who’s parent mate has multiple states.

Function Description

This command adds a frame to the project. The frame is stored to disk, so when the project is unloaded, the frame will be saved. If the project is downloaded from the control panel and opened in RapidPlan Create, the frame will show up and be editable.

The frame can be used as a reference/parent frame for:

  • Dynamic Scene Model boxes and objects

  • Other frames

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: AddFrame,data: {frame_name: pallet_origin,offset: [0.5,0.25,0.35,0.0,180.0,0.0]}}

Example YAML Response

{topic: AddFrame,type: Response}

Example CSV Response

AddFrame,0

UpdateFrame

Structure

{topic: UpdateFrame,data: {frame_name: <value>,offset: <value>,reference_frame: <value>}}
{topic: UpdateFrame,data: {frame_name: <value>,pose: <value>,reference_frame: <value>}}

Argument Description

frame_name: The name of the frame who’s position will be updated.

Mutually exclusive keys:

  • offset: An array of 6 floats that specifies an offset that will be applied to the frame relative to its current position. The clients active units and rotation convention are used, or the default of millimeters, degrees, and roll pitch yaw.

  • pose: An array of 6 floats that specifies the new position for the frame. The clients active units and rotation convention are used, or the default of millimeters, degrees, and roll pitch yaw.

reference_frame: OPTIONAL The name of the frame to be used as the reference frame for the pose or offset argument. The default value is world frame for a pose update. When offsetting a frame, the default is to reference itself.

Function Description

This command updates the position of a frame and all of its children. A frame can be updated by applying an offset from its current position with the offset argument. A frame can also be relocated to a new position in a given frame. It is important to note that this cannot re-parent the frame.

Frames can only be updated if they:

  • Are static (eg. they are not attached to a robot)

  • Are not attached to stateful objects (eg. none of the parent mates can have more than one state)

  • Have no children aside from:

    • DSM Boxes

    • DSM Objects

    • Other frames

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: UpdateFrame,data: {frame_name: pallet_origin,offset: [0.5,0.25,0.35,0.0,0.0,0.0]}}
{topic: UpdateFrame,data: {frame_name: pallet_origin,pose: [0.5,0.25,0.35,0.0,0.0,0.0]}}

Example YAML Response

{topic: UpdateFrame,type: Response}

Example CSV Response

UpdateFrame,0

RemoveFrames

Structure

{topic: RemoveFrames}
{topic: RemoveFrames,data: {frame_names: <value>}}

Argument Description

frame_names: OPTIONAL An array of the names of the frames that will be removed.

Function Description

This command removes a specified frame/s added to the scene. When a frame is removed, any DSM boxes or objects with that frame as a parent will also be removed. If no arguments are passed, all frames will be removed, or an array of the frame names can be passed to selectively remove.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: RemoveFrames,data: {frame_name: [pallet_origin,layer_one_offset]}}

Example YAML Response

{topic: RemoveFrames,type: Response}

Example CSV Response

RemoveFrames,0

AddBox

Structure

{topic: AddBox,data: {box_name: <value>,size: <value>, parent_frame: <value>}}

Argument Description

box_name: A name that will be associated with the object being created. The name must be unique.

size: An array of 3 floats that specifies the XYZ size of the box relative to its origin which is at the corner of the box. The size uses the clients active units, or the default of millimeters. Values can be either positive or negative.

parent_frame:OPTIONAL Specifies the parent reference frame. Default value is the world frame. A parent frame must be static and not on a stateful object. Eg. a parent frame cannot be attached to a robot, or an object who’s parent mate has multiple states.

offset: OPTIONAL An array of 6 floats that specifies the offset between the parent frame and this box. Once added, the offset is fixed between the box and the parent frame. The offset uses the clients active units and rotation convention, or the default of millimetres, degrees, roll pitch yaw. The default offset is [0,0,0,0,0,0].

Function Description

This command adds a box into the Dynamic Scene Model. Once added, all robots in all robot presets will avoid it. Additionally, current robot motions will avoid the box when added.

The box origin is at the corner which the size and offset arguments are relative to. The box has a fixed offset relative to the parent frame, and if the parent frame’s position is updated, the position of the box will be as well.

The Dynamic Scene Model is not stored to disk, so when the Project is unloaded, the Dynamic Scene Model is reset.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: AddBox,data: {box_name: case_1,size: [0.5,0.5,0.5], parent_frame: pallet_origin}}

Example YAML Response

{topic: AddBox,type: Response}

Example CSV Response

AddBox,0

AddObject

Structure

{topic: AddObject,data: {object_name: <value>,object_type: <value>, parent_frame: <value>, offset: <value>}}

Argument Description

object_name: A name that will be associated with the object being created. The name must be unique.

object_type: The name of the object type as defined in RPC.

parent_frame:OPTIONAL Specifies the parent reference frame. Default value is the world frame. A parent frame must be static and not on a stateful object. Eg. a parent frame cannot be attached to a robot, or an object who’s parent mate has multiple states.

offset: OPTIONAL An array of 6 floats that specifies the offset between the parent frame and this object. Once added, the offset is fixed between the object and the parent frame. The offset uses the clients active units and rotation convention, or the default of millimetres, degrees, roll pitch yaw. The default offset is [0,0,0,0,0,0].

Function Description

This command adds a CAD object from the RPC project into the Dynamic Scene Model. Once added, all robots in all robot presets will avoid it. Additionally, current robot motions will avoid the box when added.

The object has a fixed offset relative to the parent frame, and if the parent frame’s position is updated, the position of the object will be as well.

The Dynamic Scene Model is not stored to disk, so when the Project is unloaded, the Dynamic Scene Model is reset.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: AddObject,data: {object_name: case_1,object_type: case_model, parent_frame: conveyor_origin}}

Example YAML Response

{topic: AddObject,type: Response}

Example CSV Response

AddObject,0

RemoveBoxes

Structure

{topic: RemoveBoxes}
{topic: RemoveBoxes,data: {box_names: <value>}}

Argument Description

box_names: OPTIONAL An array specifying the name/s of the boxes that will be removed.

Function Description

This command removes a specified box/es from the Dynamic Scene Model. If no arguments are passed, all boxes will be removed, or an array of the box names can be passed to selectively remove.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: RemoveBoxes,data: {box_name: [case_1,case_2]}}

Example YAML Response

{topic: RemoveBoxes,type: Response}

Example CSV Response

RemoveBoxes,0

RemoveObjects

Structure

{topic: RemoveObject,data: {object_name: <value>}}

Argument Description

object_name: OPTIONAL The name of the object that will be removed.

Function Description

This command removes a specified object from the Dynamic Scene Model. If no arguments are passed, all objects will be removed, or an array of the box names can be passed to selectively remove.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: RemoveObject,data: {object_name: case_1}}

Example YAML Response

{topic: RemoveObject,type: Response}

Example CSV Response

RemoveObject,0

Reparent

Structure

{topic: Reparent,data: {box_name: <value>, parent_frame: <value>}}

Argument Description

box_name: The name of the box that will have its parent frame updated.

parent_frame: This argument specifies the new parent frame for the box. The frame must be a dynamic frame added with the AddFrame command, or a robot’s default TCP addressed as {robot_name}_default_tcp.

Function Description

This command will re-assign the parent frame for a specified DSM box. After this command executes, the box will have a new parent frame with an offset such that it remains in its current position. If the box’s new parent frame is moved, the box will move with it with that offset.

A box’s parent frame can also be the TCP of a robot, and as the robot moves, the box moves with it maintaining the initial offset. A robot’s default TCP should be used that way it is independent of presets. A robot’s default TCP can be specified as {robot_name}_default_tcp. In order to assign a robot’s tcp as the parent of a box, the robot must be stationary.

Response Details

This command will return a response to acknowledge the command has been received and executed successfully.

Example Request

{topic: Reparent,data: {box_name: case_1, parent_frame: Robot1_default_tcp}}

Example YAML Response

{topic: Reparent,type: Response}

Example CSV Response

Reparent,0

API Endpoints - Robot + Scene Modeling

SetWorkcellState

Structure

{topic: SetWorkcellState, data: { objects: {<object_name>: <object_state>}, robots: {<robot_name>: <robot_preset>}}}

Argument Description

robots:OPTIONAL this argument contains 2 sub-keys that specifies a robot preset.

  • robot_name: Specifies which robot to switch presets.

  • robot_preset: Specifies which robot preset to switch to. The preset name is required for a given robot_name.

objects:OPTIONAL this argument contains 2 sub-keys that specifies a object state.

  • object_name: Specifies which (stateful) object to switch states.

  • object_state: Specifies which object state to switch to. The object state name is required for a given object_name.

Function Description

This command changes the entire workcell preset for the loaded project with a combination of robot presets and object states. The combination can contain all robot presets and object states or a partial list.

Response Details

This command will return a response to acknowledge the command has executed successfully.

Example Request

{topic: SetWorkcellState, data: { objects: {object_1: object_state_1, object_2: object_state_2}, robots: {robot_1: robot_preset1, robot_2: robot_preset2}}}

Example YAML Responses

{topic: SetWorkcellState,type: Response}

Example CSV Responses

SetWorkcellState,0
  • No labels