Realtime Robotics RapidPlan 2.6 ASCII API
- 1 Revisions
- 2 Goal
- 3 API Format
- 3.1 Syntax (Inline YAML 1.2 Spec)
- 3.2 Requests
- 3.2.1 Formation Rules
- 3.2.2 Boolean Values
- 3.3 Responses
- 3.4 Stateful Commands
- 3.5 Commands Stored on Disk
- 3.6 Command Determinism
- 4 Default Units
- 5 Move Type and Target Type Support
- 6 API Endpoints - Project
- 6.1 SetResponseType
- 6.2 GetUnits
- 6.3 SetUnits
- 6.4 GetMode
- 6.5 ClearFaults
- 6.6 LoadProject
- 6.7 GetLoadedProject
- 6.8 UnloadProject
- 6.9 SetDefaultProject
- 6.10 EnterOperationMode
- 6.11 EnterConfigurationMode
- 6.12 Shutdown
- 6.13 UserLog
- 6.14 BeginInterlockRecording
- 6.15 GenerateInterlockData
- 7 API Endpoints - Robot
- 7.1 ActivateRobots
- 7.2 DeactivateRobot
- 7.3 Connect
- 7.4 Disconnect
- 7.5 AcquireControl
- 7.6 ReleaseControl
- 7.7 SetMaxLinearAcceleration
- 7.8 SetMaxLinearSpeed
- 7.9 SetAlternateLocation
- 7.10 SetInterruptBehavior
- 7.11 SetRobotPreset
- 7.12 GetRobotPresets
- 7.13 Queueing Moves
- 7.14 Move
- 7.15 CombinedMove
- 7.16 CancelMove
- 7.17 HoldMove
- 7.18 ResumeMove
- 7.19 GetTargets
- 7.20 CreateTarget
- 7.21 UpdateTarget
- 7.22 RenameTarget
- 7.23 RemoveTarget
- 7.24 AddConnection
- 7.25 RemoveConnection
- 7.26 GetJointConfiguration
- 7.27 GetTCPPose
- 7.28 IsOnTarget
- 7.29 BeginRoadmapRecording
- 7.30 EndRoadmapRecording
- 7.31 CancelMotionRecording
- 8 API Endpoints - Scene Modeling
- 8.1 GetObjectStates
- 8.2 GetStatefulObjects
- 8.3 SetObjectState
- 8.4 GetFrames
- 8.5 AddFrame
- 8.6 UpdateFrame
- 8.7 RemoveFrames
- 8.8 AddBox
- 8.9 AddObject
- 8.10 RemoveBoxes
- 8.11 RemoveObjects
- 8.12 Reparent
- 9 API Endpoints - Robot + Scene Modeling
- 9.1 SetWorkcellState
Revisions
Revision history from 2.6 onwards
2023/07/14: (2.5) Added
validation
argument to UpdateTarget command2023/07/19: (2.5) Added BlockMove + ContinueMove commands (more details to come), also updated CombinedMove with new optional blockMove argument
2023/08/02: (2.5) Updated Move command with a new argument
constraint
.2023/08/09: (2.5) Correction of the preset-switching behavior in a CombinedMove command.
2023/08/10: (2.5) Updated name of HoldMove and ResumeMove commands (prev. block/continue)
2023/08/11: (2.5) Added MultiRobotMove command and updated SetAlternateLocation with a new mode
multirobot
.2023/09/22: (2.5) Replaced Move command argument
constraint
withconstraints
.2023/09/28: (2.5) Add documentation about yaml parsing per RAPID-38095
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 config2023/11/29: (2.6) Added new Move goal type
route
2023/12/21: (2.6) Added BeginMotionRecording, EndMotionRecording and CancelMotionRecording commands
2024/02/08: (2.6) Clarify that Move Costs sum is not constrained by the api
2024/03/04: (2.6) 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 keymy_key
whose value ismy_value
{my_key:my_value}
will parse as an object with a keymy_key:value
whose value isnull
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 aMove
orLoadProject
. When aResponse
includes aseq
key, that indicates that aDelayedResponse
will be returned for that command. Both the immediate and delayed responses will have a globally unique sequence number (referred to asseq
) 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 aCombinedMove
command returns aFeedback
response to indicate its completion before theCombinedMove
completes and returns itsDelayedResponse
.
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
: 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 | |
---|---|
Argument Description |
|
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 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 | |
Example YAML Responses | |
Example CSV Responses |
GetUnits
Structure | |
---|---|
Argument Description |
|
Function Description |
|
Response Details | This command will return a response to show the units used by the loaded project. |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
SetUnits
Structure | |
---|---|
Argument Description |
|
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 If the 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 | |
Example YAML Responses | |
Example CSV Responses |
GetMode
Structure | |
---|---|
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 | |
Example YAML Responses | |
Example CSV Responses |
ClearFaults
Structure | |
---|---|
Argument Description |
|
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 |
Response Details | This command will return a single response code as a result value. |
Example Request | |
Example Responses |
LoadProject
Structure | |
---|---|
Argument Description |
|
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. |
Delayed Response Details | Once the load is completed, the system will send a delayed response to indicate the project has finished loading. |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
GetLoadedProject
Structure | |
---|---|
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 |
Response Details | This command will return a response code, followed by the currently loaded project or an appropriate error code. |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
UnloadProject
Structure | |
---|---|
Argument Description |
|
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. |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
SetDefaultProject
Structure | |
---|---|
Argument Description |
|
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 |
Response Details | This command will return a response to acknowledge the command has been received and executed successfully. |
Example Request | or |
Example YAML Responses | |
Example CSV Responses |
EnterOperationMode
Structure | |
---|---|
Argument Description |
|
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 | |
Example YAML Responses | |
Example CSV Responses |
EnterConfigurationMode
Structure | |
---|---|
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 |
Response Details | This command will return a response to acknowledge the command has been received and executed successfully. |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
Shutdown
Structure | |
---|---|
Argument Description | None |
Function Description | This command issues an asynchronous system call, Between this call and the system shutting down, the appliance will be in a “Shutdown” state and refuse any further ASCII commands.
|
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 | |
Example YAML Responses | |
Example CSV Responses |
UserLog
Structure | |
---|---|
Argument Description |
|
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 | |
Example YAML Responses | |
Example CSV Responses |
BeginInterlockRecording
Structure | |
---|---|
Argument Description |
|
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 |
Response Details | This command will return a response to acknowledge the command has been received and executed successfully. |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
GenerateInterlockData
Structure | |
---|---|
Argument Description |
|
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 |
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.
|
Example Request | |
Example YAML Response | For each robot, the information of the robot motion and interlock is returned.
|
Example CSV Response |
|
API Endpoints - Robot
ActivateRobots
Structure | |
---|---|
Argument Description |
|
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. |
Response Details | This command will return a response to acknowledge the command has been received and executed successfully. |
Example Request | |
Example YAML Response | |
Example CSV Response |
DeactivateRobot
Structure | |
---|---|
Argument Description |
|
Function Description | This command ‘deactivates’ a robot which means the RTR controller will ignore it when connecting to the robots within a project. Subsequent |
Response Details | This command will return a response to acknowledge the command has been received and executed successfully. |
Example Request | |
Example YAML Response | |
Example CSV Response |
Connect
Structure | |
---|---|
Argument Description |
|
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 | |
Example YAML Responses | |
Example CSV Responses |
Disconnect
Structure | |
---|---|
Argument Description |
|
Function Description | This command disconnects from all robots in the project (unless a robot is specified) and returns them to the |
Response Details | This command will return a response to acknowledge the command has been received and executed successfully. |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
AcquireControl
Structure | |
---|---|
Argument Description |
|
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 | |
Example YAML Responses | |
Example CSV Responses |
ReleaseControl
Structure | |
---|---|
Argument Description |
|
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. |
Response Details | This command will return a response to acknowledge the command has been received and executed successfully. |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
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 | |
---|---|
Argument Description |
|
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 |
Response Details | This command will return a response to acknowledge the command has been received and executed successfully. |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
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 | |
---|---|
Argument Description |
|
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 A user can specify the max linear speed allowed for a robot using this command, or reset to the default value using the 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 | |
Example YAML Responses | |
Example CSV Responses |
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 | |
---|---|
Argument Description |
|
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. |
Response Details | This command will return a response to acknowledge the command has been received and executed successfully. |
Example Request | |
Example Responses | |
Example CSV Responses |
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
| |
---|---|
Argument Description |
|
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: |
Response Details | This command will return a response to acknowledge the command has been received and executed successfully. |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
SetRobotPreset
Structure | |
---|---|
Argument Description |
|
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 | |
Example YAML Responses | |
Example CSV Responses |
GetRobotPresets
Structure | |
---|---|
Argument Description |
|
Function Description | This command will return a response with a comma separated array of the robot preset names ( |
Response Details |
For CSV responses, after the acknowledgement codes, i.e., |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
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
andRoadmap
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 | |
---|---|
Argument Description |
A
If a robot's external axes remain fixed during a move, or switch to different setpoint values defined by a target,
Robot pose value plus
|
Function Description | With this new generic A A A |
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. |
Delayed Response Details | If a path was found, the system will send a or, for a |
Example Request | |
Example YAML Responses | |
Example CSV Responses |
CombinedMove
Structure | |
---|---|
Argument Description |
HoldMove is also able to be sent as a segment of a CombinedMove command. |
Function Description |
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 If move queuing is being used, a 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 |
Delayed Response Details | For every 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 |
Example Request | 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): |
Example YAML Responses | |
Example CSV Responses |
CancelMove
Structure | |
---|---|
Argument Description |
|
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. If If a move is canceled mid-motion after a |
Response Details |