PlotJuggler VS ira_laser_tools

If you use ROS, you will have similar facilities with ROS bags and e.g. PlotJuggler. ROS bags are not as convenient to manipulate as MessagePack/JSON dictionaries, although they hold similar data, because the ecosystem is smaller (i.e. less people manipulating them and developing tools to manipulate them more efficiently).

I can also recommend using Plotjuggler instead: https://github.com/facontidavide/PlotJuggler

This is great!! Also see the open source plot juggler (not mine) https://www.plotjuggler.io/

If you want to visualize data on the plot I would recommend using PlotJuggler. Great piece of visualization tool working with ROS. It is available as snap package, so it will be easy to set up. Here's the link with all the details: https://github.com/facontidavide/PlotJuggler

For work sometimes I will use a program called PlotJuggler, where there is a splash screen but it is just a couple seconds of displaying a random, plotting related meme.

Based on your comment, I assume you mean a GUI program for interactive exploration and manipulation, rather than a library?

This was posted on HN a few months ago and came to mind: https://github.com/facontidavide/PlotJuggler

In a past job, we used the commercial app nCode Glyphworks for graphical / interactive signal processing from field tests with hundreds of sensors.

I found the ROS2 concept and design much more well established, especially for industrial. My problem on porting was more like when something available in ROS1 concept is not supported in the ROS2 concept. For example the infamous ira_laser_tools. This package basically merges all the scanning laser topics and publishes it as one so we can use it for AMCL / navigation (with the PointClouds too). The package will use ros::master api so it can manipulate the value alongside the data type format in which such concept is not supported in ROS2. In ROS1 we can take a list of topics with the data types in the format of std::string (topic name), std::string (data type). Laser topic parser in this package will process the data in a c++ way to get only the ones publishing sensor_msgs (scan data type). We can also call topics and the data type in ROS2, but in a format of std::map... I don't have sufficient c++ knowledge and reference to parse from the ROS2 api. I believe these kind of difficulties is also why nobody is working on it too.. In cases like these, how do you tackle the issue?