For return visits to a known space, use premap relocalization instead of relying on live mapping alone.
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.
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
dimos map global --export.
Configuration
| Parameter | Default | Description |
|---|---|---|
voxel_size | 0.05 | Voxel cube size in meters |
block_count | 2,000,000 | Max voxels in hash map |
device | CUDA:0 | Compute device (CUDA:0 or CPU:0) |
carve_columns | true | Enable column carving (disable for append-only mapping) |
emit_every | 1 | Publish the map every Nth frame (1 = every frame) |
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
| Cost | Meaning |
|---|---|
| 0 | Flat, easy to traverse |
| 50 | Moderate slope (~7.5cm rise per cell in case of go2) |
| 100 | Steep or impassable (≥15cm rise per cell in case of go2) |
| -1 | Unknown (no observations) |
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.
5. All Layers Combined
All visualization layers shown together:
Frontier Exploration
TheWavefrontFrontierExplorer 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 callstart_patrol and stop_patrol to control it. Note that the area has to be explored first.
How it works
- 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.
- 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.
-
Navigation loop: The module sends each goal to the planner and waits for a
goal_reachedsignal 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. - 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
| Router | Behavior |
|---|---|
coverage | Maximizes new-cell coverage per goal. Uses Voronoi weighting for even spatial distribution. |
random | Picks a random unvisited, obstacle-free cell. |
frontier | Targets 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
| Coverage | Frontier | Random |
|---|---|---|
![]() | ![]() | ![]() |
Sample patrol trace (26 min)
Blueprint Composition
The navigation stack is composed in theunitree_go2 blueprint:
skip fold output=assets/go2_blueprint.svg



