I am a roboticist and most of my professional experience is related directly or indirectly to robotics. Nevertheless, much of what I write here can be applied to other software domains.
PlotJuggler is a platform/middleware independent tool.
It works seamlessly with ROS, but it is not a ROS application. It can be extended to support any data format and data source, proprietary or not.
We start our career as software engineers using “printf” to debug our software; that’s OK at the beginning, when we don’t know better.
Inevitably (“hopefully”?), most of us learn that interactive debuggers (like GDB in Linux) are a much more powerful way to find errors in our code.
But there are software systems and applications where the interactive debugger approach can’t be used.
Embedded software, real-time applications, robotics and distributed systems are software domains where the most effective way to debug the code is through tracing and logging.
Imagine setting a breakpoint in the middle of the control loop that stabilizes a drone: that would be disastrous... and stupid.
Maybe, this is an extreme example, but there are many more cases where stopping a thread or a process would inevitably alter the behavior of the system.
I’d like to think that we can all agree on this, but let me tell you a story…
The Darpa Robotic Challenge (DRC) was a robotic competition that took place a few years ago. It was probably the most exciting thing that happened in robotics in the last decade.
It aimed to develop semi-autonomous ground robots, humanoid in particular, that could do "complex tasks in dangerous, degraded, human-engineered environments." The DRC pushed the envelope in robotics, redefining what was considered state-of-the-art.
I had the opportunity to participate to the DRC as a member of the IHMC team, that won second place.
That was an amazing experience for many reasons, but there is something in particular that transformed the way I think about robotics software.
The IHMC team is the only group I know that, instead of using C++ and ROS, built their own software framework from scratch using Java.
Instead of leveraging the vast toolset provided by the ROS ecosystem, they apparently reinvented their own wheel. That turned out to be a good idea for many reasons; most importantly, they built specific tools to increase their own productivity.
IHMC had one of the most powerful logging and visualization infrastructure that I have ever seen in my entire career.
The software on the robot would automatically log thousands of external variables, in particular sensor readings, and internal ones, such as the state of a particular class or the result of intermediate calculations.
Later, that huge amount of data could be easily navigated using an intuitive graphical interface.
Believe me when I say that this approach really changed the way I think about debugging in robotics and real-time systems.
No more: “let’s run it once again and see what happens”.
Replicating errors can be complicated, time-consuming or even dangerous when the hardware is controlled by faulty software.
But at IHMC, every single time a problem occurred to us, there was no need to replicate the error: most of the time the information in the log was sufficiently exhaustive to pinpoint the root cause of the unexpected behavior.
Once the DRC ended, I have been dreaming about bringing the same user experience and workflow to a bigger audience and, today, I believe I am a step closer to this goal thanks to PlotJuggler.
People are lazy.
Even if they know what they should do, sometimes they procrastinate and keep doing what they always do, even if it is sub-optimal. No one wants to modify his/her own habits when this change is perceived as complicated and difficult.
In other words, it is not sufficient to tell you how important it is to adopt tracing and logging as a first-class citizen in your development workflow.
We need to make this change as simple as possible, and remove even the smallest barrier to adoption. For this reason, PlotJuggler is much more than a graphical tool to visualize timeseries.
When I started building PlotJuggler, I was obsessed about creating a tool that would be simple, intuitive and fast.
PlotJuggler has been designed to remove frustrating, boring and repetitive tasks; 80% of the most frequent actions can be done with a simple movement of the mouse or/and pressing a key.
It makes data visualization a no-brainer, even a joy, no matter is your logs contains tens of thousands timeseries.
This is my contribution to the software community: a tool that can help to change the habits of people, promoting logging and tracing as a valuable alternative to debug robotics, embedded and real-time applications.
PlotJuggler 2.X is a powerful and extensible tool that you can start using today.
Is it perfect? Of course not. There are so many features that I want to add: more data formats, faster parsing of logs, more visual representations, etc.
Without the economic support of those people who use Plotjuggler, I will not be able to work on these features (even if I will always fix reported bugs, no matter what).
If you like PlotJuggler, consider making a donation.
If your company needs a specific or custom feature to be developed, don't hesitate to contact me.