With self-managed sites, you can now host data in your own cloud infrastructure, while leveraging the full capabilities of Foxglove Data Platform.

When storing your robotics data, you often want to control the regions you use, where you deploy storage, and how people access your network. By using your own cloud account, you can exercise complete control over the security and isolation of your data.

Using Foxglove with your own cloud account

Foxglove Data Platform helps you explore data more efficiently by streamlining critical development workflows – you can retrieve your data at lightning speed, annotate it with events of interest, and stream it directly to Foxglove Studio for instant visualization.

With self-managed sites, you benefit from Foxglove’s rich data exploration and visualization capabilities while keeping data in your own cloud account. Whether you’re using Amazon Web Services, Azure, Google Cloud Platform, or your own private cloud on-premises, managing your own cloud infrastructure gives you more fine-grained control over how your data is secured and accessed.

Self-managed sites minimize network latency by colocating your robotics data with your company's other resources. By deploying in secure networks (e.g. behind a VPN), self-managed sites can help you restrict access to your sensitive robotics data and comply with company and regulatory data control requirements.

Deploy today

With self-managed sites, your organization has ultimate control over how you store data, while Foxglove does the heavy lifting. To learn more, check out our docs or ask questions in our Slack community.

If you're interested in adding a self-managed site to your Foxglove organization, sign up for a Foxglove Enterprise plan and contact our team to get started.


Roboticists rely on mathematical operations called transformations (or "transforms") to situate their robots' components in relation to other objects in their world.

In this tutorial, we’ll learn how to publish static and mobile transforms in ROS, and how to visualize and edit these messages using Foxglove Studio.

Publishing transforms

Transforms describe how objects in your robot’s world are positioned in relation to each other. They fall in one of two categories – static or mobile. Static transforms remain the same over time – e.g. a transform between a camera and the rover it’s mounted on. Mobile transforms, on the other hand, often vary from moment to moment – e.g. a transform between a rover's camera and a detected pedestrian.

ROS 1 periodically publishes mobile transforms on the /tf topic, to track how they evolve over time. To improve bandwidth, ROS 1 only publishes static transforms on the /tf\_static topic much less infrequently – often only once for a given recording session.

Static

Let's use the static\_transform\_publisher node from the tf2\_ros package to publish a static transform. We’ll be using the example robot from our last transforms tutorial as a reference:

Execute the static\_transform\_publisher node from a Terminal window – x, y, z describe the relative translation, while r, p, y describe the relative orientation (i.e. roll, pitch, yaw angles):



Next, publish a static transform between your robot’s base frame (base\_link) and its arm base frame (arm\_base\_link):



You are now publishing static transforms!

To verify, let's inspect our broadcast messages in Foxglove Studio. Once you load the app, open a Foxglove WebSocket connection with the default WebSocket URL:

Foxglove WebSocket connection

Add a 3D panel to your layout to see all your published frames. Next, add two Raw Messages panels to look at your incoming /tf and /tf\_static messages:

Foxglove Studio layout

Your /tf Raw Messages panel will be empty, as we're not yet publishing any mobile transforms. Your /tf\_static Raw Messages panel, however, should be displaying your static transform messages.

Mobile

Now that we've published a static transform, let's create a broadcaster node that publishes mobile transforms to describe your robotic arm's movement.

Create a tf\_broadcaster.cpp file in your package's src/ folder, and include the necessary libraries:



Define a TfBroadcaster class that publishes a transform message for each new arm transform detected. It should subscribe to the arm position topic (/cmd\_vel, which publishes Twist messages), calculate a new transform whenever a new arm position is detected (armCallback), and use a timer (transform\_timer\_) to periodically publish the last-calculated transform:



Next, let’s instantiate our broadcaster, subscribe to the arm topic, and initialize our timer:



Finally, write a main function to declare and spin the node:



Add the following lines to your CMakeLists.txt to add the executable to the compilation list:



Compile your package with $ catkin\_make, and run this second node:



You are now publishing mobile transforms!

To verify, let's inspect our broadcast messages again in Foxglove Studio. Once you reconnect to your live data, go to the Layouts sidebar and import this example layout.

To simulate a moving robotic arm, use the provided layout's Teleop panel to publish different Twist messages to the /cmd\_vel topic:

final layout

Note how your broadcaster node reacts to these new arm position messages by updating the /tf topic messages. The /tf\_static topic message should remain unchanged, as the arm's movement doesn't affect the static transform between the base\_link and arm\_base\_link frames.

Viewing and editing transforms in Foxglove Studio

Finally, let’s investigate our transform tree to find the relative positions of all our frames, even if they aren’t directly connected.

One way to do this is with the tf2\_echo executable – this lets you calculate any frame’s position relative to a base frame, without worrying about the string of matrices connecting them. Note that this executable is in the tf package for ROS 1, but has been moved to the tf2\_ros package for ROS 2. For example, we can calculate the transform between our base\_link and arm\_end\_link frames, even though these are not directly connected:



As expected, the output Translation and Rotation values will change whenever you modify the arm\_end\_link frame’s position.

Another way to view your transform tree is to use Foxglove Studio's 3D panel. Once you connect to your data and open the 3D panel’s settings, you’ll be able to see a list of all transforms detected in your source:

Each indented frame in the 3D panel settings represents a child of a parent frame.

You can even use the 3D panel settings to modify transforms in real time. Toggle “Editable” in the “Transforms” settings, then edit each transform’s values to see them reflected in the 3D scene:

editable transforms

Keep in mind that this feature is mainly for real-time debugging – whether you’re verifying the position of your robot elements or maybe correcting bad sensor readings. These updated transform values are not actually published to the /tf and /tf\_static topics.

Learn more

Transforms are one of the most potent tools that you will need in your robotics career. Being able to publish, visualize, and even edit transforms can help you better understand the world your robot is navigating.

For a reference to all the code covered in this post, check out our GitHub. And 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!


The new Foxglove bridge connection dramatically improves streaming performance, provides custom message and publishing support, and offers reliable live connections to your ROS 1 and ROS 2 stacks. Install the foxglove\_bridge ROS package to start connecting live to your robots in Foxglove Studio.

The next generation of live ROS debugging

With foxglove\_bridge, Foxglove Studio users now have a stable, performant, and out-of-the-box solution for connecting live to their ROS 1 and ROS 2 systems. Foxglove bridge is a ROS node implemented in C++ for high performance and low overhead, and is designed to minimize impact when running on your robot or developer workbench.

With this new bridge, there’s no need to make tradeoffs. It maintains the low overhead and high performance of native connections, while supporting ROS 2 custom messages like Rosbridge connections. Connecting to your robot from outside the ROS stack also becomes easier than ever, as the Foxglove bridge reduces the networking complexity between Studio and your robot.

Since we've learned that Rosbridge can struggle with streaming high-frequency topics and large messages like images and point clouds – both from Foxglove Studio users and our own testing – we designed Foxglove bridge to tackle these performances issues and to provide a dramatically streamlined experience for Studio users debugging their robot.

Rosbridge vs. Foxglove Bridge performance
Streaming Intel RealSense images (1280x720 raw rgb8 images) from a NVIDIA Jetson TX2 robot. We found that Rosbridge was unable to keep up with reading, serializing, and sending all streamed data, dropping \~36% of messages.

Once you’ve installed and added the foxglove\_bridge node to your ROS stack, open Foxglove Studio to open a Foxglove WebSocket connection:

Foxglove Studio welcome dialog

You should now see your live robotics data loading in your Studio layout! Add new panels to start exploring your data.

Stay tuned

Robotics teams shouldn’t have to jump through hoops to view their live data. With the foxglove\_bridge, we hope Foxglove Studio users can more reliably connect to their systems – regardless of framework or data format – and spend more of their precious development time taking full advantage of our visualization and debugging features.

To learn more about our new foxglove\_bridge, check out the Foxglove Studio data connection docs and the package’s GitHub repo.

As always, join our Slack community to ask questions, or reach out to us directly with any feedback.


Announcing the New Foxglove Bridge for Live ROS Data

The next generation of live ROS debugging

Stay tuned

Read more:

Ready to try Foxglove?