With Foxglove Studio’s new Image panel, you can now add useful context to your robots’ raw and compressed camera images with 2D annotations and 3D markers. The original Image panel – now renamed to “Image (Legacy)” in the app – is now deprecated and will be removed in a future release.

Adding overlays to your robots’ images

When reviewing your sensor images, you may want to verify that your autonomy stack is working as expected. For example, if your team develops self-driving cars, you may want to verify that your perception models are correctly classifying objects in its world (e.g. “car”, “bus”, “pedestrian”, etc.), and that your planning models are accurately differentiating between them to help the car navigate the world.

With 2D annotation and 3D marker topics, you can now add this debugging context to the image directly.

2D annotations come in three forms – text labels, circles, and points. To display them, publish a topic with ImageAnnotations messages. To toggle them on, select the ones you’d like to display in the panel settings’ “Image annotations” section:

2D annotations

With 2D annotations, you can label detected objects with text, or highlight relevant areas of a scene with circles, or delineate boundaries with points.

To display 3D markers, publish topics with any of the 3D panel’s supported message types – these can range from cubes and poses to point clouds and occupancy grids. First set a “Calibration” topic in the Image panel settings – this determines the camera’s field-of-view, and is used to transform 3D markers into the image’s 2D space. Then select the 3D markers you’d like to superimpose on the image in the “Topics” section:

3D markers

Superimpose bounding boxes, maps, and other 3D markers on your annotated camera images, for even richer context on what your robot is experiencing.

If you save these changes in a layout, you’ve instantly added useful context for your whole team to reference when debugging your robotics data!

Stay tuned

By including additional context in your robots’ camera feed images, you can use the new Image panel to accelerate your robotics team’s usual visualization and debugging workflows.

For more information on 2D annotations and 3D markers, you can check out our Image panel docs. You can also join our Slack community or contact us directly with any questions.


MCAP and ROS 1 bag are two broadly-comparable file formats for recording robotics data. Both formats specify a chunked container structure that supports heterogeneously-typed messages and includes a trailing index section to enable summarization.

MCAP's most publicized advantage over bag files is its support for arbitrary message serialization formats (e.g. Protobuf, FlatBuffers, CDR, etc.), while ROS 1 bags are constrained to messages serialized in the ROS 1 msg format.

In this post, we’ll highlight a less-publicized feature of MCAP over bag files: improvements in the index structure that enable faster summarization over remote connections or slow storage devices.

Summarizing ROS 1 and MCAP files

ROS bags and MCAP files may range from megabytes to hundreds of gigabytes or larger in size. Reading them off disk or across a network can be prohibitively expensive, especially if the goal is just to get a high-level summary of their contents.

The rosbag info and mcap info commands allow you to quickly summarize the contents of a ROS bag or MCAP file, including:

Topics and message types

Frequencies and message counts per topic

Start and end times of messages

Compression statistics

Comparing summarization performance over remote connections

Bag files and MCAP files are often accessed over remote connections - e.g. sharing recordings with a Network File System (NFS) file share or an Amazon S3 bucket.

Let’s compare the performance of rosbag info and mcap info when reading from local disk vs. over NFS. We’ll use the following bag files for our comparison:

small.bag

67.1 MB in size

79 chunks, 7 topics

1606 messages

large.bag

15.7 GB in size

9855 chunks, 58 topics

5304180 messages

Here are the timings for rosbag info on local disk:



And for mcap info, also on local disk:



Going off the wall clock execution times reported (real in the output), we can see that the mcap info command executes 22x and 42x faster than the rosbag info command. In fact, the MCAP timings are so low that they can be considered mostly noise.

Although this difference is striking, you may intuit that it is partially due to slow startup of rosbag’s Python interpreter.

Below are the same measurements taken over a remote NFS connection (NFS throughput from the server to the client is approximately 64Mbps):



Here, the differences explode to factors of 54x and 4458x. The rosbag info command is slow enough to be unusable over NFS, for both large and small files.

Understanding the performance gap

So why is performance of rosbag info so poor over NFS? And how does mcap info do better?

Let’s use strace to get some clues:



We see that rosbag info is doing a dramatically larger number of disk seeks and reads than mcap info.

For another view, let’s compare seek calls for rosbag info vs mcap info as a function of number of chunks in the file.

seek calls per chunks in file

We see that the number of disk seeks executed by rosbag info grows linearly in proportion to the number of chunks in the bag file. Meanwhile, the number of seeks executed by mcap info appears constant.

Excessive seeking and reading from different locations on disk is generally harmful for IO performance:

For hard disk drives, moving the disk head generally takes at least 5 milliseconds.

For all devices, reads happen at the granularity of file system pages, which are generally 4kb. Reading less than 4kb of data will still pull 4kb from disk or over a network if using remote storage.

Operating systems mitigate these effects by performing reads through a page cache. If a page is cached, it can be read from memory instead of from disk. However, pages are not cached when reading a file for the first time – in that scenario, disk IO will be required for every read.

So why does rosbag need to do so many seeks? Let’s inspect the rosbag info output for small.bag:



Let’s focus on the compression, uncompressed, and compressed lines. Like MCAP, the bag format uses a two-layer index structure in which the bottom of the file contains an index of chunks, and each chunk is followed by an index of messages within it. But unlike MCAP, the Chunk Info records that make up the chunk index contain no information about compression algorithms or compressed/uncompressed sizes.

To gather compression statistics, rosbag info must visit every chunk in the file to read compression information from the corresponding header. Since ROS bags are commonly recorded with a default chunk size of 768Kb (uncompressed), it does not take a very large bag to accumulate a large number of chunks. On a developer laptop, the effect of this may go largely unnoticed or get attributed to Python startup. But on remote filesystems, you will notice significant degradation for bags larger than a few megabytes, since every chunk will require seeking to and reading an uncached page. The amount of data in a chunk header is small in comparison to a 4kb page, so we’d be significantly overfetching to read a small amount of data.

This problem with rosbag cannot easily be fixed. Solving rosbag info performance would not be technically difficult, but it would require a breaking change: dropping compression statistics from the printed output. Since these statistics are quite useful, this is not so easy. An opt-in flag (i.e “--fast”) could be supported without much trouble, but introducing such functionality as a non-default behavior would still leave many consumers impacted.

Furthermore, the problem extends beyond the rosbag info command: it actually results from the start\_reading method, which is called any time a bag file is opened. Bag users will pay this cost every time they open a bag with the Python SDK.

Eliminating the problem with MCAP

Fast remote summarization was one of MCAP’s design goals.

In MCAP, all the data required to summarize the file is present in the summary section, and visiting the data section is never necessary. The mcap info command requires only two seeks: first to the footer, and then to the summary start. After seeking to the summary start, it reads to the end of the file and transforms the summary section into the output that it prints.

Consequently, mcap info’s performance is largely disconnected from the size of the file or the number of chunks. While the volume of data read is still linear with respect to the number of chunks, since there is one Chunk Index record in the summary section per chunk, the contribution of each chunk to the summary section size is negligible. For example, the summary section of large.mcap, a 12GB file, is only 820 kB.

Closing advice

If you're a new ROS user and looking to choose a data recording format, we recommend adopting ROS 2 to take advantage of MCAP’s performance. MCAP is the default recording format for ROS 2, has superior summarization and SDK performance, and will receive more community development attention going forward.

However, swapping out recording formats on an existing system may be easier said than done. For users unable to switch and struggling with IO performance, consider using skip\_index: True in your bag processing scripts. This will bring the cost of opening bags in line with what you get from rosbag info – not ideal, but better than the default behavior of the Bag constructor.

If you have any questions about MCAP, or need support adopting it for your robotics development workflows, feel free to join our community Slack or contact us directly for help.



Foxglove Data Platform users can now use custom properties to add metadata to their organization’s devices.

With custom properties, you can better organize, search, and filter your team’s data – even as your team and fleet scale.

Getting started

Custom properties are predefined metadata fields that users can associate with a resource in Foxglove Data Platform. They are created by organization admins, but any team member can populate them with values for a given resource.

Creating custom properties

Foxglove organization admins can go into their Custom properties settings to predefine custom properties that their team members can use to describe devices.

create custom property

Every custom property must have a human-readable label, a key that acts as a unique identifier, and a value type (e.g. “Single-line text”, “Dropdown”, “Number”, etc.)

For example, if your team has a fleet of robots on different hardware versions, you may want to create a numeric custom property called hardwareRevision for your team’s devices. This means that any member of their organization can add a hardwareRevision number to any device to keep track of their robots' hardware versions.

Adding custom properties to a device

Once admins have created a custom property for a resource (e.g. hardwareRevision for devices), all organization members can now navigate to that resource's page to add custom property keys and values.

add custom property to device

Users can navigate to a specific device's page to add a hardwareRevision to that robot.

Querying by custom properties

After assigning custom property values to various devices, you can navigate to the devices index page to query by those values.

query by custom property

Navigate to the devices page to search by custom property values.

Stay tuned

Custom properties can help your robotics team add structure to your device data and extract meaningful insights from them. They can make it easier than ever to manage, organize, and understand your fleet of robots – even as it scales. While custom properties are currently only supported for devices, we’re planning to add support for other data entities like recordings.

If you have any questions or feature requests, join our community Slack or contact the Foxglove team directly.


Introducing Custom Properties in Foxglove Data Platform

Getting started

Creating custom properties

Adding custom properties to a device

Querying by custom properties

Stay tuned

Read more:

Ready to try Foxglove?