Skip to main content
The Go2 navigation stack runs entirely without ROS. It uses a column-carving voxel map strategy: each new LiDAR frame replaces the corresponding region of the global map entirely, ensuring the map always reflects the latest observations. Live Go2 navigation in Rerun For return visits to a known space, use premap relocalization instead of relying on live mapping alone.

Data Flow

Go2 navigation data flow

Pipeline Steps

1. LiDAR Frame (GO2Connection)

We do not connect to the LiDAR directly. Instead we use Unitree’s WebRTC client via legion’s webrtc driver, which streams a heavily preprocessed 5cm voxel grid rather than raw point cloud data. This lets us support stock, unjailbroken Go2 Air and Pro models out of the box. LiDAR frame

2. Global Voxel Map (VoxelGridMapper)

The VoxelGridMapper maintains a sparse 3D occupancy grid using Open3D’s VoxelBlockGrid backed by a hash map. Each voxel is a 5cm cube by default. Voxel hash map provides O(1) insert/erase/lookup, so this is efficient even with millions of voxels. The grid runs on CUDA by default for speed, with CPU fallback. Each incoming LiDAR frame is spliced into the global map via column carving: any previously mapped voxels in the space of a received LiDAR frame are considered stale, and entire Z-columns in its footprint are erased before the new frame is written. This guarantees:
  • No ghost obstacles from previous passes
  • Dynamic objects (people, doors) get cleared automatically
  • The latest observation always wins
Live column-carving has no loop closure. We trust Go2 odometry, which is stable but drifts over distance. You can reliably map and navigate large spaces around 500 m² in our tests, but not kilometer-scale outdoor routes. For return visits with loop-closed maps, use premap relocalization and build the premap offline with dimos map global --export.

Configuration

ParameterDefaultDescription
voxel_size0.05Voxel cube size in meters
block_count2,000,000Max voxels in hash map
deviceCUDA:0Compute device (CUDA:0 or CPU:0)
carve_columnstrueEnable column carving (disable for append-only mapping)
emit_every1Publish the map every Nth frame (1 = every frame)
Global map

3. Global Costmap (CostMapper)

The CostMapper converts the 3D voxel map into a 2D occupancy grid. The default algorithm (height_cost) maps rate of change of Z, with some smoothing. Algorithm settings live in occupancy.py and can be configured per robot.

Configuration

skip
CostMeaning
0Flat, easy to traverse
50Moderate slope (~7.5cm rise per cell in case of go2)
100Steep or impassable (≥15cm rise per cell in case of go2)
-1Unknown (no observations)
Global costmap

4. Navigation Costmap (ReplanningAStarPlanner)

The planner processes the terrain gradient and computes its own planning costmap, preferring safe free paths but willing to path aggressively through tight spaces when it has to. We run the planner in a constant loop so it dynamically reacts to obstacles as they appear. Navigation costmap with path

5. All Layers Combined

All visualization layers shown together: All layers

Frontier Exploration

The WavefrontFrontierExplorer drives autonomous exploration of unknown space. It scans the costmap for frontiers, the boundaries between mapped and unmapped cells, picks the best candidate with a wavefront BFS from the robot’s position, and publishes it as a navigation goal. When a goal is reached (or fails), it selects the next frontier until the space is fully mapped. Like patrolling below, it is exposed as an agent skill: an LLM agent can call begin_exploration and end_exploration.

Patrolling

The patrolling system drives the robot to systematically cover a known area. It is exposed as an agent skill. An LLM agent can call start_patrol and stop_patrol to control it. Note that the area has to be explored first.

How it works

  1. Visitation tracking: As the robot moves, a visitation grid aligned to the costmap marks cells around the robot’s position as visited. This gives the system a running picture of where the robot has and has not been. Visits expire over time and cells must be covered again.
  2. Goal selection: A patrol router picks the next goal. The default strategy is coverage: it samples candidate points from unvisited, obstacle-free cells, plans a path to each one, and picks the candidate whose path would cover the most new ground. Candidates are weighted by a Voronoi skeleton so goals spread evenly across the map rather than clustering in large open areas.
  3. Navigation loop: The module sends each goal to the planner and waits for a goal_reached signal before requesting the next one. If no valid goal is available, for example when the map has not loaded yet, it retries after a short delay.
  4. Stopping: When patrol is stopped, the module cancels in-progress navigation by publishing the robot’s current pose as the goal, then re-enables the planner’s normal replanning behavior.

Patrol router strategies

RouterBehavior
coverageMaximizes new-cell coverage per goal. Uses Voronoi weighting for even spatial distribution.
randomPicks a random unvisited, obstacle-free cell.
frontierTargets the boundary between known and unknown space, useful for exploration-style patrol.

Safety

Goal candidates are filtered through a safe mask, which is the free-space region eroded by the robot’s clearance radius, so the robot is never sent too close to walls or obstacles. The planner’s safe-goal clearance is also tightened while patrolling so the robot can rotate in place at every goal.

Router comparison

CoverageFrontierRandom
coveragefrontierrandom

Sample patrol trace (26 min)

Patrol path

Blueprint Composition

The navigation stack is composed in the unitree_go2 blueprint:
skip fold output=assets/go2_blueprint.svg
unitree_go2 blueprint module graph