Get desktop application:
View/edit binary Protocol Buffers messages
Compile a walk into a mission. Input DataChunks should deserialize into a CompileAutowalkRequest. Output DataChunks should deserialize into a CompileAutowalkResponse. This rpc is stateless.
Compile a walk into a mission then load to mission service. Input DataChunks should deserialize into a LoadAutowalkRequest. Output DataChunks should deserialize into a LoadAutowalkResponse.
An Action is what the robot should do at a location. For example, the user may desire that the robot perform a laser scan at a given waypoint.
Used in:
This field can be used to specify a behavior tree as an action. If the user had two callbacks they would like to run simultaneously at the waypoint this action is associated with, they could use create a behavior tree inside Node with both callbacks embedded in a simple parallel. The downside of using node, is that editors might not support editing parameters directly.
For actions associated with the Data Acquisition Service.
Used in:
The autowalk service replaces the action_name field in the CaptureActionId with the element name.
Last known Data Acquisition capabilities.
Any images taken at action creation time. For DataAcquisition actions, this includes: - Any images in the Data Acquisition capture. - Any images that are inputs to NCB workers that are in the Data Acquisition capture. - Any images that a Data Acquisition plugin in the Data Acquisition capture requests a region of interest for. Note that both this message and AcquisitionCapabilityList will contain the Spec for images sources. This message will contain the spec at record time, while last_known_capabilities should be updated as time progresses and services evolve. This data is meant to allow UIs to give users context about their actions, AND provide them a canvas to edit region of interests with after the fact. It is not used at mission playback time.
Used in:
The name of the sequence to play.
Used in:
,Name of the service in the directory.
Timeout of any single RPC. If the timeout is exceeded, the RPC will fail. The mission service treats each failed RPC differently: - EstablishSession: An error is returned in LoadMission. - Tick: The RPC is retried. - Stop: The error is ignored, and the RPC is not retried. Omit for a default of 60 seconds.
Resources that we will need leases on.
The list of variables the remote host should receive. Variables given can be available at either run-time or compile-time. The "key" in KeyValue is the name of the variable as used by the remote system. DEPRECATED as of 3.3. Please use 'parameters' instead.
All specifications and any values chosen at record time.
Any images taken at action creation time. For RemoteGRPC's, this will only happen if the RemoteGRPC advertises parameters that require a region of interest for a specific camera. This data is meant to allow UIs to give users context about their actions, AND provide them a canvas to edit region of interests with after the fact. It is not used at mission playback time.
The robot does nothing but wait while also performing its ActionWrapper(s). For example, if the user wants the robot to pose for some amount of time (while doing nothing else), they would populate an ActionWrapper with Pose and set the desired duration here accordingly.
Used in:
An ActionWrapper is what the robot should do prior to and during an action. For example, the user may desire that the robot stand in such a way that its z-axis is aligned with the gravity vector, even though it is standing on an incline.
Used in:
Position the body and perform a joint move and cartesian command in target frame
Used in:
Arm Joint Move Command The joint trajectory to execute in the initial rough pointing joint move.
Arm Cartesian Command The tool pose relative to the parent link (wrist). Defaults to a frame with it's origin slightly in front of the gripper's palm plate aligned with the wrist's orientation.
A 3D pose trajectory for the tool expressed in target frame,
Robot desired stance relative to waypoint This is taken by measuring the average of the footprints in body frame at the time of waypoint creation. This is used to generate the stance command. Target == waypoint. This assumes the waypoint is gravity aligned.
Body mobility params during cartesian move
If true, the arm will stow after this action no matter what. If false, the arm will only stow if the next action is far away.
Set the camera params of the gripper camera
Used in:
Used in:
By default, any action that includes a GripperCommand action wrapper will run the specified command BEFORE the action is run. By default, after the action is run the gripper will be closed. This behavior can be turned off by setting this flag to true.
Pose the robot prior to performing the action
Used in:
If your Target is a graph_nav waypoint, this pose will be relative to the waypoint you are navigating to. If no target was specified, this parameter will be ignored and the robot will stand in a generic pose.
Sit the robot prior to performing the action
Used in:
(message has no fields)
Align SpotCam to a waypoint. Cannot be used with SpotCamPtz or RobotBodyPose
Used in:
List of alignments to perform
Desired transform from the sensor to the target
Final zoom the camera should be after all alignments have finished
Optional list of sensor names which should be unobstructed after alignment
Used in:
Camera zoom parameter
Sensor to use for alignment
Image to use for alignment
If true, this alignment will be skipped during playback
Focus state used during alignment. Defaults to auto-focus.
Set the brightness of the LEDs on the SpotCam.
Used in:
There are four LEDs at indices [0, 3]. The brightness for each LED may be set between [0.0, 1.0], where 0 is off and 1 is full brightness.
Set the pan, tilt, and zoom of the SpotCam.
Used in:
See bosdyn/api/spot_cam
If your mission has docks, autowalk can pause the mission to return to the dock if the battery gets too low. Use this message to control when this behavior happens.
Used in:
Once charging, the robot will continue to charge until the battery level is greater than or equal to this threshold, at which point in time, the mission will start.
If the battery level is less than or equal to this threshold, the robot will stop what it is currently doing and return to the dock. Once the battery level is greater than or equal to the battery start threshold, the mission will resume.
Choreography elements required for the mission.
Used in:
Any sequences we need to play the mission.
Any animations we need if we want to play the sequence.
Common request header.
Walk to compile.
If this is set to true, mission compilation will fail if the Walk contains parameters that are set incorrectly. This can be useful during development to help the developer find issues with their client (e.g., suppose the client UI allows a user to set a parameter incorrectly). If this is set to false, mission compilation is more likely to succeed for the same Walk because any parameters that are both incorrect and modifiable are modified during mission compilation.
Common response header.
Result of compiling the mission.
Root node of compiled walk.
There will be one ElementIdentifier for each Element in the input Walk. The index of each ElementIdentifier corresponds to the index of the Element in the input Walk. Skipped elements will have default values for id's. (0 and empty string)
If certain elements failed compilation, they will be reported back in this field. The map correlates the index of the Element in the input Walk to the FailedElement.
Final docking node.
Node that contains the main sequence of actions performed in the walk. In continuous playback mode, the walk repeats when this node completes.
Possible results of compiling a walk to mission.
Used in:
Invalid status, do not use.
Compilation succeeded.
Compilation failed. The walk was malformed.
The dock itself and the target associated with it
Used in:
The docking station ID of the dock corresponds to the number printed on the fiducial, below the part of the fiducial that looks like a QR code. Only fiducial IDs greater than or equal to 500 should be used here because they are reserved for docks.
To maximize reliability, at record time, the client should dock the robot while graph_nav is still recording. When the robot is finished docking, the client should create a waypoint on top of the dock, while the robot is docked, and then stop recording. The waypoint created while the robot is sitting on the dock should be specified here.
When it is time for the robot to dock, it will approach this target before issuing docking commands. If the user is using graph_nav, the final waypoint in the NavigateRoute OR the waypoint ID in the NavigateTo MUST be at the docking prep pose. To do this, send a docking command to move the robot to the docking prep pose. Then, create a waypoint at the docking prep pose location. Graph_nav is responsible for navigating the robot to the docking prep pose. Once the robot is in the docking prep pose, the docking service does the rest.
At mission playback, if the robot is unable to reach the dock OR successfully dock, the mission will let the operator know with a user question. If the operator does not answer, the robot will safely power off. This parameter controls how long the operator has to answer. This parameter also controls how long robot will wait to retry to undock on a failed undock.
Whether the robot can use this dock for recharging or executing a return to dock and try again later failure behavior.
Whether the robot can end a mission on this dock.
An Element is the basic building block of the autowalk.
Used in:
The name of an element may be anything, but it is good practice to choose something that describes the physical location and action that is occurring (e.g., boiler room laser scan).
Location the robot should navigate to.
Describes what to do if the robot fails to navigate to target.
Action performed at target destination
Actions performed by the robot and/or payloads prior to and during an action.
Describes what to do if the robot fails to execute the action.
Set to true to skip element.
If the mission requires more than one battery, the robot needs to return to the dock and charge before it can complete the mission. This field defines the battery percentage thresholds that at which the robot should pause and resume mission execution. Considering using various thresholds depending on the target's distance from the dock
Maximum duration of action execution time, including all wrappers. If they take longer than this duration, the action will be considered a failure. Not including, or including a zero duration will set the action to NOT have a timeout.
Unique identifier for this element. This will be embedded in various Data Acquisition captures and various logging bundles. This should be globally unique across all elements.
Used in:
,Identifiable data for the root node of the element. Deprecated as of 4.0. Please use navigation_id instead.
Identifiable data for action node of the element.
Identifiable data for the navigation node of the element.
Used in:
,The reasons why this element failed. May not be provided by all elements.
Compile time modification that resolved error(s).
Used in:
The mission can automatically retry navigating to a waypoint or performing an action. Automatic retries can increase the probability of successfully navigating to a waypoint, but may cause the robot to take an unexpected path. Similarly, they can increase the probability of successfully collecting data for an action, but also increase the amount of time a mission takes. If the client does not want the robot to automatically retry navigating to a waypoint or performing an action, set this to 0. If the client wants the robot to automatically retry navigating to a waypoint or performing an action, set this to the desired number of retries. For example, if the client would like the action to be retried once, set this equal to 1. If this is unset or set to 0, no retry will occur.
At mission playback, if something fails (e.g., the robot gets stuck, an action fails), the user will get all possible actions as options in a question to choose from. If the user does not answer, the mission will fall back to the default behavior after this timeout. The default behaviors are defined by the default_behavior one_of. A minimum duration of 10 seconds is enforced.
Sometimes, the robot may not be able to get to an action (for example, its path may be blocked). Similarly, while at a waypoint where an action is performed, that action may fail (for example, the sensor is not powered on). In case of such failures, the user should choose the desired behavior using this enum.
If a failure occurs and the prompt has not been answered, the robot will proceed to the next action if able to do so. This may lead to different behavior at mission playback than at mission recording (e.g., the robot may take a different route, the robot may fail to collect the data for an action).
Used in:
(message has no fields)
Only available in missions with a dock! If robot can get back to the dock, it will, and if it does, the mission will end.
Used in:
(message has no fields)
Only available in missions with a dock! If a failure occurs and the prompt has not been answered, the robot will return to the start of the mission. Once at the start of the mission, the robot will attempt to dock. If successfully, robot will try again later after the specified delay.
Used in:
How long to wait at start of mission (or on dock) before trying again. A minimum duration of 60 seconds is enforced.
If a failure occurs and the prompt has not been answered, the robot will sit down and power off. This is the safest option.
Used in:
These parameters apply to the entire autowalk.
Used in:
If the mission contains data acquisitions, this will be their group name. The actual group name used will include the specified group name, and additional qualifiers to ensure its unique for each start of this mission.
If the mission contains SpotCAM PTZ actions, set this to true. At the start of the mission (or if the robot falls), the SpotCAM PTZ autofocus will be reset, thereby improving the quality of the subsequent PTZ captures.
The mission can automatically self-right the robot. Autonomous self-rights can damage the robot, its payloads, and its surroundings. If the user does not want the robot to self-right on its own, set this number to 0. If the user does want the robot to self-right itself, the user may set a maximum number of attempts so that the robot does not destroy itself by repeatedly falling and getting up and falling again.
The callbacks that will be executed at the end of the mission. Functionality that is often found in post-mission callbacks includes uploading data to the cloud or sending an email. The callbacks will be executed serially (first in, first executed).
It can be useful to have the robot run a walk without collecting data. If this boolean is set to true, the compiled mission will still navigate to the target of each element, however it will not actually perform the associated action & action wrappers.
Configurable options for Spot to perform extra behaviors in missions to communicate with nearby observers.
Options for Spot to perform additional human-robot interaction behaviors in missions to help communicate with observers.
Used in:
If true, Spot will tap its front-left foot twice if anomalies are discovered during an inspection. Alerts can be viewed in Orbit.
If true, Spot will lift its legs twice before undocking.
Common request header.
Walk to compile
Leases that will be needed to validate the mission. Usually, no leases are necessary for validation, and this can be left empty.
If this is set to true, mission compilation will fail if the Walk contains parameters that are set incorrectly. This can be useful during development to help the developer find issues with their client (e.g., suppose the client UI allows a user to set a parameter incorrectly). If this is set to false, mission compilation is more likely to succeed for the same Walk because any parameters that are both incorrect and modifiable are modified during mission compilation.
Common response header.
Result of loading the mission.
Results from any leases that may have been used. As part of mission validation, some of the non-mission leases may have been used.
If certain nodes failed compilation or validation, they will be reported back in this field.
There will be one ElementIdentifier for each Element in the input Walk. The index of each ElementIdentifier corresponds to the index of the Element in the input Walk. Skipped elements will have default values for id's. (0 and empty string)
If certain elements failed compilation, they will be reported back in this field. The map correlates the index of the Element in the input Walk to the FailedElement.
Mission ID assigned by the mission service.
Final docking node.
Node that contains the main sequence of actions performed in the walk. In continuous playback mode, the walk repeats when this node completes.
Possible results of loading a mission.
Used in:
Invalid status, do not use.
The mission was loaded successfully.
Compilation failed. The walk was malformed.
Load-time validation failed. Some part of the mission was unable to initialize.
Used in:
, ,Unique integer set by the mission service when loading a mission.
Unique string set by the autowalk service when compiling a walk.
The playback mode governs how many times the mission is played back (once or more), at what interval the playbacks should occur (e.g., every 2 hours), and if docking is involved, the battery level thresholds at which the robot should either (1) stop and charge or (2) start the playback process again.
Used in:
The mission should be played continuously only stopping if a battery monitor stop threshold is crossed.
Used in:
(message has no fields)
The mission should be played back once.
Used in:
Deprecated as of 4.1. To skip docking after completion, set disable_end to true for all docks in the walk proto. Boolean to allow the robot to not dock after completing a mission.
The mission should be played back periodically.
Used in:
The interval is the time that will elapse between the mission finishing and starting again. It is applied relative to the time at which the mission finishes. For example, if the user sets the interval to 2 hours, starts the mission at 12:00, and the mission takes one hour (finishes at 13:00), the next mission would start at 15:00, NOT 14:00. Next mission start time = current mission end time + interval
The number of times the mission should be played back. If set to 1, the interval no longer applies and the mission will be played back once. If set to two or more, the mission will run that number of times, with the amount of time between playbacks equal to the interval. If set to zero, the mission will run "forever".
A Target is the location the robot should navigate to.
Used in:
,If set, upon reaching the target the robot will perform an explicit relocalization. This should increase the accuracy of the robots belief of it's position on the map. After relocalizing, the robot will re-navigate to the target.
Tell the robot to follow a route to a waypoint. If the robot is off the route (i.e., "far" from the route) when NavigateRoute is sent, the robot may navigate in unexpected ways.
Used in:
A route for the robot to follow.
Parameters that define how to traverse and end the route. For example, the user may decide how close to the destination waypoint the robot needs to be in order to declare success.
Tell the robot to navigate to a waypoint. It will choose its route.
Used in:
A unique string corresponding to the waypoint ID that the robot should go to.
Parameters that define how to traverse and end the route. For example, the user may decide how close to the destination waypoint the robot needs to be in order to declare success.
Used in:
Some SetLocalizationRequests require that waypoint snapshots contain full images. Make sure your client is downloading / storing / uploading full snapshots if you plan on using this feature in your client.
Used in:
Will default to TARGET_STOW_BEHAVIOR_AUTO
Compiler will do some heuristics to figure out if we should stow. Headed back to dock = stow Headed to another action that doesn't use arm sensor pointing = stow Headed to another action that uses arm sensor pointing and is far away = stow Headed to another action that uses arm sensor pointing and is close = don't stow
Never ever stow the arm on the way to this action.
Always stow the arm on the way to this action.
Used in:
,Parameters that apply to the entire mission.
Governs the mode and frequency at which playbacks occur.
The name of the map this mission corresponds to.
The name of the mission.
The list of actions and their associated locations.
The docks the mission can dock at.
Unique identifier for this walk. This will be embedded in various Data Acquisition captures and various logging bundles. This should be globally unique across all walks.
Choreography related dependencies (any sequences and animations a robot needs to play this walk).