After four decades in the industry I’ve been involved with more than a few robots that didn’t pan out.  Truth be told, most of the robots I’ve worked on never lived up to my grand hopes.  Here are three from my time at iRobot.

deLighter Bot

I worked at iRobot for four more years after Roomba launched.  For me, working to improve an existing product is nowhere near as fun as devising something totally new.  So, I mostly spent those years trying to come up with other revolutionary robots.  The kind of new products a company looks for is always informed by the products they’ve already fielded.  Specifically, they strongly favor new products that have potential markets at least as large as their existing products and that can leverage existing sales channels.

That may have worked against my efforts.  All I was looking for was an opportunity to invent a robot that could economically accomplish a useful task that no robot had ever done before—even if the robot had a market smaller than Roomba.

One idea I worked on for several months, I called the deLighter Bot.  deLighter was to be the physical analog of Harry Potter’s “Nox” spell—the wave of a wand that turns off the lights.   The robot was targeted at businesses.  It would save firms money because, unlike employees, it would never forget to turn off the lights at the end of the day.  No longer would passersby see lights blazing all night in an empty office building.

Today there’s probably little need for my deLighter Bot.  Many private offices and conference rooms are now equipped with occupancy sensors—built-in devices that extinguish the lights when they determine that no one’s there.  No doubt most of us have encountered such devices in a lavatory where, if the sensor gets it wrong, we’re suddenly left in the dark.

I conceived of deLighter Bot as a wonderfully simple robot, that would cost maybe $500, only about twice Roomba’s price at the time.  In ~2005, when I was investigating deLighter, occupancy sensors were less common than now and retrofitting existing facilities to install them was expensive—especially in large firms with many separate lighting controls.  So buying a $500 robot to avoid that expense might have been appealing.  A common rule of thumb is that it’s reasonable to buy a piece of capital equipment if it pays for itself within two years.  That provided me a way to compute how many businesses deLighter Bot might interest.  Any business that lost $250 or more per year because of left-on lights would benefit from the bot.  I computed that deLighter Bot would be a sensible investment for tens to hundreds of thousands of businesses in the US.

Physically, the robot would look something like a Segway two-wheeled scooter.   It might or might not have a third wheel for passive balancing.  There would be a central mast extending upward from the wheel carriage.  At the top would be a camera.  Below the camera a single revolute joint would connect the mast to a lightweight arm.  The arm, reaching out a foot or so from the robot, would flip light switches on or off.

Since deLighter Bot predated AI’s current proficiency in visual recognition, I planned to attach a unique QR or bar code to each switch plate.  The robot would rely on the code to identify light switches and to help it navigate (the robot could have a map of all the switches it was responsible for).  Or, in a simpler implementation, at a certain time of day the robot would leave its charging stand, wander about, and turn off any light switch it encountered.

I got as far as building an unpowered mockup of a pole and arm.  I could maneuver my contraption to a to bank of switches and turn off each one. 

I thought the idea was fantastic and I described or demonstrated my model to anyone who would listen and look.  But no one was interested!  My boss (the one who fired Charlie Grinnell in Harvest Automation, Part 1) let me spend time developing and pitching my concept but I believe he thought the idea was dumb and he lent it no support. 

Did the world miss a chance to douse global warming 20 years ago?  Would businesses have flocked to deLighter Bot?  I don’t know.  The technology looked very promising to me but convincing the market is the hard part. 

iPup

A recurring theme at iRobot (and many other robot companies) was the notion of the telepresence robot. Telepresence robots, controlled via the internet, would give the user access to remote locations anywhere in the world. A frequently recited story was that such robots would let users check on their vacation homes, or play with the family pet while at work, or keep track of an aging parent. iRobot doggedly pursued this type of robot in several guises over many years. These robots had names such as iRobot-LE, CoWorker, CiCi, Gromet, and Ava. (There may have been a few others.)

One of the first incarnations was the eight-wheeled iRobot-LE robot.  The robot commanded a large developmental effort in part because it was required to climb stairs.  That explains why the wheels look like big gears with rubber teeth and why the leading pair are attached to the ends of flippers that can move up and down.  

I’ve since forgotten how much the robot weighed, but it must have been 50 pounds or more.  I haven’t forgotten the alarming feeling of standing at the bottom of a staircase the robot was attempting to descend—that always looked a little dicey.  The LE’s aggressive wheels tended to damage steps, and it had a price north of $2000.  

Paul Sandin (my Roomba co-developer) and I were not completely on board with the idea of a telepresence robot (a remote camera or cameras seemed like a less costly, more reliable alternative).  But if the company wanted a remotely controlled robot, we thought we could build a much more cost-effective version in the mold of Roomba.  Instead of a single $2000 robot that could climb  the stairs to the second floor why not put a, say $200 robot on each floor?

We called our robot iPup (the name paid homage to DustPuppy, Roomba’s original moniker).  It was far from clear what features customers would most value in a telepresence robot.  So, we worked on two concepts that traded off features and cost.  The first version would be short like Roomba and (we imagined) would cost $150 retail.  Since the view from an altitude of three inches isn’t very useful, we worked out a way—without adding another motor—to let the robot look up.  The robot would be weighted in such a way that it was bi-stable.  Accelerating the robot rapidly, would make it tilt up, giving the user a better view.  Quickly decelerating would tilt it back down to its normal configuration.

The second concept, likely to be about twice as expensive as the first, looked a lot like Roomba but it could perform a magic trick.  Mounted on the robot would be an erectable mast.  Normally stored inside the body of the robot, the mast (with a camera attached to its top) could be raised to at least tabletop height.  This would give the user the same capability as the competing iRobot-LE but at a tiny fraction of the cost.

The mast was the tricky part.  To devise one, we took inspiration from the humble tape measure.  When a tape measure unspools the tape curves giving it pretty good rigidity in one direction.  But apply forces from another direction and it will collapse.  So we tried various ways of attaching two or more tape measures together.  That seemed promising, but we never got to a design we fully believed in.  

I thought that the company had minimal interest in our iPup ideas.  But, a year after Paul and I left, iRobot announced that they would release a “virtual visiting robot” called ConnectR at a future date (iRobot annual report 2007).  The price was expected to be $500.  Rather than use our low-cost, but perhaps troublesome bi-stable idea for pointing the camera, they added one motor that let the camera tilt to look in any direction.  

But ConnectR seems never to have actually joined iRobot’s product lineup.  After 2007 no further mention of it was made in the company’s annual reports.  Telepresence has proven to be a tough market.  Although more than a score of companies have offered telepresence robots (Vgo, Double Robotics, and Anybots are a few) the category never took off in the same way that robotic floor cleaners did and no company seems to dominate.

Alt.Scooba

After Roomba, the next consumer robot the company developed was called Scooba.  Roomba cleaned dry floors by vacuuming and sweeping.  The new robot would wash them.  One interesting lesson we’d learned while working on the Clean project (where we tried to build a robotic autoscrubber) was how to get a floor truly clean.  Traditional hand mopping won’t do it.  The mop may remove some of the dirt, but the larger effect is only to make the dirt coating the floor uniform so that it’s harder to see.  

To get the floor truly clean requires the process autoscrubbers use: First put down a brew of water and cleaning solution, then agitate the mixture with a brush, and finally (the crucial action) vacuum up the dirty water.  Without that last step the dirt remains behind on the floor when the water evaporates.

The need to do all that required Scooba to be a much more complex machine than Roomba.  It would need one tank to hold the cleaning solution, a second tank to hold the recovered dirty water, a water pump to spray water on the floor, and a vacuum to lift the dirty water.  Scooba’s complexity was increased still further by marketing’s insistence that users should not need to sweep (or “Roomba”) the floor before using Scooba.  

And there were two more things.  One, Scooba’s internal plumbing must be designed in such a way that no matter how the user turned or tilted the robot, no water—dirty or clean—could spill out onto the floor.   Two, Scooba’s wheels needed to provide good traction even they though they’d be rolling on a wet, slick surface. 

The development schedule slipped a bit, but iRobot’s heroic engineers managed to develop all the needed mechanisms.  (One of them was called the “blow-suck.”  It was this feature that enabled Scooba to clean an un-swept floor.)   Even more impressive was the fact that the designers managed cram everything into a volume about the same as Roomba (a small commercial autoscrubber would have given engineers 50 to 100 times more volume to work with).

Scooba worked surprisingly well.  I still use the one I got around that time.  But there turned out to be an awkward bit.  When used to clean the bathroom, customers found that Scooba was too big to fit between the toilet and the wall—that area was left uncleaned.  So, customers asked for a much smaller Scooba.

In many domains there comes a moment when scaling laws stop working.  Where if you want to make something smaller or bigger you can’t just compress or expand your existing mechanism, you instead have to switch to a fundamentally different method.  I thought that moment had arrived for Scooba.  

But my arguments did not convince the new Mini-Scooba team, so while they worked on a more conventional approach I began experimenting with some other ideas.  The one I settled on involved a hollow, inverted cone-shaped brush that had a water-impervious coating on the lateral wall.  My idea was that water would drip down the hollow center of the brush to the floor.  The spinning brush would clean the floor, and then centrifugal effects would make the water climb back up the inside wall of the cone where it could be collected at the top.  All the cleaning with almost none of the complexity!

My unproven idea seemed promising, but I got no further.   Around that time I was called to work on a lawn mowing robot.  But I left the company before the project was completed.  (Actually, the project never completed.  iRobot worked on different versions of that robot over the course of ~20 years but never marketed a mower).

The conventional approach ultimately led to a marketable mini-Scooba called the 230.  But it worked less well than its larger cousin.  In the end iRobot acquired a company (Evolution Robotics) that had developed their own version of a floor scrubbing robot.  That robot, originally called Mint, was renamed Braava.  It replaced Scooba in iRobot’s product lineup.  Braava had the advantage of much lower complexity.  It used a disposable pad to accomplish its mopping function rather than a pump, and tanks, and a vacuum.   But, like big Scooba, it couldn’t fit behind the toilet either.

We’d thought of the disposable-pad approach too, before building Scooba.  But we concluded that it wouldn’t let the robot clean a large enough area.  Our choice may have been hasty.

* * *

The lesson I take from these and many other non-successes is that robots are hard in every way—conceptually, technically, and especially in their product/market fit.  For decades robots have proven far more likely to fail than succeed.  No change appears imminent.  So, if you’re interested in developing robots, it might be wise to practice your stoic skills.