I don't understand why people think this is useful. ASCII art is probably the most low resolution way of visualizing something that should be as high resolution as possible.
Sometimes that robot is running embedded hardware, can't be directly connected to a monitor, is running over a low-bandwidth LTE connection, or you simply don't want to deal with a bunch of port forwards, X forwards just to see if e.g. your sensors are working or if your algorithms are outputting something meaningful.
With pretty much all ROS-based robots, you always have a way to SSH into them. The problem is the only way to view data over SSH is "rostopic echo" which can be pretty meaningless for something like a camera or LIDAR. With this, you can tell within seconds if your camera got blocked by an object, for example.
Or you just want to see if your battery voltage dips when your motors spin. Or how much current is being consumed on full speed. Or whether your IMUs are oriented correctly.
At least these have all been necessities of mine in my various pursuits with ROS, hence I built a tool around those, and felt I might as well share it in case others have had similar frustrations with ROS.
By the way, the default mode uses Unicode Braille characters, so you get sub-character resolution (2x4 pixels per character) as long as you're on a Unicode terminal. There is also a strictly ASCII mode (-a) if your terminal doesn't support Unicode, for the sake of completeness.
Some context: I have been using ROS1 for ~5 years and I'm a contributor to the core libraries. I have not dealt with multi-robot swarms but let's face it, ROS1 wasn't meant for that. You can always point your machine to the ROS master, which in my case was running on my robot and `rostopic echo` anything. I'm not disagreeing that seeing random numbers fly by your screen is meaningless but there _are_ existing software that is good for visualization such as rviz and and rqt_plot.
This is a very cool project eitherway.
I'd love to see some improvements to dynamic_reconfigure because it's pretty bad and we should be using redis or something to handle it by now.
If you have just ssh, why not gzip the data, and plot it on your laptop?
I think you should consider modern tools instead of ascii art plot, cf: https://saitoha.github.io/libsixel/
This is just a quicker way to diagnose stuff. I do forest robotics, and when I'm in the woods with my robot the lesser fiddling with my laptop I have to do, the better. It's always great to be able to quickly verify that all sensors are working properly before starting an experiment.
If you used the various extensions that are present in most terminal emulators (Sixel, and other proprietary/fringe ones) you could get at least 8/6=1.333 bits per pixel (for Sixel) if not better, depending on whatever the terminals support.
The results look good, here is an example of a project using Sixel:
https://github.com/hackerb9/lsix/
There is even vector graphics support in Xterm and other terminal emulators (Tektronix mode, and maybe others such as ReGIS) that allows you to plot a line from point A to point B (and other shapes for ReGIS) In Tektronix mode you can plot lines with perfect resolution (4096 over the width of the terminal) using only 5 bytes per line, no matter how long the line is across the screen.
These gifs are XTerm windows in Tektronix mode:
http://phk.freebsd.dk/AducLoran/animation.gif - http://phk.freebsd.dk/AducLoran/animation2.gif
You can even use gnuplot (over ssh if you need to) in an XTerm and have the plots shown in a separate window, using Tektronix mode emulation.
I think this mode would be better suited to some of your program's outputs.
This tool is great because you can see the data without leaving the terminal, speeding up development.