Bernardo Taveira is a racing enthusiast, having spent the past 3 years involved in the Formula Student competition – first in the vehicle dynamics area, and now picking up the new driverless challenge. After finishing his master's in Systems, Control and Mechatronics, he hopes to pursue a career in the automotive field developing autonomous car software.

Kilian Freitag is a Complex Adaptive System student and a robotics admirer, who previously didn’t have much to do with racing but was working on other types of mobile robots (like those that can follow humans, for instance). He can be found in the mountains when not in front of a screen.

As students at the Chalmers University of Technology in Sweden, we love writing code that interacts with the real world. This passion is what inspired us to participate in our university's Driverless Formula Student team this year.

Our team’s history

Formula Student is the largest engineering student competition in the world, with over 600 teams from every continent. We’re especially proud to be members of the Chalmers Formula Student team, the oldest Swedish team in the competition with over two decades of experience.

We thrive to design, build, test, and race a better formula-style car every year. For the past 4 years, we have been building electric 4-wheel drive cars fully made of carbon fibre, capable of accelerating from 0 to 100km/h in under 2.5 seconds.

This year we introduced a car named Hilbert, which introduced driverless capabilities for the first time in our team’s history. This momentous milestone opens the door for us to compete in both the driverless and manual-driven classes this summer.

Hilbert car

Our goals for the 2022 season

Our team is divided in several subgroups: Frame, Aero, Powertrain, Suspension, Electronics, and Software. Software is further divided into 3 subgroups: Low Level, Control, and Driverless.

As members of the Driverless subgroup, we are responsible for everything from gathering data from the car’s sensor inputs and dealing with telemetry to logging all signals and generating its driving command output. Consequently, we function as one of the highest-level software teams in the whole project.

In previous years, we’ve run into challenges with deploying updated code to the car and debugging data live. We’d also encountered challenges with monitoring signals without a wireless connection, as well as reusing and building on programs written by previous teams. Adding driverless capabilities meant that we would be dealing with even more signals, and keeping track of even more potential points of failure.

With all this in mind, we decided to make robustness a core focus for this year. We wanted to establish a baseline software stack for a driverless car that would be easy to analyse and improve upon in the coming years.

Our tech stack

For our hardware stack, we chose a LiDAR as our main sensor – having accurate spatial awareness was of the utmost importance to our mission. While a camera may be very good at detecting different objects, we only have to deal with cones, which are easily detectable in a point cloud.

We decided to use an Intel i9 CPU for computations, as we didn’t have any heavy image detection algorithms that would require a GPU.

Since we wouldn’t have a human driver to steer or brake, we had to add some sort of actuation. We decided on an electric pancake motor for steering and implemented braking with a hydraulic pressure system. We also equipped the car with an Inertial Measurement Unit (IMU) to track its velocity and acceleration.

For our software framework, we chose ROS 2 Galactic, mainly because we knew that ROS 2 does not rely on a centralised ROS master anymore. Even though Galactic is not the LTS version, we preferred it over Foxy because we wanted to use Eclipse Cyclone DDS as our ROS middleware leverage new features like loading configuration files runtime or recording data with rosbag2’s improved performance.

Starting development

The physical car is only ready to drive quite late in the development process, so we are tasked with developing as much as possible without the actual car. As a result, we have to rely heavily on simulation to verify that our code works before it is ever loaded onto the car. We also had to streamline our deployment workflows so that the code could be loaded onto the car as seamlessly as possible when ready.

We started by running simulations on our local machines, then verifying that the pipeline worked on our dummy car (sensors mounted on a cart). Finally, we deployed the code on the racecar itself, when it was ready for final integration.

Hilbert on Foxglove Studio

We dedicated a large portion of time creating a development environment with easy deployment and debuggability. Afterwards, we decided to run every ROS 2 node in its own Docker container. This simplified our dependencies without negatively impacting performance, as the host computer doesn’t even have to have ROS installed. This is especially beneficial given the fact that our team members all develop on different CPU architectures and operating systems.

Running into our first challenges

We wanted to run the driverless stack on the car’s computer and easily analyse it live as well as open and examine the logged data from any other device. Using rviz2 and rqt in this setup meant we had to run them inside Docker containers as well to ensure compatibility, which wasn’t the most convenient solution.

In the search for a better way, we found Foxglove Studio. By providing live Rosbridge connections and a suite of panels that essentially replicated the functionality of rviz2 and rqt, Studio helped us circumvent our problem altogether:

Foxglove Studio on Rosbridge connection

We are currently leveraging Foxglove Studio for three major use cases: analysing live data, analysing simulated data, and examining logged data.

Analysing live and simulated data

We are using long-distance wifi for live telemetry, which unfortunately is restricted to 2 MB/s. This means we cannot possibly visualise any heavy data like a LiDAR point cloud live. This constraint also makes it impossible for us to simply share a network with the car to access all the ROS topics.

Foxglove’s Rosbridge connection was our saviour here, making it possible to send only key information like the states of each node or actuation commands:

Indicator panels and extension panel

We also developed our own custom Foxglove extension (top right corner) to start and stop ROS nodes in real-time.

Studio also allows you to see your data on any device with a browser. This setup makes live debugging much faster, as we can pin down a problem without having to transfer and open logged data. We even developed our own Foxglove extension to control the nodes we wanted to run at different times.

When analysing simulated data, we simply replace live car data with our simulation data, without changing anything else in the pipeline. Whether we are in simulation or on the track, we are able to use an already familiar visualisation setup to help us take advantage of every minute that we have – whether the bounding factor is our limited development time, hours of daylight, or ounces of battery life.

Examining logged data using ROS bag files

Of course, there are times when we don't immediately find the problems live, so we rely on post-analysis.

Every time we run the car for a lap around the track, we record all the topics to our local disk, and eventually offload the output log files for analysis. While standard ROS 2 bags with sqlite3 worked fairly well, we wanted to include message schemas in our data files, given that our system and messages are constantly evolving. Otherwise, we knew reproducibility would be a lot harder down the line, especially for a fast-evolving project like this where the team changes every year.

To solve these issues, we decided to record our data in the MCAP file format. MCAP introduced very impressive compression by default, reducing our files to roughly a third of their original size. It also helped us retrieve data when our car would experience issues and shut down randomly. We no longer had to deal with corrupted and unreadable files, since MCAP saves data sequentially in an append-only structure, making it much easier to recover data from interrupted recording. We no longer lost valuable information about our car’s performance during these critical events – information that was crucial to helping us iterate and improve on it.

We also decided to store and manage our data using the Foxglove Data Platform. The ability to stream our data directly from Data Platform helped us analyse logged data without having to copy an entire file to our local machines. Given the massive size of our files and the limited space on our computers, we would’ve only been able to store a few of these files at a time. Streaming was absolutely essential to simplifying and accelerating our workflows.

Conclusion

As a whole, Foxglove has helped our team solve the difficulties of cross-platform data visualisation, data storage, and replay much more elegantly. This, in turn, unlocks more efficient debugging workflows that streamline our general development.

We also appreciate how quickly Foxglove continues to be developed – we see noticeable improvements with every weekly release. We’re excited to take even fuller advantage of the breadth of Foxglove’s tooling. For example, our team is working on implementing a post-processing step where we automatically tag and upload our recorded bag files to the Data Platform, for easier team-wide searching and analysis.

Our team is competing in the manual class for FS Austria and the driverless class in FS East this year. If you are curious about further updates, follow us on our LinkedIn or Instagram.


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!


As a robotics developer, you are likely handling a wide variety of multimodal data on a daily basis – whether it’s live or recorded, real or simulated. You’re also probably figuring out how to engage with this data at the correct “level” for a given task. Do you want a bird’s-eye view of how your perception has improved across releases? Or do you want to drill down into an issue your robot encountered this morning? Something in between?

Managing intimidating amounts and classes of data, and switching back and forth between the macro and micro views necessary to understand them, is critical to developing successful robots. By centralizing your team’s data practices with Foxglove Data Platform, you can streamline collaboration and dramatically accelerate your team’s progress.

Before Foxglove Data Platform

So what does life before a scalable data management solution look like for a typical robotics team?

When building robots, you are wrangling multiple categories of data. You need to view live data to debug your robot and offload recorded data to analyze it. You need to visualize logs to see how your robot navigated real-world scenarios, and run simulations to predict how it would perform in hypothetical ones. In all these scenarios, you also need to be able to search for especially relevant segments of data, and share them with your teammates.

Without a centralized data strategy, you and your teammates may be using a variety of manual workarounds to organize this data. You may be passing hard drives around the office, to get data to the people who need it. You may be naming Google Drive folders by dates, devices, software release versions, or any number of other namespaces. You may even be duplicating data across hard drives and cloud folders, because different organizational hierarchies make sense for different teams.

As data grows, it becomes increasingly difficult to find what you need. It can exist in multiple formats and multiple places, be accessed by different groups of people, and be used for different goals. Searching data becomes such an opaque process that multiple sources of truth start proliferating across the team. Developers spend more time locating data and performing data housekeeping than they do on actually tackling the core robotics challenges integral to their team’s success.

Disorganized data often leads to equally haphazard ways of collaborating on it. It is crucial for members of a robotics team to be able to share data and coordinate work across levels of the robotics stack – otherwise, it becomes significantly harder to iterate quickly. You may want to share notes on a specific incident, debrief on a simulation test’s results, or simply debug an issue together. You may have to record your screen to demonstrate how you debugged an issue, physically pair with a teammate at a single machine, or create even more Google Drive folders and documents to explain your thought processes and insights. These extra assets (and the unspoken systems for managing them) proliferate alongside your data, adding to the original problem.

Finally, switching back and forth between macro and micro views to properly analyze data can be time-consuming and expensive. When data is stored without regard for efficient reading or retrieval, it becomes tedious to zoom in and out of it. You may want to scan months of data for examples of a particular issue, and then drill down into short segments to debug what happened in each case. How efficient is it to download enormous files from multiple hard drives or cloud buckets to your local machine to get the breadth of coverage you need? Or to wade through terabytes of irrelevant data to get to the relevant megabytes you need? There is no way to extract just the data you are interested in at either level, wasting time and adding unnecessary friction to the development process.

After Foxglove Data Platform

Without intervention, data issues can compound and breed new ones. All these obstacles prevent your team from iterating more intelligently on your robot and getting a working product to market faster.

Foxglove Data Platform tackles these common data management pitfalls by providing teams with a centralized repository for collaborating on their data. Once you create a Foxglove account at console.foxglove.dev and invite your team members, everyone on your team can start uploading data and collaborating on it together. Any contributions you make to this repository are instantly shared with every member of your organization, so there is no danger of working on outdated or inaccurate data.

After uploading files, you can annotate them with rich metadata, making it easier to navigate and search your data. In addition to tagging every import with a recording device and time, you can add other descriptive factors of your choice – like release version, location, weather conditions, and more. You can even tag events within your data to identify points of interest. In short, there’s no limit to how you can choose to describe and organize data. You have the freedom to choose the organizing principles that will help your team explore your data most meaningfully – and since data is shared, your teammates can build on top of your work instead of recreating it. You no longer have to duplicate data across different hierarchies of folders or drives – you can simply filter by your desired metadata values.

Foxglove Data Platform

Data Platform also indexes data to more efficiently retrieve the information you need – and nothing more. This makes it possible to specify as granular a query as you need, whether it’s GPS data recorded by a specific robot within a given time range, or all LIDAR data recorded in a particular city under rainy conditions. Instead of spending time and storage space on downloading, analyzing, then deleting enormous files from your computer, you can now zoom in precisely on the data you care about.

This indexing is what allows you to go from wide-scale analysis across months to hyper-specific incident debugging in a matter of seconds. Do you want to see data recorded on a particular robot, or all the files you’ve imported? Do you want to see all your robots’ data on a timeline? Or do you want to drill down on specific events for more focused analysis? Whatever your workflow, Data Platform lets you specify the lens through which you want to engage with your data. Rapidly switch back and forth between the macro and micro views that can help you learn about your robots and drive future iterations on them.

Finally, Data Platform also integrates natively with Foxglove Studio, making it effortless to explore data from yet another standpoint – visually. Once you’ve located the event or time range you want to inspect, you can click a single button to stream it in Studio within seconds, for instant visualization and debugging. Studio provides a rich suite of configurable panels to help you analyze different aspects of your data – whether it’s diagnostics, camera feeds, or 3D scenes. Studio also allows you to maintain team layouts, so you can build curated visualization and debugging dashboards to use with your teammates.

Foxglove Studio

Share your thoughts!

Managing your data (while also trying to build a functioning robot) is a huge undertaking, no matter the scope of your project. Whether you’re working on a single robot or an entire fleet, leveraging your data well can determine whether your team is able to ship a successful product on time.

By transforming how you relate to your data, Foxglove Data Platform helps you completely reimagine your team's best practices from the ground up, streamline every aspect of your development, and scale with your team’s growth.

To get started, sign your team up for an account and start importing data today. If you’re interested in a private cloud or on-premises solution, please don’t hesitate to reach out to us directly.


Scaling Your Robotics Data Strategy

Read more:

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