Check the photos in this article out. Scroll down to find the cottages that Pixar has instead of cubes. Hook me up.

I went home and, after giving Roomba a thorough cleaning, did some testing.

So it was acting up around the virtual wall units. I had some placed around the bedroom so the Roomba wouldn’t go under the bed and destroy the crap we have down there, but what ended up happening was that Roomba would spin in circles and clean the same four square feet over and over. I couldn’t for the life of me figure out what was up.

After reading some of the FAQs on the iRobot site, I started gathering that the virtual walls not only put out a beam forward (as the virtual wall) but also a beam around the wall unit itself, presumably so the Roomba doesn’t run into the unit and knock it over or change its position.

On the bottom of the virtual wall unit is a diagram that sort of illustrates this:

You can see in the diagram a small dotted halo surrounding the virtual wall unit as it projects the beam. I had interpreted this halo as a circle to highlight the virtual wall unit. Not the case - it actually outlines the wall unit’s beam pattern.

As it turns out, this diagram is correct, just not to any sort of scale. The correct diagram would look more like this:

Notice the halo extends to the far reaches of space. This is more accurate. In fact, if I cover the little broadcast point on the top of the virtual wall unit (to stop the halo), Roomba behaves as normal again.

That’s why you see the virtual wall in the diagram parked behind a physical wall and broadcasting outward - so Roomba doesn’t pick up on the protective halo of the virtual wall unit.

Why was I afflicted? I had changed the way the virtual walls in the room were laid out from previous times Roomba had run. Before I had blocked the virtual walls with a pillow so Roomba wouldn’t hit them, which, at the same time, meant I unknowingly had blocked the virtual wall’s protective halo so I never saw the behavior. This time I had not blocked the virtual walls with a pillow, and Roomba went nuts. Too much infrared in a small space.

So I’m back to status quo on that front. Virtual wall placement now becomes a more strategic task, but I should be okay.

I’ve had my Roomba for about a month now and I love it. Thing is, it’s starting to act up a bit I’m not sure if it’s just dirty or if it’s actually malfunctioning.

Roomba has these “virtual wall” units that shoot out a beam of infrared light and when Roomba detects that light, it won’t cross through it. The virtual wall transmitter seems to shoot the beam a little wide, like plus or minus 15 degrees from center. Starting last night, Roomba seems to be picking up on this IR more on the order of plus or minus 45 degrees from center, which is really hosing things as far as its ability to clean. Use a virtual wall and Roomba goes nuts.

I’m hoping it’s just in need of a cleaning. I downloaded some troubleshooting tips for cleaning the thing and I’ll try that out tonight. If it doesn’t work, I guess I’ll be contacting customer service.

I must have a RoboMower RL1000. It is a moral imperative.

As much as some folks might disagree, there is a difference between just developing software and developing software that will be used by other software developers to create new and interesting products. This includes the people who write business tier and data access tier functionality in an n-tier architecture.

I get in arguments about this kind of thing with folks. They believe I’m expecting perfection, which is something impossible to provide. That’s incorrect; I expect excellence. Understanding the difference between excellence and perfection is important, just as it is important to understand what it is to write code and what it is to write code for people who will use it to write code.

What’s the difference? While I could (and generally do) argue that there shouldn’t be any difference, here’s what I’ve found:

People who write software do error checking. People who write software for people who right software will not only provide meaningful error messages as a result of that error checking but will also add trace and debug statements so someone using it can figure out where precisely the error is happening and how to fix it.

People who write software have documentation. People who write software for people who write software provide API documentation, task-based documentation (HOWTO), examples, remarks, and helpful tips. An undocumented API is almost as useful as a nonexistant API.

People who write software only look at taxonomy and naming in relation to the application. People who write software for people who write software use clear, concise naming for identifiers and filenames that makes sense to people outside the scope of the application and makes use of the API intuitive; and they organize code in structures (namespaces, files, etc.) that make sense beyond just an individual application.

People who write software focus on what needs to be done now. People who write software for people who write software also focus on what will be done in the future. (Which is another way of saying: People who write software extend code. People who write software for people for people who write software make extensible code.)

In short:

People who write software make code that works. People who write software for people who write software make code that is usable.