Skip to content

Commit 9d3237d

Browse files
Release v4.0.1 of Boston Dynamics Spot SDK
1 parent 577c45e commit 9d3237d

File tree

582 files changed

+6907
-7643
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

582 files changed

+6907
-7643
lines changed

README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,7 +22,7 @@ The SDK consists of:
2222
- [Spot API protocol definition](protos/bosdyn/api/README.md). This reference guide covers the details of the protocol applications used to communicate to Spot. Application developers who wish to use a language other than Python can implement clients that speak the protocol.
2323
- [Spot SDK Repository](https://github.com/boston-dynamics/spot-sdk). The GitHub repo where all of the Spot SDK code is hosted.
2424

25-
This is version 4.0.0 of the SDK. Please review the [Release Notes](docs/release_notes.md) to see what has changed.
25+
This is version 4.0.1 of the SDK. Please review the [Release Notes](docs/release_notes.md) to see what has changed.
2626

2727
## Contents
2828

VERSION

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
4.0.0
1+
4.0.1

docs/concepts/autonomy/autowalk_service.md

Lines changed: 20 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -14,11 +14,11 @@ The autowalk service is a way for API clients to specify high level autonomous b
1414

1515
| Term | Description |
1616
| ----- | -----------|
17-
| [Mission](../../../protos/bosdyn/api/proto_reference.html#node) | A `bosdyn.api.mission.Node` proto that fully defines a behavior tree. The structure is infinitely recursive.
18-
| [Mission Service](../../../protos/bosdyn/api/proto_reference.html#missionservice) | A GRPC service that sits on top of the API and can compile & run a mission.
17+
| [Mission](../../../protos/bosdyn/api/mission/nodes.proto#node) | A `bosdyn.api.mission.Node` proto that fully defines a behavior tree. The structure is infinitely recursive.
18+
| [Mission Service](../../../protos/bosdyn/api/mission/mission_service.proto#missionservice) | A GRPC service that sits on top of the API and can compile & run a mission.
1919
| Program | Some high level robot behavior that can either be expressed as a mission, a python script, or some other medium.
20-
| [Autowalk](../../../protos/bosdyn/api/proto_reference.html#walk) | A `bosdyn.api.autowalk.Walk` proto that fully defines a program with structure sequence { go here, do this, go there, do that, etc }.
21-
| [Autowalk Service](../../../protos/bosdyn/api/proto_reference.html#autowalkservice) | A GRPC service that translates an autowalk into a mission.
20+
| [Autowalk](../../../protos/bosdyn/api/autowalk/walks.proto#walk) | A `bosdyn.api.autowalk.Walk` proto that fully defines a program with structure sequence { go here, do this, go there, do that, etc }.
21+
| [Autowalk Service](../../../protos/bosdyn/api/autowalk/autowalk_service.proto#autowalkservice) | A GRPC service that translates an autowalk into a mission.
2222

2323
## How Autowalks Differs From Missions
2424
The mission service and missions sit on top of the API. There is nothing you can do with the mission service that you can’t do with a python script. The reasons to write a program using missions instead of a python script are:
@@ -44,12 +44,12 @@ The walk proto defines the autowalk's “go here, do this” format. It is a lin
4444

4545
| Term | Description |
4646
| ----- | -----------|
47-
| [Action](../../../protos/bosdyn/api/proto_reference.html#action) | What the robot should do at a location.
48-
| [Action Wrapper](../../../protos/bosdyn/api/proto_reference.html#actionwrapper) | What the robot should do before and during an action.
49-
| [Action Failure Behavior](../../../protos/bosdyn/api/proto_reference.html#failurebehavior) | What the robot should do if the action fails.
50-
| [Target](../../../protos/bosdyn/api/proto_reference.html#target) | Where the robot should go. Targets are speicified within the context of a graph nav map.
51-
| [Target Failure Behavior](../../../protos/bosdyn/api/proto_reference.html#failurebehavior) | What the robot should do if it fails to reach the target.
52-
| [Battery Monitor](../../../protos/bosdyn/api/proto_reference.html#batterymonitor) | The battery thresholds at which the robot should pause/resume mission execution.
47+
| [Action](../../../protos/bosdyn/api/autowalk/walks.proto#action) | What the robot should do at a location.
48+
| [Action Wrapper](../../../protos/bosdyn/api/autowalk/walks.proto#actionwrapper) | What the robot should do before and during an action.
49+
| [Action Failure Behavior](../../../protos/bosdyn/api/autowalk/walks.proto#failurebehavior) | What the robot should do if the action fails.
50+
| [Target](../../../protos/bosdyn/api/pautowalk/walks.proto#target) | Where the robot should go. Targets are speicified within the context of a graph nav map.
51+
| [Target Failure Behavior](../../../protos/bosdyn/api/autowalk/walks.proto#failurebehavior) | What the robot should do if it fails to reach the target.
52+
| [Battery Monitor](../../../protos/bosdyn/api/autowalk/walks.proto#batterymonitor) | The battery thresholds at which the robot should pause/resume mission execution.
5353

5454
## Autowalk Service RPCs
5555
The autowalk service provides [RPCs][autowalkserivce] for clients to convert an autowalk to a mission.
@@ -80,15 +80,15 @@ As previously mentioned, missions offer more flexibility than autowalks because
8080

8181
[autowalklanguage]: images/autowalk_language_layer.png "Analogy for how autowalks work"
8282
[missions]: missions_service.md "Missions service"
83-
[autowalkserivce]: ../../../protos/bosdyn/api/proto_reference.html#autowalkservice "Autowalk Service RPCs"
84-
[element]: ../../../protos/bosdyn/api/proto_reference.html#element "Element Proto"
85-
[nodeidentifier]: ../../../protos/bosdyn/api/proto_reference.html#nodeidentifier "Node Identifier Proto"
86-
[nodeinfo]: ../../../protos/bosdyn/api/proto_reference.html#nodeinfo "Node Info Proto"
87-
[userdata]: ../../../protos/bosdyn/api/proto_reference.html#userdata "User Data Proto"
88-
[getstateresponse]: ../../../protos/bosdyn/api/proto_reference.html#getstateresponse "Get State Response Proto"
83+
[autowalkserivce]: ../../../protos/bosdyn/api/autowalk/autowalk_service.proto#autowalkservice "Autowalk Service RPCs"
84+
[element]: ../../../protos/bosdyn/api/autowalk/walks.proto#element "Element Proto"
85+
[nodeidentifier]: ../../../protos/bosdyn/api/autowalk/walks.proto#nodeidentifier "Node Identifier Proto"
86+
[nodeinfo]: ../../../protos/bosdyn/api/mission/mission.proto#nodeinfo "Node Info Proto"
87+
[userdata]: ../../../protos/bosdyn/api/mission/util.proto#userdata "User Data Proto"
88+
[getstateresponse]: ../../../protos/bosdyn/api/mission/mission.proto#getstateresponse "Get State Response Proto"
8989
[editautowalk]: ../../../python/examples/edit_autowalk/README.md "Edit Autowalk Example"
9090
[queryautowalkstatus]: https://github.com/boston-dynamics/spot-cpp-sdk/tree/master/cpp/examples/query_autowalk_status "Query Autowalk Status Example"
91-
[failedelement]: ../../../protos/bosdyn/api/proto_reference.html#failedelement "Failed Element Proto"
92-
[node]: ../../../protos/bosdyn/api/proto_reference.html#node "Node Proto"
93-
[action]: ../../../protos/bosdyn/api/proto_reference.html#action "Action Proto"
94-
[loadautowalkresponse]: ../../../protos/bosdyn/api/proto_reference.html#loadautowalkresponse "Load Autowalk Response Proto"
91+
[failedelement]: ../../../protos/bosdyn/api/autowalk/autowalk.proto#failedelement "Failed Element Proto"
92+
[node]: ../../../protos/bosdyn/api/mission/nodes.proto#node "Node Proto"
93+
[action]: ../../../protos/bosdyn/api/autowalk/walks.proto#action "Action Proto"
94+
[loadautowalkresponse]: ../../../protos/bosdyn/api/autowalk/autowalk.proto#loadautowalkresponse "Load Autowalk Response Proto"

docs/concepts/autonomy/components_of_autonomous_navigation.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -11,13 +11,13 @@ Development Kit License (20191101-BDSDK-SL).
1111
To get started with autonomous navigation, you'll need a grasp of the following concepts:
1212

1313

14-
* [Maps](#Maps)
14+
* [Maps](#maps)
1515
* [Waypoints](#waypoints)
1616
* [Edges](#edges)
1717
* [Localization](#localization)
1818
* [Initialization](#initialization)
1919
* [Missions](#missions)
20-
* [(Advanced) Area Callbacks](#area-callbacks)
20+
* [(Advanced) Area Callbacks](#area_callbacks)
2121

2222

2323
<h2 id="maps">Maps</h2>

docs/concepts/autonomy/graphnav_area_callbacks.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -113,7 +113,7 @@ The majority of work for an `AreaCallbackRegionHandlerBase` subclass will be don
113113

114114
These methods will return when their particular condition is met. If the navigation is aborted, they will raise an exception of a subclass of `bosdyn.client.area_callback_region_handler_base.HandlerError`. These exceptions do not need to be caught, and can be used to exit from `run()`. If you _do_ catch these exceptions for performing cleanup work, be sure to re-raise them after cleaning up, rather than continuing on in the `run()` method. It is expected that `run()` will complete quickly once navigation has stopped. If your use-case requires more time for cleanup operations you should create a thread to do that work and still return from `run()` quickly. Note that `safe_sleep()` works very similar to python's `time.sleep()` except that it will raise one of the above exceptions if the navigation through the region aborts during the sleep.
115115

116-
In addition to these blocking methods, implementations can directly call `check()` which will immediately raise a `HandlerError` if the callback should abort. Also, the `stage()` and `has_control()` helpers can be used to check this information about current stage and control state in a non-blocking manner. `stage()` will return the [`bosdyn.api.UpdateCallbackRequest.Stage`](../../../protos/bosdyn/api/proto_reference.html#updatecallbackrequest-stage) enum describing the stage of crossing the region.
116+
In addition to these blocking methods, implementations can directly call `check()` which will immediately raise a `HandlerError` if the callback should abort. Also, the `stage()` and `has_control()` helpers can be used to check this information about current stage and control state in a non-blocking manner. `stage()` will return the [`bosdyn.api.UpdateCallbackRequest.Stage`](../../../protos/bosdyn/api/graph_nav/area_callback.proto#updatecallbackrequest-stage) enum describing the stage of crossing the region.
117117

118118
Aside from the task-specific work that the callback does, its other responsibility is to communicate a two-part _policy_ to GraphNav as to what actions GraphNav should perform at the start and end of the region.
119119
The recommended way to set and update this policy is to use the helper methods:

docs/concepts/data_acquisition_thermal_raw.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -24,7 +24,7 @@ All other versions | Big endian
2424
Raw data captured using the SDK is captured as `.pgm` while the same data captured using callbacks is captured as `.raw`. Both contain the same data, except that the `.pgm` file contains additional header lines. In general, `.pgm` files are downloaded when using the spot SDK while `.raw` files are downloaded when downloading through [the data service](data_buffer_overview.md#data-acquisition-download). The example script can read both file types, but it throws away any header files. The `.pgm` headers are necessary to parse the data if the width and height of the image are variable.
2525

2626
## Rendering raw thermal data
27-
Some image viewers can natively open .pgm files as a grayscale image. To instead show with a particular color palette, a lookup-table can be referenced to map from temperature to a color. For example, the lookup tables used by matplotlib can be referenced at this [link](https://github.com/matplotlib/matplotlib/blob/main/lib/matplotlib/_cm_listed.py)
27+
Some image viewers can natively open .pgm files as a grayscale image. To instead show with a particular color palette, a lookup-table can be referenced to map from temperature to a color. For example, the lookup tables used by matplotlib can be referenced at this [link](https://github.com/matplotlib/matplotlib/blob/850bf04d317cbd85f3baff888dd273582d19a3c7/lib/matplotlib/_cm_listed.py)
2828

2929
### Scaling the color mapping
3030
The left image is a render using the min and max temperatures mapping directly to the min and max values in the color map. The image on the right shows the same image but with the mapping adjusted so that the lower temperature values are less prominent. This allows for more contrast and improved visibility of the hotter areas.

docs/concepts/developing_api_services.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -55,7 +55,7 @@ with keep_alive:
5555

5656
## Examples
5757
The Spot SDK provides a myriad of examples showing how an off-robot Python gRPC service can be developed.
58-
- [Web Cam Image Service](../../python/examples/web_cam_image_service/README.md)
58+
- [Custom Parameter Web Cam Image Service](../../python/examples/service_customization/custom_parameter_image_server/README.md)
5959
- [Ricoh Theta Image Service](../../python/examples/ricoh_theta/README.md)
6060
- [Remote Mission Services](../../python/examples/remote_mission_service/README.md)
6161
- [Data Acquisition Plugins](../../python/examples/data_acquisition_service/README.md)

docs/concepts/robot_services.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -72,7 +72,7 @@ The robot state service also tracks different parameters for the robot and this
7272
The log status service provides users access to files Spot generates that contains data about its performance during operation. Files can be generated with data from the past, such files are known as retro logs. Files can also be generated with present data and into the future, such files are called experiment logs. The `LogStatus` object in the response of each API displays the status of the requested file and the id that can be provided to BD support for assistance in debugging issues. The steps for sending logs to our support team are outlined [here](https://support.bostondynamics.com/s/article/Spot-robot-logging#DownloadSendLog).
7373

7474
## metrics_logging
75-
The metrics logging service aggregates internal operation and usability metrics to help Boston Dynamics improve performance and user experience. You can retrieve metrics by using the RPCs defined in the [service definition](../../../../proto/public_api/bosdyn/protos/bosdyn/api/metrics_logging/metrics_logging_robot_service.proto). For a working example, see `Metrics over CORE I/O` from [Payloads Examples](../../python/examples/docs/payloads_examples.md), which uses the [MetricsLoggingClient](../../python/bosdyn-client/src/bosdyn/client/metrics_logging.py).
75+
The metrics logging service aggregates internal operation and usability metrics to help Boston Dynamics improve performance and user experience. You can retrieve metrics by using the RPCs defined in the [service definition](../../protos/bosdyn/api/metrics_logging/metrics_logging_robot_service.proto). For a working example, see `Metrics over CORE I/O` from [Payloads Examples](../../python/examples/docs/payloads_examples.md), which uses the [MetricsLoggingClient](../../python/bosdyn-client/src/bosdyn/client/metrics_logging.py).
7676

7777
## image
7878

docs/concepts/writing_services_for_data_acquisition.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -58,7 +58,7 @@ When `use_background_capture_thread` is set to False, the `CameraBaseImageServic
5858

5959
### Example Image Services
6060

61-
There are two SDK examples showing `ImageService` implementations using the helper functions: a [USB web camera](../../python/examples/web_cam_image_service/README.md), and the [Ricoh Theta camera](../../python/examples/ricoh_theta/README.md).
61+
There are two SDK examples showing `ImageService` implementations using the helper functions: a [USB web camera](../../python/examples/service_customization/custom_parameter_image_server/README.md), and the [Ricoh Theta camera](../../python/examples/ricoh_theta/README.md).
6262

6363
### Tips for Creating an Image Service
6464
- The `image_decode` function should attempt to accurately fill out the PixelFormat and ImageFormat fields for the image proto in addition to the image data. This allows for end-user applications to more accurately decode the image data.

docs/html/.buildinfo

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
11
# Sphinx build info version 1
22
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
3-
config: ac03fa0fdc295493ab3b8a8dfe429ea1
3+
config: 4c97b22c7a4ac743f2b4785d9887c8d6
44
tags: 645f666f9bcd5a90fca523b33c5a78b7

0 commit comments

Comments
 (0)