While our team’s North Star is to provide a suite of general-purpose tools for visualizing and debugging robotics data, we know many users have domain-specific needs that our out-of-the-box offering does not address.

At Foxglove, we believe in focusing on the tools that most of our users find useful, but we want the best of both worlds. We want to provide features applicable to most roboticists, but also empower you to develop bespoke tools customized to your specific needs, while leveraging Studio’s existing data and layout management features.

That’s why we’re very excited to announce the alpha release of Foxglove Studio extensions. We developed an SDK to help you easily build and install your own custom panels in Studio. Instead of creating your own tool or shoehorning yet another app into your workflow to accomplish some task, you can rely on Studio to be a one-stop shop for investigating your robotics data. With extensions, there is no limit to how uniquely tailored your Studio environment can be to your project.

We’ve also opened up the first version of our extensions marketplace, where you can publish your Studio extension or search for and install other users’ contributions. With this marketplace, we hope to take a page from the open source community’s handbook and help the robotics world become that much smaller and more collaborative.

Stay tuned

Building flexible and extensible software is a central tenet of our development philosophy. Our users should be able to adapt Studio to their use cases, without being limited by our roadmap priorities or blocked by our finite development resources. With the new Studio extensions API and marketplace, we hope to facilitate more collaboration and empower you to do more. But we’re not stopping just yet!

We already have a few ideas in the works for improving our extensions library, such as allowing custom panels to publish messages and supporting more “genres” of extensions including custom data formats and message decoders.

Share your feedback

As we brainstorm new ways for Studio to accompany you to the bleeding edge of robotics, we’d love to hear your feedback to inform future development of this extensions feature. Our extension API remains experimental in this alpha release, so feel free to let us know what improvements or new features you'd like to see!

Join the conversation on our Slack or Twitter. You can also check out our GitHub to get involved in discussions or to file your own feature requests.

Read our docs for a step-by-step tutorial on how to get started on your first Studio extension. Happy hacking!


Overview

Now that we've learned about the building blocks that make up a ROS system, let's apply our knowledge to see these components in action!

In this post, we'll cover how to install ROS on your computer, run your first ROS node, and interact with your data using Foxglove Studio. Whether you want to inspect your active nodes, chart values of interest, or publish ROS messages back to your stack, we'll cover a few of the many ways that Studio can enhance your data exploration experience and accelerate your robotics development.

Installing ROS

To get started with developing robotics software with ROS, you’ll first need to install it on your machine – whether your platform of choice is Ubuntu, macOS, or Windows.

Ubuntu

ROS officially supports Ubuntu, so it's easiest to get up and running on this platform – we recommend using Ubuntu 20.04 and following these instructions on their website to finish installation.

macOS or Windows

To install and run ROS on macOS or Windows, you must have access to a Linux system.

You can set one up by installing VirtualBox, a free and open source virtualization software package that allows you to run Linux on macOS or Windows. Parallels is another virtualization option, albeit paid, for macOS. Again, we recommend using Ubuntu 20.04 and following the same instructions for installing ROS to get started.

Running your first ROS node

Let's test that ROS was installed correctly by running our first ROS node. For this tutorial, we'll be launching turtlesim, a ready-to-launch ROS tutorial conveniently packaged as a node.

Open two terminal windows. In the first, start your ROS master:



In the second, start turtlesim:



If everything worked as expected, you should see logs similar to the following in your turtlesim window:



You should also see a window pop up, showing a tiny turtle peacefully floating in the middle of a vast ocean:

turtlesim

Now that we have our simulation running, let's interact with our turtle by controlling its movements in this ocean world. Open another terminal to run the teleop program, conveniently packaged as another node in the same turtlesim package:



Once running, the turtle\_teleop\_key node binds to your keyboard's arrow keys to determine what ROS messages to publish back to the /turtle1/cmd\_vel topic, which in turn controls where our turtle swims. You should see logs similar to the following in your terminal:



If we're focused on this terminal window and pressing arrow keys, we'll see our turtle following our directions, leaving behind a trail indicating where it has been.

turtlesim teleop

Using Foxglove Studio to interact with turtlesim

Now that we've been able to interact with our simulated turtle in a few ways with the turtlesim package, let's use Foxglove Studio to look behind the scenes at how this all works.

Download and open Studio – if this is your first time opening the app, you’ll be greeted with a Welcome layout and introductory message.

When you're ready, use the sidebar's Layouts tab to load a "New" empty layout.

new layout

To explore our turtlesim data , we must first connect Studio to our ROS system. You can use a native ROS connection within your Ubuntu environment (whether that's inside a virtual machine or not) – simply enter your ROS master's IP and port (e.g. "https\://localhost:11311") to connect to your ROS system.

connection tab

View the simulation's ROS graph

To start off our data exploration, let's try to understand the connections between the running processes within our ROS system. Conveniently enough, Studio has a panel for exactly this.

Use the sidebar's Add panel tab to drag and drop a Topic Graph panel into your layout. This panel will display an interactive graph visualization of the current node and topic topology.

add panel

If your connection was successful, your panel should come alive with a graph of your active nodes, the topics they are publishing and subscribing to, and the services attached to them:

turtlesim topic graph

Click and drag overlapping items in the graph to reposition them for easier viewing. We can see from this graph that our turtlesim node subscribes to the /turtle1/cmd\_vel topic and publishes the topics /turtle1/pose and /turtle1/color\_sensor.

Plot the turtle's position

Next, let's use Studio to investigate how the values in our published messages change over time.

From our ROS computation graph, we learned that our turtle publishes its position on the topic /turtle1/pose. Let's examine this topic using the Raw Messages and \[\_/docs/studio/panels/studio/panels/plot) panels.

Use the sidebar's Add panel tab to drag and drop both panels into your layout. In the Raw Messages panel, add /turtle1/pose to see the structure of the topic's messages:

raw messages

In the Plot panel, add /turtle1/pose.x and /turtle1/pose.y as the custom values to plot on your x-axis and y-axis, respectively. These topic message paths use message path syntax to drill down into the /turtle1/pose topic's x and y field values.

You should start to see the corresponding values populating your plot:

turtlesim plot

Go back to the turtle\_teleop\_key terminal and navigate our turtle around. As expected, you'll see the plot's values change as our turtle’s position changes.

Navigate the turtle

Finally, let's use Studio to publish messages back to our live ROS stack to test and debug our turtle simulation.

Earlier, we saw that the turtlesim node subscribes to the /turtle1/cmd\_vel topic, which contains our turtle's position. Knowing this, we should be able to publish navigation commands as ROS messages on this same topic, directly from within Studio, to control our turtle's position.

Add the aptly named Publish panel to your layout, for a convenient interface that allows you to draft and publish ROS messages on a given topic. Specify /turtle1/cmd\_vel as your topic to publish on, and select geometry\_msgs/Twist as your datatype. This will automatically populate the input field with a JSON message template that adheres to the geometry\_msgs/Twist schema.

Edit any of the message's field values, and click "Publish":

publish

Notice that manually publishing our edited message to /turtle1/cmd\_vel causes our turtle to move in the simulation! This in turn also affects the trajectory of our Plot panel's charted line.

Continue exploring with Foxglove Studio

While turtlesim may be a basic example of a ROS simulation, its foundational concepts mirror those present in more complex robotics systems in production – both real and simulated.

Simulation fills a crucial role in robotics development by enabling fast iteration without putting expensive hardware or human safety at risk. Many robotics companies simulate hundreds or thousands of times as much data as they generate in real life.

We hope this tutorial helped you review some foundational ROS concepts, see the role simulation plays in robotics development, and learn how Foxglove Studio can shed light on the inner workings of your robot (or in this case, simulated turtle). Since Studio integrates a variety of traditional robotics tools into one user-friendly app, we hope it helps you spend less time spinning up different tools and more time making your robot go.

For other ways to explore your robotics data, check out the rest of Studio's panels (e.g. Table, \[\_Data Source /docs/studio/panels/studio/panels/data-source-info), \_Node/docs/studio/panels), and stay tuned for our yet-unreleased extensions library.


The typical cycle for robotics development usually starts with a deployed robot collecting data on a real-world excursion – whether that world is a warehouse, a public road, or the ocean's "twilight zone".

Typically, this data is offloaded into storage at the end of the excursion, and then analyzed to determine the improvements the robot's software requires. The necessary changes are made, the new and improved software is deployed onto the robot, and that robot is sent back out into the world to collect more data.

And so the cycle continues.

In the robotics community, there is no shortage of tools that can help you inspect, analyze, and visualize your data. From native Robot Operating System (ROS) tools like rqt and rviz, to newer generations of tools like PlotJuggler and Foxglove Studio, there are a multitude of ways you can inspect the inner workings of your robot's brain.

But how do you get to a point where you have robotics data to visualize in the first place? What technical decisions do you need to make, and what steps do you need to take, to collect your data? How do you weigh all the possible strategies for this vital step?

Though there isn't an industry-wide standard or one right answer, there are basic trade-offs to consider when deciding how to collect your robotics data. The decisions you make will depend on your project's specific goals and constraints. By having a list of options to weigh, you can make more informed choices about the best data strategy for your project.

Data collection approaches

Before you can store or analyze any data, you need to collect it. There are several ways you can do this:

Local disk recording

Live telemetry

Hybrid approach

All these methods have their pros and cons – the frequency with which your robot needs to send real-time data, the volume of data it records on a typical excursion, and its offload bandwidth will all inform which method you should use.

Your guiding principle should be finding the strategy that will most consistently return uncompromised data from the dynamic real-world environments that your robot navigates. Your data will guide future iterations of your robot, so the method that allows you to collect and learn from your data most reliably is often a good place to start.

Local disk recording

Robots are often deployed to areas that are inconvenient or dangerous for humans to go, and consequently cannot rely on a consistent internet connection to safely offload data. These robots with inconsistent or limited in-the-field connectivity can write their data to local storage to ensure that it can be collected and retrieved properly.

robot in hazardous environment

Your robot's disk space will also affect how you collect data. With limited space, your robot must be more discerning about what data to record and what data to throw away. Running more business logic on the robot itself will conserve disk space – in this scenario, only the lighter-weight derived insights would be recorded to disk. While this “stretches out” disk space by writing a "lower resolution" version of your data, processing raw data live on your device will impact your robot's real-time performance.

Finally, the importance of real-time feedback will determine how you record your data. If your data does not need to be referenced until the robot is back from the field, purely local disk recording is ideal. However, if you need to monitor your robots in real-time, local disk recording would not be able to address this requirement.

Live telemetry

If it is crucial for you to know at any given time where your robot is, your robot must be able to offload data to a storage solution – like the cloud or your laptop – as it actively collecting it.

autonomous cars

Unlike local disk recording, which is blissfully independent of an internet connection, real-time offload requires a consistent and reliable connection to your robot – either wirelessly or via a physical cable. Since network connections can be unreliable, your robot can use in-memory buffering to avoid losing vital data whenever connectivity drops, transmitting these stored messages once a stable connection returns.

Due to bandwidth constraints, live telemetry is usually reserved for a small subset of your data. However, real-time offload of full-resolution data can be particularly useful in controlled scenarios, when your internet connection is reliable or when the scope of your task is within certain limits – for example, when you are conducting a sanity check on your robot or calibrating its sensors at homebase before sending it off into the field.

Hybrid approach

Both local disk recording and live telemetry can be present at once on a given robot – some data can be analyzed asynchronously after the robot has returned, and other data can be immediately transmitted for real-time monitoring.

Given that these approaches are useful in different scenarios, you can mix and match local disk recording and live telemetry for subsets of your robotics data. Ultimately, the environment that your robot navigates, the type of data it wants to collect, and its goals while out in the field will all determine how you record your data.

A hybrid approach is especially useful when you want both real-time insight into your fleet and high resolution data to diagnose potential failures. With live telemetry, you can monitor your fleet's location and current status. In the event of a failure, you can upload the full fidelity data recorded on the robot's local hard disk to review it for diagnosis. In short, the hybrid approach navigates the trade-off between how much local disk space you have (local disk recording), and how much data you can reliably offload via your available bandwidth (live telemetry).

Recording formats

Knowing how to record your robotics data is only half the battle. Another equally important question to address is the format in which to record this data.

There are several main criteria to consider when weighing data format options. Namely, you will want to choose a format that makes your data:

Conducive to analysis

Trivial to recover in case of hardware or software failure

Possible to record with low overhead

Easy to offload

Self-describing

Different data formats facilitate different types of analysis. Choose a format while keeping in mind the type of analysis you may want to perform – whether it's visually playing back a recorded session, or using SQL to query petabytes of recordings.

Your data should be stored in a format that makes it easy to recover. For example, in the event of an unexpected shutdown or accident, the data your robot has already recorded should be preserved and remain uncompromised.

Your robot's recording process should be IO and CPU efficient. The volume of data you write and its compressibility will all affect performance and offloading.

Finally, your data should contain self-describing schemas for easier deserialization and compression. This enables you to decode your data without having to reference separate interface definition files, which may change frequently.

In short, choose the data format that allows your robot to record and offload its data for future analysis – all within its performance and bandwidth constraints. Let's cover your options, based on your robotics framework.

ROS 1 robots

ROS is currently the industry standard for robotics data recording, mainly because it allows you to get up and running quickly, and easily integrate features that would be very time and labor-intensive to build yourself – i.e. modules for computer vision, SLAM, etc. This allows you to leverage the expertise of your peers, and makes collaborative robotics development extremely easy.

ROS allows you to write the messages published by your nodes throughout the course of a robot's excursion to a bag file. Bag files store ROS messages in a format that can then be played back, visualized, and analyzed – along with message definitions for all these messages. Many tools like rqt\_bag and rosbag have been written to help you record, play back, and otherwise interact with these bag files. Writing your data to bag files optimizes recording and playback performance, because you avoid deserializing and reserializing your messages.

ROS 2 robots

Whereas ROS 1 is a bundle of data formats, transport protocols, and reference implementations (C++ and Python), ROS 2 is a more generic C API with pluggable implementations. Even though ROS 2 has a default network transport protocol (DDS) and a default bag storage implementation (sqlite3), ROS 2 functions less as specific implementations and more as an abstract middleware interface for serialization, transport, and discovery. As such, rosbag2 allows recording and replaying of different data formats via a flexible interface, improving communication over different networks.

While ROS 2 seems like a promising new direction for ROS, there are a few in-progress issues that could pose a problem to recording and playback. Most notably, ROS 2 bags currently do not store message definitions alongside their recorded data. This omission makes it more difficult for external tools like Foxglove Studio to inspect and analyze this data. With that said, storing message definitions in ROS 2 bags is an open issue that the rosbag2 team is actively tracking.

Non-ROS robots

Outside of the ROS ecosystem, there are no clear-cut standards for data serialization formats.

Some teams use an open source data serialization format like Apache Avro, which optimizes for space and performance by storing data in compact binary format. Avro files are easy to process and read, because they store their data type schemas in JSON format. While JSON alone would get unwieldy for repeated fields across records, AVRO files use a direct mapping that makes it efficient for higher volume usage.

Other teams record a raw stream of protobuf messages to a file. Protobuf, Google's mechanism for serializing structured data, transmits data as a compressed binary to conserve space, bandwidth, and CPU usage. Because there isn't a storage protocol, you will have to do some upfront work to get started. You can use length-delimited streams to distinguish between subsequent messages, and design your own container format to provide message definitions for your data stream.

It is not uncommon for non-ROS teams to convert their data in custom recording formats into bag files, so they can load their data with ROS analysis tools.

Summary

There are many tradeoffs to consider before your robot even starts collecting data. What we covered is not a one-size-fits-all approach, nor is it an exhaustive list of all the ways you can optimize data collection. Knowing your robot's working environment, your constraints, and your data's usage is paramount to assessing how you should tackle these questions.


Recording Your Robotics Data

Read more:

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