Simulation plays a crucial role in robotics development by allowing developers to assess their algorithms and designs without physical prototypes. In this tutorial, we will demonstrate how to simulate a robotic arm with physics-based simulator Gazebo and visualize it with Foxglove Studio.

Setting up

Before getting started, install ROS 1 Noetic and Gazebo.

This tutorial assumes basic knowledge of ROS – the tutorials on the ROS Wiki and the Foxglove blog are a good place to brush up on your ROS basics.

Running the simulation demo

Before running the simulation demo, we must first build the simulation package in the foxglove/tutorials GitHub repo. See the README.md file for detailed instructions.

Once the package has been built and the workspace sourced, run the simulation:



This will start Gazebo and spawn a Universal Robot UR5e with a mounted depth camera, a fixed RGB camera, and a box-shaped object in the Gazebo world.
To spawn a robot and camera models, you can provide URDF files that contain \<gazebo> tags. These tags instruct Gazebo to create depth and RGB camera sensors and expose them on ROS topics using gazebo\_ros\_pkgs plugins.

Besides the Gazebo simulation, simulation.launch also launches MoveIt to plan and execute robot motions. The simulation also launches foxglove\_bridge to visualize the robot model and camera images in Foxglove Studio.

Moving the robot

Run the Python script in the simulation demo package to execute robot motions using MoveIt's Python API:



This will cause the robot to move through several positions to inspect the box with its mounted depth camera.

Use rqt\_joint\_trajectory\_controller or MoveIt's motion planning RViz plugin to move the robot to other arbitrary positions.

Visualizing with Foxglove Studio

To visualize this data, download the latest version of the Foxglove Studio desktop app.

Make sure that the ROS\_PACKAGE\_PATH setting includes your workspace, so that Studio can locate the mesh files referenced in the robot's URDF file.

Next, open a live Foxglove Websocket connection – specify ws\://localhost:8765 as the connection URL.

Add a 3D panel to visualize the robot model and all transforms. Then, add a few Image panels to view the RGB and depth image topics.

You should now see both the robot model and camera images visualized in your Studio layout:

Stay in touch

To reference all code covered in this post, check out our foxglove/tutorials GitHub repo.

As always, feel free to reach out to us directly in our Slack community to ask questions or request a topic for the next tutorial.


Foxglove Data Platform now supports metadata records and attachments for MCAP files. Once you import an MCAP file into the platform, you can now go to the recording's details page to view its metadata or download its attachments.

Metadata records store contextual information about the entire associated recording – data like the robot ID, hardware details, and operating location. Attachments, on the other hand, are tied to specific timestamps in the recording and contain auxiliary artifacts like maps, calibration values, and system log files. Together, metadata and attachments can provide roboticists with a more holistic view of what their fleet encounters on its various excursions.

metadata and attachment tabs for a recording

Use the Foxglove web console to export an MCAP file with all its original metadata and attachments included, or you can choose to download individual attachments for separate analysis:

downloading a recording or its attachments

Stay tuned

With metadata and attachments support, we hope all Foxglove users can now get a more comprehensive understanding of their team's MCAP data.

If you have questions or feedback about Foxglove's MCAP support, don’t hesitate to contact us directly or to join our community Slack channel for live support.


At Foxglove, we leverage Vercel to host our marketing website and Cloudflare to reap other benefits like URL rewrites. This allows us to host different parts of our website from separate repositories—for example, we generate our homepage and API docs from separate projects.

When introducing Cloudflare in front of Vercel, however, Vercel returned an “Invalid Configuration” error for our domain. Ignoring this problem could lead to an expired TLS certificate and interrupted service for our users. Unfortunately, the only solution offered was to point our DNS records to Vercel directly – something that would require us to move away from Cloudflare altogether.

Vercel error

Maintaining HTTPS protection in Cloudflare

Contrary to what many online resources and the Vercel docs themselves advise, you should not resolve this issue by disabling Always Use HTTPS. We felt it important to maintain automatic HTTPS protection across our entire domain and redirect all HTTP requests to HTTPS.

Cloudflare HTTPS

Understanding the role of ACME

Both Cloudflare and Vercel utilize the ACME protocol—with SSL providers like Let’s Encrypt—to issue certificates. To validate domain ownership, the protocol sends an HTTP (not HTTPS) request to /.well-known/acme-challenge/\<id> on your server.

It's vital that the HTTP URLs matching this pattern are delivered to your origin server and are not redirected to HTTPS. Instead of setting up Cloudflare page rules exempting this URL pattern from HTTPS, as previously required, you can now rely on Cloudflare to correctly handle ACME HTTP requests by default, without additional configuration.

The example below shows two requests—one being redirected to HTTPS, and the second one being passed through to the Vercel origin, without additional configuration:



Resolving the “Invalid Configuration” issue

Unfortunately, even after attempting various page rule modifications, we found that Vercel was still unhappy. To satisfy Vercel, we ultimately had to set the SSL/TLS encryption mode in Cloudflare to Full or Full (strict), and no higher.

Cloudflare TLS Mode

We initially had this set to Strict (SSL-Only Origin Pull), but this proved incompatible with Vercel. The Strict (SSL-Only Origin Pull) setting transforms all requests to the origin (Vercel) from HTTP to HTTPS—even if the request to Cloudflare is using HTTP. This transformation occurs silently, causing Vercel to disregard the request. By setting it to Full (strict), Cloudflare will automatically exempt ACME requests from the Always Use HTTPS setting and forward them through to Vercel unmodified.

The Vercel docs suggest setting the SSL/TLS encryption mode to Full, but have not been updated to explicitly mention avoiding the new Strict (SSL-Only Origin Pull) option as of this time.

Check out the the two example HTTP requests below to understand the effects of modifying this setting. The first request returns various Content-Security-Policy and other headers from Vercel’s CDN, while the second responds with fewer headers, signifying that it's reached Vercel’s ACME validation endpoint:



In summary, if you're looking to make Vercel and Cloudflare play nicely together, avoid setting your Cloudflare SSL mode to Strict (SSL-Only Origin Pull). With this one essential configuration detail, you can prevent any unnecessary interruptions to your services.


The leading observability platform for robotics developers

Use Foxglove Studio's rich interactive visualizations to analyze live or pre-recorded data.

Use the Foxglove Data Platform to manage and organize your data.

Lean on robust community support to get the most out of our extensible tools.

Follow our blog

Want product news and updates?

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