PlotJuggler Bridge Released

ROS ROS General
, ,
1

Bridge
Bridge1536×1024 97.4 KB

I’m happy to introduce PlotJuggler Bridge, a lightweight server that exposes ROS 2 or DDS topics over WebSocket, allowing remote tools like PlotJuggler to access telemetry without directly participating in the middleware network.

In many robotics setups, accessing telemetry from another computer is harder than it should be. DDS discovery over WiFi can be unreliable, opening DDS networks outside the robot can create configuration issues, and installing a full ROS 2 environment on every machine used for debugging is often inconvenient.

PlotJuggler Bridge solves this by acting as a gateway between the middleware network and external clients.
It runs close to the robot, reads the topic data, and exposes it through a simple WebSocket endpoint that any client can connect to.

This approach keeps the ROS/DDS network local while making telemetry easily accessible from other machines.

The project is available here:

Why it is useful

This is especially helpful in scenarios such as:

  • monitoring a robot remotely over WiFi
  • accessing telemetry from Windows or macOS machines without ROS installed
  • avoiding DDS discovery and networking configuration issues
  • debugging systems without exposing the full middleware network
  • connecting tools without needing message definitions compiled locally

Because the bridge performs runtime schema discovery, clients can access topics even if they use custom ROS messages, without requiring those message packages to be installed on the client machine.

The bridge also aggregates and optionally compresses data, which helps reduce bandwidth usage and improves stability when streaming telemetry over wireless networks.

Main features

PlotJuggler Bridge includes several features designed for real-world robotics workflows:

  • WebSocket access through a single endpoint
  • automatic runtime discovery of topic schemas
  • support for custom ROS message types without client-side compilation
  • aggregation of messages for efficient streaming
  • optional ZSTD compression
  • support for multiple simultaneous clients
  • bandwidth-friendly handling of large messages by stripping large array fields while preserving useful metadata

How it works

diagram
diagram1189×323 55 KB

ROS 2 / DDS -> PlotJuggler Bridge -> WebSocket -> PlotJuggler

The bridge subscribes to topics in the ROS/DDS network and exposes them through a WebSocket server.
External tools can connect and receive the streamed telemetry without joining the middleware network.

Quick to start

The bridge can typically be up and running in less than 5 minutes.

Setup instructions are available in the repository README:

You will need PlotJuggler 3.16 or newer, which includes the WebSocket client plugin:

Basic usage

Once the bridge is running, the workflow is straightforward:

  1. Start the bridge on the machine connected to the ROS/DDS network.
  2. Open PlotJuggler on any computer.
  3. Connect to the WebSocket Client using the bridge address.

The available topics will be discovered automatically and can be inspected immediately.

About the work

My name is Álvaro Valencia, and I am currently working on PlotJuggler as an intern while finishing the last months of my Robotics Software Engineering degree.

I collaborate closely with @facontidavide on this project. PlotJuggler clearly reflects years of work, effort and passion, and contributing to it is a great experience.

Together we are developing the components required to make this new Robot → PlotJuggler connection workflow simple and practical to use. The goal is to make remote telemetry access easier while keeping the system flexible for future extensions that will appear in upcoming PlotJuggler developments.

And stay tuned… more interesting things are coming soon for PlotJuggler.

9 Likes
Is there a working group for maintaining ROS 2-based robots in industry? 🤖
ROS News for the week of March 9th, 2026
ROS News for the Week of March 16th, 2026
2

I am incredibly excited about this new feature and thankful that @AlvaroVM helped me implementing and testing this.

Looking forward for the feedback of the community!

By the way, PlotJuggler 3.16 includes also a connector to the Foxglove bridge… if you want that one :winking_face_with_tongue:

1 Like
3

Are there any technical differences between this one and the one from foxglove?

4 Likes
4

YES!!!

There are some important differences:

  • Foxglove bridge will send one websocket message for each DDS message. PJ_bridge aggregates all the messages in 50 messages per second. The original timestamp is preserved.
  • PJ-bridge compresses the payload and will use less bandwidth
  • PJ-bridge will strip away (optional configuration) information that PlotJuggler can not read (yet), such as pointclouds, images and maps.

But since testing both can be done in less than 5 minutes, try them yourself and decide if one fits your need better than the other.

1 Like
5

A couple of “ROS 2 to WebSocket” solution have been proposed before (GitHub - RobotWebTools/rosbridge_suite: Server Implementations of the rosbridge v2 Protocol · GitHub, ROS Foxglove bridge | Foxglove Docs). I am also wondering, why there isn’t a common solution that can be reused by all these projects?

1 Like
6

rosbridge_suite inspired Foxglove bridge. rosbridge_suite is limited to json and cbor encoding, while Foxglove supports json , protobuf , ros1 , and cdr. Directly copying messages as cdr has a lower overhead.

Why would there be only one common solution? Everyone is free to start a new project and argue why its better than what came before.

7

@christian to be fair, the foxglove_bridge is the most general purpose solutions

Anyway, before people argue about duplications and existing solutions, I invite them to review what we did and not just assume (see wikipedia for “straw man argument”).

pj_bridge doesn’t apply any conversion to the original message. The DDS message (cdr encoded) is sent without any transform to the client. But it also does an aggregation and compression of messages that is particularly valuable for (checking notes)… PlotJuggler, to keep the overhead to the very minimum.

if you believe it is useful to you, use it. Otherwise… dont?

8

I’m wondering what the performance difference would be between running a plotjuggler_bridge vs running plotjuggler with Zenoh transparent_compression.

9

:100: !
Some of us are working towards exactly that, but as @facontidavide said, you can’t really force people to use a common solution. The best you can do is to (try to) provide the best option and let people decide for themselves. As part of Transitive (the open-source framework for building full-stack robotics apps) we are providing an alternative to ros-bridge/foxglove-bridge/pj-bridge that uses a very different architecture. It pushes robot data to the cloud from where it can be pulled by users at any time, even when the robot is offline, rather than pulling from robots directly. This also enabled aggregation of data from multiple robots. To reduce bandwidth usage it only sends deltas instead of entire messages. It works with ROS 1 and ROS 2 (even at the same time) by using @transitive-sdk/utils-ros, which provides a unified interface for both (as much as possible). More details in FAQ: How does Transitive’s data-sync differ from ROSbridge?

You can try it out using the ROS Tool capability (“app”) which is built on top of it:

10

@chfritz may be my announcement was a little premature, because I don’t have yet the full benchmarks, in terms of CPU and bandwidth used by these different options.

Triggered by this discussion I took a quick look and pj_bridge uses 50% CPU that foxglove_bridge uses and simultaneously 1/4th of the bandwidth.

image
image384×129 10.1 KB

So… maybe it wasn’t such a bad idea to add my implementation to the bucket?

I will be delighted to add the Transitive bridge to my comparison :smiley:

I think that maybe Foxglove should consider adding compatibility to the plotjuggler_bridge :rofl:

1 Like
11

How does

go with

? I guess the first statement holds only if the stripping is not configured?

12

Happy to help with that. Can you share the setup or bagfile you used for this comparison?

13

correct, my bad for not being specific.
Wow people, I am receiving a lot of scrutiny in this thread! :joy:

For instance, in a Pointcloud2 message I remove the data, because PlotJuggler doesn’t know what to do with that.. yet. This is an option that people can turn off, if they want to use the bridge for something else.

image
image301×194 19.9 KB

14

I don’t know much about the Zenoh bridge and I probably don’t have enough bandwidth to test it (pun intended).

But do you need ROS installed on you client computer, if you use that?
One of my value propositions is that you don’t need ROS, and it works on Linux, Windows, Mac and maybe… the browser in the future!

2 Likes
15

Unless I am missing something from your webpage, I don’t think the Transitive Robotics bridge is at the same level of the other two we are discussing here…

image
image791×331 55.5 KB

16

That screenshot is from the ROS Tool capability, not the Transitive platform.

This analogy might help:

  • Transitive is like Android.
  • Transitive Capabilities are like Android apps.
  • Transitive Robotics is like Google – unfortunately only in a limited way :wink: . It:
    • develops and maintains Transitive,
    • operates the “capability store”,
    • offers a hosted deployment of Transitive, and
    • develops and offers some capabilities.

Transitive itself and all its tooling are open-source. But just like with Android apps, it’s up to the capability author to decide whether to make them open-source, free, or premium.

The first three links in my post all linked to code and documentation regarding Transitive and its tooling for making it easy to develop such full-stack capabilities, and that’s what I was suggesting to compare to.

17

I see. It makes sense to use the raw serialisation format instead of plaintext for efficiency. According to this, foxglove-bridge seems to be the more generic solution amongst the three discussed here.

I guess PlotJuggler could use the foxglove-bridge when keeping the original data instead of stripping away custom fields. Or the Foxglove bridge gets features required by PlotJuggler.

Well, if there are multiple implementations solving the same problem, one could ask how they differ. No? I mean, someone could also ask why there are different RMW implementations or camera nodes providing images from regular UVC webcams. And discussing the pros/cons of the individual solutions is exactly what we are doing here now. Normally it’s a good thing to compare different solutions to find or develop the best solution (for one’s purpose). This wasn’t mean in any negative way. I was genuinely interested what the pros/cons of the different solutions are and why one solution cannot be reused by another project.

IMHO, having one good ROS 2 WebSocket bridge by merging efforts, e.g. Foxglove bridge adding features required by PlotJuggler, would be better for the ecosystem than having multiple solutions with orthogonal feature sets.

3 Likes
18

You are not wrong, but my goal is not to create a general purpose solution, but to create the absolute best one for PlotJuggler.
Benchmarks are telling me that currently that is the case by a large margin.

2 Likes