ROSshow: ASCII art visualizations for robot sensor data | Hacker News Reader

ROSshow: ASCII art visualizations for robot sensor data

github.com

165 pointsdheera40 comments

Awesome! For the images you can go one step further with this fun Unicode hack to make the terminal characters almost square: https://www.uninformativ.de/blog/postings/2016-12-17/0/POSTI...

Hadn't thought of that! Nice work, I'll think about how to work this in. It's tricky with the way I implemented the buffers but it looks worth it.

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.

Very cool stuff!

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.

Here is the ASCII/Braille-art library (which I wrote) extracted out as a generic library: https://github.com/dheera/python-termgraphics

It's on pip: pip install termgraphics (evolving, future versions may break backward compatibility but I'll try not to)

Thanks! I can see some good uses for this outside of ROS.

There is a very cool Julia library: https://github.com/Evizero/UnicodePlots.jl

You mean, like GNUplot with sixels? Such as https://news.ycombinator.com/item?id=19521230 ???

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.

Great idea!

I'd love to be able to do 'rostopic echo /scan --visualise'

Quick question: Can't we just set the font size to very small and turn block character into pixels?

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.

Very slick. Wonder if you considered using Tektronix graphics to get higher resolution images. https://en.wikipedia.org/wiki/Tektronix_4010

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

I am installing it on our lab's Clearpath Husky right now. Thank you!!

Someone said ASCII is a bad suited tool and I agree.

I use the following with mintty on windows: (or mlterm on linux)

#!/bin/bash

export GNUTERM="sixelgd size 1280 720 truecolor font arial 10"

gnuplot-nox -e "set title '$HOST'; plot '<cat'"

Then it's just cat something | '{ print $5}' | tail -n +500 | sixel-plot.sh

I put an example with a screenshot and recompiled gnuplot binaries (debian) on http://github.com/csdvrx/sixel-gnuplot

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.

Happy you like it :)

It should definitely support all Unicode however. mlterm is very unicode friendly.

Maybe it's a font problem?

Anyway, I agree with you, mainstream terminals should support sixel!

I love the braille visualisation. It‘s amazingly high-def

Thanks for making this project!

Here is a ROS discourse discussion on the project where I've shown a gif with laser scan visualization: https://discourse.ros.org/t/rosshow-view-ros-topics-in-the-t... . Thanks for applying my feedback! Love the list of supported messages.

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.

This is cool! I think it would be very useful if we could quickly do some basic math before outputting. For example scaling or averaging etc..

Wish I had this when I was part of my university's robotics club, this looks amazing.

Thank you so much for making this.

This is so cool! Could definitely see people using this for side projects

what about matplotlib with the sixel backend?

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:

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.

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/

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.

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.

Reply on news.ycombinator.com