Gawk!

Awk is awesome!

So I was trying to selectively execute a whole bunch of rosbags for a little bit of labelling, and decided to try out gawk a bit to help automate the loading process, rather than to manually type in the path name to each bag file. I was earlier using a shell script to run through every file ./*.bag and calling the variable from rxbag. However, when I wanted to resume my work I had to resume going through the files midway, and so had to use some pattern matching in there. Which is where awk came into the picture.

Anyway, handy tip – after some searching I finally found the required call, which turned out to be, not surprisingly, system(), to call external programs. But I had to send in the matched patterns as an argument to rxbag, so this is what I did

awk '/2012-05-17/ {system("rxbag " "\""$0"\"")}' ds.txt

So 2012-05-17 is the regex pattern I was looking for (The single quotes are to stop bash from reading into the stuff within), ds.txt contained a simple piped output of the list of files in my directory (ls *.bag > ds.txt) The fancy part is in the system call. Now since I had to send in a variable as an argument ($0 is the first line/field of the awk output) within the double quoted system call, I had to use the fancy double quote escape characters you see there "\"". And that was it! awk calls the code within the brackets for every match of the regex pattern.

Neat, eh?

Talking about things neat, here’s a fun video of the project I’m working on at the RI :D

Peek a Boo!

My development machine here at Hi Tech being, well, low end, had been driving me crazy. Eclipse used to take eons to build (even by eclipse’s notorious standards), and rviz used to choke and sputter on my point clouds. Highly annoying.

My incessant pleas were soon enough heard and I was given access to a mean development rig, resplendent with a SSD and all the fireworks. The caveat being that I could only access it over the network – which meant a simple ssh -X command to access the bountiful resources. Not an issue, right? Wrong.

Turns out that ssh -X only routes drawing calls to the client, which means that all the rendering is done locally. So, although I could avail of the (marginally) better build times (remember, it’s eclipse, SSD notwithstanding. Immovable leviathan wins), I was back to square one.

My first tubelight moment was to try using vnc, and after some fiddling around managed to set up in my previous post (in this post. Looked great, and I could finally access the desktop remotely, with the screen frame buffer being sent across my low latency network. I happily run Gazebo only to see –
Missing GLX on Screen :0

As with all things linux, it really couldn’t have been such an obvious solution. This error occured because xvnc does not handle OpenGL calls to the screen. At this point I suddenly remembered my long tussle with bumblebee on my laptop, and looked up virtualGl, and sure enough, it seemed to be the panacea. So, I downloaded virtualGl binaries from their sourceforge page, and followed the user guide to install virtualGl.

Minor modifications:
1. From 11.10 (Oneiric) onwards, the default window manager is lightdm, and so instead of stopping gdm, service stop lightdm
2. After doing this, also rmmod nvidia if you have nvidia drivers installed. Unload the corresponding drivers for ati (fglrx?)
So, having installed the virtualGl binaries on both the server(remote machine) and the client(your terminal) and after configuring vglserver_config on the remote machine, relogin to the remote machine using vglconnect [userame]@[ip address], and voila! Everything will be setup by vglconnect. All you need to do then to execute any GL application is to prefix a vglrun to the command, e.g. I use vglrun rosrun rviz rviz.

So what goes on behind the scenes is that virtualGl loads a helper library whenever you call vglrun. This nifty little hook sits in the memory, and redirects all GL calls to and from the vglserver, which draws it onto the required buffer. So the application doesn’t even get to know what’s really going on. Neat, huh?
As a parting shot, here’s glxgears, running in it’s full ‘glory’.

xvnc

Situation: You need to access a powerful linux machine remotely from another remote machine, with everything running on the remote machine (unlike a ssh -X, in which objects are rendered on your machine), while someone else is *already* working on that machine and doesn’t want to be distrubed.

Solution :
1. Install vncserver on remote machine, vncviewer on client
2. For the host machine running gnome and metacity window manager (e.g. ubuntu, fedora), edit ~/.vnc/xstartup to be something like this

#!/bin/sh

# Uncomment the following two lines for normal desktop:
#exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
unset SESSION_MANAGER
gnome-session&
metacity&
(Thanks to http://forums.fedoraforum.org/archive/index.php/t-201885.html )
3. On host machine, run vncserver. A first time setup will run you through a password you want to assign
It’ll then start a vncserver. e.g. at New 'X' desktop is OCUPC:1
OCUPC being host name, and :1 the screen the server is attached to
4. On client machine, run vncviewer . Ta-da!