More intelligent, but not necessarily better?

Selecting sensors and designing algorithms that make autonomous robots perform their tasks is an interesting field of study. One could easily jump into the conclusion that better results can be obtained by adding more advanced sensors and programming intelligent control software that is able to use all the information collected.

The iRobot Roomba was the first domestic robot to achieve commercial success. It only uses simple sensors (I suspect it has IR proximity sensors, bumper switches, etc.) and a a cleaning pattern with a significant component of randomness. Lately competitors have emerged that attempt to differentiate their products by claiming that the addition of computer vision and mapping capabilities coupled with systematic cleaning patterns makes them produce better results.

The video below (from an independent source) clearly shows that the chaotic strategy of the Roomba is better. While the competitors' robots slowly ponder their paths, the Roomba has already cleaned the entire space, and covered most areas more than once, probably leading to a better cleaning result.

What every recreational roboticist should know about computer vision

As I wrote before, I intend to apply some computer vision (CV) algorithms to make SHORT-E more aware of its surroundings. I guess that CV is still not routinely used by recreational roboticists. Hobbyists tend to use simpler sensory information such as that obtained from ultrasonic rangefinders or infrared proximity sensors to make their robots able to navigate in their operation environment.

This is understandable, as computer vision is quite a complicated discipline, the programming tools are not easy to use (or even compile in some cases), and most hobbyists' robots' computational hardware is just not up to the task of executing processor and memory intensive algorithms. However, while I'm not experienced in CV, I happen to have a PhD in computer science and will use Chumby One as my robot's brain, so I'd be a wussy if I didn't at least try to do some rudimentary CV.

For my fellow recreational roboticists that have not yet decided to take the leap: I recommend starting with this nice and popularized introduction to computer vision. If you're impatient, you can safely skip the first part about vision in biology and dive straight into chapters 2...4.

Household tags to aid robots

I'm back at work this week, so progress on the robot project will probably slow down a bit. Meanwhile, I'll at least try to post some general robotics-related stuff.

Automaton has a rather interesting article about making our homes more robot-friendly. As progress in computer vision is slow, why wouldn't we embed tags in our homes that assist household robots in their tasks? Using these tags robots could keep track of their location and recognize objects they are supposed to manipulate.

The idea isn't new and it has actually been applied before. I too have thought of someday using RFID or NFC tags to help my robots recognize objects and locations. There are also commercial robot indoor navigation sensor systems like the Hagisonic Stargazer that are based on fixing landmarks to the ceiling. Nevertheless, the concept is interesting and could help make genuinely useful household robots reality.

Working on getting things to work on the Chumby

Recently I've been working on a couple of things related to my robot project.

1. Getting Chumby and Arduino to talk to each other via USB serial. I've successfully completed a simple test where the Chumby sends an ASCII message to the Arduino, and the Arduino then shows the message on its LCD and echoes it back to the Chumby. Still to be done: writing a proper communication protocol that will be used by SHORT-E.
2. Trying to build and install a working version of the OpenCV computer vision library for the Chumby. It has not been easy. The current status is such that I managed to compile and install OpenCV, but for some reason it cannot load JPEG or PNG images even though I have built libjpeg and libpng for the Chumby and they work ok with other software (at least Fswebcam is able to use them). And even worse, OpenCV cannot seem to get proper frames directly from my webcam, even though it manages to trigger the camera to capture something.

I had to use OpenCV 2.2.0 because I couldn't configure the latest version not to support Python - and OpenCV's stupid CMake configuration scheme makes it next to impossible to cross-compile a version that does support Python. And I do have Python on my Chumby.

Currently I'm able to use OpenCV with BMP images, and I've found a piece of code that does JPEG to BMP conversion using libjpeg. I'm still hoping to get OpenCV to support my web camera by trying to compile a version of OpenCV that uses FFmpeg. First I'll of course have to build FFmpeg for the Chumby.

I'm hoping to be able to implement some sort of simple tracking functionality using OpenCV. E.g. have SHORT-E find and drive to a red ball or even follow a moving person. Hopefully Chumby's processing power will suffice for something like this.