5 ms·

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

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.

msadowski 8y ago
You rarely need to see anything at full resolution while developing software for robots. This tool is great because you can see the data without leaving the terminal, speeding up development.
dheera 8y ago
Author here. Honestly I built this out of necessity. Yes, there are better ways to visualize things, but often times you want to just SSH into a robot and see whether a sensor is outputting something that makes sense or whether it's outputting garbage. 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.
- isatty 8y ago
  I kind of have to disagree slightly with what you said there, namely about solely relying on SSH. 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.
- csdvrx 8y ago
  2x4 pixel is still too low. 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/ https://saitoha.github.io/libsixel/
  - jefft255 8y ago
    We can do that already by recording a rosbag and then reading the data back on a laptop. Or by port forwading, changing rosmaster and blablabla. 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.
- etatoby 8y ago
  Using Braille patterns is a pretty cool idea. But you're still using 3×8/2×4=3 bits per pixel, excluding colour information and SSH compression. 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/ 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/animation.gif - http://phk.freebsd.dk/AducLoran/animation2.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.
aflam 8y ago
We had issues reliably using rviz or other visualisation tools on ROS. Something will often break (opengl with docker ? outdated version of ROS or missing packages ?). There is a lot of value in having a text-based way out for simpler debugging.

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.

msadowski 8y ago

You rarely need to see anything at full resolution while developing software for robots. This tool is great because you can see the data without leaving the terminal, speeding up development.

dheera 8y ago

Author here. Honestly I built this out of necessity. Yes, there are better ways to visualize things, but often times you want to just SSH into a robot and see whether a sensor is outputting something that makes sense or whether it's outputting garbage. 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.

isatty 8y ago
I kind of have to disagree slightly with what you said there, namely about solely relying on SSH. 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.
csdvrx 8y ago
2x4 pixel is still too low. 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/ https://saitoha.github.io/libsixel/
- jefft255 8y ago
  We can do that already by recording a rosbag and then reading the data back on a laptop. Or by port forwading, changing rosmaster and blablabla. 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.
etatoby 8y ago
Using Braille patterns is a pretty cool idea. But you're still using 3×8/2×4=3 bits per pixel, excluding colour information and SSH compression. 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/ 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/animation.gif - http://phk.freebsd.dk/AducLoran/animation2.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.

aflam 8y ago

We had issues reliably using rviz or other visualisation tools on ROS. Something will often break (opengl with docker ? outdated version of ROS or missing packages ?). There is a lot of value in having a text-based way out for simpler debugging.