---
name: reference-rover-dashboard-options
description: ROS2 rover dashboard options comparison (Foxglove, rosbridge, Grafana, webviz alternatives) plus NVENC hardware video encoding research for SC Robotics.
metadata:
type: reference
---
## Context
Tyler wants a web dashboard for the SC Robotics rover, built off ROS 2 control, so he can open a link on his phone and operate/monitor everything. Considered Grafana initially but it's the wrong primary tool for this (built for time-series history, not live video/3D/control). Researched 2026-08-16.
## Bandwidth constraint driving the decision
Rover mesh link (batman-adv over Wi-Fi HaLow on the 900MHz leg, separate 2.4GHz leg for video) can drop to 0.2-0.4 Mbps at range. Any dashboard/video choice needs to tolerate a degraded link gracefully.
## Options evaluated
**1. Foxglove Bridge (top recommendation)**
`foxglove_bridge` — apt-installable ROS 2 WebSocket node, modern successor to rosbridge, higher performance, supports ROS 2 msg/idl types, params, graph introspection.
- Free tier: 3 dev seats, 10GB storage, 5 connected devices, unlimited personal layouts, live robot connections.
- "Remote Access" feature lets you teleoperate through Foxglove's hosted platform without being on the same network — no VPN/port-forward needed. 300 free remote-access minutes/device/month. Solves the "open a link on my phone" requirement directly.
- Web app works in any browser including mobile Chrome. Handles live video, 3D (URDF/TF/pointclouds), telemetry natively.
- Pro tier: $20/mo for 3 seats + 1TB (dropped from $126).
- Downside: teleop/control panels somewhat limited vs a fully custom UI; heavy customization needs paid tiers.
**2. rosboard**
Single ROS node, run it, point a browser at `robot-ip:8888`. Explicitly built mobile-friendly. Extremely lightweight, ROS1/ROS2 compatible, extensible via one JS file per custom viz type.
- Limits: no live control/teleop out of the box (monitoring-only), no 3D/URDF visualization, not built for video streaming. Good for quick sensor dashboards, not a full ops console.
**3. Grafana + InfluxDB/Prometheus bridge**
Ready-made bridges exist (`ros2_monitor_grafana`, `robot_influx_bridge`, `diagnostic_remote_logging`'s InfluxDB connector, Telegraf bridges).
- Great for historical time-series (battery voltage, link TQ over time, topic Hz) and alerting.
- Weak for live: 3D/video have to be base64-encoded into the database as a hack, not a real video pipeline. No live teleop. Best as a secondary panel, not primary dashboard.
**4. Webviz-style / rviz-in-browser alternatives**
- **ut-amrl/webviz** — actively maintained, ROS1+ROS2 same codebase, low-bandwidth websocket-based, lets you set poses/nav goals from the browser (real control). Worth a serious look given the bandwidth constraint.
- **Vizanti** — smartphone-friendly 2D RViz replica + mission planner, runs fully offline on the robot, ROS2 branch exists, built for outdoor field robots.
- **PHNTM Bridge** — WebRTC-based ROS2 bridge, mobile-touchscreen-optimized, Docker control, built-in WiFi/system-load monitoring. Newer/smaller, less battle-tested than Foxglove.
- **rvizweb / omni-rviz2** — older, mostly stale, not recommended for a fresh ROS2 build.
- Original webviz.io (Cruise) is dead/archived.
**5. Rerun.io**
Excellent for perception/multimodal debugging (point clouds, images, TF) with a timeline UI and WASM browser viewer. ROS2 bridges exist (official + third-party "Rewire"). Oriented at offline/replay debugging, not live teleoperation — no joystick/control-command story. Skip unless deep sensor-data debugging is needed later in season.
**6. PlotJuggler**
Great for scalar time-series signal analysis (PID tuning, sensor plots), real ROS2 remote bridge (`PlotJuggler/plotjuggler_bridge`, WebSocket-based). Not a web app — native/Qt, doesn't meet the "open a link on my phone" requirement. Good companion tool for controls tuning at a laptop.
**7. Custom rosbridge_suite + roslibjs build**
What most competition robotics teams actually ship. Real examples: Eurobot teams' React/Vite dashboards, `CPRT/webUI` ROS2 rover dashboard (map, telemetry, video, node manager, waypoints, resizable Mosaic layout, WebRTC video built in), `rosviz-web` (Next.js/Three.js, bundles Prometheus/Grafana as secondary panel).
- Pattern: `rosbridge_server` (websocket, port 9090) + `roslibjs` client + React/Vite frontend + Leaflet for maps + Three.js for 3D + WebRTC video component.
- Full control over layout/joystick/UI, not that hard to build (walkthrough courses exist for joystick + camera feed + odometry dashboard). Tradeoff: you own the maintenance.
## Video streaming (critical given bandwidth)
Consensus: **use WebRTC, not MJPEG.** MJPEG is explicitly "avoid"/"do not use" for teleop — 100-500ms latency, 10-50 Mbps bandwidth for OK quality, far more than the link can give at range.
- WebRTC (VP8, hardware-encoded if possible) hits 30-250ms glass-to-glass, automatic NAT traversal, adapts bitrate live as bandwidth degrades — matches the graceful-degradation plan for the 2.4GHz video leg.
- Tuning: cap ~640x480, always sacrifice resolution before frame rate (below ~15fps operators struggle more than at low-res). Below ~2Mbps: 480x360/10fps as floor before pausing video entirely.
## NVENC (NVIDIA hardware video encoding)
NVIDIA's dedicated hardware video encoder ASIC, baked into every Jetson (Nano/TX2/Xavier/Orin) since ~2011. Encodes H.264/H.265 without touching CPU or main GPU compute.
- Case study (Formant, on Jetson): software H.264 at 1080p/30fps pegged all 6 CPU cores at 100%; switching to NVENC dropped CPU usage to under 25% and cut latency significantly. Essentially a free win if the rover's compute is a Jetson (Orin Nano/NX common for college robotics).
- **With Foxglove Bridge**: official ROS2 package `foxglove_compressed_video_transport` transcodes image topics via ffmpeg — point it at `h264_nvenc` instead of default CPU-only `libx264`. On Jetson, `jetson-ffmpeg` + NVMPI gets hardware H.264/H.265 wired into the pipeline. Foxglove's Remote Access also auto-transcodes to adaptive-bitrate WebRTC on its own regardless.
- **With custom rosbridge+React+WebRTC**: NVIDIA's `isaac_ros_h264_encoder`/`isaac_ros_h264_decoder` (Isaac ROS) use NVENC/NVDEC directly, optimized with NITROS transport to avoid extra CPU overhead vs generic `image_transport_plugins`.
- **AV1: skip it.** Jetson NVENC hardware does not support AV1 encoding at all (only H.264/H.265). AV1 hardware encode only exists on newer desktop/laptop GPUs (RTX 40-series+, recent Intel Arc, current-gen AMD), not embedded Jetson. Software AV1 would burn the CPU cycles NVENC is meant to save, on a link that's bandwidth- not compute-constrained.
- **H.264 vs H.265 on Jetson**: H.265 gives ~30-40% better compression at same quality, but browser/WebRTC support is spottier (good on Safari, patchy on Chrome/Firefox depending on hardware decode). H.264 is the safe universal choice for a browser dashboard and is what most WebRTC stacks and Foxglove default to.
- **Extreme reference point**: commercial teleop vendor Voysys, on Jetson AGX Xavier with NVENC, gets three 10-megapixel cameras down to ~300 kbps total (under 1% of "normal" bandwidth) combining hardware H.265, periodic intra-refresh (spreads keyframe data across frames instead of bursting, avoids congestion spikes on degraded links), and foveated compression (full res only where operator is looking). Proprietary, not installable, but proves the 0.2-0.4 Mbps floor is a survivable video budget with the right codec + keyframe strategy, not just resolution/fps cuts. Periodic intra-refresh specifically worth replicating if video ever needs to run over the 900MHz leg.
## Net recommendation
1. **Foxglove Bridge** — least engineering effort, handles 3D+video+telemetry out of the box, free-tier Remote Access solves the phone-link requirement without building networking, industry-standard so well-documented.
2. **Custom rosbridge_suite + roslibjs + React/WebRTC** — if full UI/UX control is wanted (custom teleop widgets, mission-specific panels) or avoiding vendor dependency. Higher build cost, well-documented pattern with competition-team prior art.
3. **ut-amrl/webviz or Vizanti** as a lightweight fallback to prototype alongside either option — both explicitly built for bandwidth-constrained field robots.
Skip Grafana as primary (secondary telemetry-history panel only, if wanted later). Skip MJPEG entirely for video. Use H.264 via NVENC if on a Jetson; don't chase AV1.