I somehow got into a discussion with my friend Josh last night about robotics. He mentioned an interest in picking up a Roomba and modifying it. I let him know that they have an SDK, tools, and sites out there for developing custom stuff for the Roomba. Pretty neat stuff…

The more we talked, though, the more we began to argue about some of his goals.

For me, the real problems with the Roomba units are more hardware-related than software. The existing cleaning algorithms seem to get the job done — at least over an extended period of time. The stuff I’d love to see changed would be for it to have a dumping station (sort of like the existing charging station idea) where it could clean out the dirt/dust it has sucked up. Also, I’d like to see it be a bit more durable and require less cleaning. I’ve seen way too many get gummed up with pieces of string, carpet fibers, etc. and eventually all it can do is spin in a circle a few times before shutting down.

Josh had other ideas, though. He said he wanted to include some sort of internal operating system that could connect to his computer to send/receive information. He talked about using different techniques for determining how dirty the area was and to spend more time over the dirty sections. Stuff like that… eh… whatever. I’m not that passionate about vaccuuming, really… and I’d never rely on something like a Roomba for all of my cleaning needs.

Where Josh and I were in major disagreement, though, was relating to mapping versus algorithms.

Using algorithms that rely on movement patterns and reacting to sensor data just makes the most sense to me. This allows it to be highly adaptive. You can put it in pretty much any room and it’ll do a decent job.

Josh had a different view on the subject, though. He felt that the way to make it the most efficient was to include mapping. It would “explore” its surroundings and be able to avoid areas where obstacles are going to be.

Mapping is fine and dandy for fairly static things like, say, walls or a washer and dryer set… Things like those aren’t likely to move. But what about, say, a laundry basket that is sitting somewhere? If it maps the boundaries of it, we don’t want it to skip that spot in the future once we’ve moved the laundry basket, right?

Josh argued that this would be handled through a GUI… where points and landmarks could be adjusted on-the-fly by the user.

In the end, his argument was that his method would be more efficient than using algorithms because it is a specialized application — rather than something made to work in 9 out of 10 households.

I can’t help but disagree. There’s too many unknowns when dealing with robotic mapping. You can rely on counting wheel rotations, sonar, lasers, etc., but they still aren’t foolproof… and small inaccuracies will simply build up exponentially over time — affecting future mappings.

Efficiency is more than just sucking up the dirt from every last inch of the carpet. Mapping may let you get to that extra 1% missed by using generic algorithms and wall-hugging techniques, but I think those gains are still outweighed by how much time and effort has to go into the project, how much time is spent correcting inaccuracies, etc.

It just isn’t worth it. At least not for me.

But we were at least able to come to somewhat of an agreement… I agreed that it would be fun to do and, if nothing else, a good excercise in robotic mapping.

In looking back at some sites I had bookmarked about robotics, I managed to find an interesting article about robotic navigation that basically just reinforced my initial gut-reaction to what Josh wanted to do. I didn’t really get any reaction out of him — aside from a link to some MSDN article about some Microsoft framework for use with robotics. Seemed interesting for hobbyists, so I might check it out later, but it still had very little to do with what he and I were talking about.

If a whitepaper from Carnegie Mellon University’s robotics department discussing the challenges in the field of robotic navigation won’t change his mind, though, nothing will…