PlotJuggler vs rqt_plot: Why ROS Users Switch

Short answer: rqt_plot is the plotting tool that ships with ROS itself — if ROS is installed, it is already on your machine, and for a quick look at one live topic it remains a perfectly sensible first reach. PlotJuggler is what ROS users move to when the quick look turns into real analysis: recorded bags as well as live topics, hundreds of series handled comfortably, per-curve time offsets, saved layouts, XY plots and custom transforms. The positioning is not ours — it is the author’s own. When Davide Faconti announced PlotJuggler 1.0 in 2017, he described it as something that “can be considered a unified replacement for rqt_plot, rqt_rosbag and rqt_console” — one tool doing the job of three rqt utilities. Nearly a decade later, that sentence still describes the relationship accurately. Part of our Alternatives & Comparisons hub.

The evidence table

Why “zero-install” deserves respect

It is easy, writing a comparison like this, to treat rqt_plot as merely the thing you outgrow. That would be unfair. The zero-install baseline is a real feature: on a robot, on a field laptop, on a colleague’s machine you have borrowed for ten minutes, rqt_plot is there. Verifying that a topic publishes, that a value moves when it should, that a sensor is alive — these are thirty-second checks, and a tool that is already installed wins thirty-second checks. The rqt family also sits close to the ROS workflow in other ways: rqt_bag is the familiar companion for recordings, and rqt_multiplot exists for users who want configured curve arrangements inside the rqt world. Nothing in this page argues you should uninstall any of them. The argument is narrower: know the moment the job changes character.

The moment ROS users switch

That moment usually arrives with one of four triggers, and regular readers will recognise their own history in at least one:

1. The data became a file. The robot is off, the test is over, and what remains is a bag. Analysis now means opening recordings, comparing yesterday’s run with today’s, and aligning signals that started at different times — the workflows in our ROS bag and MCAP tutorial and multiple-bag comparison guide. This is PlotJuggler’s home ground and was never rqt_plot’s.
2. The series count grew up. A real system publishes hundreds of fields. A viewer that was fine for three topics becomes a scrolling exercise; PlotJuggler was built for thousands of series with OpenGL rendering, and its signal list, search and layout system assume that scale.
3. The question needed a computed answer. Not “show me the velocity” but “show me the error between commanded and measured, integrated over the manoeuvre”. Built-in transforms and the Lua Custom Function Editor (see the Lua tutorial) answer that inside the tool; a plain viewer cannot.
4. The view needed to be repeatable. The same twelve curves, the same arrangement, every test, shared with the team. That is a layout — saved once, reloaded forever — and it is the difference between an analysis practice and a series of improvisations.

Verdict by user type

The historical footnote is worth keeping straight, because it is often misquoted: Faconti’s 2017 “unified replacement” line named rqt_plot, rqt_rosbag and rqt_console — a claim about unifying three utilities in one interface, made at the PlotJuggler 1.0 announcement on ROS Discourse. It was positioning, not a benchmark, and we cite it as exactly that. The modern, verifiable version of the same claim is the table above. For the wider field — platforms, SDK-first tools and general dashboards — see the Best ROS 2 Data Visualization Tools roundup, the Foxglove comparison and the hub. PlotJuggler itself is on the Download page.