Feat/rerun latency panels

[Nabla7]

Viewer Backends

Dimos supports three visualization backends: Rerun (web or native) and Foxglove.

Quick Start

Choose your viewer backend with the VIEWER_BACKEND environment variable:

# Rerun web viewer (default) - Full dashboard in browser
VIEWER_BACKEND=rerun-web dimos run unitree-go2

# Rerun native viewer - Fast native window + control center in browser
VIEWER_BACKEND=rerun-native dimos run unitree-go2

# Foxglove - Use Foxglove Studio instead of Rerun
VIEWER_BACKEND=foxglove dimos run unitree-go2

Viewer Modes Explained

Rerun Web (rerun-web)

What you get:

• Full dashboard at http://localhost:7779
• Rerun 3D viewer + command center sidebar in one page
• Works in browser, no display required (headless-friendly)

---

Rerun Native (rerun-native)

What you get:

• Native Rerun application (separate window opens automatically)
• Command center at http://localhost:7779
• Better performance with larger maps/higher resolution

---

Foxglove (foxglove)

What you get:

• Foxglove bridge on ws://localhost:8765
• No Rerun (saves resources)
• Better performance with larger maps/higher resolution
• Open layout: dimos/assets/foxglove_dashboards/go2.json

---

Performance Tuning

Symptom: Slow Map Updates

If you notice:

• Robot appears to "walk across empty space"
• Costmap updates lag behind the robot
• Visualization stutters or freezes

This happens on lower-end hardware (NUC, older laptops) with large maps.

Increase Voxel Size

Edit dimos/robot/unitree_webrtc/unitree_go2_blueprints.py line 82:

# Before (high detail, slower on large maps)
voxel_mapper(voxel_size=0.05),  # 5cm voxels

# After (lower detail, 8x faster)
voxel_mapper(voxel_size=0.1),   # 10cm voxels

Trade-off:

• Larger voxels = fewer voxels = faster updates
• But slightly less detail in the map

[jeff-hykin]

Worker modules connect to the server via connect_rerun

Thread locks dont work for workers because workers can be using python multiprocessing. A multiprocessing lock needs to be used instead. Right now I think the code is working by coincidence (you could remove the lock entirely and get similar behavior).

[Nabla7]

When I removed the lock I would get errors where two modules would be trying to start the rerun server at the same time.

Can you provide the errors you are getting now?

[jeff-hykin]

The thread lock will prevent an error when its using threads (the lock is doing something, it just doesnt work under all conditions). Sometimes dask uses threads but sometimes it uses processeses. It depends how many modules are loaded and what n_workers is set to. If dask uses processes then the lock won't actually lock.

IMO the worst bugs are the ones that dont give errors. Even with just threads, adding a random time delay (instead of a lock) would make an error nearly impossible to reproduce, but doesnt fix the issue.

I havent run the code, I just wanted to give you a heads up that I think theres a logic issue thats going to cause unreliable behavior as more modules are added and as people set custom values for n_workers.

If I were to try to make an error super likely, I would set n_workers=25, threads_per_worker=1, and then init rerun on 25 modules.