Docker¶
Everything lives under .docker/. The image is a two-stage build on
python:3.12-slim — no compiler at runtime, no ROS.
Try it with no robot¶
Watch Nav2 running on the host¶
The btview service uses network_mode: host, so 127.0.0.1:1667 inside the container is
the same socket the robot's publisher bound on the host:
docker compose -f .docker/docker-compose.yml run --rm btview
docker compose -f .docker/docker-compose.yml run --rm btview snapshot --active
Host networking is a Linux feature. On Docker Desktop (macOS, Windows) use the published address instead:
Watch a robot elsewhere on the network¶
Two containers, private network¶
The split profile runs a synthetic publisher and a monitor on a compose bridge — useful
for exercising the network path without a robot:
mock binds 0.0.0.0:1667 inside the network; monitor connects to tcp://mock:1667.
Getting a good terminal¶
The image sets TERM=xterm-256color, and compose forwards your own $TERM. Two things
matter for the full-screen UI:
-it— without a TTY, Textual has nothing to draw on.docker compose runincludes it; a baredocker runneeds it spelled out.- Font — if glyphs come out as boxes, add
--ascii.
Non-interactive commands need neither:
Getting files out¶
export, record and the TUI's s key write to the working directory. Mount one:
docker run --rm -v "$PWD:/out" -w /out btview:latest \
export --host 192.168.1.42 --format mermaid -o tree.mmd
docker run --rm -v "$PWD:/out" -w /out --network host btview:latest \
record -o /out/run.btv.jsonl --duration 60
Building for a robot¶
The image is architecture-agnostic; for an ARM64 robot from an x86 laptop:
Honestly though: on the robot itself, pipx install btview is smaller, starts faster, and
sidesteps the networking entirely. Containers are the better answer on your workstation.