RViz2 vs Foxglove: Visualising and Debugging a Robot in the Field

TL;DR: In the RViz2 vs Foxglove comparison, RViz2 is the native ROS 2 visualizer that runs inside your ROS graph, offers the richest 3D display types and plugin ecosystem, and costs nothing – but it assumes a working DDS connection and a local ROS 2 install. Foxglove is a separate application that connects over a WebSocket bridge or opens MCAP/ROS bag files directly, works in a browser or desktop app, simplifies remote access and bandwidth control, and adds layout sharing plus a hosted data platform on paid tiers. Most field teams running a Leo Rover or similar UGV end up using both: RViz2 on the robot’s own network or over a VPN for live navigation debugging, Foxglove for remote links, recorded-data review, and sharing a reproducible view with colleagues.

Why does field debugging break the tools that work on your desk?

On a bench, almost any setup works. The robot sits two meters away on gigabit Ethernet, DDS multicast discovery finds everything instantly, and you can plug in a monitor if something goes wrong. Latency is a millisecond. Bandwidth is effectively unlimited.

Field conditions remove all of those assumptions. A rover driving a test plot or an inspection corridor is reachable over 2.4/5 GHz Wi-Fi at the edge of range, an LTE modem with a carrier-grade NAT, or a mesh radio with a few megabits of real throughput. Packet loss is not an exception. DDS discovery over such links is fragile: multicast is frequently blocked, participant discovery floods the link, and a single large topic – an uncompressed 1920×1080 8-bit RGB camera stream is roughly 6 MB per frame before compression – can saturate everything else.

So the practical question is not “which visualizer looks nicer.” It is: which tool still gives you a usable picture of the robot’s state when the network is marginal, and which one lets you reconstruct what happened after the robot comes back. That is where RViz2 and Foxglove diverge meaningfully.

What is RViz2 and where does it fit?

RViz2 is the 3D visualization tool maintained as part of the ROS 2 distribution. It is a ROS 2 node. It uses the same rmw/DDS middleware as the rest of your system, subscribes to topics directly, and publishes back – interactive markers, 2D Pose Estimate, 2D Goal Pose. That bidirectional, in-graph nature is its defining property.

What this buys you in practice:

• Displays that understand ROS semantics natively. TF trees, costmaps, laser scans, point clouds, occupancy grids, robot models from URDF, path and trajectory messages – all first-class, all tied to a frame and a time.
• Tool interaction. Setting an initial pose for AMCL or dropping a Nav2 goal from the 3D view is a click. Foxglove can publish messages too, but RViz2’s navigation tooling is the reference implementation the Nav2 docs assume.
• Plugin surface. Any package can ship an rviz_common::Display or rviz_common::Tool plugin. Nav2, MoveIt 2, and many perception stacks do. If you work with manipulators, the MoveIt Motion Planning plugin for RViz2 has no direct Foxglove equivalent.
• Zero licensing friction. RViz2 is open source under the BSD license and ships with ROS 2 desktop installs. No account, no tier, no seat count.

The cost is coupling. To run RViz2 you need a machine with a compatible ROS 2 installation, message definitions, and middleware configuration, on a network where your DDS implementation can discover and reach the robot’s participants. Mixing ROS 2 distributions or middleware implementations can work in limited cases, but is not generally a supported deployment assumption. On a flaky link, RViz2 inherits whatever DDS does under loss, which with the default reliable QoS means retransmissions and growing queues rather than graceful degradation.

Making RViz2 survive a weak link

Several configuration choices materially improve RViz2 over marginal networks. Before changing anything, confirm you can reach the robot at all with ros2 topic list and ros2 topic hz.

• Set ROS_DOMAIN_ID consistently and use a discovery server (Fast DDS) or a unicast peer list rather than relying on multicast.
• Subscribe to compressed image transports. image_transport republishers give you compressed and theora variants; RViz2’s Camera and Image displays can use available image transports.
• Reduce point cloud density at the source with a voxel grid filter instead of pushing full-resolution clouds across the link.
• Use Best Effort QoS on high-rate sensor topics in the RViz2 display settings so a dropped packet does not trigger retransmission.
• Prefer a VPN (WireGuard, ZeroTier, Husarnet) over port-forwarding so DDS sees a flat, routable network.

What is Foxglove and how does it differ from RViz2?

Foxglove is a visualization and debugging application built around panels in a configurable layout. It is available as a desktop app and in the browser. Crucially, it is not a ROS node. It connects to a live robot through the foxglove_bridge package – a WebSocket server that runs on the robot and serializes ROS 2 messages to connected clients – or it opens recorded files locally.

That architectural choice is the main thing that separates the two tools in the RViz2 vs Foxglove decision:

• One TCP WebSocket instead of a DDS mesh. You expose a single port. No multicast, no discovery storm, no participant churn. This is far easier to tunnel, firewall, and reason about.
• No ROS install required on the viewing machine. Teammates on macOS or Windows can open the browser app and connect. Schema definitions are transmitted over the bridge, so Foxglove can render many message types it has not been preconfigured to recognize.
• Selective subscription. Foxglove only requests topics that visible panels need. Closing a panel stops that subscription. On a constrained link, that is a practical bandwidth control.
• Panel-based UI. 3D, Image, Plot, Raw Messages, State Transitions, Log, Teleop, Diagnostics, Map, Table, Gauge, Indicator. The Plot and State Transitions panels in particular replace a separate rqt_plot workflow.
• Layout portability. A layout is a JSON document. You can export it, commit it to a repo, and hand it to a colleague who then sees exactly the panels and topic bindings you did.

Foxglove’s free offering covers use of the application for individual workflows. Team features – shared layouts across an organization, hosted recording storage, and data management – sit on paid plans. Pricing and tier contents change, so verify the current terms on Foxglove’s own site before building a workflow around a specific feature.

MCAP and why recorded-data review matters more than live view

Foxglove developed MCAP, an open serialization-agnostic container format for timestamped messages. MCAP is the default storage plugin in rosbag2 for ROS 2 Jazzy and is available as an option in earlier distributions via rosbag2_storage_mcap. It supports self-describing message schemas, chunked compression, and indexed seeking.

For field work this matters more than any live panel. A rover on a test run records locally at full fidelity regardless of link quality. You retrieve the file afterward, open it in Foxglove, scrub the timeline, and correlate the laser scan, the TF tree, the costmap, and the controller’s velocity command at the exact moment the robot stalled. RViz2 can replay bags too – run ros2 bag play and point RViz2 at the resulting topics – but RViz2 itself has no timeline scrub bar or synchronized plot alongside the 3D view.

How do the two tools compare feature by feature?

The table below summarizes the practical differences relevant to field robotics. Treat it as a decision aid rather than a scoreboard; the correct answer for most teams is a combination.

What does a typical field-test setup look like?

The following is a configuration Fictionlab’s team finds practical for outdoor testing with a Leo Rover class platform. It assumes a Raspberry Pi or similar single-board computer on the robot and a laptop in the field.

1. Record everything on the robot, always. Run ros2 bag record with the MCAP storage plugin on the robot’s own storage. Record the full topic set you might need, not the subset you think you need. Storage is cheap; a repeated field trip is not.
2. Run foxglove_bridge as a systemd service on the robot. Default port 8765. Configure a topic allow list so the bridge does not advertise every internal debug topic.
3. Put the laptop and robot on a VPN. WireGuard or an equivalent overlay gives you a stable address regardless of whether you are on local Wi-Fi or LTE. This also makes RViz2 usable when you need it.
4. Use Foxglove as the primary live view in the field. Build a layout with a 3D panel, a compressed image panel, a Plot panel bound to /cmd_vel and odometry, a Diagnostics panel, and a Log panel. Export that layout to your repo so every operator starts from the same view.
5. Switch to RViz2 when you need to interact with Nav2. Setting an initial pose, dropping goals, inspecting the global and local costmaps with full display options – RViz2 remains the fastest path. Over VPN this is acceptable if you keep subscriptions lean.
6. Review MCAP files afterward in Foxglove. Scrub to the failure moment, step frame by frame, and correlate the sensor data against controller output. This is where most of the actual debugging happens.

A note on expectations: throughput figures depend entirely on your radio, terrain, and interference environment, so no universal numbers apply. Measure your own link with iperf3 before blaming the visualizer. In testing, teams frequently discover the bottleneck is an uncompressed image topic rather than the tool rendering it.

When should you pick one over the other?

The RViz2 vs Foxglove choice resolves fairly cleanly once you name the task.

Favor RViz2 when you are developing on a bench or a stable LAN, your work centers on Nav2 or MoveIt 2 where the dedicated plugins save real time, you need a custom C++ display plugin for a proprietary message type, or you need the tool chain to remain fully open source with no external service dependency. Research groups and university labs working through structured curricula often standardize on RViz2 for exactly this reason – see how it fits typical education and teaching workflows.

Favor Foxglove when the robot is remote and the link is imperfect, when teammates without a ROS install need to see what the robot sees, when your debugging loop is dominated by recorded-data review rather than live interaction, or when you want a reproducible layout that travels with the project. Cross-platform access matters disproportionately in mixed teams.

Use both when – and this covers most serious field programs – you have a development phase and a deployment phase with different constraints. The two tools do not conflict. Both can connect to the same robot simultaneously, and foxglove_bridge has modest overhead when idle.

Frequently asked questions

Can RViz2 and Foxglove run at the same time against one robot?

Yes. RViz2 subscribes over DDS; Foxglove connects to foxglove_bridge, which is itself just another ROS 2 node subscribing over DDS. Both see the same topics. The only consideration is bandwidth: two clients subscribing to a high-rate camera topic can substantially increase outbound traffic from the robot. On a constrained link, keep one client lean.

Does Foxglove require an internet connection or an account?

The desktop application can open local MCAP and bag files and connect to a local foxglove_bridge without internet access. The browser application and hosted data-storage features require connectivity, and hosted features may require an account. If you work in locations without reliable connectivity, install the desktop app and verify your intended workflow offline before the field trip.

Is MCAP better than the SQLite3 rosbag2 format?

For most field use, MCAP is the better default. It is the default storage plugin in ROS 2 Jazzy, supports chunked compression and indexed seeking, and can embed message schemas. SQLite3 remains valid and is still available. Embedded schemas make MCAP files easier for compatible tools to inspect and share, although decoding custom ROS message data still depends on the reader supporting the relevant schema encoding and serialization.

Why does RViz2 show nothing even though ros2 topic list works?

The two most common causes are QoS mismatch and TF problems. If a publisher uses a QoS profile incompatible with the display’s subscription – for instance a sensor publishing Best Effort while RViz2 requests Reliable – no data flows. Set the display’s QoS to match. The second cause is a missing or stale transform: if RViz2 cannot resolve the message frame into the configured Fixed Frame, it drops the data silently. Check ros2 run tf2_tools view_frames output.

Can Foxglove send commands to the robot, or is it read-only?

It can publish. foxglove_bridge supports publishing to topics and calling services when enabled, and Foxglove ships a Teleop panel that can publish geometry_msgs/Twist. Treat this with caution over a high-latency link: teleoperating a rover with hundreds of milliseconds of round-trip delay is a reliable way to drive into something. Use it for discrete commands rather than continuous driving.

Which tool handles point clouds better over a slow link?

Neither tool solves this on its own, because the problem is upstream. A dense LiDAR cloud is large before it ever reaches the visualizer. The fix in both cases is source-side reduction: apply a voxel grid filter, crop to a region of interest, or publish a decimated topic specifically for remote viewing. Foxglove’s selective subscription helps in that you can close the 3D panel and stop the flow entirely, but the real gain comes from publishing less data.

Does choosing Foxglove lock the project into a vendor?

The data layer does not. MCAP is an open specification with multiple independent readers and writers, and foxglove_bridge is open source. Layouts are plain JSON. What sits behind a paid tier is the collaboration and hosted-storage layer, not the ability to read your own recordings. Verify the licensing terms of each component against your organization’s policy before standardizing, since terms can change.

Where to go from here

Both tools reward time spent configuring them properly before you are standing in a field with a stalled robot and twenty minutes of battery left. Build your Foxglove layout and commit it. Write your .rviz config and commit that too. Set up the VPN at your desk, not at the test site. Record to MCAP by default so that every run leaves behind something you can replay.

If you are evaluating platforms for outdoor experiments, dataset collection, or algorithm validation, Fictionlab documents how the Leo Rover is used across field deployments and lab work. Explore the research applications overview to see the sensor configurations, ROS 2 integration details, and typical field setups other teams build on.