Update on BAGEL (BAG ExpLoration): What's New

Hi again,

Following up on my earlier post about BAGEL, a browser-based ROS bag viewer/editor with no native dependencies and no ROS install. Since v1.0 it’s grown from a viewer into something closer to a full robotics debugging tool. Quick links for anyone new here:

Link: https://bagel-ros2.vercel.app

Source: GitHub - Hussain004/BAGEL: ROS Bag Visualizer · GitHub

Full changelog with design rationale: BAGEL/FEATURES.md at main · Hussain004/BAGEL · GitHub

What’s new since v1.0:

Bag editing (v1.1, v1.2)

  • Trim by time range, drop topics you don’t need, export a fresh indexed MCAP, all client-side, no CLI.

  • Works across every format BAGEL reads: .mcap, ROS2 .db3, and ROS1 .bag all edit down to MCAP now.

URDF robot models and richer 3D (v1.3)

  • Drop a URDF (or paste one) and the robot animates in the 3D scene, following the bag’s /tf and joint states.

  • MESH_RESOURCE and TRIANGLE_LIST markers render real meshes instead of a placeholder.

  • CameraInfo overlay (principal point reticle, intrinsics badge), a wireframe camera frustum in the 3D scene, and one-click undistort using the calibration.

  • Saved per-data-type display defaults, loop playback, per-camera frustum hide toggles.

Analysis and shareability (v1.4)

  • Bag Health dashboard: per-topic Hz, jitter, gaps, and bandwidth with color-coded waately see which topic dropped out or is publishing erratically.

  • Inline math expressions as derived plot series (unit conversions, vector magnitudes, bias correction), real tokenizer/AST, no eval.

  • Export any panel as a WebM video or PNG sequence for a time window.

  • Timeline bookmarks/annotations that round-trip through the share URL.

Live robot data (v1.5)

  • The big one: paste a ws:// URL (the same protocol Foxglove Studio and foxglove_bridvery panel updates in real time from a running robot. No ROS install, no account, justa browser tab.

  • Record live sessions straight to a proper indexed MCAP from the browser.

  • Works over ROS1 bridges too, not just ROS2. - Sim clock (/clock) support, so Gazebo/Isaac Sim sessions get correct timestamps ins

  • Cross-bag health comparison when multiple bags are loaded.

Format breadth and RViz parity (v1.6) - Standalone .pcd / .ply viewer, no bag wrapping needed.

  • Foxglove Studio’s JSON-schema MCAPs (foxglove.* types) decode correctly now instead of showing empty panels.

  • WebCodecs-based H264/H265 video decoding for foxglove.CompressedVideo topics.

  • Zoom and pan in the image viewer.

What’s next?

v1.7 is up next: a 3D measurement tool (click two points, get a distance), nav_msgs/Path rendering, more colormaps, image-on-point-cloud projection using camera intrinsics, then bag merge/split, then QoS inspection (surfacing reliability/durability/history per topic).

1 Like

Is this bagel :bagel: related to that bagel :bagel: ?

No it is not. This one here is pronounces “bag” :shopping_bags: “ul”.

The improvements look nice.

I’ve tested it on a mere 3.5 GB local MCAP bag, and it seems that loading time-series data (IMU, battery) is veeeery slow. 6k messages load for about 5 minutes. The pointclouds and images, do, on the other hand, load almost instantly.

Also, compressedDepth codec is not supported.

1 Like

Thanks for the testing, this is exactly the kind of report that’s useful :smiley:

compressedDepth is now fixed. It wasn’t handled at all before, formats like “16UC1; compressedDepth” or “32FC1; compressedDepth png” fell through to the plain PNG/JPEG path and either failed to decode or produced garbage. Added a proper decoder: strips the 12-byte ConfigHeader, decodes the PNG at full 16-bit precision, and applies the depthQuantA/depthQuantB dequantization for the 32FC1 inverse-depth case. RVL-compressed depth isn’t supported yet, if your bag uses that you’ll get a clear error instead of a silent bad decode. Let me know if you hit it and I’ll bump it up the list.

About the time-series loading I have fixed two real inefficiencies: the ROS2 message-schema parser was re-parsing the full grammar on every single message instead of once per topic, and the plot was re-flattening the entire accumulated array from scratch on every streamed batch instead of just the new messages. Though neither of those was the dominant cost on your 3.5GB bag. Images/pointclouds feel instant because they only need one message at the playhead; a full-topic time series has to decompress every chunk touching that topic, and since MCAP interleaves topics within a chunk, that’s close to the whole file, decompressed in pure JS rather than WASM (a deliberate tradeoff, the WASM zstd module didn’t bundle cleanly with our build tooling). That’s the bigger lever and I haven’t pulled it yet, so time-series loading on a bag your size will still be noticeably slower than pointclouds, just not as bad. It’s on my list!