In our previous posts, we've talked about how ROS 2 nodes can leverage different ways of communicating with each other. They can use topicsto publish continuous communication streams, or use services and actions to make individual requests.

ROS 2 parameters are slightly different from these concepts – rather than being a way for nodes to communicate, they are a way to configure your nodes so that they can have slightly different behaviors when they launch in different contexts.

In this tutorial, we will cover when and why you would use ROS 2 parameters – as well as how you can read and set parameter values using both YAML configuration files and CLI commands.

How ROS 2 params work

ROS 2 nodes first declare the parameters they can accept (1), then read the parameter values passed to them during startup – via the command line interface (2) or a YAML configuration file (3) – to determine their behavior. Parameters can be integers, floating point numbers, booleans, string, or arrays of the previous types.

alt\_text

By setting different parameter values in different contexts, a node can modify its behavior to work in various scenarios. For example, a node that controls a robot's speed can be configured with different speed limits, depending on whether the robot will be deployed.

When to use ROS 2 params

Let’s suppose you have two identical robots in two different warehouses. While their general responsibilities are the same – i.e. locating, loading, and moving inventory – these robots will have different names, move at different speeds, and navigate through different sets of waypoints. By using ROS 2 parameters, you can modify each robot’s internal variables to differentiate their behavior based on their home warehouse.

For this tutorial, let’s assume “RobotA” will be in Warehouse A and go back and forth in a corridor at a max speed of 1.4 m/s. “RobotB” will be in Warehouse B and navigate a more complicated set of waypoints at a max speed of 5.6 m/s.

waypoints

To differentiate how our robots behave, we will define three parameters for them to read at startup – robot\_name, max\_speed and waypoints.

Creating a node with ROS 2 parameters

Let’s create our node, define its parameters, and read the parameters' values from the command line interface.

Start by creating a new package in your ROS 2 workspace:



In the src/ folder of your package, create a new robot\_node.cpp file with the following dependencies:



Declare a new RobotNode class that inherits from Node and contains our parameter values as its private attributes:



Next, add a constructor that defines your robot\_name, max\_speed and waypoints parameters:



Once the node declares the parameters, it is ready to read them:



Now that we’ve gotten the parameters and stored them in the class attributes, we can now check the values passed:



Add a class destructor to avoid compilation problems:



Finally, create the main function to execute your node.



Modify your CMakeLists.txt file to include your executable and install it in the project’s lib folder:



Compile the package with $ colcon build and source your workspace.

Running your executable should give you the following output:



To pass the parameters to the node during startup, we have to add them with the argument --ros-args -p \<param>:=\<value>. You can pass as many parameters as you like:



We have successfully configured our node with three parameters!

Setting multiple parameter values with a YAML file

Now let's imagine that we want to pass many more parameters to our node. It may get tiresome passing these values one by one via the CLI. To streamline this process, we can leverage YAML configuration files.

A YAML configuration file contains the parameters and their values in an easy-to-read and -write format. A single YAML file can be used to configure multiple nodes, each with their parameters.

Let’s create a warehouseA.yaml file for our first robot:



And a warehouseB.yaml file for our second robot:



Store these YAML files in a newly created params/ folder in your package.

Let’s try running our node with our new warehouseA.yaml file:



Running it with warehouseB.yaml should give you a slightly different output:



We have successfully passed different parameters to the same node using YAML files! These configuration files make parameters much easier to modify and read.

Using CLI commands

ROS 2 includes useful CLI commands to manage parameters once the nodes have been started. Let’s see some of these commands in action. Start by opening two terminals. In the first terminal, run our robot\_node like before:



In the second terminal, get a list of declared parameters:



Now that we know the parameter names, let’s get the values:



Get all the parameters and store their values directly in a YAML file:



To change a parameter in a node that is already running, add a timer to your node that checks periodically for a new max\_speed parameter value:



Then create the timer in the constructor:



Finally, define a timerCallback to check the parameter and print its new values:



Don’t forget to spin your node:



Compile your code, and execute the node:



In another terminal, change the robot's max\_speed to 2.0:



You’ll see that your robot\_node will receive the new max\_speed and print it in the terminal.

Terminal output

L: Running robot\_node with the original parameters. R: Setting a new max\_speed with ros2 param.

Summary

ROS 2 parameters make the same node work in different situations, making it possible to reuse your code to add capabilities. We hope this tutorial helped you better understand how you might use parameters in the larger scheme of your robot’s architecture.

For a reference to all the code covered in this post, check out our GitHub repo.

As always, feel free to reach out to the Foxglove team in our Slack community to ask questions, give us feedback, and request a topic for the next tutorial!


At Foxglove, our team's North Star is to provide robotics teams with general-purpose visualization and debugging tools. We believe in focusing on the features that are most useful to the greatest number of our users.

With that said, your team may still have domain-specific needs that our open source tooling doesn't address. While we want to prioritize generally applicable features, we still want to empower you to develop tools customized to your needs – all while leveraging Studio's existing data and layout management features.

That's where Foxglove Studio extensions come in. In this tutorial, we'll walk through how you can develop custom Studio panels for your unique workflows.

Getting started

Let's start by generating an extension template with create-foxglove-extension:



Open the newly created extension-demo/ folder in an editor of your choice – in src/index.ts, you'll see an example panel being registered with a human-readable display name for Studio.

Change the default name from “example-panel” to “Extension Demo”:



In src/ExamplePanel.tsx, you'll see a simple ExamplePanel that uses React state to keep track of seen topics, seen messages, and its render status:



This example panel will run the following onRender function whenever it receives any relevant RenderState updates:



You'll see that this onRender updates the panel state with a few items:

New done callback, to indicate that the panel has finished its previous render cycle and should re-render

New topics from the data source

New messages on subscribed topics

Next, the panel will watch for new topics and new messages on our subscribed topics. Any changes to these RenderState fields will trigger the onRender function:



Finally, the panel will subscribe to an array of topics – new messages on these topics will populate the RenderState's currentFrame. Once rendering finishes, we invoke the panel's most recently set renderDone callback:



At the bottom of the ExamplePanel function, we see how all this logic is used to render a table of the data source's topics and datatypes:



Installing locally

Now that we've walked through what our template does, let's see this panel in action locally.

To install the extension in your local Foxglove Studio desktop app, compile your extension code in a folder under your home directory (e.g. \~/.foxglove-studio/extensions/unknown.extension-demo-0.0.0):



In Studio, you should now be able to see and add an "Extension Demo" panel to your layout:

example panel
If you load your own data (or explore Studio's sample data), the "Extension Demo" panel should display a table of the data's topics and datatypes.

You've successfully loaded your first Foxglove Studio extension!

Developing a custom extension

Now's the time to get creative! Whatever project-specific need you have that Foxglove Studio's out-of-the-box panels don't meet, you can build yourself.

For this tutorial, let’s build a simplified version of the Foxglove Studio Image panel – one that allows users to choose from a dropdown of available image topics and displays the first image seen on the selected topic.

Build the dropdown menu

First, let's add the user controls we need to our interface – namely the image topic dropdown menu.

We’ll need a list of all image topics (i.e. those with a sensor\_msgs/CompressedImage datatype):



We'll also need save the user-selected topic to the panel state, and subscribe to its future messages:



As a nice user experience consideration, you can select the first available image topic by default, so we can start displaying an image as soon as relevant messages become available:



Now, we can finally render the dropdown menu in the ExamplePanel's return:



Set the message to render

Before displaying an image, we need to determine the correct message to render.

Install the @foxglove/schemas package:



Import the package's CompressedImage TypeScript schema so we can define an ImageMessage type:



Since we’re only interested in drawing a single image at a time, let’s change our existing messages / setMessages state variables to message / setMessage:



Then in our existing onRender function, replace setMessages(renderState.currentFrame) with the following logic to save the last seen image topic message:



We now have a reference to the image topic message we want to render in our panel state.

Render the image

Add a canvas HTML element to the panel's return value:



Outside our ExamplePanel function, define a drawImageOnCanvas helper function:



Every time we see a new message on the user-selected image topic, let's use our previously defined canvasRef to draw the image message's data on our HTML canvas:



We've finished our first custom Foxglove Studio extension!

Testing in Foxglove Studio

Now that we've written all our code, let's test our extension with some real data in Foxglove Studio!

First, build your changes to your local extensions folder:



Then, reload Studio to see the latest version of your extension live!

Add the panel to your layout, load some data, and select different topics from the dropdown menu to see the interface in action:

installed extension

You've just developed and installed your first custom Foxglove Studio extension!

Sharing your extension

Now that you’ve created an extension locally, let’s package it up so you can share it!

Make sure you've set all relevant metadata fields in the package.json file – i.e. the extension's name, publisher, version, and description. Then run yarn package to package your extension manifest and compiled code in a ZIP archive (i.e. extension-demo-0.0.0.foxe).

Once you've packaged your extension, you have two ways to deploy it – by sharing it privately or publicly.

To share your extension privately with your Foxglove organization, publish it to your team (this requires being on our Pro plan). All teammates registered with your Foxglove organization will have your extension installed by default in their Studio apps when they sign in to their account.

private extensions

To share your extension publicly with all Studio users, submit your extension code as a PR to the Studio extension marketplace. This displays your custom panel in the app’s Extensions sidebar, for users to optionally add to their panel list.

Stay tuned

If you're feeling adventurous, you can build on top of your "Extension Demo" panel by adding user-configurable panel settings.

In the future, we hope to support more varied use cases for custom extensions – i.e. to support custom file formats, data sources, and message decoders in Studio. Please feel free to reach out to us in our Slack community to give feedback on what you'd like to see in our next iteration of the extensions ecosystem!

You can find the full code snippet covered in this tutorial in the examples/ directory of the create-foxglove-extension repo. For a more detailed look at all the API methods used in this tutorial, check out the extension panel API docs.


Time series visualization tool PlotJuggler recently announced support for the MCAP file format in its 3.6.0 release. You can now load multiple streams of robotics data with one container file format in PlotJuggler, for seamless data storage and analysis.

Why MCAP?

As a generic visualization tool for a wide range of robotics applications, PlotJuggler was designed from the ground-up to be endlessly customizable – from configurable settings to an extensible interface.

To stay flexible, PlotJuggler works hard to separate the phases of data handling – storage, transport, and parsing – as much as possible in its application logic. With frameworks like ROS, however, these phases are all quite tightly coupled.

In response to this problem, lead developer Davide Faconti decided to introduce MCAP to the PlotJuggler ecosystem, thus allowing roboticists using both ROS 1 and ROS 2 to leverage one common file format. This decouples data storage (MCAP) from data parsing (ROS 1 or ROS 2), thus achieving his guiding principle of separating concerns and keeping the tool modular and extensible.

MCAP also solves a shortcoming of rosbag2 SQLite storage. Unlike MCAP or even ROS 1, ROS 2 bag files do not store the schema of their messages alongside their actual data. This makes it difficult and sometimes impossible to visualize certain ROS 2 messages in PlotJuggler, as the information needed to parse these messages may be unavailable. With completely self-contained MCAP files, however, PlotJuggler can now load and parse ROS 2 messages without any issues.

As the main PlotJuggler developer, I am looking forward to continuing collaborating with Foxglove and contributing to the robotic ecosystem with our individual strengths.

Davide Faconti

Davide is excited to expand MCAP support on the upcoming PlotJuggler roadmap as well. Fortunately, MCAP already provides readers and writers for a wide array of data formats (e.g. ROS 1, ROS 2, Protobuf, JSON, etc.). This sets the stage for PlotJuggler to enable saving and reloading messages streamed into the app. For example, users may one day be able to log received JSON data using MQTT, or receive Protobuf messages using WebSockets technology, in the app.

Stay tuned

The Foxglove team is just as excited to continue collaborating with Davide and PlotJuggler to improve the MCAP ecosystem. We hope that our joint efforts to expand support across different open source tools will only accelerate progress for everyone in our industry.

If you have any feedback for us, please don’t hesitate to reach out. You can join the Foxglove Slack community, or contact us directly.


Manage your robotics data with Foxglove Data Platform

Scalable data management for fast-moving robotics teams

Manage your team settings and data through a convenient web UI.

Analyze meaningful segments of your data.

Use our public API endpoints or CLI to quickly retrieve the data that you're interested in.

Ready to get started?Upgrade to a paid plan today.