Being able to see the world as your robot does is critical for robotics development. Foxglove Studio’s 3D panel is a particularly dense visualization tool for just that – it renders a myriad of poses, point clouds, and other visualization markers to paint a picture of what your robot may have encountered out in the world.

Today, we’re excited to announce a beta version of our new and improved 3D panel. We’ve taken the powerful features of our original panel, and made them more performant, responsive, and delightful to use. We’ve also moved the panel’s topic tree and settings editor into the sidebar, to maximize the real estate you can use to hone in on and inspect your 3D data.

Selected object

Select the 3D (Beta) panel from the Foxglove Studio sidebar to get started!

panel list

We’re excited to hear what you think! Share your thoughts on Slack, Twitter, or GitHub to let us know what other features you want to see supported. We’d love to find new ways to streamline your workflows and help your team reach its full potential.


If you're using ROS 1, check out The Building Blocks of ROS 1 instead.

Note: ROS 2 has integrated several packages described in this post (e.g. rqt\_console, rqt\_graph, rqt\_plot, etc.) as plugins in the rqt meta-package. For the purposes of this post (i.e. covering different features in discrete steps), we've opted to call out the individual packages in the CLI commands (e.g. ros2 run rqt\_graph rqt\_graph vs. rqt). Check out the rqt docs for more information.

If you’ve kept up-to-date on tech’s latest robotics projects or tinkered around with your own robot kit, you’ve probably come across mentions of ROS 2.

At its core, the Robot Operating System (ROS) is an open source software suite built to simplify robotics development. It provides a collection of tools that runs everything from low-level device control, hardware abstractions, and package management. Due to its distributed design, users can pick and choose what parts of ROS to integrate into their own projects.

ROS was born in 2007, out of roboticists’ desire to more easily share resources and build upon each other’s work. These experts experienced firsthand how difficult it was building software for an increasingly diverse array of robots across a variety of platforms, and realized that no one person was equipped to tackle the field’s challenges alone. They hoped a deliberately modular framework like ROS would foster more collaborative robotics development and encourage code reuse among the community’s brightest minds.

The ROS 2 Project emerged around 2015, when ROS 1's commercial shortcomings were becoming ever more apparent. By leveraging what was great about ROS 1 and improving what wasn't, ROS 2 contributors began evolving the framework to incorporate new use cases and technologies and to address the real-world challenges roboticists were facing.

Nearly 15 years after its conception, the ROS ecosystem now consists of tens of thousands of users worldwide, with applications ranging from COVID-19 disinfection robots to humanoid robotic hands. Its members have contributed cutting-edge libraries like map generation systems, navigation tools, and computer vision utilities, ensuring ROS’s continued relevance in the robotics world.

Basic concepts

ROS is a distributed framework of self-contained processes, or nodes, that discover and communicate with each other at runtime. Any given robot can have multiple nodes, each of which owns a subset of the robot’s tasks – one node may keep track of the robot’s velocity, another its steering angle, and still another its camera feed. All nodes communicate with each other via DDS (Data Distribution Service), a middleware protocol that drives a distributed architecture and allows nodes to discover each other.

Nodes communicate with each other by publishing or subscribing to messages on different channels of information, called topics. In this way, we can separate concerns into their respective nodes, while still empowering the robot to make complex decisions to execute a task. Nodes can be grouped into packages, which can then be easily shared and distributed among ROS users.

ROS nodes

Messages for a topic adhere to a fixed schema, called a message type. For example, one topic can contain messages with just position coordinates (geometry\_msgs/msg/Point), another lidar point cloud data (sensor\_msgs/msg/PointCloud), and still another text logs (std\_msgs/msg/String).

A message type is defined via multiple fields, each with a specified type. For example, the geometry\_msgs/msg/Pose message type consists of a position and orientation field, each of which have their own message type definitions:

message types

In summary, if nodes are like walkie-talkies that can communicate with each other, then topics are the channels that they broadcast audio on, and messages are the words that travel across these channels. In the same way that certain walkie-talkie channels are reserved for specific types of communication, each ROS topic is also reserved for messages that adhere to a specific type.

Useful commands

To get started using ROS, you will need to install it on your machine – ROS 2 provides installation instructions for Ubuntu, Windows, and macOS.

Use ros2 run to run nodes contained in various ROS packages.

For example, ros2 run turtlesim turtlesim\_node will find the turtlesim ROS package and run its turtlesim\_node to bring up a simulation of swimming turtles on your desktop. Running ros2 run rqt\_graph rqt\_graph will run that package’s rqt\_graph node to render a graph of your nodes connected by their publications and subscriptions.

Once you have a few nodes from different packages running, use ros2 node to display information about your currently active nodes.

ros2 node list – Lists current nodes.

ros2 node info /your\_node\_name – Provides more information about a given node, including publications and subscriptions.

Once you have several nodes running, use ros2 topic to fetch information for any published topic.

ros2 topic echo /your\_topic – Displays messages published to a given topic.

ros2 topic list – Prints information about active topics.

ros2 topic type /your\_topic – Returns the message type for a topic.

ros2 topic pub /your\_topic geometry\_msgs/msg/Point \[args] – Publishes data to a given topic with a specified message type.

Finally, use ros2 interface to inspect messages and their types in more detail.

ros2 interface list – Lists all message types.

ros2 interface show geometry\_msgs/msg/Point – Displays the fields for a given message type.

Useful packages

Given how extensive the ROS environment is, it is easy to get overwhelmed by the selection of available packages. Here are a few popular data visualization packages that you can get started with:

rviz – Provides a 3D visualizer for ROS messages.

rqt\_console – Provides a GUI for displaying and filtering ROS messages.

rqt\_graph – Visualizes the ROS computation graph – i.e. nodes and the topics they publish and subscribe to.

rqt\_image\_view – Displays camera images using image\_transport.

rqt\_plot – Plots numeric values on a 2D chart.

How Foxglove Studio fits in

While the ROS ecosystem offers an impressive array of features and services, it can be overwhelming to find, install, and run them all at once. ROS is also tightly bound to specific versions of Ubuntu, which introduces significant overhead for users interested in quickly viewing their data.

Studio has integrated many of ROS's visualization and debugging tools into one cross-platform desktop application, so that instead of memorizing package names and CLI commands, you can simply drag and drop a panel from our menu into your layout to start seeing results. For example, we've incorporated features similar to rqt\_console, rqt\_graph, rqt\_image\_view, and rqt\_plot, into our Raw Messages, Topic Graph, Image, and Plot panels, respectively. Check out our docs for a list of commonly used developer tools that we've integrated into the Studio app.

Studio further streamlines visualization and debugging workflows by allowing users to load .db3 files directly into the app – you no longer need to run ros2 run and ros2 bag in multiple terminals every time you want to inspect your data.

Studio panels vs ROS tools

Studio also supports user contributions to an extensions library, so you can build your own project-specific panels to customize your robotics development workflows.

To learn more about how Foxglove Studio can accelerate your robotics development, feel free to check out our docs or reach out to us directly in our Slack community.


When we announced MCAP, a standardized container format for storing heterogeneous robotics data, we wanted to empower teams to spend less time building commodity tools and more time tackling their hardest robotics challenges. Not only does MCAP address the shortcomings of existing storage options, it also makes third-party tools (like Foxglove Studio and Data Platform) extremely easy to leverage, regardless of your data format.

To help you make the transition, we released an MCAP reader and writer with Python, C++, Go, TypeScript, and Swift support earlier this year. In this tutorial, we’ll cover how to write an MCAP writer in Python to record JSON data to an MCAP file. We’ll then load up our MCAP file in Foxglove Studio to inspect the contents of our data.

Finding and decoding CSV data

For the purposes of this tutorial, let’s work with some publicly available robotics data. We’ll be using the “Sydney Urban Objects Dataset”, released by the Australian Centre for Field Robotics at the University of Sydney.

Sydney Urban Objects Dataset

This CSV dataset contains a variety of common urban road objects scanned with a Velodyne HDL-64E LIDAR. The 600+ scans – from vehicles and pedestrians to signs and trees – were originally collected in order to test matching and classification algorithms.

Each scanned object contains the following fields:

t - Timestamp

intensity - Laser return intensity

id - Laser ID

x,y,z - 3D point coordinates

azimuth - Horizontal azimuth angle

range - Range of laser return

pid - Point ID of the original scan

Decoding this data is pretty simple, thanks to Python’s built-in csv and datetime libraries:



This prints out the timestamp, intensity, and coordinates for each point in the CSV file you choose to read in:



Encoding the data into a foxglove.PointCloud

To later view a given CSV file’s point cloud in Foxglove Studio, we must encode the point data in a way that Studio will understand. Fortunately, Studio provides a collection of message schemas that it knows how to display. For this tutorial, we’ll focus on building a JSON point cloud, using the foxglove.PointCloud schema. While JSON might not be the most efficient format for storing point cloud data, it’s easy to get started with! We will cover other serialization formats supported by MCAP (like Protobuf) in future tutorials.

| field         | type                  | description                                                      |
| ------------- | --------------------- | ---------------------------------------------------------------- |
| timestamp     | time                  | Timestamp of point cloud                                         |
| frame\_id     | string                | Frame of reference                                               |
| pose          | Pose                  | The origin of the point cloud relative to the frame of reference |
| point\_stride | uint32                | Number of bytes between points in the data                       |
| fields        | PackedElementField\[] | Fields in the data                                               |
| data          | bytes                 | Point data, interpreted using fields                             |

Let’s start with encoding the point data. The foxglove.PointCloud schema expects a data field that contains a single base64-encoded buffer with all point data, as well as a fields field that contains metadata describing how to decode the data.

Since foxglove.PointCloud requires a single timestamp, let’s get it from the first point we see in our file. Then, we’ll pack each field as a four byte single-precision little-endian float.

Let’s start by describing the layout of our data in a foxglove.PointCloud message:



Next, let’s pack the points using Python’s built-in struct and base64 libraries.



In Studio, each 3D object exists in its own coordinate frame. A point cloud’s frame\_id identifies the coordinate frame it belongs in, and its pose determines its relative position from that coordinate frame’s center.

Since we will only have one coordinate frame in our MCAP file, you can choose any arbitrary string as our frame\_id, and use the identity pose to place our point cloud in its center.



We’ll leave the timestamp field for later, when we write the messages into the MCAP file.

Writing the MCAP file in Python

Now that the point cloud is built, we can write it into an MCAP file.

An MCAP file has messages, which are organized into channels, each of which adhere to a particular schema. A message's channel informs the reader of the topic it was originally published on, while a channel's schema describes how to interpret the message's content.

Writing the header

We’ll start with some imports from the Python MCAP library:



Next, let’s open a file where we’ll output our MCAP data and write our header:



Creating a channel

Let's create a channel of messages to contain our point cloud. The schema's name and content tell Foxglove Studio that it can parse and display this message as a point cloud.



Writing a message

Let's write a single foxglove.PointCloud message on the channel we just created:



Close the MCAP writer to include the summary and footer in your output MCAP file:



That’s it! We now have a valid MCAP file with a single point cloud message.

Inspecting your MCAP file

To inspect your MCAP file, install the MCAP CLI tool:



Run the following commands to summarize your file’s contents and to verify that it has no issues:



For a more visual representation of this data, let's use Foxglove Studio. Open either the desktop or web app, and add a Raw Messages and our newly added 3D (Beta) panel to your layout.

Then, simply drag and drop your output MCAP file into the app window to start playing the data. Make sure to enable the pointcloud topic in the 3D (Beta) panel to display the point cloud in 3D space. You can also inspect the raw data for the pointcloud topic in your Raw Messages panel:

Foxglove Studio

Stay tuned

This tutorial covered writing JSON data to an MCAP file using Python, but this is just the beginning. You can also read MCAP files, use other data formats (like ROS 1, ROS 2, and Protobuf), and write your reading / writing code in other languages (like C++). Our blog post Recording Robocar Data with MCAP, for example, covers how you can write Protobuf data using an MCAP C++ writer.

Check out the Python docs for more info on reading and writing MCAP files in Python, as well as the official MCAP website for a list of all the other languages we support. And as always, feel free to reach out to us in our Slack community to ask questions, give us feedback, and request a topic for the next tutorial!


Recording JSON Data to MCAP Files

Read more:

Ready to get started?Download today on Linux, Windows, or macOS.