Debug Projection

The differentiated debugging capability in RoboTunnel

Debug Projection is the reason RoboTunnel is more than a tunnel. It adds a robot-side projection layer that can adapt data for remote debugging while keeping Foxglove, RViz, and structured inspection paths usable.

What it is

Debug Projection creates a managed session between robot-side topics and the remote debugging client. Instead of forwarding everything as-is, the agent can apply profile and policy decisions that better fit the network you actually have.

source topic -> projection policy -> session endpoint -> Foxglove / RViz / stream pull

Supported topic classes today

  • sensor_msgs/msg/Image for resize / rate-aware visual debugging paths
  • sensor_msgs/msg/PointCloud2 for stride / voxel-style reduction
  • sensor_msgs/msg/LaserScan for lower-rate or lower-density projection
  • tf2_msgs/msg/TFMessage passthrough guardrail
  • Other topics fall back to relay / throttled handling when no transform is defined

Profiles and per-topic policy

robotunnel debug start <robot> \
  --mode foxglove \
  --profile lidar_low_bw \
  --topic /lidar/points \
  --topic-policy-file ./topic_policy.json

Built-in profiles include balanced, lidar_low_bw, vision_low_bw, stats_only, compressed_passthrough, and compressed_resize.

{
  "/camera/image_raw": { "image_scale": 0.5, "max_fps": 8 },
  "/lidar/points":     { "point_stride": 4, "voxel": 0.10 },
  "*":                 { "max_fps": 10 }
}

Foxglove and RViz integration

# Foxglove
robotunnel debug start <robot> --mode foxglove
robotunnel debug open <robot> --launch

# RViz over VNC
robotunnel debug start <robot> --mode rviz_vnc
robotunnel debug open <robot> --endpoint rviz_vnc --launch

The point is not to replace your tools. It is to keep them usable remotely when the network is hostile. For the session control surface itself, continue to the CLI Reference.