Boston Dynamics Spot

Spot is Boston Dynamics' quadruped mobile robot: four actuated legs, an onboard locomotion controller, and a payload deck that most fleets fit with a compute payload and, for manipulation tasks, the Spot Arm. It ships as a walking sensor platform first — most deployed units run inspection routes — but the same teleoperation and control interfaces that drive an inspection mission also drive mobile-manipulation data collection, which is the case this page is about.

That distinction matters because Spot sits in a different category from a fixed-base arm like a Franka FR3 or a UR5e. The base moves, the world frame the robot reasons about is relative to where it booted up rather than fixed to a workbench, and locomotion itself is never fully open-loop to the operator. Collecting clean robot demonstration data on Spot means understanding what you actually command — body velocity, not leg joints — and what the platform logs for you versus what you need to add.

Control interfaces that matter for data collection

Spot is programmed through the Spot SDK, distributed as the bosdyn-client Python package (with an official C++ SDK also available); both talk to the robot over gRPC using Protocol Buffers as the wire format, so any language with a gRPC stack can implement a client against the same protocol. A handful of gRPC services matter most for data collection:

• Robot command service. Moves the robot. Mobility commands include stand, sit, selfright, safe_power_off, velocity, and trajectory — the SDK documentation is explicit that clients should send short-lived commands and continuously resend them rather than issuing one long-running command, which is a natural fit for a teleoperation loop streaming commands at a fixed rate.
• Arm service (when Spot Arm is fitted). Accepts joint-space moves, Cartesian end-effector commands, gripper/grasp commands, and — for contact-rich work — dedicated force and impedance control plus an ArmSurfaceContact mode built for higher-accuracy, force-limited surface contact.
• Image service. A gRPC service implementing bosdyn.api.ImageService. One image service can expose many image sources at once, covering both the base robot's built-in cameras and any camera on a payload, so a single client call can pull a synchronized set of frames rather than polling cameras separately.
• Payload interface. Spot's main payload port is a DB25 connector (two of them, one per side of the deck) delivering unregulated 35–58.8V DC at up to 150W per port, with a documented maximum total payload weight and a fixed mounting envelope. Boston Dynamics' own Spot GXP breakout board is a common way to turn that into a regulated 5/12/24V supply plus a standard Gigabit Ethernet jack and a PPS timing line for anything you bolt on — extra compute, a lidar, or additional cameras.

import bosdyn.client
from bosdyn.client.robot_command import RobotCommandClient, RobotCommandBuilder
 
sdk = bosdyn.client.create_standard_sdk("collect_client")
robot = sdk.create_robot("192.168.80.3")
robot.authenticate("user", "password")
 
lease_client = robot.ensure_client("lease")
lease_client.acquire()
 
command_client = robot.ensure_client(RobotCommandClient.default_service_name)
cmd = RobotCommandBuilder.synchro_velocity_command(v_x=0.4, v_y=0.0, v_rot=0.0)
command_client.robot_command(cmd)

Teleoperation options

Three distinct ways to drive Spot show up in practice, and they are not interchangeable for data collection.

Tablet controller, direct drive. Boston Dynamics' own tablet drives the robot with a gamepad-style joystick mode or a touch-to-go mode where you tap a destination on the camera feed. This is the fastest way to move Spot around and the way most site operators actually work, but it is a control surface, not a data-recording tool by itself — you get the robot moving, not a structured log of the session.

SDK-driven teleoperation. A client streams velocity or trajectory commands to the robot command service (and, with Spot Arm, joint or Cartesian commands to the arm service) from a human-in-the-loop input device — a gamepad, a leader arm for the manipulator, or a VR controller retargeted to end-effector pose. This is the path that produces demonstration data in the imitation-learning sense: every command your operator issues is a value your logging layer can capture alongside the corresponding sensor state.

Autowalk. Boston Dynamics' record-and-repeat mission tool: an operator walks Spot through a route once using the tablet, tags actions (an inspection photo, an arm reach) at points along the way, and the robot's own autonomy stack replays the route later, replanning around obstacles it wasn't shown. Autowalk is built for repeatable inspection, not for producing the varied, per-episode demonstrations a policy trains on — a recorded mission is one route, played back the same way every time, which is close to the opposite of what imitation learning needs.

The important shared fact across all three: Spot's locomotion is stabilized by the onboard controller no matter which of these you use. A human teleoperating Spot is commanding body velocity or body pose, and the controller is solving for hip and knee joint targets underneath that command to keep four legs under a balanced body. That is a fundamentally different control abstraction from arm teleoperation, where the human's motion (via a leader arm or VR pose) maps much more directly onto the joints or end-effector pose you actually want to log.

What a clean dataset looks like on this platform

A mobile-manipulation episode on Spot has more moving parts than a fixed-base arm episode, and each one needs to land on the same clock:

• Base state. Commanded body velocity or trajectory, plus the robot's estimated pose in an inertial frame — Spot's SDK exposes a vision frame and an odom frame for this, both anchored to where the robot booted up, because the body frame alone is egocentric and moves with the robot, so it cannot describe absolute position over time.
• Arm state, if Spot Arm is fitted: joint positions and velocities, and/or end-effector pose in whichever frame your policy expects.
• Gripper state. Open/close position and, if you're using it, the grasp/force signal from the gripper's contact sensing.
• Cameras. The base robot carries five pairs of stereo cameras giving roughly 360° coverage for navigation and obstacle context; the gripper itself carries an integrated 4K RGB camera, depth sensing, and an IMU, which is usually your primary manipulation view. Most collection setups also add a wrist- or head-mounted RGB-D payload camera for a cleaner manipulation-specific feed than the navigation stereo pairs provide.
• Synchronization. Base odometry, arm joint state, gripper state, and every camera stream need time synchronization onto one clock and one episode boundary. This is harder on Spot than on a bench-mounted arm: the base is a non-inertial, continuously moving reference frame, so "robot pose" is itself a time-varying quantity you're logging, not a fixed calibration you compute once. Get multi-camera calibration between the body cameras, the gripper camera, and any payload camera done once and version it, rather than re-deriving it per session.

If your fleet already standardized on a capture pipeline for other platforms, Bring Your Own Rig describes connecting a robot like Spot through one SDK with ROS 2 and vendor API adapters, automatic time-sync, and calibration checks, rather than building the base-plus-arm synchronization layer from scratch.

Common pitfalls

Confusing Autowalk missions with demonstration data. A recorded mission is a compiled route replayed by Spot's own autonomy, not a per-episode human trajectory. If your goal is a training dataset for imitation learning, collect through SDK-driven or tablet-plus-logging teleoperation, and reserve Autowalk for what it's built for: repeatable, scripted site walks.

Treating body pose like a static transform. Because the base moves continuously, you cannot calibrate "robot pose" once and reuse it — you need the vision or odom frame logged at capture time for every sample, and you need to know which frame your downstream policy expects.

Underestimating comms range and reliability for SDK teleoperation. Tablet control and Wi-Fi-based SDK sessions degrade with distance and obstructions; a lost link mid-session is a bigger problem for a walking robot mid-stride than for a stationary arm, so plan E-Stop behavior and session recovery accordingly.

Skipping the lease/E-Stop setup for quick scripting sessions. A one-off collection script without a proper keep-alive loop works until the lease times out partway through and the robot silently stops accepting commands — which looks like a policy bug, not a client bookkeeping bug.

Assuming arm and base commands are automatically coordinated. The robot command service and arm service are separate command paths issued through the same client, so nothing stops a base trajectory and an arm Cartesian command from conflicting. Whole-body coordination is something your teleoperation interface or policy has to impose; the SDK gives you two command surfaces, not a combined one.