Do I need ROS installed to use Foxglove?

No, for recorded data. MCAP is Foxglove's own format and opens directly with no ROS runtime, no sourced workspace, and no bridge. A live connection to a running ROS graph does need the foxglove_bridge node running somewhere on the robot's network, since that's what exposes the graph over Foxglove's WebSocket protocol.

What's the difference between Foxglove and Foxglove Studio?

Foxglove Studio was the open-source visualization app; its last release shipped in February 2024. The commercial product that followed dropped "Studio" from the name and is now just Foxglove — a broader platform for visualizing, recording, and managing multimodal robotics data, not only a rebrand of the old app.

Can Foxglove open a ROS 2 sqlite3 bag, or only MCAP?

Both. MCAP is native and requires no conversion, and ROS 2's sqlite3-backed .db3 bags (and ROS 1 .bag files) are also supported for local playback. If you're archiving recordings long-term, though, MCAP's embedded schemas and indexed seeking still make it the better format to standardize on — see MCAP vs ROS 2 bag.

Is Foxglove only for live debugging, or also for reviewing recorded episodes?

Both are first-class, and for demonstration-data collection the recorded case matters more day to day. A saved layout scrubs through a recorded episode exactly like a live feed — same panels, same synced timeline — which is what makes it usable as a QA tool for reviewing dozens of episodes in a row rather than only a live debugging console.

Foxglove Integration: QA Robot Recordings

SHORT ANSWER

Foxglove is a visualization tool for timestamped robotics data — open a live ROS graph or a recorded MCAP file, lay out 3D scenes, camera feeds, and plotted signals side by side, and scrub through an episode frame by frame. In a demonstration-data pipeline it's the QA step between recording and training: the fastest way to catch a bad episode before it reaches a dataset.

Foxglove is a visualization tool built for timestamped, multimodal robotics data — camera streams, point clouds, joint states, transforms — arranged into panels and scrubbed through a synced timeline. It doesn't record data or train anything; it sits between the two, as the place a human actually looks at what a robot's sensors captured. For a demonstration-data pipeline, that makes it the QA layer: the tool a reviewer opens to decide whether an episode is clean enough to keep.

How the data gets there

Foxglove connects to data two ways, and the distinction matters for how you'll use it day to day.

Live connections go through foxglove_bridge, a node that runs alongside your ROS graph and exposes it over Foxglove's WebSocket protocol — a live feed of every topic, similar in spirit to rosbridge but supporting ROS 2 .msg/.idl schemas, parameters, and graph introspection natively. It's currently packaged for ROS 1 Melodic and Noetic, and ROS 2 Humble, Jazzy, Kilted, and Rolling. Point the Foxglove app at the bridge's host and port, and every currently-publishing topic becomes available to a panel immediately, no recording required.

# On the robot, alongside your normal ROS 2 nodes
ros2 launch foxglove_bridge foxglove_bridge_launch.xml port:=8765

Recorded connections open a file directly — and MCAP is Foxglove's own format, created by the company in 2022 specifically so a recording could be opened with no conversion step and no ROS install on the machine doing the reviewing. ROS 2 .db3 (sqlite3) bags and legacy ROS 1 .bag files are also supported for local playback, but MCAP is the one built around Foxglove's indexing and seeking from the start.

# Any machine with the Foxglove app, no ROS required
open demo_episode_014.mcap

Beyond the desktop app, Foxglove has grown into a broader data platform: recordings can be uploaded, organized, and shared through Foxglove's Data Platform rather than staying local files passed around by hand, and Foxglove Agent runs on the robot itself, watching a directory for finished recordings and uploading them automatically — including resuming an upload after a dropped connection, which matters for fleets collecting on cellular or intermittent links. For a data-collection team, that turns "review the recording" into a step that happens without anyone copying files off a robot manually. Both connection types render into the same panel set and the same scrubbable timeline — a live session and a recorded episode look and behave identically once they're on screen, which is what makes muscle memory built debugging a live robot transfer directly to reviewing a pile of recorded episodes later.

Building a QA layout for reviewing episodes

A layout built for reviewing demonstration episodes usually combines a small, consistent set of panels rather than a sprawling one-off arrangement:

3D panel: Robot model (URDF), point clouds, and TF frames rendered together — catches a miscalibrated camera or a stale transform at a glance
Image panel: One per camera, often with annotations overlaid — the fastest way to spot a dropped frame, a fogged lens, or an out-of-frame gripper
Plot panel: Joint positions, gripper command, or end-effector pose plotted against time — smooth curves versus sudden jumps distinguish clean teleoperation from jerky, hard-to-imitate motion
State Transitions panel: Discrete signals — episode phase, success flag, gripper open/closed — as a timeline of colored segments, useful for confirming episode boundaries land where the metadata says they do

Saved as a shared layout file, this becomes the same first look every reviewer gives an episode: play it once at speed to catch the obvious problems, then scrub to any moment the Plot or State Transitions panel flags as suspicious.

The workflow in practice

Teams running regular demonstration-collection sessions tend to settle into a rhythm where Foxglove sits right after capture and right before conversion:

Live-check the rig before collecting, connecting the bridge to confirm every camera and sensor topic is publishing at the expected rate before an operator starts a session — cheaper to catch a disconnected cable here than after forty recorded episodes.
Batch-review recordings at the end of a session, opening each MCAP in the shared QA layout and flagging anything with a dropped frame, a stalled joint-state stream, or a success label that doesn't match what the video shows.
Export a short clip or screenshot when flagging a specific problem for a teammate, rather than describing a timestamp in a chat message — Foxglove's per-panel export makes a bug report reproducible.
Only convert what passed review. QA in Foxglove happens on the raw MCAP capture, before the LeRobot or RLDS export step, so a bad episode gets caught once instead of silently degrading a training run downstream.

Gotchas

A live connection needs the bridge running, and it isn't started by default on most ROS stacks — it has to be added to your launch files deliberately, which teams sometimes discover only when they try to debug a rig that isn't publishing to Foxglove.
Large MCAP files can be sluggish to scrub at full resolution, especially with several high-resolution camera topics in one layout — down-sampling image topics for review-only layouts keeps the timeline responsive without touching the archived recording.
.db3 bags open, but they don't get MCAP's indexed seeking — reviewing a large sqlite3-backed bag is noticeably slower than the equivalent MCAP, one more reason to standardize recording on MCAP rather than converting only when something goes wrong.
Panel names and defaults change between releases — Foxglove ships frequently, and a layout saved a year ago may reference a panel option that's moved. Re-save shared QA layouts after major version bumps rather than assuming they're static.
"Foxglove Studio" and "Foxglove" are not the same product anymore. Tutorials, forum posts, and older internal docs written before the rebrand describe the open-source 1.x app; features referenced there — plugin APIs especially — don't all carry over to the current commercial product, so date-check anything you find before relying on it.

KEY FACTS

PRODUCT NAME: Foxglove — the commercial app; "Foxglove Studio" is the retired open-source 1.x line
LIVE ROS CONNECTION: foxglove_bridge, ROS 1 Melodic/Noetic and ROS 2 Humble/Jazzy/Kilted/Rolling
NATIVE FORMAT: MCAP — created by Foxglove and opened with no conversion step
PANEL LIBRARY: 20+ built-in panels, including 3D, Image, Plot, State Transitions, Topic Graph

/ QUESTIONS

Frequently asked

/ KEEP READING

Data formatsMCAPMCAP is a self-describing, chunked, indexed log format for timestamped multimodal messages, and the default ROS 2 bag storage plugin since Iron.Middleware and toolingROS 2Record robot demonstrations from a live ROS 2 graph with rosbag2, avoid the QoS and clock pitfalls that corrupt recordings, and export to training formats.Data qualityQA for Robot Demonstration DatasetsA QA pipeline for robot demonstration data: automated checks, human review sampling, an accept/reject/repair rubric, and metrics to track.Data qualityCalibrating a Multi-Camera Robot RigHow to calibrate intrinsics, extrinsics, and hand-eye transforms on a multi-camera rig, and verify the result with reprojection error.

Put this into practice.

Tell us what your robots need to learn. We will scope the rig, the operators, the protocol, and the first datasets — usually in one call.

Start a pilot Read the docs