The author demonstrated this live at Homebrew Robotics Club last night. It was among the best live-demos I've seen, with the presenter simultaneously talking to the group in an entertaining way and running the demonstrations.
This is great!! I would really like to see this implemented as a generic library for visualizing data, not limited to ROS. Something like matplotlib on python but with all the output in ASCII.
Thank you OP. This is one of the best projects I have seen on hacker news in several weeks! In my company, we face similar challenges. Many times we need to visualize sensor output over really bad network connections on the other side of the country. If we had seen this before, we may have simply used this out of the box.
This is very cool and looks like it could be extremely useful. Maybe worth trying to integrate into rostopic echo itself, I.E. by passing an extra flag or something. Might be worth going that route with ROS2 since I see roshow2 is still in the TODO phase, though I realize that's a whole can of worms.
If the core ROS people are interested in integrating it I'd be happy to discuss, but if that doesn't happen I don't think they expose an API to control the behavior of the rostopic command.
You did give me an idea though which is to have rosshow "fall back" to rostopic echo for types it doesn't understand, so that you never have to "try twice".
For ROS 2 support -- I abstracted out all the Viewer logic from the ROS logic so in principle it should only take modifying 1 file of code and maybe some package configuration changes to support ROS 2. I'll work on this after I familiarize myself with ROS 2, or would love community help here.
Expose API? I am not sure why that is necessary? The source code for rostopic is here:
https://github.com/ros/ros_comm
What is the barrier to simply adding a 'plot' command to rostopic?
[edit to add:] Ignore the naysayers, this is an excellent tool. I am sad I missed the demo Wednesday night.
Yep so the terminal size directly influences the amount of bandwidth consumed by this, so if you want higher resolution at the expensive of higher bandwidth you can just reduce your font size.
For gnome-terminal just hit Ctrl+[minus].
I wouldn't recommend going all the way down to 1 pixel though.
This looks really cool and fun, but, one roboticist to another, why do you not stream out just the raw data and render hidef clientside? Surely streaming "pixels" transfers way more bits than necessary, which is bad for low throughput connections.
It's been a little while since I worked with ROS, but this is just fantastic. Excellent idea. Working with hardware in the real world is messy. A tool that gives you quick-and-good-enough feedback to help debug/tune things? +1
Yeah sixels look really nice. I usually use gnome-terminal which doesn't seem to support it, which is why I never really built sixel for myself in the first place. But it looks worthwhile to build support in for it.
Considering I already have a framework to support both Braille and normal ASCII art, I think it should be possible to work in sixel support with graceful fallback to Unicode and ASCII. I think the way I have it set up, only the termgraphics library would need to be changed, without needing to change the visualization logic.
Your post made me create an account to respond to you and upload a few screenshots of what I use along with binaries. Check github.com/csdvrx/sixel-gnuplot - you will see it's not just nice but also super practical.
apt-get install mlterm and you're done!
For fallback, I agree: a braille support in gnuplot would be great when sixel support is not available.
Interesting. Just tried that. It works, but it seems like it doesn't support a lot of Unicode (including Chinese which is my system language and used in a lot of my text files) so it's kind of a deal-breaker to use on a day to day basis.
If gnome-terminal and other mainstream terminals supported sixel though that would be really amazing.
Nevertheless though it would be nice to build support into ROSshow for sixel since it's not that difficult to launch mlterm just for ROS visualizations, and for people who use English only, and in hopes that gnome-terminal will support it one day.
This is super nice! Only nuisance I can think of is that there's no way to start listening even if nothing is being published or if publishing stopped for a while. Not sure if it's worth to fix for these cases.
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.
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.
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.
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:
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.
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.
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.
