Ravi Mohan's Blog

Showing posts with label research. Show all posts
Showing posts with label research. Show all posts

Monday, November 26, 2007

Books for 2008

These are the books I'll be working through in 2008.

Sunday, October 28, 2007

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!

Saturday, October 06, 2007

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.

Tuesday, September 18, 2007

The Lame and the Blind - Proofs And Code in research software

There is this old story about a blind man teaming up with a legless man. The blind man carries the legless man on his shoulders and provides the locomotion while the sighted cripple tells him where to head.

Similar divisions of labor exist in enterprise software (think "developer" and "analyst") but this two fold division of labour is exacerbated when one focuses on research software. Here the scientists are the "sighted folks" who know where to go but can't move and the developers are (ideally, as we'll see later) the folks who know how to move the project forward by writing code, but don't have the requisite mathematical/scientific skills to navigate and choose one direction over another.

Earlier today, I was talking to a scientist trying to move a multi million dollar machine learning project forward, who was feeling hamstrung because it was impossible to find a few people who could follow advanced calculus and also write good C code.

Unlike in the folktale, a real life arrangement consisting of a blind man and a cripple would be very inefficient, with the occasional fall, not to mention the constant stubbing of toes and odd outburst of swearing. But equally, nothing in real life mandates this kind of "pairing". Nothing prevents a scientist from learning how to code (except a feeling that coding is a relatively "blue collar" activity) and nothing prevents a developer from learning the requisite maths and science (except that most developers, especially the enterprise/agile/dsl types either don't have the caliber to learn hard math or think erroneously that these skills are beyond them or just don't want to work that hard).

The few folks who do master both proofs and code, can and do make a tremendous difference. The very best people in every research area that incorporates software and maths are very capable scientists/mathematicians and very capable programmers. Peter Norvig is an example. As is Donald Knuth. Or Manolis Kellis. Or Yann leCun.

If you are running a research software project you'd want to staff it with high level multi-class (think dungeons and dragons) scientist-mathematician-developers. Unlike in D and D specializing in one area does not need to involve trading off the other.

After all the lame man/blind man arrangement is not the best possible one. The best (and normal) situation is having two (or n) people who can both walk and see.

Thursday, June 14, 2007

Rogue Researcher's Route Map - Addendum

I wrote about what I learned when attempting to do Comp Sci research on my own (A Rogue researcher's route map).

Something I've learned since then might help people read research papers- Every (good) research paper asks (and hopefully answers) a question. Try to discover the question being asked and the answer and nail them both down by trying to express them in a couple of sentences each.

This really helps you understand the significance of a paper for your research. And stops you from panicking when you discover papers which seem to cover ground similar to what you are doing).

Paul Graham , talking about startup ideas, says,

Treating a startup idea as a question changes what you're looking for. If an idea is a blueprint, it has to be right. But if it's a question, it can be wrong, so long as it's wrong in a way that leads to more ideas.

Seems to work for research as well, especially for solo hackers attempting research outside institutional frameworks.

Friday, October 27, 2006

Cracking the GRE

Update: Analytical Score updated.

I wrote the GRE a few days ago.

Scores -

  • quant- 790/800
  • verbal 800/800 (heh!)
  • Analytical Writing - awaited (I am not too worried about this).- 6.0/6.0

I am going through the annual "Should I apply for this year or next year, MS or PhD, Applied mAths or CompSci? " dance.

Choices .. choices ..

Saturday, June 17, 2006

[DevNote] Interpreter To Compiler

I generally use a wiki (moinmoin in case anyone is interested) on my laptop to keep notes on various projects I work on. However the wiki has not been transferred from my old laptop to my new one. With all the travellng I am doing, this won't get done till the next month or so. Meanwhile I'll use this blog to record (some of) my dev notes (when i can get net access ...sigh.....). Since Blogger doesn't support tagging or categories, I'll prepend a "[DevNote]" string to the title of the post so readers can ignore the post if they wish. These notes are likely to be cryptic and incoherent and most readers should just skip them.

To transform an interpreter to a compiler,

  1. Rewrite interpreter in CPS form.
  2. Identify Compile time and Runtime actions(CPAs and RTAs)
  3. Abstract RTAs into separate 'action procedures'.Use thunks to wrap any weird control structures where necessary
  4. Abstract Continuation Building procedures (CBPs)
  5. Convert RTAs and CBPs into records. Now the eval on the parse tree spits out a datastructure.
  6. Write an evaluator for the resulting data structure making sure to (a) implement register spilling (b) 'flatten' code to generate "assembly like" code.
  7. TODO : investigate the pros and cons of Bottom Up Rewriting Systems (BURS) vs the scheme above vs generating a (gcc) RTL like intermediate language
  8. TODO : investigate the effects on stack discipline and garbage collection when the various schemes are adopted . Which is more convenient?