Friday, August 06, 2010

Cricket: My Adventure in Robotics.

In my spare time I have been working on building a robot. I call it Cricket. The idea of writing computer code that can be used to manipulate objects in the real world fascinates me. Working on the bot has played into this fascination and has provided a lot of fun and an outlet for my curiosity.

One of the problems I have had in the past with the idea of building robots is that my ability to make things out of raw materials sucks, and I don't have a good shop to build things in. Luckily the good folks at Lego Inc. has a robotics kit that is computer programmable, so I build Cricket out of Lego Mindstorms (leveraging my many many years building Lego models as a kid), and I am using Python to write software to control it (leveraging my many years writing python code. note: leveraging is good).

Cricket has 4 wheels, but the wheels on each side are connected via gears so it drives more like a tracked vehicle. This allowed me to build a four wheel drive bot with only 2 motors as my parts supplies are limited. The bot actually has excellent traction and can climb over fairly significant objects with relative ease. Currently Cricket has no sensors, but the lego kit comes with touch, sound and light sensors which I hope to employ in future iterations of the model.

My long term goal is to have Cricket that will find its way from point A to point B, avoiding obstacles autonomously. My immediate short term goal is to add touch sensor support so that it can detect when it bumps into an object.

I have the basic code to control movement of the bot. I can issue commands like 'go forward 10' which translates to move forward for 10 seconds. I can move it forward, backwards, and make left and right turns. I can also control how much power each motor use.s

I have decided my current interface for Cricket is not sufficient to support reacting to sensors appropriately, since now I send a command (turn left etc.) to the bot and it blocks while it executes. i.e. type command; wait for execution; type another command. To incorporate sensors I would have to make the commands aware of each sensor, which is sub0optimal at best.

My next task is to find a way to write a non-blocking execution engine for the bot. I am thinking of using a game engine model. Signals will come from various sources: user input, sensors etc, and the bot acts accordingly based on its internal view of the world. This way I could add functionality to have it abort or initiate movement if a sensor triggers. i.e. if it hits a object, or a light turns on etc.

It should prove to be very interesting to write this code. Stay tuned for more info.