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.


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.


Last year, we announced Foxglove Studio extensions – custom panels that you could build and install locally to explore your robotics data. With extensions, any Foxglove user is empowered to create bespoke visualization and debugging panels for their project-specific needs.

Today, we’re excited to simplify sharing extensions in a company setting. For customers on our Pro or Enterprise plans, you can now publish extensions and deploy them automatically across your organization.

Check out our docs to get started with building your own extension and sharing it with your team.

Foxglove has made it easy for us to share and visualize data across many teams at 6 River Systems. We’re excited to more easily distribute our custom extensions across the company.

Katy Powers, Localization and Mapping Lead at 6 River Systems

Sharing unique tools for unique problems

Foxglove Studio ships with a rich suite of data visualization and debugging tools, called panels, to help you explore your robot’s data. If Studio doesn’t have an out-of-the-box panel ready for your use case, you can write an extension with your company-specific needs. This still allows you to leverage Studio’s existing layout and data management features – from configuring settings, adding the extension as a panel to a layout, or connecting to a data source. With extensions, you can customize Foxglove Studio for your project – whether you’re working on a space satellite or developing an autonomous Formula One car.

Until now, you’ve had to choose between developing local extensions for yourself, or publishing your extension publicly for all Foxglove users. If you did want to share an extension privately, you had to upload it to Dropbox or Google Drive. Your teammate would then have to download the extension and install it themselves. If you made changes to your extension, you would need to repeat this process over again – for each teammate who wanted to use your latest changes.

With private team extensions, this collaboration process becomes much more streamlined - your entire organization can now access the latest version of your published extension. Instead of manually passing around extension files, you can simply use the foxglove CLI to publish the extension (from your desktop or CI), and it will be automatically installed for all users in your organization.

Share your feedback

Building out robust collaboration support has been a key focus of our Studio roadmap – we announced team layouts, shared data via Data Platform, and now team extensions as milestones on this journey.

As we continue improving Studio to accompany your team to the bleeding edge of robotics, we’d love to hear your feedback. Join the conversation on our Slack or Twitter, or check out our GitHub to file feature requests.

Check out our documentation to get started building your own extension and sharing it with your team.


Announcing Private Foxglove Studio Extensions for Your Organization

Read more:

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