
# Overview

Now that we've learned about the [building blocks that make up a ROS system](/blog/the-buiding-blocks-of-ros), 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](http://wiki.ros.org/Installation/Ubuntu) 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](https://www.virtualbox.org/), a free and open-source virtualization software package that allows you to run Linux on macOS or Windows. [Parallels](https://www.parallels.com/) is another virtualization option, albeit paid, for macOS. Again, we recommend using Ubuntu 20.04 and following the same instructions for [installing ROS](http://wiki.ros.org/Installation/Ubuntu) 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`](http://wiki.ros.org/turtlesim), a ready-to-launch ROS tutorial conveniently packaged as a node.

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

```bash
$ roscore
```

In the second, start `turtlesim`:

```bash
$ rosrun turtlesim turtlesim_node
```

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

```bash
[ INFO] [1622151455.538755408]: Starting turtlesim with node name /turtlesim
[ INFO] [1622151455.540372304]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000]
```

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

![turtlesim](/images/blog/running-your-first-ros-node/turtlesim.png)

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:

```bash
$ rosrun turtlesim turtle_teleop_key
```

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:

```bash
Reading from keyboard
---------------------------
Use arrow keys to move the turtle.
```

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](/images/blog/running-your-first-ros-node/turtlesim-teleop.png)

# 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](/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 _Layouts_ menu in the top-right corner to load a "New" empty layout.

![new layout](/images/blog/running-your-first-ros-node/new-layout.png)

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 menu](/images/docs/app-concepts/data-sources/menu.png)

## 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_ menu to drag and drop a [_Topic Graph_](/docs/visualization-panels/topic-graph) panel into your layout. This panel will display an interactive graph visualization of the current node and topic topology.

![add panel](/images/blog/running-your-first-ros-node/add-panel.png)

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](/images/blog/running-your-first-ros-node/topic-graph.png)

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](http://wiki.ros.org/ROS/Concepts#ROS_Computation_Graph_Level), we learned that our turtle publishes its position on the topic `/turtle1/pose`. Let's examine this topic using the [_Raw Messages_](/docs/visualization-panels/raw-messages) and [_Plot_](/docs/visualization-panels/plot) panels.

Use the sidebar's _Add Panel_ menu 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](/images/blog/running-your-first-ros-node/raw-messages.png)

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 paths use [message path syntax](/docs/app-concepts/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](/images/blog/running-your-first-ros-node/plot.png)

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_](/docs/visualization-panels/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`](https://docs.ros.org/en/melodic/api/geometry_msgs/html/msg/Twist.html) 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](/images/blog/running-your-first-ros-node/publish.png)

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_](/docs/visualization-panels/table), [_Data Source Info_](/docs/utility-panels/data-source-info), [_Node Playground_](/docs/utility-panels/node-playground)), and stay tuned for our yet-unreleased extensions library.



> **Note**: The concepts and CLI commands covered in this post are applicable across ROS 1 and 2. With that said, newer versions of ROS 1 and ROS 2 have integrated several packages (e.g. `rqt_console`, `rqt_graph`, `rqt_plot`, etc.) as [plugins](http://ros.org/wiki/rqt_common_plugins) into a parent `rqt` package. For the purposes of this post (i.e. covering different features in discrete steps), we've opted to use the older, but still supported, version of these CLI commands (e.g. `rosrun rqt_graph rqt_graph` vs. `rqt`). Check out the [`rqt` docs](http://wiki.ros.org/rqt) 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.

**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**.

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](https://clearpathrobotics.com/blog/2021/04/clearpaths-boxer-drives-autonomous-disinfection-robot-in-fight-against-covid-19/) to [humanoid robotic hands](https://www.shadowrobot.com/). 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 are registered with the _ROS master_**, a service registry that helps nodes locate 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](/images/blog/the-building-blocks-of-ros/ros-nodes.png)

**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/Point`](http://docs.ros.org/en/noetic/api/geometry_msgs/html/msg/Pose.html)), another lidar point cloud data ([`sensor_msgs/PointCloud`](http://docs.ros.org/en/melodic/api/sensor_msgs/html/msg/PointCloud.html)), and still another text logs ([`std_msgs/String`](https://docs.ros.org/en/melodic/api/std_msgs/html/msg/String.html)).

A message type is defined via multiple fields, each with a specified type. For example, the [`geometry_msgs/Pose`](https://docs.ros.org/en/melodic/api/geometry_msgs/html/msg/Pose.html) message type consists of a `position` and `orientation` field, each of which have their own message type definitions:

![message types](/images/blog/the-building-blocks-of-ros/message-types.png)

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 officially supports only [Ubuntu](http://wiki.ros.org/Installation), but you can get set up on Windows ([Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/about)) and MacOS ([Docker for Mac](https://docs.docker.com/docker-for-mac/)) as well.

**Before running any nodes, you must run [`roscore`](http://wiki.ros.org/roscore)** to spin up the following components:

- **ROS master** – Service registry that helps nodes locate each other.
- **`rosout`** – Logger for nodes' debugging output.
- **Parameter server** – Server that allows nodes to store and retrieve parameters at runtime.

![roscore](/images/docs/app-concepts/data-sources/ros/roscore.png)

Now that you have your core ROS system up, you can **use [`rosrun`](http://wiki.ros.org/rosrun) to find ROS packages that contain nodes you want to run**.

For example, `rosrun turtlesim turtlesim_node` will find the [`turtlesim`](http://wiki.ros.org/turtlesim) ROS package and run its `turtlesim_node` to bring up a simulation of swimming turtles on your desktop. Running `rosrun rqt_graph rqt_graph` will run [that package’s](http://wiki.ros.org/rqt_graph) `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 [`rosnode`](http://wiki.ros.org/rosnode) to display information about your currently active nodes**.

- `rosnode list` – Lists current nodes.
- `rosnode info /your_node_name` – Provides more information about a given node, including publications and subscriptions.

Once you have several nodes running, **use [`rostopic`](http://wiki.ros.org/rostopic) to fetch information for any published topic**.

- `rostopic echo /your_topic` – Displays messages published to a given topic.
- `rostopic list` – Prints information about active topics.
- `rostopic type /your_topic` – Returns the message type for a topic.
- `rostopic pub /your_topic package_name/MessageType [args]` – Publishes data to a given topic with a specified message type.

Finally, **use [`rosmsg`](http://wiki.ros.org/rosmsg) to inspect messages and their types** in more detail.

- `rosmsg list` – Lists all message types.
- `rosmsg show package_name/MessageType` – Displays the fields for a given message type.

# Useful packages

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

- [`rqt_console`](http://wiki.ros.org/rqt_console) – Provides a GUI for displaying and filtering ROS messages.
- [`rqt_graph`](http://wiki.ros.org/rqt_graph) – Visualizes the ROS computation graph – i.e. nodes and the topics they publish and subscribe to.
- [`rqt_image_view`](http://wiki.ros.org/rqt_image_view) – Displays camera images using [`image_transport`](http://wiki.ros.org/image_transport).
- [`rqt_plot`](http://wiki.ros.org/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`](http://wiki.ros.org/rqt_console), [`rqt_graph`](http://wiki.ros.org/rqt_graph), [`rqt_image_view`](http://wiki.ros.org/rqt_image_view), and [`rqt_plot`](http://wiki.ros.org/rqt_plot), into our [_Raw Messages_](/docs/visualization-panels/raw-messages), [_Topic Graph_](/docs/visualization-panels/topic-graph), [_Image_](/docs/visualization-panels/image), and [_Plot_](/docs/visualization-panels/plot) panels, respectively.

Studio further streamlines visualization and debugging workflows by allowing users to load `.bag` files directly into the app – you no longer need to run `roscore` and [`rosbag`](http://wiki.ros.org/rosbag) in multiple terminals every time you want to inspect your data.

![Studio panels vs ROS tools](/images/blog/the-building-blocks-of-ros/studio-panels-vs-ros-tools.png)

We’re currently working to support user contributions to an extensions library, which will allow you to write your own custom plugins, build project-specific panels, and ultimately customize every aspect of your Studio development workflow.

To learn more about how Foxglove Studio can accelerate your robotics development, feel free to check out [our docs](https://foxglove.dev/docs) or reach out to us directly in [our Slack community](https://foxglove.dev/join-slack).



**If you're looking to get into robotics, there's no substitute for having a physical robot.** It's the only way to get a feel for how sensors and actuators work together and to observe noisy real-world data coming in from sensors. Understanding how everything wires together is a fundamental part of the experience.

Fortunately, all-in-one robotics platforms are becoming increasingly accessible. If you want to focus on machine learning model training, Amazon's [DeepRacer](https://aws.amazon.com/deepracer/) provides a ready-to-race autonomous RC car. A wide array of [robotic arm](https://www.robotshop.com/en/robotic-arms.html) kits are also available to purchase at newly reasonable prices. **But for the novice roboticist looking for a complete robotics development experience, my current favorite is the [Duckiebot](https://www.duckietown.org/).**

# What is Duckiebot?

![Duckiebot](/images/blog/building-and-visualizing-your-first-robot/duckiebot.jpg)

**Duckiebot is unique, because it provides a deep dive into the real-world challenges and trade-offs that a roboticist would encounter, while still giving you the breadth of exposure to the entire end-to-end system.** The Duckiebot kit consists of an embedded computer, a collection of sensors, and a 3D printed frame where you assemble everything by hand. The only tool required is a screwdriver (included in the kit), and you can build the robot in an afternoon.

To give your robot a place to drive, the Duckietown driving track kit comes with foam tiles and masking tape for arranging your tracks and personalizing your miniature town. Best of all, EdX launched a free online companion course ([Self-Driving Cars with Duckietown](https://www.edx.org/course/self-driving-cars-with-duckietown)) this year, taking you from a basic working knowledge of software development to a broad understanding of the disciplines involved in building robots.

![Duckiebot tracks](/images/blog/building-and-visualizing-your-first-robot/duckiebot-tracks.png)

**One of the most fundamental challenges in robotics is system comprehension.** Understanding what the robot is sensing (_perception_), what decisions it is making based on the perceived environment (_planning_), and how those decisions translate to actuator commands (_controls_) will be a core part of your development experience. For the Duckiebot, we have a few different tools at our disposal to start grappling with this comprehension challenge.

After you've assembled the hardware, flashed the SD card, and pressed the power button, you are rewarded with the first set of feedback: LEDs and a small display with system health metrics. The Duckiebot kit also provides a web interface with more health metrics and system status.

![Duckiebot web UI](/images/blog/building-and-visualizing-your-first-robot/duckiebot-ui.png)

**Getting to the next level of depth requires connecting directly to the robot's software.** Like many robotics platforms, Duckiebot builds on top of the Robot Operating System ([ROS](https://www.ros.org/)) framework.

Though I won't go into a complete overview of ROS in this post, it's helpful to know that ROS-based robots are organized into modules called _nodes_. Nodes share information by publishing and subscribing to _topics_. Topics can be thought of as a stream of messages sharing a common data type, such as GPS coordinates, camera images, or steering angle commands.

To get a deeper look into what my Duckiebot is seeing or thinking, we need a tool that helps us inspect this underlying ROS data...

# Visualizing ROS robots with Foxglove Studio

This is where [Foxglove Studio](/) comes in. Our team's long experience in robotics found that the existing tooling is often too rigid or limited to solve many common problems. Robotics tooling should be as accessible and easy to use as Unity3D is for game development, or as Photoshop is for photo editing.

**Foxglove Studio uses a concept of _panels_, where different types of panels visualize information in different ways.** These panels include camera feeds, time series plots, an extensible 3D view, a map, a connectivity graph, and more. **You can arrange these panels into several dashboard views, or _layouts_, to investigate what your robot is doing.**

**Studio works on any platform** (in my case, Windows), despite most ROS tools only supporting Linux. It also works out-of-the-box with ROS robots, so we can connect to Duckiebot (or any robot) by opening a new [ROS connection](/docs/app-concepts/data-sources) to `<your-robot-host>.local` - for me, this is `darkwing.local`.

![Connecting with ROS](/images/blog/building-and-visualizing-your-first-robot/ros.png)

First, to inspect the published sensor data, let's add an [Image panel](/docs/visualization-panels/image) to our layout to get a camera feed.

![Image panel](/images/blog/building-and-visualizing-your-first-robot/image-panel.jpg)

Our duck is alive!

To get a high-level understanding of what software is running on the robot, you can add a [Topic Graph panel](/docs/visualization-panels/topic-graph), which shows ROS nodes and topics and how they are connected to each other.

![Topic Graph panel](/images/blog/building-and-visualizing-your-first-robot/topicgraph-full.png)

A lot is going on in the Duckiebot!

To start with a simplified overview, let's turn off the topics and services using the floating toolbar on the right.

![Topic Graph panel, simplified](/images/blog/building-and-visualizing-your-first-robot/topicgraph.png)

This view allows us to focus on what ROS nodes are currently running and how they connect to each other. Not all nodes are actively publishing data at the moment, since this is a brand new Duckiebot that hasn’t been fully developed into a self-driving robot yet.

# Continue exploring

From here, you can add more panels and experiment with configuration options to see what other data you can visualize. As a first step, try using the [Plot panel](/docs/visualization-panels/plot) to create a time series plot of your Duckiebot’s time-of-flight sensor.

For a head start on experimentation, download this <a href="/downloads/foxglovestudio-duckiebot.json" download>Foxglove Studio layout</a>, which has been preconfigured with the following panels for easy Duckiebot analysis:

- [Data Source Info](/docs/utility-panels/data-source-info)
- [Diagnostics – Summary](/docs/visualization-panels/diagnostics)
- [Image](/docs/visualization-panels/image)
- [Parameters](/docs/visualization-panels/parameters)
- [Plot](/docs/visualization-panels/plot)
- [Rosout](/docs/visualization-panels/rosout)
- [Topic Graph](/docs/visualization-panels/topic-graph)

You can then import this layout file via the _Layouts_ menu to load it into your Studio app.

![Import Duckiebot layout](/images/blog/building-and-visualizing-your-first-robot/import-layout.png)

**Congratulations on building and visualizing your first robot!**

If you have any questions or ideas about robotics visualization, we'd love to chat with you in our [Slack community](http://foxglove.dev/join-slack).



At [Foxglove](https://foxglove.dev/download), our team is intimately familiar with the challenges that come with robotics development. Existing tools – like data inspection applications, visualization programs, or debugging utilities – are often difficult to extend, clunky to use, and unsuitable for team collaboration, making for a painfully slow development workflow. **We knew there was a better way to develop and debug our robots.**

**Our vision for [Foxglove Studio](https://foxglove.dev/docs) is to ease these workflow pains and to accelerate robotics development for everyone.** During our time working at [Cruise](http://getcruise.com/), we experienced firsthand the problems that a fully integrated [data visualization app](https://medium.com/cruise/webviz-fb5f77ebe52b) could solve for a self-driving car company. We started Foxglove when we recognized the opportunity to build on top of this work and bring the same benefits to the wider robotics community.

![app](/images/blog/introducing-foxglove-studio/app.png)

Whether you’re building an autonomous car, a warehouse robot, or a [self-driving rubber duck](https://www.duckietown.org/), we hope Foxglove Studio can help you **spend less time fighting your tools, and more time focusing on what your robots are doing**.

# Why Foxglove Studio?

With Studio, our goal is to empower the robotics community to more easily make sense of their complex and noisy real-world data. We’ve taken the dizzying array of tools that robotics development usually requires, and integrated them into a single seamless developer experience.

## Cross-Platform

**Foxglove Studio is conveniently packaged as a desktop app for Linux, Windows, and macOS.** Making Studio a desktop application has unlocked some unique benefits. Because Studio is no longer limited by a sandboxed browser environment, it can connect directly to your ROS 1 stack via the [native ROS connection](https://foxglove.dev/docs/app-concepts/data-sources). It also remains unconstrained by the performance restrictions that come with running huge amounts of robotics data through a browser.

Most ROS tools are only supported on Linux, but **Foxglove Studio works cross-platform** – even if your ROS stack is running on a different operating system, Foxglove Studio can communicate with your robot out-of-the-box.

## Modular & Extensible

Every view in Foxglove Studio is a customizable layout, made up of configurable data exploration tools called panels. Our panels can do everything from rendering interactive charts and 3D scenes, to displaying camera images and diagnostic logs. **Using these modular panels, you can effectively build a custom robot control center from scratch to support your every possible workflow.**

Here are some of our most commonly used panels:

- **3D panel** – Display visualization markers (e.g. point clouds, bounding boxes, classification labels) in a 3D scene
- **Image panel** – View images from your robot’s cameras
- **Plot panel** – Plot values from incoming data in interactive charts
- **Raw Messages** panel – Drill down into your incoming data

![common panels](/images/blog/introducing-foxglove-studio/common-panels.png)

Most recently, we’ve added the following panels to tackle common robotics tasks:

- **Map panel** – Display [`sensor_msgs/NavSatFix`](https://docs.ros.org/en/api/sensor_msgs/html/msg/NavSatFix.html) messages as points on a map.
- **Parameters panel** – Read and set rosparams from your connected ROS source.
- **Topic Graph panel** – Render a graph showing the current ROS node and topic topology.
- **URDF Viewer panel** – Use a [Unified Robot Description Format](http://wiki.ros.org/urdf) (URDF) file to visualize your robot model.

![new panels](/images/blog/introducing-foxglove-studio/new-panels.png)

Studio also provides a flexible [Node Playground panel](https://foxglove.dev/docs/utility-panels/node-playground), where users can write custom data transformations in a code editor sandbox – to test out experimental outputs, or to create visualizations on the fly.

## Open-Source

**We’re partnering with our most important collaborators – our users – to build the future of Foxglove Studio.**

Even with our best efforts to release and maintain tools that help every roboticist, we know a one-size-fit-all approach doesn’t cover every possible use case or meet every specific need. We don’t want Studio to limit your workflow options, or otherwise constrain how you can leverage our tools in the future.

That is why we’ll be implementing a **public API for roboticists to build their own panels** that encapsulate the project-specific functionality they need. This will go hand-in-hand with our extensions library, also in the works: in the same way Visual Studio Code has a rich ecosystem of plugins, we want Studio users to be able to browse a **library of user-contributed extensions build to customize every aspect of the in-app experience**. These changes will empower roboticists with any niche development needs to contribute their own custom tools that plug and play within the Studio ecosystem.

We’re also looking to integrate with new data formats beyond ROS 1. Please [reach out](https://foxglove.dev/join-slack) with any data protocols or serialization formats you would like Studio to support.

# Stay in touch

We hope this post helped introduce you to the world of Foxglove Studio. At Foxglove, our North Star is to **streamline how you explore and extract insights from your robotics data**. We hope Studio helps lower the barrier to entry for understanding your robot – on your journey from prototype to polished product.

We’re thrilled you’ve stumbled upon [our community](https://foxglove.dev/community), and we hope you get involved! Let us know what you think is worth building next. Our codebase is written in TypeScript for [easy contributing](https://github.com/foxglove/studio) – feel free to open a pull request, or share your feature requests via our [Slack concierge](https://foxglove.dev/join-slack).

**To see Studio in action, [download the app](https://foxglove.dev/download) and [start tinkering](https://foxglove.dev/docs/getting-started)!**

### _Special thanks_

_We know Foxglove Studio could not exist without the hard work of our colleagues at Cruise, especially those building [Webviz](http://webviz.io/). We stand on the shoulders of giants, and we hope our own open source contributions help the robotics community rush towards the bleeding edge of our field._


Blog