Revisiting the original Roomba and its simple architecture

A couple of weeks ago, iRobot announced bankruptcy. The pathbreaking Boston-area company that makes the Roomba will now be owned by a Chinese consumer-goods manufacturer. People argue about who is to blame for the failure of iRobot: Was it poor management decisions? Government overreach in preventing mergers? An inability to innovate? The inevitable race to the bottom of any commodity consumer good? Regardless of the reasons, I am sad about one thing: that robot developers are missing what made the original Roomba successful. I will try to explain what made the design of the original Roomba truly innovative, and what lessons we should take from it. The Original Roomba Introduced in 2002, the Roomba was the first successful consumer robot for the home. Cheap, off-the-shelf components helped price this original Roomba at two hundred dollars so that people who needed a home vacuum could consider buying it. It worked well enough that iRobot eventually sold over forty million of them. Completely autonomous, the Roomba only needed to be switched on. It would run all over the floor, noisily brushing and vacuuming. When it was done, you emptied its dirt chamber and plugged it in to recharge. It had its limitations--- for example, it couldn't move furniture, confine itself to one area, or deal with carpet strings or wet messes. Its vacuum was anemic. But within these limitations, it could maintain the floor at an everyday level of cleanliness. This original Roomba was much simpler and more elegant than today's mobile vacuum cleaning robots, including iRobot's present models and many other competing products. In fact, its internal design was fundamentally different from most other robots. Greater than the sum Normally, industrial robots are made robust and safe by using high-quality, expensive parts that can execute programmed motions precisely, reliably, and repeatedly. The robots are then deployed into a carefully-designed, predictable environment, with safety systems built around them. As long as they don't encounter surprises, their programs continue to work smoothly. If something goes wrong, the safety systems stop them for engineers to debug them. But as a consumer robot built for unstructured home environments, the Roomba took a radically different approach. Its software was written in such a way that the robot could run as reliably as possible given unreliable parts and an unpredictable environment. The Roomba didn't have enough memory to remember a map of the room. Instead of building a map, it used clever tricks to cover the available floor region, albeit inefficiently. If it encountered an obstacle, the robot could try backing up, turning, and moving to a different location. If a rotating brush failed, the Roomba might not be able to clean the floor as well as before, but it could at least keep running and do as well as it could using the remaining brush and the vacuum. The product was better than the sum of its parts. From lab to stores The secret to the Roomba's success was in its software. It was built using an unconventional approach originally invented by Professor Rodney Brooks in the 1980s at the MIT AI Lab. One of the researchers who spent time with Rod Brooks's mobile robot group, Joe Jones, was not actually part of the group, but someone deeply interested in this approach to building robots. Brooks had built a software library, a "behavior language," that enabled his students to program robots using this approach. Jones was one of the few people who actually used the behavior language. Rodney Brooks co-founded iRobot, and Joe Jones joined the company as an engineer. They made money by building custom robots, eventually landing military contracts for remote-controlled PackBots. Ten years later, when the company had enough money, Joe pushed the company to develop a home vacuum cleaner, and this became the Roomba. Behavior-based robotics At MIT, Rodney Brooks's work in the mobile robot group was motivated by a well-known paradox: computer programs can do many so-called higher-level thinking tasks like numerical calculations, physics simulations, theorem proving, and playing chess, but they fail at many real-world tasks that seem simpler, like crawling out of a pit, that even so-called low-level animals like insects can perform with ease. Clearly, living things over the millenia have evolved basic survival skills that are important in the real world. Something was missing in the computer science approach to building robots. Brooks was proposing an alternative approach that would at least demonstrate insect-like abilities in the real world. Robots sense their world using cameras, sonar, and other sensors, and they act on the world via motors or other actuators. The conventional approach to building an autonomous robot was to use sensors to gather information about the world, build a model of the world using this information, think about possible actions and their effects on this model to form a plan, and then finally execute the plan on the real world by commanding the actuators to do things. But this method failed to deal with a changing, unpredictable world that is sensed using unreliable sensors. Instead, Brooks advocated building very simple programs that continuously gather sensor data and directly drive the actuators. Each program would achieve a single, simple goal. For example, imagine a robot with two "eyes" consisting of simple photoreceptor cells that can measure how much light falls on them. Such a robot could be made to move toward a light source by always turning it to the left if the left eye sees a brighter light, and vice versa. In software, this could be done by driving each wheel in proportion to the difference between the brightness perceived by the two eyes. This light-seeking program would be an example of a basic ability. Then, using Brooks's proposed software architecture, the programmer could compose several such different basic abilities, called "behaviors," to achieve higher-level goals. Individual behaviors can be developed independently and added to the robot. Some behaviors are analogous to the fundamental survival skills developed by organisms early in evolution. These skills remain available while more skills are developed. The trick is in picking the right skills to use depending on the circumstances. For example, if a Roomba discovers that it is standing at the edge of a staircase, then it should stop cleaning and back up, trying a different direction. Survival is a higher priority than cleaning. Lessons The Roomba showed that behavior-based robotics can be a practical approach to developing autonomous robots that are actually useful and fit for purpose. The approach is not without its challenges. It can be very difficult to figure out how exactly the different behaviors can be reconciled in a robot. The complex interplay between them can make the robot very hard to debug. Building robots is hard. Behavior-based robotics doesn't solve all the problems building robots, but it does show how certain very significant limitations can be addressed. It's not clear whether robotic vacuums have kept the simplicity of this approach. They don't seem to have. Today's Roombas and competitors sport a great many features: cameras, network connections, phone apps, maps built using visual simultaneous localization and mapping (vSLAM), and so on. For the purposes of cleaning a floor, not all these features count as innovations. Some might be necessary (longer-lived batteries and a more powerful vacuum), but others might be unnecessary dead weight. In the heat of retail competition and the pursuit of growth, it can be hard to keep your eye on the ball. When trading off advantages and costs, you have to remain true to your architecture. The simplicity of the original Roomba was a virtue.