We’re excited to announce that ROS 2 users can now record their data directly to MCAP files, for easy analysis with third-party integrations and developer tools.

rosbag2 now sets the rosbag2\_storage\_mcap plugin as the default storage format. Starting from the ROS 2 Iron Irwini release (coming in May 2023), you can record ROS 2 data to MCAP (.mcap) files by default, or opt to still use the fully supported SQLite3 (.db3) format.

Community-led development

This work is the culmination of a large community-led effort to improve existing tools for the next generation of ROS 2 users, and we’ve prioritized making this change as seamless as possible for the community.

We had the privilege of collaborating with ROS 2 maintainers at Open Robotics and Apex AI to add this out-of-the-box support for MCAP. As members of the ROS 2 Technical Steering Committee, we’re committed to continually improving ROS and making open source robotics development easier for all.

Check out our comparison of rosbag2 storage plugins for our extensive profiling of MCAP and SQLite3 performance.

Recording

SQLite3, the current ROS 2 recording format default, has a few limitations around recording efficiency and playback, which are addressed by MCAP. When recording, the SQLite3 storage plugin typically uses a “write optimized” mode – this achieves high write throughput at the risk of data corruption if recording is interrupted. This can be changed to a “resilient mode”, which removes the risk of corruption at the cost of write throughput. With MCAP, you can enjoy the data safety of SQLite3’s “resilient” mode, while also achieving the write throughput of its “write optimized” mode.

The MCAP storage plugin provides ROS 2 users with several configuration options for tuning the recorder. For example, you can choose between zstd and lz4 compression options, depending on your compute and compression needs.

Finally, MCAP files are fully self-contained, making it possible to use with third-party tools outside of the ROS environment. By including all necessary message definitions, MCAP files can easily be integrated with tools like Foxglove Studio or PlotJuggler, as they have the message definitions and information needed to decode the file.

Playback

When you now run $ ros2 bag play \<PATH\_TO\_FILE> to play back ROS 2 data files, it will automatically detect whether the file was recorded in MCAP or SQLite3 and decode as needed:



It’s important to note that rqt\_bag can also now handle both rosbag2 storage backends equally well.

Stay tuned

While there are no plans to deprecate SQLite3 support in ROS 2, we hope that the inclusion of MCAP as the default recording format going forward will simplify development and solve pain points for many robotics teams. And because MCAP is flexible enough to record heterogeneous data (e.g. ROS 1, ROS 2, Protobuf, JSON, FlatBuffers, etc.) in a single file, it can adapt to your team's framework choices and evolving data stack.

As you get started with this new recording format, we’d love to hear your feedback! Join the conversation in our Slack community or on Twitter, or check out the MCAP GitHub repo to file feature requests.


Robots are compound systems navigating complex worlds. To understand how they interact with other players in their environments, we can use mathematical operations called transformations. Transformations (or more simply, "transforms") express an object's position and orientation in relation to another.

In this tutorial, we'll cover how transforms describe the worlds that our robots navigate – not only by positioning their components in relation to each other, but also in relation to the objects they encounter.

Situating objects with frames

In robotics, a frame refers to the coordinate system describing an object's position and orientation, typically along x, y, and z axes. ROS requires each frame to have its own unique frame\_id, and a typical scene consists of multiple frames for each robot component (i.e. limb, sensor), detected object, and player in the robot's world.

A scene always has one base frame – usually named world or map – that is an unmoving constant. All other frames in the scene – including the robot’s own frame, which ROS typically calls base\_link – are children to this base frame, and are positioned relative to this parent in some way.

The robot’s base\_link frame usually starts at its base and branches off into child frames for limbs and sensors:

sensors
Visualizing the UR5 collaborative robot arm in Foxglove Studio's 3D panel. Each frame's x, y, and z axes are denoted by red, blue, and green arrows.

Each sensor’s frames can also branch off into further child frames for the objects they detect. In this way, all objects in a given scene are somehow defined in relation to the base frame and its child frames.

Connecting frames with transforms

Transforms define the translations and rotations needed to get from a source frame to a target frame – whether it's parent-to-child, child-to-parent, or across multiple "generations" of frames. A complete set of a scene's transforms, from the base frame to all its related children, constitutes a transform tree.

With a transform tree, you can quickly find the position and orientation of any given frame in the scene, no matter how many levels removed you are from the base. Transforms can be either static or mobile – static transforms (e.g. between base\_link and a sensor\_link frame) remain constant, while mobile transforms (e.g. between base\_link and either a robotic arm mounted to the base or a separate detected object) can change as the world does.

In ROS, transform messages are broadcast on two topics – /tf\_static (for static transforms) and /tf (for mobile transforms). This separation improves bandwidth and reduces the number of transforms being published. ROS also provides the tf2 library to help us calculate transformations between frames.

In the real world

Let's imagine a rover with a camera and robotic arm, navigating a flat maze:

robot

We can see that the rover's base\_link frame has static transforms to two child frames –  a sensor\_link frame representing the unmoving camera mounted to the front, and an arm\_base\_link frame representing the unmoving arm base mounted to the top.

We also see that the arm\_base\_link frame has a mobile transform to its own child frame – an arm\_end\_link frame representing the moving arm.

Building the transform tree

While ROS's tf2 library provides an easy way for us to calculate transforms, let's take a peek at what this library is actually doing under the hood.

Each child frame has a transform that represents its position vector and rotation in relation to its parent frame:

Parent: base\_link

sensor\_link – (2,1) position, -45° (π/4) rotation

arm\_base\_link – (1,-1) position, 30º (π/6) rotation

Parent: arm\_base\_link

arm\_end\_link – (1,1) position, no rotation

transforms

Given all this information, we can now use transforms to deduce arm\_end\_link's position in the base\_link frame!

Calculating an object's position using transforms

To start traversing our transform tree (from base\_link to arm\_base\_link to arm\_end\_link), we need two pieces of information:

T - 2D transform matrix between base\_link and arm\_base\_link (translation of dx over x and dy over y, rotation over z)

p – Position vector for arm\_end\_link in the arm\_base\_link frame

Let's set the following values in T matrix:

Φ = π/6 – Rotation of arm\_base\_link in base\_link

dx = 1 – Position (x) of arm\_base\_link in base\_link

dy = -1 – Position (y) of arm\_base\_link in base\_link

And the following values in the p matrix:

x = 1 – Position (x) of arm\_end\_link in arm\_base\_link

y = 1 – Position (y) of arm\_end\_link in arm\_base\_link

Finally, let's multiple these matrices together to get arm\_end\_link's position in the base\_link frame:

matrix operation

With our operation, we find that arm\_end\_link is in position (1.366, 0,366) of the base\_link frame!

Since arm\_end\_link is a mobile frame, it's important to note that this result is only valid at the robotic arm's current position and angle. As the transform between arm\_base\_link and arm\_end\_link inevitably changes, so will arm\_end\_link's position in space.

Learn more

Actual robots in the real world are often much more complex than our single-sensor example, and must navigate much trickier terrain than a flat maze. Calculating an object's position in its environment will often require multiplying more than two matrices to travel from a source frame to a target frame.

Fortunately for us, ROS provides the tf2 library to do the necessary transformation matrix math for us, so we can avoid doing these manual calculations ourselves!

Stay tuned for our next tutorial on how to use these libraries to publish and view transforms in Foxglove Studio. As always, feel free to ask questions, share feedback, and request a topic for the next blog post in our Slack community!


If you’re using Foxglove Data Platform to store, organize, and annotate robotics data, you may be curious about how exactly your team or company is leveraging the tool. How much data is being collected, and how is it being interpreted by your teammates?

To help you answer these questions, we’ve added an Insights dashboard to Foxglove Data Platform. In addition to helping you understand trends in your organization's data usage, we hope that this dashboard will also help you explore new ways to take full advantage of Foxglove features, optimize your development workflows, and reach your team's full potential.

Viewing organization insights

The Insights feature is only available to Foxglove organization administrators. Once logged in to your Foxglove account, navigate to your Settings page and select the Insights tab:

On this page, you’ll see two charts – for Import volume and Occurring events.

Import volume

This chart tracks the amount of data (net and cumulative) your Foxglove organization members have imported, by week:

Import volume chart

Tracking your import volume can give you a sense of the data storage your company will be billed for, whether you are nearing your plan’s data limit, and the periods of time when your team imported the most data.

Occurring events

This chart tracks the number of events added for a given week of collected data, by week:

Occurring events chart

Understanding which date ranges that team members has annotated the most can give you a general sense of your data coverage. Seeing how frequently team members are creating events can also help you understand whether the organization is taking full advantage of this powerful strategy for tagging and exploring data.

Learn more

By understanding how your team is processing and organizing data, we hope you can make better decisions about how to optimize these workflows for continuous improvement. In short, we hope this new Insights dashboard serves as another tool in your robotics development toolbox.

This version of the dashboard is just the beginning. We plan to add more visualizations to help you quickly understand how your team is using Foxglove. If you have suggestions for new features, we’d love to hear them! You can contact us directly, or join our Slack community to share your feedback.


Announcing Insights for Foxglove Data Platform

Viewing organization insights

Import volume

Occurring events

Learn more

Read more:

Ready to try Foxglove?