Get desktop application:
View/edit binary Protocol Buffers messages
Retrieve information about how to operate the service, including what lease resources are required by the navigation callback.
Message for requesting information about a area callback implementation.
Common request header.
Message for providing information about a area callback implementation.
Common response header.
Information about how the AreaCallback should be called.
BeginCallback is called once as the robot enters a AreaCallback region of a map. This call initializes the navigation callback for operation.
Common request header.
Description of the region we are going to cross.
The timestamp (in robot time) by which a command must finish executing. If unset, a AreaCallback implementation may pick a reasonable value.
Deprecated in 4.1, the relevant data is set in custom_params and config_data instead. Configuration data associated with this area callback region
Any other custom parameters to the callback.
Custom config data used by the service to do its job.
BeginControl is called once after the area callback implementation requests control. Control is handed off (via a lease) from the caller to the area callback.
Common request header.
Leases that a AreaCallback uses once it takes control of the robot. This list should match AreaCallbackInformation required_lease_resources.
The command id associated with a single execution of a navigation callback.
UpdateCallback is called periodically while the callback is running. Area callback implementations use UpdateCallback to dictate how caller should operate while callback is running (pause, continue, etc.)
Common request header.
The command id associated with a single execution of a navigation callback.
If set, update the end time (in robot time) by which a command must finish executing.
Called only if the route changes in the middle of the region (for example, if the robot is blocked by an obstacle and re-routes).
Common request header.
The command id for which the route is changing.
The new planned route through the region.
The remaining old route that was not completed.
Common response header.
EndCallback is called once when the caller decides the navigation callback is over. This might be because the robot exited the callback region or might be because the callback reported that it finished doing work.
Common request header.
The command id associated with a single execution of a navigation callback.
The recording service can be used to record a Graph Nav map (containing waypoints and edges). The recorded map can consist of the following: * Chain: a topological arrangement of waypoints/edges where every waypoint has at least 1 but at most 2 edges attached to it. * Branch: separate Chains can be joined together into a Branch at exactly one waypoint. When recording a map using the recording service, a common pattern is: * Call StartRecording to begin recording a chain of waypoints. * Call SetRecordingEnvironment to define persistent annotations for the edges and waypoints. * While recording, call GetRecordStatus to get feedback on the state of the recording service. * While recording, call GetMapStatus to determine what waypoints have been created. * Optionally call CreateWaypoint to create waypoints in specific locations. * Call StopRecording to pause the recording service and create branches. * While recording (or after completing recording), call DownloadWaypoint/Edge Snapshot rpcs from the GraphNavService to download the large sensor data with the map.
Start recording the map from the current localization. Creates a waypoint if you are starting to record. Otherwise, waits until you are sufficiently far away from the previous waypoint.
The StartRecording request tells the recording service to begin creating waypoints with the specified recording_environment.
Common request header.
The recording service is protected by a lease. The client must have a lease to the recording service to modify its internal state.
This will be merged into a copy of the existing persistent recording environment and used as the environment for the created waypoint and the edge from the previous waypoint to the new one. It will not affect the persistent environment.
If filled out, asks that the record service verify that the given fiducial IDs are presently visible before starting to record. This is useful for verifying that the robot is where the user thinks it is in an area with known fiducials.
If provided, this timestamp will be used in every waypoint snapshot as the "started_recording_on" timestamp. Otherwise, a new timestamp will be generated after "StartRecording" is called. This is to allow association between waypoint snapshots based on recording session time.
The StartRecording response message returns the first created waypoint, which is made at the location the robot was standing when the request was made, in addition to any status information.
Common response header.
The waypoint that was just created.
The results/status of the lease provided.
Return status for the request.
If the status is STATUS_MISSING_FIDUCIALS, these are the fiducials that are not currently visible.
If the status is STATUS_FIDUCIAL_POSE_NOT_OK, these are the fiducials that could not be localized confidently.
Large graphs can only be uploaded if the license permits them. Recording will stop automatically when the graph gets too large. If StartRecording is requested again after the graph gets too large, it will fail, and license status will be filled out.
If the status is ROBOT_IMPAIRED, this is why the robot is impaired.
This is the robot local timestamp that graph_nav began recording on. If the Start Recording Request's session start time is provided, this should be the same as the request's session start time.
General statistics of the map loaded in GraphNav.
Stop recording the map from the current localization.
The StopRecording request message tells the robot to no longer continue adding waypoints and edges to the graph.
Common request header.
The recording service is protected by a lease. The client must have a lease to the recording service to modify its internal state.
The StopRecording response message contains the status of this request and any useful error information if the request fails.
Common response header.
The return status for the request.
If not localized to end, specifies which waypoint we are localized to.
The results/status of the lease provided.
This is the robot local timestamp that graph_nav began recording on. If the StartRecordingRequest's session start time is provided, this should be the same as the request's session start time.
General statistics of the map loaded in GraphNav.
Create a new waypoint at the current localization.
The CreateWaypoint request message specifies a name and environment the robot should use to generate a waypoint in the graph at it's current location.
Common request header.
Name of the waypoint to create. Overrides any naming prefix.
This will be merged into a copy of the existing persistent recording environment and used as the environment for the created waypoint and the edge from the previous waypoint to the new one. It will not affect the persistent environment.
The recording service is protected by a lease. The client must have a lease to the recording service to modify its internal state.
If filled out, asks that the record service verify that the given fiducial IDs are presently visible before creating a waypoint. This is useful for verifying that the robot is where the user thinks it is in an area with known fiducials.
Additional world objects to insert into this waypoint.
The CreateWaypoint response message contains the complete waypoint, and the associated edge connecting this waypoint to the graph when the request succeeds.
Common response header.
The waypoint that was just created.
The edge connecting the waypoint just created with the last created waypoint in the map.
Return status for the request.
The results/status of the lease provided.
If the status is STATUS_MISSING_FIDUCIALS, the following fiducials were not visible to the robot when trying to create the waypoint.
If the status is STATUS_FIDUCIAL_POSE_NOT_OK, these are the fiducials that could not be localized confidently.
Large graphs can only be uploaded if the license permits them. Recording will stop automatically when the graph gets too large. If CreateWaypointResponse is requested after the graph gets too large, it will fail, and license status will be filled out.
General statistics of the map loaded in GraphNav.
Set the environment and name prefix to use for the recording.
The SetRecordingEnvironment request message sets a persistent recording environment until changed with another SetRecordingEnvironment rpc.
Common request header.
Persistent environment to use while recording. This allows the user to specify annotations and naming prefixes for new waypoints and edges.
The recording service is protected by a lease. The client must have a lease to the recording service to modify its internal state.
The SetRecordingEnvironment response message includes the result and status of the request.
Common response header.
The results/status of the lease provided.
Create an arbitrary edge between two waypoints.
The CreateEdge request message specifies an edge to create between two existing waypoints. The edge must not already exist in the map. This can be used to close a loop or to add any additional edges.
Common request header.
Create an edge between two existing waypoints in the map with the given parameters.
The recording service is protected by a lease. The client must have a lease to the recording service to modify its internal state.
The CreateEdge response message contains the status of this request and any useful error information if the request fails.
Common response header.
Return status for the request.
If set, the existing edge that caused the STATUS_EXISTS error.
The results/status of the lease provided.
General statistics of the map loaded in GraphNav.
Tells the client the internal state of the record service, and the structure of the map that has been recorded so far.
The GetRecordStatus request message asks for the current state of the recording service.
Common request header.
The GetRecordStatus response message returns whether the service is currently recording and what the persistent recording environment is at the time the request was received.
Common response header.
If true, the record service is actively recording a chain.
The current persistent recording environment.
If the status is ROBOT_IMPAIRED, this is why the robot is impaired.
This is the robot local timestamp that graph_nav began recording on. If the Start Recording Request's session start time is provided, this should be the same as the request's session start time.
General statistics of the map loaded in GraphNav.
The GraphNav service service is a place-based localization and locomotion service. The service can be used to get/set the localization, upload and download the current graph nav maps, and send navigation requests to move around the map.
Trigger a manual localization. Typically done to provide the initial localization.
The SetLocalization response message contains the resulting localization to the map.
Common response header.
Result of using the lease.
Return status for the request.
If set, describes the reason the status is not OK.
Result of localization.
Alternative information if the localization is ambiguous.
If the status is ROBOT_IMPAIRED, this is why the robot is impaired.
This status determines whether the robot has compatible sensors for the map that was recorded. Note that if sensors aren't working, STATUS_IMPAIRED will be returned, rather than STATUS_INCOMPATIBLE_SENSORS.
Graph Nav will check the quality of the resulting localization and report the status here. Note that to preserve backwards compatability with 3.2 and earlier, a poor quality check does not result in this RPC failing.
Tell GraphNav to navigate/traverse a given route.
A NavigateRoute request message specifies a route of waypoints/edges and parameters about how to get there. Like NavigateTo, this command returns immediately upon processing and provides a command_id that the user can use along with a NavigationFeedbackRequest RPC to poll the system for feedback on this command. The RPC does not block until the route is completed.
Common request header.
The Lease to show ownership of the robot.
A route for the robot to follow.
What should the robot do if it is not at the expected point in the route, or the route is blocked.
How to travel the route.
The timestamp (in robot time) that the navigation command is valid until.
Identifier provided by the time sync service to verify time sync between robot and client.
If provided, graph_nav will move the robot to an SE2 pose relative to the final waypoint in the route. Note that the robot will treat this as a simple goto request. It will first arrive at the destination waypoint, and then travel in a straight line from the destination waypoint to the offset goal, attempting to avoid obstacles along the way.
Unique identifier for the command. If 0, this is a new command, otherwise it is a continuation of an existing command.
Response to a NavigateRouteRequest. This is returned immediately after the request is processed. A command_id is provided to specify the ID that the user may use to poll the system for feedback on the NavigateRoute command.
Common response header.
Details about how the lease was used.
Return status for the request.
If the status is ROBOT_IMPAIRED, this is why the robot is impaired.
Unique identifier for the command, If 0, command was not accepted.
On a relevant error status code, these fields contain the waypoint/edge IDs that caused the error.
On a relevant error status code (STATUS_INVALID_EDGE), this is populated with the edge ID's that cased the error.
Errors about Area Callbacks in the map.
Tell GraphNav to navigate to a waypoint along a route it chooses.
The NavigateToRequest can be used to command GraphNav to drive the robot to a specific waypoint. GraphNav will plan a path through the map which most efficiently gets the robot to the specified goal waypoint. Parameters are provided which influence how GraphNav will generate and follow the path. This RPC returns immediately after the request is processed. It does not block until GraphNav completes the path to the goal waypoint. The user is expected to periodically check the status of the NavigateTo command using the NavigationFeedbackRequest RPC.
Common request header.
The Leases to show ownership of the robot and the graph.
ID of the waypoint to go to.
Preferences on how to pick the route.
Parameters that define how to traverse and end the route.
The timestamp (in robot time) that the navigation command is valid until.
Identifier provided by the time sync service to verify time sync between robot and client.
If provided, graph_nav will move the robot to an SE2 pose relative to the waypoint. Note that the robot will treat this as a simple goto request. It will first arrive at the destination waypoint, and then travel in a straight line from the destination waypoint to the offset goal, attempting to avoid obstacles along the way.
Unique identifier for the command. If 0, this is a new command, otherwise it is a continuation of an existing command. If this is a continuation of an existing command, all parameters will be ignored, and the old parameters will be preserved.
Defines robot behavior when route is blocked. Defaults to reroute when route is blocked.
Response to a NavigateToRequest. This is returned immediately after the request is processed. A command_id is provided to specify the ID that the user may use to poll the system for feedback on the NavigateTo command.
Common response header.
Results of using the various leases.
Return status for the request.
If the status is ROBOT_IMPAIRED, this is why the robot is impaired.
Unique identifier for the command, If 0, command was not accepted.
On a relevant error status code, these fields contain the waypoint/edge IDs that caused the error.
Errors about Area Callbacks in the map.
Tell GraphNav to navigate to a goal with respect to the current anchoring.
The NavigateToAnchorRequest can be used to command GraphNav to drive the robot to a specific place in an anchoring. GraphNav will find the waypoint that has the shortest path length from robot's current position but is still close to the goal. GraphNav will plan a path through the map which most efficiently gets the robot to the goal waypoint, and will then travel in a straight line from the destination waypoint to the offset goal, attempting to avoid obstacles along the way. Parameters are provided which influence how GraphNav will generate and follow the path. This RPC returns immediately after the request is processed. It does not block until GraphNav completes the path to the goal waypoint. The user is expected to periodically check the status of the NavigateToAnchor command using the NavigationFeedbackRequest RPC.
Common request header.
The Leases to show ownership of the robot and the graph.
Users may either choose seed_tform_goal or gps_navigation_params as a goal.
The goal, expressed with respect to the seed frame of the current anchoring. The robot will use the z value to find the goal waypoint, but the final z height the robot achieves will depend on the terrain height at the offset from the goal.
If given, the NavigateToAnchor request will instead be interpreted as a command to navigate to GPS coordinates. When given, the seed_tform_goal will be ignored,and instead the parameters in this message will be used. Otherwise, the NavigateToAnchorRequest works identically to when seed_tform_goal is used instead. For example, the TravelParams will be respected for this kind of goal.
These parameters control selection of the goal waypoint. In seed frame, they are the x, y, and z tolerances with respect to the goal pose within which waypoints will be considered. If these values are negative, or too small, reasonable defaults will be used.
Preferences on how to pick the route.
Parameters that define how to traverse and end the route.
The timestamp (in robot time) that the navigation command is valid until.
Identifier provided by the time sync service to verify time sync between robot and client.
Unique identifier for the command. If 0, this is a new command, otherwise it is a continuation of an existing command. If this is a continuation of an existing command, all parameters will be ignored, and the old parameters will be preserved.
Response to a NavigateToAnchorRequest. This is returned immediately after the request is processed. A command_id is provided to specify the ID that the user may use to poll the system for feedback on the NavigateTo command.
Common response header.
Results of using the various leases.
Return status for the request.
If the status is ROBOT_IMPAIRED, this is why the robot is impaired.
Unique identifier for the command, If 0, command was not accepted.
On a relevant error status code, these fields contain the waypoint/edge IDs that caused the error.
Errors about Area Callbacks in the map.
Result of the GPS command.
Get feedback on active navigation command.
The NavigationFeedback request message uses the command_id of a navigation request to get the robot's progress and current status for the command. Note that all commands return immediately after they are processed, and the robot will continue to execute the command asynchronously until it times out or completes. New commands override old ones.
Common request header.
Unique identifier for the command, provided by nav command response. Omit to get feedback on currently executing command.
The NavigationFeedback response message returns the robot's progress and current status for the command.
Common response header.
Return status for the request.
If the status is ROBOT_IMPAIRED, this is why the robot is impaired.
If the status is AREA_CALLBACK_ERROR, this map will be filled out with the error. The key of the map is the region id.
Remaining part of current route.
The completed route taken for this command. Intended primarily for visualization of route progress. Do not use this to determine if the route is finished, as under certain conditions edges can be reported as completed before the route is done. Check the status for STATUS_REACHED_GOAL to determine if the robot has finished the route.
Estimated length of remaining route.
ID of the command this feedback corresponds to.
The most recent transform describing the robot's pose relative to the navigation goal.
Indicates whether the robot's body is currently in motion.
Path following mode
Map of Region IDs with relevant information
Additional information about what kind of route the robot is following and why.
Additional information about whether or not the robot believes the current route to be blocked.
Only filled out if status is STATUS_STUCK to provide additional context.
Get the localization status and data.
The GetLocalizationState request message requests the current localization state and any other live data from the robot if desired. The localization consists of a waypoint ID and the relative pose of the robot with respect to that waypoint.
Common request header.
Return the localization relative to this waypoint, if specified.
If true, request the live edge-segmented point cloud that was used to generate this localization.
If true, request the live images from realsense cameras at the time of localization.
If true, request the live terrain maps at the time of localization.
If true, request the live world objects at the time of localization.
If true, requests the full live robot state at the time of localization.
If true, the smallest available encoding will be used for the live point cloud data. If false, three 32 bit floats will be used per point in the point cloud.
If true, request data about the robot's GPS localization.
The GetLocalizationState response message returns the current localization and robot state, as well as any requested live data information.
Common response header.
Where the robot currently is. If a waypoint_id was specified in the request, this localization will be relative to that waypoint.
Robot kinematic state at time of localization.
Status of one or more remote point cloud services (such as velodyne).
Contains live data at the time of localization, with elements only filled out if requested.
If the robot drives around without a good localization for a while, eventually it becomes "lost." I.E. it has a localization, but it no longer trusts that the localization it has is accurate. Lost detector state is available through this message.
If the robot has GPS capability and the map was recorded with GPS, this message will show graph nav's estimate of the robot location in earth-centered frames. To see the raw GPS data, look at the WorldObject list.
Clears the local graph structure. Also erases any snapshots currently in RAM.
Clears the graph on the server. Also clears GraphNav's localization to the graph. Note that waypoint and edge snapshots may still be cached on the server after this operation. This RPC may not be used while recording a map.
Common request header.
The Lease to show ownership of graph-nav service.
The results of the ClearGraphRequest.
Common response header.
Details about how the lease was used.
Status of the ClearGraphResponse.
Download the graph structure.
The DownloadGraph response message includes the current graph on the robot.
Common request header.
The structure of the graph.
This is a streaming version of the DownloadGraph RPC.
Streaming version of the DownloadGraphResponse.
Common response header.
Chunk of data to download. Responses are sent in sequence until the data chunk is complete. After receiving all chunks, concatenate them into a single byte string. Then, deserialize the byte string into a DownloadGraphResponse object.
Upload the full list of waypoint IDs, graph topology and other small info. Note: if multiple clients/RPCs are attempting to upload a graph at the same time, uploads will be performed synchronously in the order in which they are received, and the later UploadGraph request will block until the earlier completes.
Uploads a graph to the server. This graph will be appended to the graph that currently exists on the server.
Common request header.
Structure of the graph containing waypoints and edges without underlying sensor data.
The Lease to show ownership of graph-nav service.
If this is true, generate an (overwrite the) anchoring on upload.
If true, validation warnings will be treated as errors, and STATUS_INVALID_GRAPH will be returned. This is false by default.
This is a streaming version of UploadGraph to allow uploading larger graphs. Note: as with UploadWaypointSnapshot, this streaming process involves serializing a full UploadGraph message from chunks. After all the chunks have been uploaded, a regular UploadGraph RPC will be performed internally, so UploadGraphStreaming has the same semantics as UploadGraph when it completes. That is, UploadGraphStreaming is *not* to be used for incrementally uploading graph data as the robot is navigating -- this is merely a streaming wrapper around UploadGraph.
This is a streaming version of the UploadGraph request.
Common request header.
Serialized bytes of a UploadGraphRequest message, restricted to a chunk no larger than 4MB in size. To break the data into chunks, first serialize it to bytes. Then, send the bytes in order as DataChunk objects. The chunks will be concatenated together on the server, and deserialized.
Uploads large waypoint snapshot as a stream for a particular waypoint.
Used to upload waypoint snapshot in chunks for a specific waypoint snapshot. Waypoint snapshots consist of the large sensor data at each waypoint. Chunks will be streamed one at a time to the server. Chunk streaming is required to prevent overwhelming gRPC with large http requests.
Common response header.
Serialized bytes of a WaypointSnapshot message, restricted to a chunk no larger than 4MB in size. To break the data into chunks, first serialize it to bytes. Then, send the bytes in order as DataChunk objects. The chunks will be concatenated together on the server, and deserialized.
The Leases to show ownership of the graph-nav service.
One response for the entire WaypointSnapshot after all chunks have been concatenated and deserialized.
Common response header.
Details about how the lease was used.
General map statistics after upload.
Uploads large edge snapshot as a stream for a particular edge.
Used to upload edge data in chunks for a specific edge snapshot. Edge snapshots contain large sensor data associated with each edge. Chunks will be streamed one at a time to the server. Chunk streaming is required to prevent overwhelming gRPC with large http requests.
Common response header.
Serialized bytes of a EdgeSnapshot message, restricted to a chunk no larger than 4MB in size. To break the data into chunks, first serialize it to bytes. Then, send the bytes in order as DataChunk objects. The chunks will be concatenated together on the server, and deserialized
The Leases to show ownership of the graph-nav service.
One response for the entire EdgeSnapshot after all chunks have been concatenated and deserialized.
Common response header.
Details about how the lease was used.
General map statistics after upload.
Download waypoint data from the server. If the snapshot exists in disk cache, it will be loaded.
The DownloadWaypointSnapshot request asks for a specific waypoint snapshot id to be downloaded and has parameters to decrease the amount of data downloaded. After recording a map, first call the DownloadGraph RPC. Then, for each waypoint snapshot id, request the waypoint snapshot from the server using the DownloadWaypointSnapshot RPC.
Common request header.
ID of the snapshot associated with a waypoint.
If true, download the full images and point clouds from each camera.
If true, the point cloud will be compressed using the smallest available point cloud encoding. If false, three 32-bit floats will be used per point.
Skip downloading the point cloud, and only download other data such as images or world objects.
The DownloadWaypointSnapshot response streams the data of the waypoint snapshot id currently being downloaded in data chunks no larger than 4MB in size. It is necessary to stream these data to avoid overwhelming gRPC with large http requests.
Common response header.
Return status for the request.
ID of the snapshot associated with a waypoint.
Chunk of data to download. Responses are sent in sequence until the data chunk is complete. After receiving all chunks, concatenate them into a single byte string. Then, deserialize the byte string into a WaypointSnapshot object.
Download edge data from the server. If the snapshot exists in disk cache, it will be loaded.
The DownloadEdgeSnapshot request asks for a specific edge snapshot id to be downloaded. Edge snapshots contain the large sensor data stored in each edge.
Common request header.
ID of the data associated with an edge.
The DownloadEdgeSnapshot response streams the data of the edge snapshot id currently being downloaded in data chunks no larger than 4MB in size. It is necessary to stream these data to avoid overwhelming gRPC with large http requests.
Common response header.
Return status for the request.
ID of the snapshot associated with an edge.
Chunk of data to download. Responses are sent in sequence until the data chunk is complete. After receiving all chunks, concatenate them into a single byte string. Then, deserialize the byte string into an EdgeSnapshot object.
Verify that the graph is still valid and all required external services are still available. A map that was valid at upload time may not still be valid if required services are no longer running.
Run a check on the currently loaded map.
Report possible errors with the loaded map.
Status of the currently loaded map.
Errors about Area Callbacks in the map.
Defines services for processing an existing GraphNav map.
Processes a GraphNav map by creating additional edges or waypoints. After processing, a new subgraph is created containing additional waypoints or edges to add to the map.
Processes a GraphNav map by creating additional edges. After processing, a new subgraph is created containing additional edges to add to the map. Edges are created between waypoints that are near each other. These waypoint pairs are called "loop closures", and are found by different means. In general, if parameters are not provided, reasonable defaults will be used. Note that this can be used to merge disconnected subgraphs from multiple recording sessions so long as they share fiducial observations.
Standard message header.
Parameters. If not filled out, reasonable defaults will be used.
If true, any processing should directly modify the map on the server. Otherwise, the client is expected to upload the processing results (newly created edges) back to the server. The processing service shares memory with a map container service (e.g the GraphNav service).
Result of the topology processing RPC. If successful, contains a subgraph of new waypoints or edges created by this process.
Standard message header.
Result of the processing.
This graph contains the new edge(s) created by map processing. Note that these edges will be annotated with their creation method. Note that several subgraphs may be returned via streaming as the map is processed.
If modify_map_on_server was set to true in the request, then the map currently on the server was modified using map processing. If this is set to false, then either an error occurred during processing, or modify_map_on_server was set to false in the request. When map_on_server_was_modified is set to false, the client is expected to upload the results back to the server to commit the changes.
When there are missing waypoint snapshots, these are the IDs of the missing snapshots. Upload them to continue.
When there are missing waypoints, these are the IDs of the missing waypoints. Upload them to continue.
If true, the processing timed out. Note that this is not considered an error. Run topology processing again to continue adding edges.
Processes a GraphNav map by modifying the anchoring of waypoints and world objects in the map with respect to a seed frame. After processing, a new anchoring is streamed back.
Causes the server to optimize an existing anchoring, or generate a new anchoring for the map using the given parameters. In general, if parameters are not provided, reasonable defaults will be used. The new anchoring will be streamed back to the client, or modified on the server if desired.
Standard request header.
Initial guess at some number of waypoints and world objects and their anchorings.
If true, the map currently uploaded to the server will have its anchoring modified. Otherwise, the user is expected to re-upload the anchoring.
If true, the anchoring will be streamed back to the user after every iteration. This is useful for debug visualization.
If true, the GPSSettings inside waypoint annotations will be modified based on the optimization. Every waypoint will have waypoint.gps_settings set, with ecef_tform_waypoint applied form this optimization. To get these results, call the DownloadGraph RPC. Alternatively, the ecef_tform_waypoint can be found using: response.gps_result.ecef_tform_seed * seed_tform_waypoint[waypoint_id]. Note that after this operation completes successfully, all waypoints in the graph can be used to navigate using GPS, even if they didn't have GPS data in their waypoint snapshots.
Streamed response from the ProcessAnchoringRequest. These will be streamed until optimization is complete. New anchorings will be streamed as they become available.
Contains new anchorings for waypoint(s) processed by the server. These will be streamed back to the user as they become available.
Contains new anchorings for object(s) (e.g april tags) processed by the server. These will be streamed back to the user as they become available
If modify_anchoring_on_server was set to true in the request, then the anchoring currently on the server was modified using map processing. If this is set to false, then either an error occurred during processing, or modify_anchoring_on_server was set to false in the request. When anchoring_on_server_was_modified is set to false, the client is expected to upload the results back to the server to commit the changes.
The current optimizer iteration that produced these data.
The current nonlinear optimization cost.
If true, this is the result of the final iteration of optimization. This will always be true when stream_intermediate_results in the request is false.
On failure due to constraint violation, these hints were violated by the optimization. Try increasing the pose bounds on the constraints of these hints.
On failure due to constraint violation, these hints were violated by the optimization. Try increasing the pose bounds on the constraints of these hints.
When there are missing waypoint snapshots, these are the IDs of the missing snapshots. Upload them to continue.
When there are missing waypoints, these are the IDs of the missing waypoints. Upload them to continue.
Unorganized list of waypoints and object IDs which were invalid (missing from the map).
List of edges that are inconsistent with the optimized result. This can happen when incorrect loop closures have been made before optimization, when inconsistent anchoring hints were passed in, or because the optimizer ended up in a local minimum.
If GPS embedding optimization was enabled, this is the result of that process.
This associates a waypoint with a common reference frame, which is not necessarily metric.
Used in:
, ,Identifier of the waypoint.
Pose of the waypoint in the seed frame.
Controls how certain the user is of an anchor's pose. If left empty, a reasonable default will be chosen.
Used in:
,A full 6x6 Gaussian covariance matrix representing uncertainty of an anchoring.
Represents the 95 percent confidence interval on individual axes. This will be converted to a SE3Covariance internally by creating a diagonal matrix whose elements are informed by the confidence bounds.
This associates a world object with a common reference frame, which is not necessarily metric.
Used in:
, ,Identifier of the world object.
Pose of the object in the seed frame.
Used in:
The waypoint ids for the graph, expressed in a common reference frame, which is not necessarily metric. If there is no anchoring, this is empty.
World objects, located in the common reference frame.
The user may assign a number of world objects and waypoints a guess at where they are in the seed frame. These hints will be respected by the ProcessAnchoringRequest.
Used in:
List of waypoints and hints as to where they are in the seed frame.
List of world objects and hints as to where they are in the seed frame.
Indicator of whether or not the waypoint and edge annotations are complete and filled out.
Used in:
, ,No assertions made about this annotation.
This annotation and all of its fields have been deliberately set.
This annotation has been deliberately set to "no annotation" -- any subfields are unset.
Data for a AreaCallback to be stored in the map
Used in:
, ,Custom config data used by the service to do its job.
Deprecated in 4.1, use param_collection instead so that the parameter specs are available for building editors. Any other custom parameters to the callback. This will be copied into custom_params inside the BeginCallback RPC if it exists.
Any other custom parameters to the callback. This will be copied into custom_params inside the BeginCallback RPC if it exists.
Configuration data for how this area callback should be treated in the map.
Error reporting for things that can go wrong with calls.
Used in:
If error is ERROR_RESPONSE, the response will be included here.
Used in:
Unable to communicate with the callback.
The callback responded with an error.
The service was not registered.
Specific information about how a AreaCallback implementation should be called. All fields are optional, and need only be filled out if the desired behavior is different from the default.
Used in:
A area callback can request to be in control of one or more resources at runtime.
Parameters this area callback supports that do not match any of the other fields.
How the robot should stop at waypoints by default.
Configuration to store in the map about how to treat the region edges.
Specify what graph nav should expect to detect for blockages in this region. For example, if the callback can open doors, the region may initially look blocked due to a closed door, but Graph Nav should still expect it to be traversable.
Used in:
(Default) The region may appear blocked to Graph Nav, but the callback will still be able to traverse it. If the region is blocked, Graph Nav should consider it passable unless it actually gets stuck trying to navigate it.
Graph Nav should expect the region to be clear. If the region is blocked, Graph Nav can treat that as impassable.
Control whether Graph Nav will stop and wait for nearby entities when crossing the region. Entity waiting is normally on for regular Graph Nav, but is by default turned off inside Area callback regions.
Used in:
(Default) Disable waiting for entities when crossing the region.
Enable waiting for entities when crossing the region.
Specify whether graph nav should check for impairment when the callback is in control of the robot. Certain failures may make Graph Nav unable to navigate, but may not affect the callback. If the callback is in control of the robot, it may be preferable to let it finish and return control to Graph Nav before reporting any impaired error instead of interrupting the callback.
Used in:
(Default) Do not check Graph Nav impairment when the callback is in control.
Continue to check Graph Nav impairment when the callback is in control. If Graph Nav detects that it is impaired, it will stop the callback immediately.
Configuration data for how an area callback should be treated in a map.
Used in:
,(message has no fields)
Data for a AreaCallback in the annotation.
Used in:
This service must be used in a given region to safely traverse it.
Human-readable description of this region.
Configuration data associated with this area callback.
Information about problems Area Callback services specified in a map or on a route.
Used in:
, , , ,Area Callback services that were requested but could not be contacted by graph nav. A service is considered missing if it is either not registered, or if it is registered but does not respond to a AreaCallbackInformation request.
Area Callback services that were requested but are reporting critical faults.
Used as response type in: AreaCallbackService.BeginCallback
Used as field type in:
Common response header.
Return status for the request.
Unique identifier for the AreaCallback, used to update the callback in subsequent calls. If empty, the request was not accepted.
Filled out if status is STATUS_CUSTOM_PARAMS_ERROR.
Used in:
UNKNOWN should never be used.
The area callback successfully began.
The area callback failed to start due to some problem with the supplied configuration_data.
The area callback end time already expired.
One or more keys or values in custom_params are unsupported by the area callback. See the custom_param_error for details.
Used as response type in: AreaCallbackService.BeginControl
Used as field type in:
Common response header.
Details about how the lease was used.
Return status for the request.
Used in:
UNKNOWN should never be used.
The AreaCallback has successfully taken control of the robot.
The request command id does not exist or is no longer executing.
The supplied lease does not match the leases requested in AreaCallbackInformation.
A lease use error occurred.
Used in:
Graph Nav is currently recording a map. You must call StopRecording from the recording service to continue.
Optional metadata to attach to waypoints that are being recorded.
Used in:
User-provided name for this recording "session". For example, the user may start and stop recording at various times and assign a name to a region that is being recorded. Usually, this will just be the map name.
If the application recording the map has a special user name, this is the name of that user.
Version string of any client software that generated this object.
Identifier of any client software that generated this object.
Special tag for the client software which created this object. For example, "Tablet", "Scout", "Python SDK", etc.
Information about the route that a robot has followed during a command.
Used in:
List of waypoints reached in the order they were reached.
Information about the completed edges, in the order they were completed.
Used in:
If true, this edge was specially constructed to bypass a blockage, and does not exist in the map.
Used in:
Status is unknown/unset.
The edge was successfully created.
Edge already exists with the given ID.
Clients can only create edges when recording.
One or more of the specified waypoints aren't in the map.
Specified edge did not include a transform.
Used in:
Status is unknown/unset.
The waypoint was successfully created.
Clients can only create waypoints when recording.
An internal server error prevented the creation of the waypoint.
Could not see the required fiducials.
The map was too big to create a waypoint based on the license.
A required remote cloud did not exist in the service directory.
A required remote cloud did not have data.
All fiducials are visible but their pose could not be determined accurately.
A 3D direction with a covariance estimate.
Used in:
The vector is to be interpreted as a 3D normalized direction in a frame.
2x2 covariance matrix representing uncertainty in the direction (in a local tangent frame).
Used in:
Error where the given snapshot ID does not exist.
The DownloadGraphRequest requests that the server send the graph (waypoints and edges) to the client. Note that the returned Graph message contains only the topological structure of the map, and not any large sensor data. Large sensor data should be downloaded using DownloadWaypointSnapshotRequest and DownloadEdgeSnapshotRequest. Both snapshots and the graph are required to exist on the server for GraphNav to localize and navigate.
Used as request type in: GraphNavService.DownloadGraph, GraphNavService.DownloadGraphStreaming
Common request header.
Used in:
Error where the given snapshot ID does not exist.
A base element of the graph nav map. Edges consist of a directed edge from one waypoint to another and a transform that estimates the relationship in 3D space between the two waypoints.
Used in:
, , ,Identifier of this Edge. Edges are mutable -- the identifier does not have to be updated when other fields change.
Identifier of this edge's Snapshot data.
Describes the transform between the "from" waypoint and the "to" waypoint.
Annotations specific to the current edge.
Annotations understood by BostonDynamics systems.
Used in:
,Stairs information/parameters specific to the edge.
Direction constraints for how the robot must move and the directions it can face when traversing the edge.
If true, the robot must be aligned with the edge in yaw before traversing it.
If true, the edge crosses flat ground and the robot shouldn't try to climb over obstacles. DEPRECATED as of 3.3. Replaced by ground_clutter_mode. As of 4.1, no longer functional.
Overrides the following fields of the mobility parameters to whatever is stored in the map. For example, if this FieldMask contains "stairs_mode" and "terrain_params.enable_grated_floor", then the map will be annotated with "stairs_mode" and "enable_grated_floor" settings. An empty FieldMask means all fields are active annotations. Note that the more conservative of the velocity limit stored in the mobility parameters and the TravelParams of the entire route will be used for this edge (regardless of what override_mobility_params says).
Contains terrain parameters, swing height, obstacle avoidance parameters, etc. When the robot crosses this edge, it will use the mobility parameters here.
Assign edges a cost; used when finding the "shortest" (lowest cost) path.
How this edge was made.
If true, disables alternate-route-finding for this edge.
Path following mode for this edge.
Max distance from the recorded edge that the robot is allowed to travel when avoiding obstacles or optimized its path. This is half of the full width of the corridor the robot may walk within. If this value is not set, the robot will choose a default corridor width.
Disable directed exploration for this edge.
Reference to area callback regions needed to cross this edge. The string is a unique id for this region, which may be shared across multiple edges.
Used in:
We don't know if there are direction constraints.
The robot must not turn while walking the edge, but can face either waypoint.
Robot should walk the edge face-first.
Robot should walk the edge rear-first.
No constraints on which way the robot faces.
Ground clutter avoidance mode. This enables detection and avoidance of low obstacles.
Used in:
, ,The mode is unset.
The mode is explicitly off.
Enable detection of ground clutter using recorded footfalls. Objects that were not stepped on during map recording are obstacles.
Path following mode
Used in:
, , ,Unknown value
Use default path following parameters
Use strict path following parameters
Defines any parameters of the stairs
Used in:
Check this before reading other fields.
Parameters describing a straight staircase. DEPRECATED as of 3.3. Please use staircase_with_landings.
Parameters describing an arbitrary staircase.
The Y position with respect to the staircase frame to align to when traversing this staircase. Regardless of how the recorded waypoints are distributed on the staircase, when traversing the staircase all navigation goals will have this Y position with respect to the staircase in order to guide the robot over the stairs in a straight line.
Used in:
Unknown value, default to DESCENT_PREFERENCE_ALWAYS_REVERSE.
Robot will prefer to descend in reverse, but may descend forwards if the route could not otherwise be executed. This could be due to conflicting constraints created by an annotation or by another staircase.
Robot will always attempt to descend stairs in reverse, even if it causes navigation to fail.
Robot may descend in any order. The exact order it chooses will be decided by the lowest cost path found by the local trajectory optimizer and adjacent constraints, if they exist. NOTE: If a staircase which is difficult for the robot to descend in the forward direction is marked with this option, it may cause the robot to fall.
Used in:
Edges with transforms from odometry.
Edges with transforms from a short chain of other edges.
Edges with transforms from multiple fiducial observations.
Edges that may help find alternate routes.
Created via a CreateEdge RPC.
Created when we start recording after recording has been paused. For example, an "extension" of a graph will start with an edge of type EDGE_SOURCE_LOCALIZATION.
An edge is uniquely identified by the waypoints it connects. Two waypoints will only ever be connected by a single edge. That edge is traversable in either direction.
Used in:
, , , , ,Identifier of the "from" waypoint.
Identifier of the "to" waypoint.
Relevant data collected along the edge. May be used for automatically generating annotations, for example.
Identifier of this snapshot. Snapshots are immutable -- if any of the other fields change, this ID must also change.
Sampling of stances as robot traversed this edge.
Data used by area callback services to perform their action.
Used in:
Timestamp of the stance.
List of all the foot positions for a single stance.
KO Body position corresponding to this stance.
Vision Body position corresponding to this stance.
Does this stance correspond to a planar ground region.
Used as response type in: AreaCallbackService.EndCallback
Used as field type in:
Common response header.
Return status for the request.
Used in:
UNKNOWN should never be used.
The AreaCallback has cleanly ended.
The request command id does not exist or is no longer executing.
Shutting down the callback failed. The callback worker thread did not respond to shutdown signal.
Info about GPS localization if the robot has this capability.
Used in:
State of the live GPS data.
State of GPS data at the current waypoint.
Estimate of where the robot body is in the Earth-Centered-Earth-Fixed (ECEF) frame at the time of localization.
Estimate of the latitude/longitude/height of the robot at the time of localization.
Used in:
Using GPS.
Error getting frames (ko, etc.)
No GPS available.
GPS registration isn't ready.
No GPS state measurements.
Too few satellites to localize.
GPS registration is missing a frame.
The GPS data exists, but is high error.
The GPS data exists, and we have not used it yet, but it is too old to use.
Internal error (e.g. missing waypoints).
Parameters controlling how the robot will navigate to a GPS coordinate.
Used in:
The goal position as latitude/longitude. Height is ignored.
Counter-clockwise rotation in radians around the "up" axis that the robot will try to achieve at the goal. This is a bearing around the "up" axis such that East points to zero yaw, and West is pi radians yaw. If not provided, the robot will try to achieve any allowable orientation at the goal.
The maximum distance we are willing to accept for the LLH coordinate from the mapped data in meters. This is a 2 dimensional measurement (height is not considered). If not filled out, Spot will decide based on internal defaults.
Generic sparse visual descriptor with a byte blob and a descriptor name.
Used in:
Name of the descriptor which identifies how it is to be interpreted.
Binary blob representing the descriptor.
Used in:
Successfully started recording.
Unable to continue recording because a larger map requires an upgraded license.
Used in:
Unable to record waypoints because the robot is impaired. When this happens, the system will not create new waypoints until the robot is no longer impaired. See impaired_state for more details.
This is an arbitrary collection of waypoints and edges. The edges and waypoints are not required to be connected. A waypoint may belong to multiple graphs. This message is used to pass around information about a graph's topology, and is used to serialize map topology to and from files. Note that the graph does not contain any of the waypoint/edge data (which is found in snapshots). Snapshots are stored separately.
Used in:
, ,The waypoints for the graph (containing frames, annotations, and sensor data).
The edges connecting the graph's waypoints.
The anchoring (mapping from waypoints to their pose in a shared reference frame).
Indexes an observation of a landmark at a particular bundle, keyframe and keypoint. Waypoint snapshots have bundles of keyframes, each keyframe has a number of extracted keypoints. Observations are structured as: bundle_0 ... bundle_1 .... keyframe_0 .... keyframe_1 ........ keypoint_0 ........ keypoint_1 ........ ... ........ keypoint_J .... ... .... keyframe_K ... bundle_N
Used in:
The bundle from within the waypoint snapshot that this landmark observation came from.
The keyframe from within the bundle that this observation came from.
The keypoint within the keyframe that this observation came from.
Time of the camera image which observed this landmark.
The localization state of the robot. This reports the pose of the robot relative to a particular waypoint on the graph nav map.
Used in:
, , ,Waypoint this localization is relative to.
Pose of body in waypoint frame.
Pose of body in a common reference frame. The common reference frame defaults to the starting fiducial frame, but can be changed. See Anchoring for more info.
Time (in robot time basis) that this localization was valid.
Message describing whether or not graph nav is lost, and if it is lost, how lost it is. If robot is lost, this state can be reset by either: * Driving to an area where the robot's localization improves. * Calling SetLocalization RPC.
Used in:
Whether or not the robot is currently lost. If this is true, graph nav will reject NavigateTo or NavigateRoute RPCs.
The lost detector either accepts or rejects localizations based on a scoring criteria. This is the total number of localizations that have been accepted since the last SetLocalization RPC.
This is the total number of localizations that have been rejected since the last SetLocalization RPC.
This is the total number of localizations that have been rejected by the lost detector since either a localization was accepted, or a SetLocalization RPC.
This is the number of meters (3d translation of the robot body) the lost detector believes the robot to have traveled since it had a rejected localization.
This is the most recent localization the lost detector accepted.
This is the most recent localization that the lost detector rejected.
The number of edges the LostDetector believes the robot has crossed without first getting an accepted localization.
Parameters the lost detector is using.
Parameters for the lost detector which control when it determines that we are lost. In general, when we start seeing "bad" localizations, (based on sensor data and map data agreement) we start counting the amount of time and distance the robot has traveled before we see a "good" localization. If this distance exceeds a threshold, we then start counting the number of edges that the robot has crossed with a "bad" localization. Once a number of edges crosses a threshold, we then declare the robot lost. Note that these thresholds are hierarchical; so we first start counting time, then distance, then number of edges.
Used in:
Maximum time (seconds) that the robot can walk with a bad localization before we start counting distance/edges with bad localization.
The maximum distance the robot can walk (m) with a bad localization before we start counting the number of edges with bad localization.
The maximum number of edges the robot can walk with a bad localization before we declare the robot to be lost.
Determines how "strict" the lost detector is about declaring lost. This value is used to set the other thresholds.
Determines how "strict" the lost detector is about declaring lost.
Used in:
, ,Unset (defaults to STRICTNESS_DEFAULT).
Never declares lost.
Declares lost less readily than default.
Default lost detector strictness.
Declares lost more readily than default.
General statistics on the map that is loaded into GraphNav on the robot, including information on the graph topology and snapshot data.
Used in:
, , , , , , ,Waypoints (including alternate route finding waypoints).
Waypoint snapshots.
The alternate route finding waypoints (used for alternate path planning).
Edges (including alternate route finding edges).
Edge snapshots.
Alternate edges (used for alternate path planning).
Anchors for waypoints. (For computing anchorings to fixed reference frames).
Anchors for world objects (fiducials).
The total distance travelled along recorded edges by the robot in the loaded map.
Statistics from a particular type of object stored in the GraphNav map.
Used in:
The number of elements.
Lower bound on the number of bytes allocated for these elements on RAM inside the GraphNav server.
Results of using the various leases.
Status code specific to the ModifyNavigationResponse.
Used in:
Modify request was accepted.
The command ID wasn't the ID of the last command.
Used in:
An unknown / unexpected error occurred.
Request was accepted.
[Time Error] Client has not done timesync with robot.
[Time Error] The command was received after its end time had already passed.
[Time Error] The command end time was too far in the future.
[Robot State Error] Cannot navigate a route if the robot has a critical perception fault, or behavior fault, or LIDAR not working.
[Robot State Error] Cannot navigate a route while recording a map.
[Route Error] One or more waypoints/edges are not in the map.
[Route Error] One or more edges do not connect to expected waypoints.
[Route Error] There is no path to the specified route.
[Route Error] Route contained a constraint fault.
[Route Error] Route contained too many waypoints with low-quality features.
[Route Error] Happens when you try to issue a navigate route while the robot is lost.
[Route Error] Happens when the current localization doesn't refer to any waypoint in the route (possibly uninitialized localization).
[Route Error] Happens when the current localization doesn't refer to any waypoint in the map (possibly uninitialized localization).
[Wrestling Errors] Happens when graph nav refuses to follow the route you specified. Try saying please?
[Route Error] Happens when you try to issue a navigate to while the robot is stuck. Navigate a different route, or clear the route and try again.
[Request Error] Happens when you try to continue a command that was either expired, or had an unrecognized id.
[Route Error] Happens when you try to navigate along a route and a needed callback is no longer available.
The result of the GPS command, if relevant.
Used in:
An unknown/unexpected error occurred.
The GPS command was valid and can be executed.
The GPS command could not be completed because the map does not have GPS coordinates, neither in waypoint annotations nor in the waypoint snapshot data. Please record the map using a GPS-enabled robot, or annotate the waypoints with custom GPS coordinates.
The GPS command could not be completed because the coordinates passed in were too far from any mapped GPS data.
Used in:
An unknown / unexpected error occurred.
Request was accepted.
[Time error] Client has not done timesync with robot.
[Time error] The command was received after its end time had already passed.
[Time error]The command end time was too far in the future.
[Robot State Error] Cannot navigate a route if the robot has a critical perception fault, or behavior fault, or LIDAR not working.
[Robot State Error] Cannot navigate a route while recording a map.
[Route Error] There is no anchoring.
[Route Error] There is no path to a waypoint near the specified goal. If any waypoints were found (but no path), the error_waypoint_ids field will be filled.
[Route Error] Route contained too many waypoints with low-quality features.
[Route Error] Happens when you try to issue a navigate to while the robot is lost.
[Route Error] Happens when the current localization doesn't refer to any waypoint in the map (possibly uninitialized localization).
[Wrestling error] Happens when graph nav refuses to follow the route you specified.
[Route Error] Happens when you try to issue a navigate to while the robot is stuck. Navigate to a different waypoint, or clear the route and try again.
[Request Error] Happens when you try to continue a command that was either expired, or had an unrecognized id.
[Route Error] The pose is invalid, or known to be unachievable (upside-down, etc).
[Route Error] Happens when you try to navigate along a route and a needed callback is no longer available.
[Route Error] The command contained an invalid GPS request. See gps_status for more details.
Used in:
An unknown / unexpected error occurred.
Request was accepted.
[Time error] Client has not done timesync with robot.
[Time error] The command was received after its end time had already passed.
[Time error]The command end time was too far in the future.
[Robot State Error] Cannot navigate a route if the robot has a critical perception fault, or behavior fault, or LIDAR not working.
[Robot State Error] Cannot navigate a route while recording a map.
[Route Error] One or more of the waypoints specified weren't in the map.
[Route Error] There is no path to the specified waypoint.
[Route Error] Route contained too many waypoints with low-quality features.
[Route Error] Happens when you try to issue a navigate to while the robot is lost.
[Route Error] Happens when the current localization doesn't refer to any waypoint in the map (possibly uninitialized localization).
[Wrestling error] Happens when graph nav refuses to follow the route you specified.
[Route Error] Happens when you try to issue a navigate to while the robot is stuck. Navigate to a different waypoint, or clear the route and try again.
[Request Error] Happens when you try to continue a command that was either expired, or had an unrecognized id.
[Route Error] Happens when you try to navigate along a route and a needed callback is no longer available.
Data for a Area Callback region
Used in:
human readable name for the region
service name for the Area Callback region
Status of the Area Callback region
Used in:
The robot is navigating the Area Callback region
The robot is waiting for assistance to navigate through the Area Callback region
The Area Callback service is in control of the robot
Indicates whether the robot thinks its current path is blocked by an obstacle. This will be set when Status is STATUS_FOLLOWING_ROUTE, or STATUS_STUCK, and will be BLOCKAGE_STATUS_UNKNOWN in all other cases.
Used in:
The robot believes the path forward to be clear of obstacles.
The robot believes there is an obstacle in the path which it can't get around easily. It will attempt to get around the obstacle, and if all else fails it will declare itself stuck.
The robot has given up trying to get around perceived obstacles in the path and has declared itself stuck. This will only ever be set when Status is STATUS_STUCK.
When the robot is following a route (and Status is STATUS_FOLLOWING_ROUTE), this gives additional detail about what the robot is doing to follow that route. When Status is not STATUS_FOLLOWING_ROUTE, this will be set to ROUTE_FOLLOWING_STATUS_UNKNOWN.
Used in:
The robot is following the nominal path to the goal, either from a request or from internal path planning.
The robot is trying to get back to the nominal path to the goal, either because it was not on the nominal path originally, or because it was moved away from the path.
The robot is taking a different path through the map via edges/waypoints to get around a perceived obstacle. This might take it through a different part of the building.
The robot is walking to a different, nearby part of the map to find a path around a perceived blockage.
Used in:
An unknown / unexpected error occurred.
The robot is currently, successfully following the route.
The robot has reached the final goal of the navigation request.
There's no route currently being navigated. This can happen if no command has been issued, or if the graph has been changed during navigation.
Robot is not localized to a route.
Robot appears to be lost.
Robot appears stuck and unable to make progress, but can still navigate to other destinations. stuck_reason provides more details on the reason that caused the robot to become stuck.
The command expired.
Cannot navigate a route if the robot has a critical perception fault, or behavior fault, or LIDAR not working. See impaired_status for details.
The route constraints were not feasible.
The command was replaced by a new command
The localization or route changed mid-traverse.
The lease is no longer valid.
An error occurred with an Area Callback in a way that graph nav was unable to recover from. Navigating to another location may also fail. Lease errors will be reported via STATUS_LEASE_ERROR instead.
If status is STATUS_STUCK, this enum provides reasons differentiating various cases that can cause the robot to re
Used in:
The robot failed to find a way past an obstacle.
An area callback reported that it is blocked.
An area callback failed, but in a way that the robot is still able to navigate to other locations.
The robot has seen the goal and perceived that there is no pose it can navigate to to reach the goal. There is no value in rerouting.
Represents an interval in x, y, z and yaw around some center. Some value x will be within the bounds if center - x_bounds <= x >= center + x_bounds. If the values are left at zero, the bounds are considered to be unconstrained. The center of the bounds is left implicit, and should be whatever this message is packaged with.
Used in:
, ,Bounds on the x position in meters.
Bounds on the y position in meters.
Bounds on the z position in meters.
Bounds on the yaw (rotation around z axis) in radians.
A 3D position with a covariance estimate.
Used in:
The vector is to be interpreted as a 3D position in a frame.
3x3 covariance matrix representing uncertainty in the position.
Parameters for processing an anchoring.
Used in:
If true, the anchoring which already exists on the server will be used as the initial guess for the optimizer. Otherwise, a new anchoring will be generated for every waypoint which doesn't have a value passed in through initial_hint. If no hint is provided, and this value is false, every waypoint will be given a starting anchoring based on the oldest waypoint in the map.
The optimizer will try to keep the orientation of waypoints consistent with gravity. If provided, this is the gravity direction expressed with respect to the seed. This will be interpreted as a unit vector. If not filled out, a default of (0, 0, -1) will be used.
Parameters which affect the measurements the optimizer uses to process the anchoring.
Used in:
If true, waypoints which share the same kinematic odometry frame will be constrained to one another using it.
If true, waypoints which share the same visual odometry frame will be constrained to one another using it.
If true, waypoints will be constrained so that the apparent pose of the robot w.r.t the waypoint at the time of recording is consistent with gravity.
If true, edges which were created by topology processing via loop closures will be used as constraints.
If true, world object measurements will be used to constrain waypoints to one another when those waypoints co-observe the same world object.
If true, GPS measurements stored in waypoint snapshots will be used to help constrain the anchoring.
Parameters affecting the underlying optimizer.
Used in:
Maximum iterations of the optimizer to run.
Maximum time the optimizer is allowed to run before giving up.
Relative weights to use for each of the optimizer's terms. These can be any positive value. If set to zero, a reasonable default will be used. In general, the higher the weight, the more the optimizer will care about that particular measurement.
Used in:
Used in:
Overall status of the GPS embedding optimization.
Pose of the "seed" frame of this optimization in the Earth-Centered-Earth-Fixed (ECEF) frame. This can be used to estimate the pose of every waypoint in the ECEF frame via: ecef_tform_waypoint = ecef_tform_seed * anchoring.waypoints[waypoint_id].seed_tform_waypoint
This is the number of GPS measurements actually used to compute the GPS embedding.
Status of the GPS embedding optimization.
Used in:
Managed to find an ECEF transform.
Not enough high quality GPS measurements in the map.
Used in:
Programming error.
Success.
Not all of the waypoint snapshots exist on the server. Upload them to continue.
The graph is invalid topologically, for example containing
missing waypoints referenced by edges.
The optimization failed due to local minima or an
ill-conditioned problem definition.
The parameters passed to the optimizer do not make sense (e.g negative weights).
One or more anchors were moved outside of the desired constraints.
The optimizer reached the maximum number of iterations before converging.
The optimizer timed out before converging.
One or more of the hints passed in to the optimizer are
invalid (do not correspond to real waypoints or objects).
Tried to write the anchoring after processing, but another client may have
modified the map. Try again.
An anchor hint (waypoint or fiducial) had an
Parameters for how to check for collisions when creating loop closures. The system will avoid creating edges in the map that the robot cannot actually traverse due to the presence of nearby obstacles.
Used in:
By default, this is true.
Assume that the robot is a sphere with this radius. Only accept a loop closure if this spherical robot can travel in a straight line from one waypoint to the other without hitting obstacles.
Consider significant height variations along the edge (like stairs or ramps) to be obstacles. The edge will not be created if there is a height change along it of more than this value according to the nearby sensor data.
Parameters to control point cloud sparse feature matching.
Used in:
If true, feature matching will be performed. If both ICP and Feature matching are used, feature matching will be performed first for a coarse alignment, followed by ICP for a local refinement.
Parameters for how to close a loop using fiducials (AprilTags). This infers which waypoints should be connected to one another based on shared observations of AprilTags. Note that multiple disconnected subgraphs (for example from multiple recording sessions) can be merged this way.
Used in:
The minimum distance between waypoints found by walking a path from one waypoint to the other using only the existing edges in the map. Set this higher to avoid creating small shortcuts along the existing path. Note that this is a 2d path length.
Once a loop closure candidate is found, the system creates an edge between the candidate waypoints. Only create the edge if it is shorter than this value. Note that this is a 3d edge length.
Maximum distance to accept between a waypoint and a fiducial detection to use that fiducial detection for generating loop closure candidates.
The maximum apparent height change of the created edge that we are willing to accept between waypoints. This avoids closing loops up ramps, stairs, etc. or closing loops where there is significant odometry drift.
If true, redundant edges will be ignored, and only the "best" in a small area will be selected (true by default).
Parameters for how to refine loop closure edges using iterative closest point matching. If both ICP and Feature matching are used, feature matching will be performed first for a coarse alignment, followed by ICP for a local refinement.
Used in:
The maximum number of iterations to run. Set to zero to skip ICP processing.
The maximum distance between points in the point cloud we are willing to accept for matches.
Parameters for how to close loops using odometry. This infers which waypoints should be connected to one another based on the odometry measurements in the map.
Used in:
The maximum distance between waypoints found by walking a path from one waypoint to the other using only the existing edges in the map. Beyond this distance, we are unwilling to trust odometry.
The minimum distance between waypoints found by walking a path from one waypoint to the other using only the existing edges in the map. Set this higher to avoid creating small shortcuts along the existing path. Note that this is a 2d path length.
The maximum apparent height change of the created edge that we are willing to accept between waypoints. This avoids closing loops up ramps, stairs, etc. or closing loops where there is significant odometry drift.
Once a loop closure candidate is found, the system creates an edge between the candidate waypoints. Only create the edge if it is shorter than this value. Note that this is a 3d edge length.
Use prior loop closures to infer new odometry based loop closures. This is useful when other sources of loop closures (like fiducials) are being used. The existence of those loop closures allows the system to infer other nearby loop closures using odometry. Alternatively, the user may call the ProcessTopology RPC multiple times to achieve the same effect.
If true, redundant edges will be ignored, and only the "best" in a small area will be selected (true by default).
Parameters which control topology processing. In general, anything which isn't filled out will be replaced by reasonable defaults.
Used in:
True by default -- generate loop closure candidates using odometry.
Parameters for generating loop closure candidates using odometry.
Parameters for refining loop closure candidates using iterative closest point cloud matching.
True by default -- generate loop closure candidates using fiducials.
Parameters for generating loop closure candidates using fiducials.
Parameters which control rejecting loop closure candidates which collide with obstacles.
Causes the processing to time out after this many seconds. If not set, a default of 45 seconds will be used. If this timeout occurs before the overall RPC timeout, a partial result will be returned with ProcessTopologyResponse.timed_out set to true. Processing can be continued by calling ProcessTopology again.
Controls whether and how the service performs sparse feature matching.
Used in:
Programming error.
Success.
Not all of the waypoint snapshots exist on the server. Upload them to continue.
The graph is invalid topologically, for example containing
missing waypoints referenced by edges.
Tried to write the anchoring after processing, but another client may have
The RecordingEnvironment is a set of annotation information and a name for the current environment that will persist for all edges and waypoints until it is changed or updated
Used in:
, , ,This will be prepended to the start of every waypoint name.
Persistent waypoint annotation that will be merged in to all waypoints in this recording.
Persistent edge annotation that will be merged in to all edges in this recording.
Defines a region in a map. Regions are shapes, commonly they are boxes. Many waypoints may share the same regions. Regions do not need to cover the waypoint itself. A common use for such regions is to define certain parts of the point cloud as being unreliable for localization. Note that this is a different concept than the LocalizeRegion, which is used to determine where the robot's body must be relative to the waypoint for it to localize -- the RegionWithFrame instead can be used to label data near the waypoint. *Regions and Reference Frames* -- regions are stored inside waypoint annotations as "RegionWithFrames". These consist of a region and a named reference frame relative to the waypoint (such as "odom" or "seed", or "waypoint" etc).
Used in:
Unique identifier of the region within a map. This will be used to deduplicate regions that many waypoints may reference. Note that the transform of the region is defined with respect to this waypoint's KO frame, so the same region may exist in several waypoints while having different transforms in each case. Regions with the same ID are not guaranteed to be unique. Graph Nav will use whatever regions exist in the current waypoint only, and will ignore all other regions; so if you want Graph Nav to use a region in multiple waypoints, you must duplicate the region into each waypoint in which it is to be used.
Oriented bounding box defining the region. The axes are defined relative to the "base frame" for this region. See RegionWithFrame for how this frame may be defined.
How (if at all) the region affects data filtering for scan matching.
Defines how scan match data is filtered near this waypoint. Data filters are logical set operators expressed on sets of data near the waypoint. Notes on interactions: If there are multiple regions marked as INCLUDE_ONLY, data that falls within any of these regions will be used, that is the operation of many DATA_FILTER_INCLUDE_ONLY regions is a logical set union. Conversely, DATA_FILTER_IGNORE operators override DATA_FILTER_INCLUDE_ONLY. For example, if there are 3 regions, A, B and C; and region A is marked as INCLUDE_ONLY, B is marked as INCLUDE_ONLY, and C is marked as IGNORE, the data that will be used for scan matching is: (A _u_ B) ~ C (that is, union(A, B) excluding C).
Used in:
Defaults to DATA_FILTER_NONE.
No special considerations for scan matching in this region.
No scan match data falling within this region will be used.
Only data from within this region will be used.
Description of an Area Callback region at the time of crossing
Used in:
The unique id of the region we are entering.
Human-readable description of the region we are entering.
The planned route through the region.
Flag that indicates that the robot is already inside the callback region at the beginning of the callback, rather than starting from the edge of the region as usual. This can happen in some cases when the robot gets stuck inside the region, and restarts with a new navigation command.
Defines a region and a transform near a specific waypoint. Regions will only be used if they are attached to waypoint annotations. Regions may be duplicated over many waypoints.
Used in:
The region attached to this waypoint.
Reference frame that the region's transform is defined with respect to. For example, "waypoint" for the waypoint's reference frame, or "odom" for the odometry frame at the time of waypoint recording.
Transform of the region in the base frame.
Message describing the state of a remote point cloud service (such as a velodyne).
Used in:
The name of the point cloud service.
Boolean indicating if the point cloud service was registered in the robot's directory with the provided name.
Boolean indicating if the point cloud service is currently outputting data.
Route that the robot should follow or is currently following.
Used in:
, , , , ,Ordered list of waypoints to traverse, starting from index 0.
Ordered list of edges to traverse between those waypoints.
Used in:
UNKNOWN should never be used.
The AreaCallback has acknowledged the route change.
The request command id does not exist or is no longer executing.
These parameters are specific to how the robot follows a specified route in NavigateRoute.
For each enum in this message, if UNKNOWN is passed in, we default to one of the values (indicated in the comments). Passing UNKNOWN is not considered a programming error.
Used in:
,This setting applies when a NavigateRoute command is issued with the same route and final-waypoint-offset. It is not necessary that command_id indicate the same command. The expected waypoint is the last waypoint that GraphNav was autonomously navigating to.
Used in:
The mode is unset.
The robot will find the shortest path to any point on the route after the furthest-along traversed edge, and go to the point that gives that shortest path. Then, the robot will follow the rest of the route from that point. This is the default.
The robot will fail the command with status STATUS_NOT_LOCALIZED_TO_ROUTE.
This setting applies when the robot discovers that the route is blocked.
Used in:
, ,The mode is unset.
For NavigateToRequests, the robot will find the shortest path to the destination that avoids the blockage. For NavigateRouteRequests, the robot will find the shortest path to any point after the furthest-along blockage, and after the furthest-along traversed edge, and go to the point that gives that shortest path. Then, the robot will follow the rest of the route from that point. If multiple points on the route are similarly close to the robot, the robot will prefer the earliest on the route. This is the default.
The robot will fail the command with status STATUS_STUCK;
This setting applies when a new NavigateRoute command is issued (different route or final-waypoint-offset), and command_id indicates a new command.
Used in:
The mode is unset.
The robot will find the shortest path to the start of the route, possibly using edges that are not in the route. After going to the start, the robot will follow the route.
The robot will find the shortest path to any point on the route, and go to the point that gives that shortest path. Then, the robot will follow the rest of the route from that point. If multiple points on the route are similarly close to the robot, the robot will prefer the earliest on the route. This is the default.
The robot will fail the command with status STATUS_NOT_LOCALIZED_TO_ROUTE.
Used in:
, ,(message has no fields)
Info on whether the robot's current sensor setup is compatible with the recorded data in the map.
Used in:
, , ,If true, the loaded map has LIDAR data in it.
If true, the robot is currently configured to use LIDAR data.
The SetLocalization request is used to initialize or reset the localization of GraphNav to a map. A localization consists of a waypoint ID, and a pose of the robot relative to that waypoint. GraphNav uses the localization to decide how to navigate through a map. The SetLocalizationRequest contains parameters to help find a correct localization. For example, AprilTags (fiducials) may be used to set the localization, or the caller can provide an explicit guess of the localization. Once the SetLocalizationRequest completes, the current localization to the map will be modified, and can be retrieved using a GetLocalizationStateRequest.
Used as request type in: GraphNavService.SetLocalization
Used as field type in:
,Common request header.
Operator-supplied guess at localization. In this localization message, only waypoint_id and waypoint_tform_body will be used. All other fields are ignored. If the message is not provided, the initial guess will be assumed to be the identity transform to whatever waypoint was requested for methods that require it. Use initial_guess.waypoint_id to restrict the SetLocalizationRequest to specific waypoints.
Robot pose when the initial_guess was made. This overcomes the race that occurs when the client is trying to initialize a moving robot. GraphNav will use its local ko_tform_body and this ko_tform_body to update the initial localization guess, if necessary.
The max distance [meters] is how far away the robot is allowed to localize from the position supplied in the initial guess. If not specified, the offset is used directly. Otherwise it searches a neighborhood of the given size.
The max yaw [radians] is how different the localized yaw is allowed to be from the supplied yaw in the initial guess. If not specified, the offset is used directly. Otherwise it searches a neighborhood of the given size.
Tells the initializer whether to use fiducials, and how to use them.
If using FIDUCIAL_INIT_SPECIFIC, this is the specific fiducial ID to use for initialization. If no detection of this fiducial exists, the service will return STATUS_NO_MATCHING_FIDUCIAL. If detections exist, but are low quality, STATUS_FIDUCIAL_TOO_FAR_AWAY, FIDUCIAL_TOO_OLD, or FIDUCIAL_POSE_UNCERTAIN will be returned.
If true, consider how nearby localizations appear (like turned 180).
If using FIDUCIAL_INIT_SPECIFIC and this is true, the initializer will only consider fiducial detections from the target waypoint (from initial_guess). Otherwise, if the target waypoint does not contain a good measurement of the desired fiducial, nearby waypoints may be used to infer the robot's location.
If true, and we are using fiducials during initialization, will run ICP after the fiducial was used for an initial guess.
Improve localization based on images from body cameras
Used in:
It is a programming error to use this one.
Ignore fiducials during initialization.
Localize to the nearest fiducial in any waypoint.
Localize to nearest fiducial at the target waypoint (from initial_guess).
Localize to the given fiducial at the target waypoint (from
Used in:
Unset. Note that the quality check is only performed if the overall Status enum returns STATUS_SUCCESS, and will be unset otherwise.
The quality check passed.
After applying the localization, a poor point cloud match to the map was detected. This can happen if, for example, the map has changed, or the starting location of the robot is now very different than it was at recording time.
After applying the localization, Graph Nav checked the localization, and found that the robot's gravity vector does not align with the map's. This can happen if a fiducial being used to align to the map was detected wrongly during recording, or if the robot's IMU is miscalibrated. It can also occur when the initial guess passed in to the SetLocalization RPC is in the incorrect reference frame.
There wasn't enough data to make a determination about quality.
The prior passed in is too different from the expected height of the robot e.w.r.t the waypoint.
Used in:
The status is unknown/unset.
Localization success.
Robot is experiencing a condition that prevents localization.
The given waypoint is unknown by the system. This could be due to a client error, or because the graph was changed out from under the client.
Localization was aborted, likely because of a new request.
Failed to localize for some other reason; see the error_report for details. This is often because the initial guess was incorrect.
Failed to localize because the fiducial requested by 'use_fiducial_id' was too far away from the robot.
Failed to localize because the fiducial requested by 'use_fiducial_id' had a detection time that was too far in the past.
Failed to localize because the fiducial requested by 'use_fiducial_id' did not exist in the map at the required location.
Failed to localize because the fiducial requested by 'use_fiducial_id' had an unreliable pose estimation, either in the current detection of that fiducial, or in detections that were saved in the map. Note that when using FIDUCIAL_INIT_SPECIFIC, fiducial detections at the target waypoint will be used so long as they are not uncertain -- otherwise, detections at adjacent waypoints may be used. If there exists no uncertain detection of the fiducial near the target waypoint in the map, the service returns this status.
The localization could not be set, because the map was recorded using a different sensor setup than the robot currently has onboard. See SensorStatus for more details.
Visual feature based alignment failed or the pose solution was considered unreliable.
Failed to localize because there is no map loaded.
Used in:
Example of a potentially ambiguous localization near the result of the initialization.
Used in:
Status is unknown/unset.
Recording has been started.
In this case we tried to start recording, but GraphNav was internally still waiting for some data from the robot.
Can't start recording because the robot is following a route.
When recording branches, the robot is not localized to the existing map before starting to record a new branch.
Can't start recording because the robot doesn't see the required fiducials.
Can't start recording because the map was too large for the license.
A required remote cloud did not exist in the service directory.
A required remote cloud did not have data.
All fiducials are visible but at least one pose could not be determined accurately.
When recording branches, the robot is too far from the existing map when starting to record a new branch.
Unable to start recording because the robot is impaired. See impaired_state for more details.
Information about how the robot should behave when stopping at a location.
Used in:
,Which direction the robot should face when lining up at a waypoint.
If true, always align to stairs at the start of the callback. Overrides face_direction if stairs are found.
Offset applied to the above facing direction (radians).
How close the robot needs to be to the desired pose (meters).
How close the robot needs to be to the desired pose (radians).
What direction robot should face.
Used in:
(Default) Face along the direction of the next edges in the route, regardless of the waypoint orientation.
Face in the direction of the recorded waypoint.
Face in the direction of the recorded waypoint, but if traversing the region in the opposite direction to how it was recorded, flip the orientation 180 degrees.
Face in the direction of the end of the region.
Used in:
Status is unknown/unset.
Recording is stopped.
In this case we tried to stop recording, but had an incorrect localization. graph_nav is expected to be localized to the final waypoint in the chain before we stop recording.
The robot is still processing the map it created to where the robot is currently located. You can't stop recording until that processing is finished. You should not move the robot, then try to stop recording again after 1-2 seconds.
Parameters describing how to travel along a route.
Used in:
, , , , , ,Threshold for the maximum distance [meters] that defines a circular region for when we have reached the final waypoint.
Oriented 2D bounding box [meters & radians] that defines an rectangular region for when we have reached the final waypoint.
Threshold for the maximum yaw [radians] that defines when we have reached the final waypoint (ignored if ignore_final_yaw is set to true).
Speed the robot should use. Omit to let the robot choose.
If true, the robot will only try to achieve the final translation of the route. Otherwise, it will attempt to achieve the yaw as well.
Max distance from the recorded edge that the robot is allowed to travel when avoiding obstacles or optimized its path. This is half of the full width of the corridor the robot may walk within. If this value is not set, the robot will choose a default corridor width.
Disable directed exploration to skip blocked portions of route
Disable alternate-route-finding; overrides the per-edge setting in the map.
Path following mode
Time to wait for blocked path to clear (seconds)
Ground clutter avoidance mode.
The strictness at which the lost detector will declare the robot lost during this command. Note that this level of strictness will continue to apply even if the robot is teleoperated by the user. Changing the level of strictness also resets the lost detector. So if the robot is lost, issuing a new command with a lower level of strictness will cause the robot to continue as if it were not lost. Issuing a command with LOST_DETECTOR_STRICTNESS_UNKNOWN results in no change.
Indicates whether robot will navigate through areas with poor quality features
Used in:
Unknown value
Navigate through default number of waypoints with poor quality features
Navigate through unlimited number of waypoints with poor quality features
Determines which local path planner to use.
Used in:
,Unknown value.
Use default path planner. Currently this is the short range planner.
Use short range planner.
Use long range planner. This is an experimental feature that helps the robot navigate around large obstacles that were not present during mission recording. NOTE: Alternate route-finding waypoints are disabled when using the long range planner.
Used in:
Traveling to the start of the region.
Waiting at the start of the region.
Traveling to the end of the region.
Waiting at the end of the region.
Used as response type in: AreaCallbackService.UpdateCallback
Used as field type in:
Common response header.
Return status for the request.
Enumeration of ways navigation callback can ask Graph Nav to continue operating.
Set the control policy that Graph Nav should use when crossing this region, and how and when Graph Nav should delegate control to or wait for the callback. This is the expected way to respond, and changing the policy is how a callback instructs graph nav to wait or continue on.
An error has occurred. Graph Nav will stop calling UpdateCallback and will call EndCallback.
The area callback is complete. Graph Nav will stop calling UpdateCallback and will call EndCallback.
Localization changes inform Graph Nav when the callback has moved the robot, and are ignored unless callback has control of the robot.
Used in:
(message has no fields)
Used in:
Details about how the lease was used. Only set when error == ERROR_LEASE.
Used in:
UNKNOWN should never be used.
The callback has determined that this way is impassable.
Something went wrong with the callback.
A lease error occurred while executing commands.
The callback has exceeded allowed execution time.
Used in:
Policy for what Graph Nav should do at the start of the region.
Policy for what Graph Nav should do at the end of the region.
Override the default settings for how the robot should behave at the end. Does not apply for OPTION_CONTINUE.
Used in:
Continue past the waypoint. If not already stopped at it, do not stop.
Stop at the waypoint.
Stop at the waypoint and transfer control to the callback.
Used in:
UNKNOWN should never be used.
The AreaCallback is actively updating. If an execution error does occur, that is reported via the response oneof.
The request command id does not exist or is no longer executing.
The area callback end time already expired.
Used in:
Change the localization within GraphNav.
Used in:
When unset, Graph Nav will not change the localization.
The robot is now at the end of the region.
Response to the UploadGraphRequest. After uploading a graph, the user is expected to upload large data at waypoints and edges (called snapshots). The response provides a list of snapshot IDs which are not yet cached on the server. Snapshots with these IDs should be uploaded by the client.
Used as response type in: GraphNavService.UploadGraph, GraphNavService.UploadGraphStreaming
Common response header.
Status for an upload request.
Details about how the lease was used.
The waypoint snapshot ids for which there was cached data.
The waypoint snapshot ids for which there is no cached data.
The edge snapshot ids for which there was cached data.
The edge snapshot ids for which there was no cached data.
Large graphs can only be uploaded if the license permits them.
Errors about Area Callbacks in the map.
General map statistics.
If the returned status is STATUS_INVALID_GRAPH, this contains the detailed information about why the graph was invalid. Note that some graph validation errors are warnings and the robot will be able to navigate on the graph even when they are present.
Used in:
Can't upload the graph because it was too large for the license.
The graph or its anchoring are invalid. See the ValidationStatus for more details.
The sensor data associated with this graph is incompatible with the current robot. A common example would be trying to upload a map recorded on a robot that had LIDAR to a robot that did not, or vice versa.
There is an error associated with one of the area callbacks in this graph.
Detailed information about why STATUS_INVALID_GRAPH was returned. This will only contain information if the UploadGraph request could not be validated.
Used in:
One or more edges references a waypoint that doesn't exist. There are the waypoint IDs referenced by edges that do not exist. This is an error. Fix the graph and re-upload.
The anchoring uploaded referenced waypoint IDs that do not exist. These are the missing IDs. This is a warning. The anchorings will be ignored.
One or more edges had an invalid from_tform_to transform. These are the edge IDs uploaded that have an invalid transform. Valid transforms have quaternion rotations that are normalized. This is a warning. Edges with invalid transforms will be fixed on upload.
One or more waypoint anchors in the anchoring have an invalid transform. These are the waypoint IDs that have an invalid transform. Valid transforms have quaternion rotations that are normalized. This is a warning. Anchors with invalid transforms will be fixed on upload.
One or more of the object anchors in the anchoring have an invalid transform. These are the object IDs that have an invalid transform. Valid transforms have quaternion rotations that are normalized. This is a warning. Anchors with invalid transforms will be fixed on upload.
The Graph in the UploadGraph request contained more than one waypoint with the same ID. These are the waypoint IDs which occur in the UploadGraph request more than once. Note that IDs are duplicated in this list the same number of times they are duplicated in the request. This is an error. Fix the graph and re-upload.
The anchoring contains one or more anchor IDs that are duplicated. Note that IDs are duplicated in this list the same number of times they are duplicated in the request. This is a warning. Only the first anchor will be used.
The anchoring contains one or more object anchor IDs that are duplicated. Note that IDs are duplicated in this list the same number of times they are duplicated in the request. This is a warning. Only the first anchor will be used.
The Graph in the UploadGraph request contained more than one edge with the equivalent ID. These are the edge IDs which occur in the UploadGraph request more than once. Note that IDs are duplicated in this list the same number of times that they are duplicated in the request. Note that edges are *not* directional, and it is impossible to have both a->b *and* b->a in the same map. This is an error. Fix the graph and re-upload.
Edges are not allowed to have the same "from" and "to" waypoint. These are the waypoint IDs which have self edges in the UploadGraph request. This is an error. Fix the graph and re-upload.
At least one waypoint in the graph has an empty ID. This is an error. Fix the graph and re-upload.
At least one edge in the graph references a waypoint with an empty ID. This is an error. Fix the graph and re-upload.
At least one waypoint anchor in the anchoring has an empty ID. This is a warning. Empty anchors will be ignored.
At least one object anchor in the anchoring has an empty ID. This is a warning. Empty anchors will be ignored.
One or more edges had a malformed staircase annotation. This is an error. Remove, rerecord, or fix the annotation.
Used in:
Unset.
Success.
The data in this waypoint snapshot is not compatible with the current configuration of the robot. Check sensor_status for more details.
Used in:
Represents a visual descriptor of a feature, usually a sparse visual feature.
Used in:
,Oriented Brief (ORB) sparse visual feature.
Place to put other descriptors not explicitly captured above.
Represents a set of visual features collected at a particular time from a particular camera source. Associates an image geometry + pixel data with visual features extracted there.
Used in:
The visual features extracted at the camera image.
Contains the actual data in the image capture (may be compressed), and information about the source. Note that the raw data may be omitted if visual features are already extracted.
Transformation from a bundle frame to the image. Depending on the context, the bundle frame may be the body, odometry, etc.
Represents a bundle of visual KeyFrames taken around the same time. For example, if the robot has many cameras, this represents all of the cameras captured at around the same time/location.
A number of key frames, possibly from different sources.
Reference frame that the keyframes' poses are expressed in.
Frame tree snapshot mapping common poses at record time (odom, body, etc.) to each other and the bundle frame.
Represents a 2d (pixel-based) detection of a feature in an image.
Used in:
The descriptor of the sparse feature, used to match it to other features.
Position (pixels) in the image.
Size of the feature in pixels. If the feature is circular, this is the radius of the circle. If the feature is square, this is the side length of the square.
Orientation of the feature in the image plane, radians. Counterclockwise.
The depth (in meters) from the camera if it exists, or empty otherwise.
2x2 Covariance matrix of the position measurement's uncertainty.
Expected variance of the depth measurement, if it exists.
Represents a 3D landmark that has some visual descriptor attached to it.
Used in:
Unique ID of the landmark. Ids of landmarks are unique only in a particular instance of a graph nav map. Ids of landmarks may change as maps update.
The landmark may either be a full 3D landmark (in which case it is a point), or an orientation-only landmark (in which case it is a normalized direction). The frame of the landmark is left ambiguous here; generally the container of the landmark will specify which frame it is in. Note that landmarks may have *both* position and direction. A 3D position with covariance.
The vector is to be interpreted as a normalized 3D direction in the landmark frame. This represents the direction "into" the landmark from where it was first observed.
The canonical descriptor associated with this landmark. If a landmark looks different from different angles, then multiple landmarks are likely to be created for it. This will be set whenever the first observation is made of a landmark to create it.
Indices of the observations that support this landmark.
A group of 3D landmarks. These landmarks may be associated with a single waypoint, or with groups of waypoints.
Unorganized 3d landmark cloud.
Name of the reference frame that the landmarks are in.
The frame tree must contain, at minimum, the landmark_frame and some other frame that the waypoint or current robot body knows about (for example, "odom" or "vision").
Used in:
Whether to return a STATUS_VISUAL_ALIGNMENT_FAILED if refine_with_visual_features fails.
A base element of the graph nav map. A waypoint consists of a reference frame, a name, a unique ID, annotations, and sensor data.
Used in:
, ,Identifier of the waypoint. Unique across all maps. This identifier does not have to be updated when its fields change.
Identifier of this waypoint's Snapshot data.
Transform from the KO frame (at time of recording) to the waypoint.
Annotations specific to the current waypoint.
Annotations understood by BostonDynamics systems.
Used in:
,Human-friendly name of the waypoint. For example, "Kitchen Fridge"
The time that the waypoint was created while recording a map.
Estimate of the variance of ICP when performed at this waypoint, collected at record time.
Options for how to localize to a waypoint (if at all).
How this waypoint was made.
Information about the state of the client when this waypoint was created.
This waypoint may have specific settings to help with loop closure. This Is useful for example when trying to ensure that a loop closure occurs at a particular intersection or near a dock.
Optional GPS navigation settings for this waypoint.
Regions may be defined around the waypoint which affect how scan matching or other parameters work.
Strictness of the lost detector to use while traversing this waypoint. If unset, the default strictness will be used.
Waypoints can optionally define where they are in an Earth-Centered-Earth-Fixed (ECEF) frame, which can aid in localization.
Used in:
If the annotation state is set, the GPS settings will be applied. Otherwise, they will be ignored. If ignored, GPS will only be used at this waypoint if data from a GPS exists in the waypoint snapshot, and the robot has a GPS payload installed and running. Set the annotation state to override this behavior.
This defines the pose of the waypoint in the Earth-Centered-Earth-Fixed (ECEF) frame.
If true, GPS localization will be disabled at this waypoint. If false, the robot will use GPS when available to localize to this waypoint.
Used in:
Check this before reading other fields.
Oneof field that describes the waypoint's location as a default region (no special features/traits).
Oneof field that describes the waypoint's location as a empty/featureless region.
Oneof field that describes the waypoint's location as a circular region.
Indicates the number of meters away we can be from this waypoint we can be before scan matching. - If zero, the default value is used. - If less than zero, no scan matching will be performed at this waypoint. - If greater than zero, scan matching will only be performed if the robot is at most this far away from the waypoint. Distance calculation is done in the 2d plane with respect to the waypoint.
Used in:
meters.
Use the default region to localize in.
Used in:
(message has no fields)
Do not localize to this waypoint.
Used in:
(message has no fields)
Used in:
If true, loop closure will be fully disabled at this waypoint.
If true, collision checking will be disabled for loop closures from or to this waypoint.
If nonzero, edges are allowed to be this long when making loop closures to this waypoint. If zero, global/default settings will be used.
If nonzero, loop closures to this waypoint may shortcut this amount of path length. If zero, global/default settings will be used.
Used in:
Waypoints from the robot's location during recording.
Waypoints with user-requested placement.
Waypoints that may help find alternate routes.
Waypoints may be anchored to a particular seed frame. The user may request that a waypoint be anchored in a particular place with some Gaussian uncertainty. Note on gravity alignment: optimization is sensitive to bad alignment with respect to gravity. By default, the orientation of the seed frame assumes gravity is pointing in the negative z direction. Take care to ensure that the orientation of the waypoint is correct with respect to gravity. By convention, waypoints' orientation is defined as: Z up, X forward, Y left. So, if the robot is flat on the ground, the waypoint's z axis should align with the seed frame's z axis. z z ^ ^ | | | | | | +------>x | Waypoint Seed
Used in:
,This is to be interpreted as the mean of a Gaussian distribution, representing the pose of the waypoint in the seed frame.
This is the uncertainty of the anchor's pose in the seed frame. If left empty, a reasonable default uncertainty will be generated.
Normally, the optimizer will move the anchorings of waypoints based on context, to minimize the overall cost of the optimization problem. By providing a constraint on pose, the user can ensure that the anchors stay within a certain region in the seed frame. Leaving this empty will allow the optimizer to move the anchoring from the hint as far as it likes.
Relevant data collected at the waypoint. May be used for localization or automatically generating annotations, for example. Should be indexed by a waypoint's "snapshot_id" field.
Used in:
Identifier of this snapshot. Snapshots are immutable -- if any of the other fields change, this ID must also change.
Any images captured at the waypoint.
Aggregated point cloud data.
Perception objects seen at snapshot time.
Full robot state during snapshot.
Robot grid data.
If true, the point cloud of this snapshot has been processed.
If this snapshot is a modified version of the raw snapshot with the given ID (for example, it has been processed), a new unique ID will we assigned to this field. If the field is empty, this is the raw version of the snapshot.
If true, the point cloud contains data from a remote point cloud service, such as LIDAR.
Transform from the robot body to the remote point cloud sensor's reference frame.
Defines the payloads attached to the robot at this waypoint.
Identifiers (software, nickname, etc.) of the robot that created this waypoint.
Information about when the recording session started in robot time basis. This will be filled out by the recording service when StartRecording is called.
World objects (such as fiducials) may be anchored to a particular seed frame. The user may request that an object be anchored in a particular place with some Gaussian uncertainty. Note on gravity alignment: optimization is sensitive to bad alignment with respect to gravity. By default, the orientation of the seed frame assumes gravity is pointing in the negative z direction. Take care to ensure that the orientation of the world object is correct with respect to gravity. By convention, fiducials' orientation is defined as: Z out of the page, X up and Y left (when looking at the fiducial). So, if a fiducial is mounted perfectly flat against a wall, its orientation w.r.t the seed frame would have the top of the fiducial facing positive Z. +-----------+ z | ^x | ^ | | | | | | | | | <----+ | | | y | Seed | | +-----------+ Fiducial (on wall)
Used in:
,This is to be interpreted as the mean of a Gaussian distribution, representing the pose of the object in the seed frame.
This is the uncertainty of the anchor's pose in the seed frame. If left empty, a reasonable default uncertainty will be generated.
Normally, the optimizer will move the anchorings of object based on context, to minimize the overall cost of the optimization problem. By providing a constraint on pose, the user can ensure that the anchors stay within a certain region in the seed frame. Leaving this empty will allow the optimizer to move the anchoring from the hint as far as it likes.