Intoxicating Conversation

I just got back from our end of the month "Losers' Club" meetings (more on these here). In the absence of the one person in our group who maintains an interest in enterprise software, we focussed on the more "blue sky" aspects of software/comp sci.

Topics that came up for discussion - Haptic sensors for robots, micro robots, challenges in building a simulation of the human cardio vascular system, metrics for each component of a research effort, Randy Pausch and his lecture on Time Management, the Bhagavad Gita, Reinforcement Learning as a methodology to learn control algorithms, Computational Fluid Dynamics and Aerodynamic modelling, building SkyNet, using histograms to model discrete probabilistic distributions, Algorithms for probability Density Tree construction, how to keep tight focus on research projects that spin off more areas for exploration with every step taken aka how to balance exploitation and exploration in the context of Rogue Research, proof techniques as weapons in a personal arsenal, abstract problem spaces, Lush as a lisp for day to day work, overcoming the fear of Calculus, Django (yay!) vs Rails (bleh!), the non importance of learning java script, Prototype vs jquery, Goal Driven vs Capability Driven learning styles, continous phenomena in genotype decoding, a proposal for a facebook style app for researchers, Aikido, conferences in Goa, and of course status reports, "iteration reviews" and plans for the next month.

Aaah, Life is Good!

A Few Good Men

One of the oddities of India's "silicon valley" is that there is very little hapening that is technically interesting.

For example, take interest groups. User groups for various topics of technical interest certainly do exist - for some value of "exist". They are unfortunately not very effective. Some common patterns I've seen are

FizzBust - There is a lot of enthusiasm for setting up a group, drawing up an agenda and holding an initial meeting. After that first (or occasionally second) meeting, nothing much happens and the group dies away.

"Eternal Beginners Syndrome" - Every single user group meeting has talks of the variety "Introduction to X" where X is the topic of interest. This is certainly fine *if* people ever move on to intermediate or advanced topics. This rarely happens. What's worse, every one of these "introductions" are (a)focussed on power point presentations and (b) every slide in those horrendous presentations are cut n pasted from the same old books. Encouraging powerpoint for non visual data is the infallible identifying sign of a group that has passed its peak and is now declining in utility and relevance.

A closely related pattern is "Propaganda over Exploration" - the group takes on the attributes of a cult with some members claiming to have "superior wisdom", the dissemination of which becomes the primary aim of the group. Thus rather than have a a collegial group exploring and learning and where appropriate criticizing the focus of the group, one has "masters" and "followers". This quickly drives away any good folks.

"Philosophy Over Code" - This is where people wax lyrical over the virtues of GPL vs the BSD license but haven't written a single piece of open source code in their lives and don't intend to.

"Uncritical Acceptance" - Once in a X user group I suggested that one possible topic for an upcoming "X Conference" would be "Where is the use of X inappropriate". I was quickly shushed with "That is a valid question but asking it in public would "hurt the movement" ". My reaction was "Duh? "movement"? what movement?" but I didn't press further.

The way to run an effective (vs "popular") user group would seem to actively invert all these phenomena. Have a small bunch of experts meet regularly to discuss things of interest. Don't actively try to expand the group or conduct "outreach". Avoid all formal organization and "outreach programs". If someone wanders in after hearing some word of mouth description of what goes on that's fine, but don't actively aim at recruiting or expanding the group. Have everyone bring code (or proofs or papers or whatever the metric of actual progress in the field is) and actively discourage empty philosophizing.

I've been experimenting with some of the above ideas for the last few months and they see to work well. One kind of "community" I'd like to see is of amateur researchers in hard comp sci - amateur in the sense of "pursuing research strictly out of interest and not to get paid" , not "amateur" as in "lacking skill". Assembling a group like this has its own difficulties however. With a few honorable exceptions most members of (Indian) "research groups" of technical companies could be stood up against the nearest wall and shot with no appreciable impact on the output of those groups. Likewise for most researchers in (Indian) government service or the (Indian)educational institutions. But "most" != "all" and that is what keeps me from abandoning the idea.

Snapshots from my Robot Simulator

I've built a tiny robot simulator for my ongoing research. Like the (absolutely brilliant) Stage Simulator, my simulator enables the simulation of robots in a 2D world. Of course my simulator is much simpler than Stage, primarily because it doesn't try to do as much as Stage does. On the other hand it has a couple of important differences that are important to my research. For e.g. it has a built in sensor and motion error model and (being implemented) a sophisticated Sonar Model.

Anyway, here are some early snapshots of a simple environment.

A simple world for a robot to navigate - The world is 10m X 20m with a resolution of 2 cm. The corridor is 2.5 m wide.

A robot (the little blue dot)stands in the middle of a corridor.

The world overlaid with a quadtree that overlays and recursively decomposes the 2D world and enables efficient ray projection.

The world illuminated with a laser. The illuminated points are rendered in yellow. The scan has a resolution of 1 degree,a "pan" of 360 degrees and a range of 3 m. I was a bit concerned that this would be slow but it takes no appreciable time, even when the angular resolution is 0.1 degree. All hail the quadtree!

Of course the robot sees only the illuminated points, not the complete length of the walls etc.

This is what the robot "sees". There are other sensors simulated (e.g. an odometer) but they are not rendered here. You'll notice that the laser sensor senses the environment "perfectly", i.e the range detected is the actual range to an obstacle that intercepts the laser beam. No real sensor works like that. To simulate this imperfection in a simulator, a probabilistic error model is added to filter the reading so the robot sees an approximation to the real range.

Here we've added a bivariate gaussian error (with a standard deviation of 10 cm) to the laser sensor. If you squint, you can see that the readings now only approximate the wall surface. To see this more clearly, we'll remove the unseen parts of the corridor walls and the overlaid quadtree to get a picture of what the robot sees, with the simple error model in place.

This is what the robot "sees" through the error filter. Note the "scatter" of the readings. Now the robot doesn't know for certain where the walls (or whatever objects obstruct the laser - different parts of the world react differently to different sensors - some surfaces absorb light for e.g returning no readings to the laser sensor) are.

The robot simulator is not the central thrust of my research effort, but it helps to have an environment in which one can plug in various sensor models, motion models and error models and see what the robot would see. I thoroughly enjoyed coding this up.

The next step is to replicate a realistic sonar (vs laser) sensor. There are a few interesting issues to be resolved to get this to work properly. Sonar works differently from lasers - cones of ultrasound have different propagation and reflection characteristics from rays of light. Stage simulates sonar with the same "ray trace" approach as is used for lasers. For my research I need a more accurate model (and hence the need for a custom simulator). Early next week, I will be visiting the Robotics Lab of the DRDO (The Defense Research and Development Organization - For non Indians reading this, they are the local equivalent of DARPA) to talk to some scientists working on similar problems. I have a basic sonar model working already, the key challenge of which was to layer different continuous probability distributions and sample data from them in reasonably efficient fashion, but to describe that would make an already long post longer, so I'll stop now.