go2w_motion_command

Minimal robot-side ROS 2 container for validating Unitree GO2-W Sport API control through abstract motion commands (vx, vy, wz).

This repository is intentionally narrower than go2w_teleop_gamepad: instead of converting joystick input to Sport API commands, it keeps a robot-side service running in Docker and lets the operator trigger timed motion commands from a terminal.

Purpose

The goal is to verify that the robot can be controlled through high-level body motion commands while relying on Unitree's onboard Sport API controller to interpret and execute them.

The v1 feature set is:

• Start a robot-side Docker container manually from a terminal.
• Send a timed motion command (vx, vy, wz) from another terminal command.
• Stop motion automatically after a bounded execution time.
• Trigger an emergency stop command that cancels the active motion and publishes StopMove.

Control Model

The container runs a ROS 2 node that:

• exposes /motion_command/execute
• exposes /motion_command/stop
• publishes unitree_api/Request to /api/sport/request
• optionally monitors /api/sport/response

Motion is executed by repeatedly publishing Move (api_id=1008) at a fixed rate for a bounded duration. When the duration expires, the node publishes StopMove (api_id=1003).

Safety Notes

• This is experimental software and not a certified safety system.
• The robot must already be in a standing Sport-mode state that accepts Move and StopMove.
• This repository does not issue StandUp, RecoveryStand, or Damp.
• The emergency stop in this repo uses StopMove, not Damp, to avoid intentionally collapsing the robot.
• Start with conservative command values and ample open space.

Repository Layout

go2w_motion_command/
├── docker/
├── go2w_motion_command/
└── go2w_motion_command_interfaces/

Robot Deployment

Build on the robot:

./docker/run.sh build

Start the container manually:

./docker/run.sh up -d

Watch logs:

./docker/run.sh logs -f

Stop the container:

./docker/run.sh down

The container does not auto-start. It runs only when started from the terminal.

Motion Command Usage

Example forward motion for the default 2.0 seconds:

./docker/run.sh motion --vx 0.10 --vy 0.0 --wz 0.0

Example yaw motion for 1.5 seconds:

./docker/run.sh motion --vx 0.0 --vy 0.0 --wz 0.20 --duration 1.5

Emergency stop:

./docker/run.sh stop

If a motion is already active, the server rejects a new motion command until the current motion finishes or stop is called.

Runtime Defaults

Defaults are stored in go2w_motion_command/config/motion_command_params.yaml.

• default_duration_s = 2.0
• max_duration_s = 10.0
• allow_unrestricted_speeds = false — set to true to enable higher speed limits below
• max_vx = 0.20 (safe default) / max_vx_unrestricted = 0.60
• max_vy = 0.15 (safe default) / max_vy_unrestricted = 0.45
• max_wz = 0.30 (safe default) / max_wz_unrestricted = 0.90
• publish_rate_hz = 50.0

Requests outside these limits are rejected.

Development Notes

This repository follows the same basic robot-side pattern as go2w_teleop_gamepad:

• ROS 2 Humble
• CycloneDDS
• network_mode: host
• eth0 pinned in CYCLONEDDS_URI
• unitree_api sourced from unitree_ros2

Strategy Context

This repository is a robot-side ROS 2 validation step for higher-level controllers. It proved that the Unitree GO2-W can be driven through the Sport API using abstract body-motion commands (vx, vy, wz) rather than joystick input. The container runs on the robot, exposes a timed motion-command service, and translates each command into repeated unitree_api/Request Move messages on /api/sport/request, followed by StopMove when the command ends or is cancelled.

This confirms that Unitree's onboard Sport-mode controller can digest high-level velocity commands and handle the underlying low-level balance and motion execution. For future controllers such as MPPI, the intended final integration is to replace the timed test-command source with an MPPI controller that publishes the same (vx, vy, wz) abstraction, while keeping the robot output path through the Sport API the same.