Ever since the feature was introduced, we've had a small number of users report that Backup on Connect suddenly, with no "inciting event", stops working for them. I was never able to reproduce the problem, but had a way to get functionality back: basically, reinstalling. Which sucks, and I hated having to suggest it. But we do what we have to do.

For years I've been at a loss to figure out why, but thanks to Frank Fackelmayer, who was willing to let me provide him with a bunch of debugging versions, I've managed to get a handle on the bug, and have fixed it.

I can't tell you how awesome it is to fix a longstanding, rare, confusing, crazy-seeming bug. But this isn't going to be one of those amazing stories of heroism in the face of threading deadlock. No, it's going to show how stupid I can be. Or, at the very least, how stupid I feel now that I know what the problem is.

Now that we're all in agreement that I'm about to be proven an idiot (foreshadowing?), let's begin!

How it's done

Backup on Connect is implemented as an AppleScript that is called by launchd. We register our agent for two events: volume mount and -- since there's no "volume unmount" event -- a WatchPaths on the Volumes folder.

When we get one of these, the script determines what drives have mounted or unmounted, and for each "new" volume, it checks the Scheduled Copies folder for files that match the drive name. In that list, it checks each one to see if the target volume in the settings data is the same as the mounted volume name. If so, the script is launched.

All well and good - relatively simple stuff, and the kind of thing that AppleScript is pretty darn good at (it's so easy to ask it for, say, a collection of files containing the word "idiot", "stupid" or "dummy").

How it's done wrong

But here things went wrong. When the script retrieves the list of matching schedule bundles (bzzt) from Finder, I simply asked for any files that contained the volume name. I knew it might overmatch (returning files with source volumes with the same name, for example), but I handled that case, since the overmatch would get double-checked when verifying the target volume name.

All good! I am a super genius! Ship it!

Perhaps you see where this is going.

This particular "super genius" didn't consider that there might be a file in that folder that matched but wasn't a scheduling settings package. Or a match that wouldn't have a settings file in it to check. And that "super genius" didn't handle the potential error from the settings file parse. Because: "super genius"--which you may now read as "idiot".

Worse still, every SuperDuper installation had one file (in pre-2.7.2) and now two files (in 2.7.2) that match if the drive is named "Backup": "Backup by time.scpt" and "Backup on mount.scpt".

I will leave determining what the most common name for a Backup volume is as an exercise for the reader. It's a real puzzler, so don't hurt yourself.

Random is not your friend

So, why didn't this happen to everyone? And why couldn't I ever reproduce it?

Basically, the order the files were returned from Finder determined whether the script would work or not. In my tests, they always came in last, so no problem. But if they came in somewhere before the appropriate .sdsp...boom. So, basically, it was a bit random.

The solution is almost always easy when the problem is known, once the head-slamming-on-desk impact injury has healed enough for clear thought to return.

Homework

I've made a pre-release version of the fix (which I've tested) available here.

To install, download to your Mac. Once you have the file, open the SuperDuper! application bundle (Control+click, Show Package Contents), navigate to Contents/Resources in there, and replace the "Backup on Mount.scpt" with the one you downloaded. Also, replace the same file in Library/Application Support/SuperDuper!/Scheduled Copies.

So, if you're interested, give it a try and let me know if you have trouble. If you don't want to do this yourself, the fix will, of course, be included in the next update.

I think the last time I wrote about the Squeezebox was in 2005 (yikes!), but it's time to virtually attaboy again: the Slim Devices folks have recently released the Squeezebox Boom, and it's pretty darn great. (I might be a little biased because I wrote their Mac-native support years ago, but really, no sense bragging on something I don't like.)

There's a surprising amount of competition out there in the "networked audio player" market, but Slim Devices (now part of Logitech) has been around a while, and their open source solution is one of the very best. The Boom mates a Squeezebox with a rather nice set of stereo speakers to create a pretty ideal stand-alone player/clock radio: something I've been looking for over the past few years.

This'll work with virtual all unprotected audio files you might have (including AAC, ALC, FLAC, OGG, MP3, MPA, WAV, AIFF), and includes support for Rhapsody, Pandora, Sirius... the list kind of goes on and on.

Minor downsides: awkward external power wall wart (boo!), no battery support for those times you might want to take it out on the porch, some minor control placement issues (all personal taste), and—like all Squeezeboxen—it requires that you have the SqueezeCenter server running on something (which can even be an Infrant NAS -- it ships with the SqueezeCenter built right in)... but those are decidedly minor.

Highly recommended, and a big congratulations to Dean Blackketter and the rest of the Slim Devices team.

I know it feels like that from the outside. But from the inside, we've been putting out quite a few external beta releases (11 at last count), incorporating feedback from our testers, and carefully observing what users with 2.1.4—who have tried to use it with Leopard—have tried to do.

Before I start, though, please recognize that I'm describing things we noticed back in October. So, this is not causing additional delay—these are some of the things that contributed to the delay in the first place.

Paying Attention to Users

We've always observed our users very carefully. And, after Leopard's release, we noticed one big thing: users with 2.1.4 and Leopard have been trying to store their SuperDuper! backup to the same volume they've been using for Time Machine. But there's a significant problem with that: namely, since the Time Machine backup isn't on the source volume, Smart Update is going to try to delete it.

Now, Time Machine "protects" its own backups through a number of complex mechanisms, so no damage is done—except the backup fails.

Choices

In some ways, this is quite similar to the "storing other files alongside a backup" case that has come up before (and has an entire section of the User's Guide dedicated to it)—basically, we could request that users partition the destination drive, put their Time Machine backups on one volume, and their SuperDuper! backup on another.

But, even with Leopard's new "live partitioning" capability, that's a pain, isn't obvious, requires a support round trip, doesn't meet user expectations, and isn't transparent.

It also wasn't something we took into consideration during our original compatibility design. We focused on the various new capabilities of the OS, ensuring that we worked well, but since we were used to partitions—and knew that Time Machine liked as much disk space as possible—we gave it a lot of space to work with and left it alone.

So, once we started seeing this—which was after Leopard's release, of course—we had to make a choice. Push responsibility to the user to do the right thing, or anticipate and handle it inside SuperDuper! so users wouldn't be immediately frustrated.

But I Don't Want to Use Time Machine!

We certainly understood—and understand—that some users don't want to use Time Machine. But the problem is, a large proportion of Leopard's users do, and we have to serve the needs of both groups. We can't come out with a "Leopard-compatible" release that doesn't work properly with Time Machine.

And we couldn't really release a "quick update" that just copied the basics first, and then an update that handled this case right. Had we done that, we would have still needed to take a full external cycle to test the copy engine changes we needed to make, and then run the same extensive cycle again when we made the low-level changes to handle this case.

So, we bit the bullet and made the necessary changes to handle the case properly, the way users would expect: it just works.

So, if you Smart Update a volume that you're using for Time Machine, it works just fine. Your Time Machine backups, and your bootable SuperDuper! backup, and stored on the same volume, side-by-side, without interfering with each other, with no need to partition or do anything special (other than use Smart Update, of course).

On top of that, you can still copy that volume—that is, a volume that has both Time Machine backups and a bootable SuperDuper! backup—to a 3rd volume to make a second backup, and everything there works great, too.

This is technically more complicated that you might expect, but all of that is under the covers. On the surface, there are no visible changes.

Side Benefits

So, this is the main reason why we were able to improve the handling of Spotlight and preserve icons as I discussed in the last post: we had to handle the Time Machine case, but it benefits all users by improving the way Spotlight (which everyone basically uses) and icon preservation (which a small, but vocal group use) works.

Why Focus on Time Machine?

Which, of course, is an extension of But I Don't Want to Use Time Machine!, above.

The fact is, Apple considers Time Machine to be the most important, most visible new feature in Leopard. They've put a lot of marketing muscle behind its rollout, and its tendrils are in everything, from the default desktop to Quick Look.

As I've discussed before, it's a big, good change, and it benefits all users, even those who use SuperDuper! We're truly two complementary technologies, and we need to ensure that SuperDuper! works perfectly with it to ensure that SuperDuper! itself remains a viable product.

And if the product remains viable, we'll be able to continue improving it for everyone—something we all want!

It's Not All Time Machine, Though—Really!

Another interesting thing we found as we got reports from new users, that we never encountered internally: a very old bug in the Migration Assistant (described in Slowly going insane while waiting for a fix back in 2005) is back, with a vengeance. But there's a new variation: rather than having a missing carriage return, there are now also blank lines in the file, which result in the same failure.

So, we've had to implement a second workaround to fix this problem, too.

How Much Longer?

Anyway, enough of that. At this point, we're basically locked down. We have a few UI tweaks to complete, and we should have a final release out to everyone within a few weeks.

You'll notice this is the first timeframe I've provided other than "soon"... and that means I'm quite confident it'll be in your hands shortly. So, once again thanks for your patience, and I really think you're going to be pleased with the update.

Another week, another Leopard Status Update. Please, hold your cheers and applause until the end.

Two parts

Although most people think about SuperDuper! as a single application, it's actually comprised of a number of parts. The two main ones are the UI application (which you interact with) and the Copy Engine, which actually performs the copy.

When changes are made to the UI component, testing takes significantly less time, because it's much easier to ensure that those changes are working properly, and improper operation is relatively low risk: if a button doesn't dim properly in some conditions, it's an easy bug to work around for an end user.

Changes to the copy engine, though, are extremely high risk. Errors made in copying files affect the backup itself, and often occur silently: everything looks like it's working, but, not so much.

Testing the tests

This is one of the reasons that this update is taking so long to release. Due to the nature of the changes in Leopard, we've had to make significant changes to the engine. And while we, of course, have extensive test suites internally, those tests are "necessary" but not "sufficient".

Final bits

As I've mentioned before, we did, of course, have betas of Leopard, and we were working with them. But a beta is just a beta: changes are made up until the shipping version, and that was the case with Leopard as well.

But, there's another consideration, too: we can't do our "big" external test cycles until the "public" has the real bits. Yes, we can roll to testers who have the same beta we have, but when you're making the kinds of changes we had to make this release, it's important to roll in new testers who have different file setups and different patterns of copying.

(Tester fatigue is an issue that all developers are constantly struggling with: it's not so much that a tester is "tired", but that they fall into a pattern of use, and rarely venture outside it.)

So, our internal tests couldn't be run until we received the final bits (we never release test versions to our testers that are risky, to ensure they can really use the test release as a production copy), and our big external test couldn't start until after that.

That testing -- of which there have been multiple rounds -- has been going very nicely indeed.

More progress

So, last week, we locked down the "cloner changes": given feedback from the testers and our external tests, and running against 10.5 and 10.5.1, we're pretty confident that the engine's working properly.

That's a good thing.

We've added some new capabilities to the engine, too. We can now preserve the contents of the Spotlight index on the destination (which also preserves its indexing status in a more reliable way) and preserve the "File System Event" database that Leopard uses. More on this in a later post.

While we were doing that, we decided to do one more thing.

Save the icons

We had always felt that the volume icon -- being a file on the source drive like any other -- should be copied to the backup drive, since you'd want to restore the original drive to the same condition it was originally in, and that included the icon.

Well, we had a lot of pushback on that choice (to put it mildly - I think the thread that discusses this issue and the workaround we came up with originally is the longest one on the discussion forums), and we decided that we were wrong. Since you rarely restore, and your backup drive is constantly visible, it was best to preserve the destination icon. Plus, if you restore with SuperDuper!, we'll preserve the icon of the destination for the restore, so it's all good.

The changes we made, above, made this possible. And so, the destination volume icon will now be preserved.

More coming

So, a lot more progress has been made. Testing's going really well. And I'll talk a bit more about some other new stuff later.

All those within the sound of my voice, let it be known: I hate the Nokia E61i.

Well, hate might be too strong a word. After all, Nokia has done some things right.

To start: I decided to give it a try after it got some raves from the Nokia crowd. Since I hadn't used a Nokia in years, it seemed like a good one to try: the E61i's got a nice keyboard and a really nice screen -- although it's only QVGA it's very visible inside and out. The build quality seems pretty nice. It's a good size as these things go, a bit heavy but nicely finished.

The software bundle is good for a business device: various email connectivity tools, push email for Exchange, Blackberry, IMAP. The "today" screen does a good job of showing what's pertinent right now.

But, that's about it.

Even though the E61i was released very recently, it's not a "Feature Pack 1" device (and, from what I've been told, will never be updated to Feature Pack 1). So, perhaps my experience was suboptimal. But it's no less optimal than that of other E61/E61i users.

And, overall, it's pretty suboptimal. This is a "messaging" focused phone. Its whole reason for being is to send and receive email and react to that. That's exactly what I wanted it for. And in that, at least in my situation, it fails pretty miserably.

My server is a Kerio Mailserver (which I'm quite happy with, and will write about in a future post), which provides both IMAP IDLE support and ActiveSync/Exchange capabilities. The E61i ships with an Exchange plug-in, so I used that. It configured reasonably easily (although the layout of the various screens doesn't take advantage of the landscape display, which truncated many fields in a pretty stupid way), and began to sync. And that all worked pretty much OK.

The problems started dealing with the mail itself. First, you can't move items to folders. You can only copy them, so handling Junk mail "properly" is well-nigh impossible.

Second, there's no way to mark a message as "unread". So, if you have mail you haven't yet dealt with, but read, you'd best remember what mail it was.

Third, deleted messages stay visible in the mail list until the sync occurs.

Fourth, links in the mail highlight nicely, but open in the "Service" browser, which isn't the "good" one: it's the old, WAP-style, crummy browser. "Web", the WebCore-based browser can't be associated with links. Instead, you need to copy the link, open Web, and paste them in to a "Go To Address" dialog. Not good, but I guess it could be worse.

Fifth, while this browser mostly works, it eats memory like crazy (even though the memory status in the main menu always indicates there's lots of memory left -- go figure). This causes it to randomly start failing, crashing, exiting... pretty much at any time. So, if you're using a web-based application (as I need to, based on mail notification), you're going to lose data. Typically after typing a long reply.

And stopping the numbering, because of the low memory, the mail program probably closed, which means you need to re-open it, which means you lose context.

Whatever you do, don't click a link in mail, because it'll instance that other browser, and it's hard to get out of.

But that's not all. I haven't even started talking about the slow and blinky screen refreshes, the fact that contact notes don't sync, that calendar notes sync incorrectly (CRs get eaten), that contact details are very inefficiently presented on the screen requiring a ton of scrolling, that network connections are constantly being announced for no reason, that selecting the messaging plugin on the today screen sometimes goes to the list and sometimes to a message (depending on the number of messages there, but it feels less predictable), the awful indeterminate progress indicator, ugly fonts, poor calendar implementation... I could go on and on.

To try to take care of some of this, I installed the trial copy of RoadSync, an alternate ActiveSync application that's worked well on the M600i (a UIQ3 device, rather than S60 Series 3). But it doesn't directly support browser links either. But it does seem to sync slightly better, supports moving to folders and allows mark-as-unread.

But with a browser that crashes constantly and a battery that -- under typical "me" use -- dropped precipitously after just an hour or two... it's just not a phone I could possibly live with.

It makes me appreciate the UIQ3 and Windows Mobile devices I've tried, though! Compared to this, the M600i and Dash are absolute paragons of reliable usability!

Maybe hate isn't too strong a word. But whatever word is used, there's one thing for sure: for my usage, the E61i sucks.

My friend Jonas Salling has started blogging again, and that's always a good thing.

He's got some recent posts up there as he tests the WiFi support for Clicker, and the results may surprise you!

Jonas is one of the hardest working developers out there, and he never settles for less than absolute excellence when releasing new stuff.

The long-in-development Clicker 3.5 is no exception, and it looks like it's getting really close to release. That's good news for all the fans of Clicker, since a great product is getting a lot better. And I'm sure he has many cool things in store moving forward as well.

Welcome back, Jonas -- looking forward to more posts!

I freely admit, right at the start of this post, that I switch cell phones too often. A lot of this is because I try to do a lot with my mobile phone, mostly mail and web based. And I want the thing to work well with my Mac, and to be a phone: I don't really want a two-inch-thick "communication controller" on a belthook.

At the same time, I don't want a tiny screen or a crappy browser, and I need a decent way to input text.

I've had generally good luck with the recent generation Windows Mobile "smartphone" devices (like the T-Mobile Dash, aka the HTC Excalibur), but the version of Internet Explorer in them is pretty limited, and replying to support questions can be frustrating because of those limitations.

Some time ago, I'd purchased a Sony Ericsson M600i, which looked like it was going to be a good'un: good size, design, keyboard and capabilities. Unfortunately, at least 3/4 of a year ago, it seriously sucked. The design is good, but the version of UIQ3 it originally shipped with was buggy beyond words: the email program crashed constantly, disconnected from email, etc. The browser was capable, but it crashed all the time, too. And, to top it off, the thing wouldn't sync with the Mac.

It didn't last long... until I took it back out of the box last week.

After applying Sony Ericsson's recent software update (R9F011 for the curious), UIQ3 has taken a huge step into reliabilityland. All of a sudden, the applications are no longer crashing. Mail, while limited by some boneheaded design choices, works. The web browser has been updated, and it's fast and capable: it even renders some relatively complex stuff on the Shirt Pocket site.

On top of that, Kerio Mailserver has finally implemented support for the M600i's OTA ActiveSync (Exchange) support, so events, mail, contacts, etc are pushed to the device automatically. Combined with a new iSync plugin, the thing works with my Mac pretty well: transparent two-way sync is awfully compelling.

Not phone nirvana, but a nice set of updates combining to deliver a greatly improved experience. It'll be interesting to see how the iPhone measures up. If the "Push" support is only for Yahoo mail (I'm hoping that it properly supports IMAP IDLE), it doesn't do OTA sync, and it doesn't support a vibrant 3rd party community (that gives us Apple Design Award-winning products like Salling Clicker), its cool touchscreen and attractive UI won't really make up for its lack of capability.

Demo vs. reality -- always fun. We'll have to see in June.

It wasn't that long ago that HP had the absolute worst OSX drivers of any major peripheral developer. Their scanners barely worked, their printers sort of worked, the software they loaded was pretty shamefully buggy, flaky... they just sucked.

So, imagine my surprise when -- after a recent Mac purchase at the Apple Store -- I decided to get a "free" HP C6180 all-in-one printer and... hey! It's been de-suckified!

The thing is well designed, has good drivers, built-in networking, even scans and faxes over the network -- pushing or pulling to multiple "associated" Macs. It's not perfect but what the hell? It's like someone is writing these drivers who actually uses a Mac!

When did that happen? Doesn't HP know they're supposed to have crappy Mac products?

And after that good experience, and reading a number of great reviews, I grabbed an HP B9180 Photosmart Pro Printer, too. Again, a great printer, with good drivers, built-in networking, relatively frugal with inks, good paper handling: and it generates great prints.

This is HP -- "we generate huge dots with expensive ink and our photos look like crap" HP. And -- not.

Wow. I don't know what's going on at HP, but they should definitely keep it up.

One of the problems with Bluetooth mice and the Mac is that virtually none of them supply drivers. So, your mouse might have a gazillion handy-dandy buttons, but you’ll only get the wheel + right/left click.

For USB mice, USB Overdrive was the way to go for a long time, to the point where it was pretty clear that Microsoft’s own mouse and keyboard drivers were being done by the USB Overdrive guy. But, unfortunately, he’s been unable to get the Bluetooth support out the door.

Apple’s recent Bluetooth version of Mighty Mouse is out the door, but it, too, has minimal capability—you just can’t do much with the extra buttons, at least, not much beyond what has been pre-programmed. (And don’t get me started on that idiotic side-button-and-way-to-move-the-mouse-while-clicking implementation… ugh. Sometimes, Apple gets it wrong.)

For all this, there is a solution: Steer Mouse.

Steer Mouse is a replacement driver, like USB Overdrive, that enables all the various buttons for all your 3rd party mice, Bluetooth or USB, and even allows your Mighty Mouse to work more flexibly. (Alas, like USB Overdrive, it’s a preference pane that’s not really a preference pane.)

Works a treat with every mouse I’ve thrown at it. Just make sure to turn off the default “Move cursor to OK” action—the system should never, ever move the mouse on the user like that.

When I was a kid, I used a bunch of string, clothespins and pulleys to rig up a gizmo that was supposed to automatically make my bed for me. The idea—which I think I got out of a book (Thanks, Jake!)—was to attach the string to the top of the sheet and blanket, then use pulleys to run it to the edge of the headboard. You then route the string to the bottom of the bed, et voilá: pull the strings in the morning, and your bed’s made!

Except it didn’t really work out that way. Not only did I get tied up in the strings (quite lucky I didn’t strangle myself), but honking the strings didn’t really make my bed. It just sort of pulled the sheet up. Definitely not the hardest part of a properly made bed.

It was an interesting try, though, and a learning experience: automation isn’t easy. It’s relatively easy to get some crude part of the activity done, but the devil’s in the details.

I think a lot of my interest in this stuff was sparked by William Pene du Bois’ book The Twenty-One Balloons (or Roald Dahl’s Charlie and the Chocolate Factory/Charlie and the Great Glass Elevator—or maybe even that great story There Will Come Soft Rains by Ray Bradbury), but whatever it was I’m fascinated by the concept of “automatic houses”, and always wondered if I’d live to see the day when household chores would be done with the push of a button, a glass of scotch, and a comfy chair.

I was pretty excited when Roomba came out a few years ago: they were clearly onto something, were paying attention to price points, and had extensive experience making more expensive robots for commercial and military use. Many improvements were made to their later generations, too, and they’ve now introduced a mop replacement, Scooba.

In parallel—or even before—Sweden’s Electrolux was working on their own robotic vacuum, which they presented to the world back in 1997. They released their first version—the Trilobite—in 2002 or so, followed by a significantly updated US version (also the Trilobite) in 2004, and Trilobite 2.0 in Europe at around the same time. Unlike iRobot, Electrolux wasn’t trying to hit a low price point; for them, the Trilobite is a technology showcase—and an example at what can be done with a mass-produced consumer product at the high end. (Dyson was working on something similar called the DC06, but abandoned the product, at least publicly, for performance reasons; other models, such as the Karcher are out as well, but I have no direct experience with them.)

It’s important to note that none of the robotic vacuums are going to Rosie-up your house. You will still have to use a regular vacuum every so often to do a deeper cleaning; if you dump a box of Quisp on the floor, they’re not going to dash out of their hole, clean it up, and run back. Instead, they’re intended to be used on a regular basis, doing general cleaning in between the times when you use a larger vacuum.

With those expectations in mind, here’s a comparison of the two. (I think this one of the longest posts I’ve written for this blog: sorry if it’s kinda boring, but I’m interested in this stuff.)

Roomba Scheduler - General Description
The Roomba Scheduler is iRobot’s current top-of-the-line model, with a street price of about $300 new. It’s quite similar to their “Discovery” model (priced $50 less), but—as the name implies—it can be scheduled to run automatically as desired.

Both the Scheduler and Discovery come with a docking station that charges the unit, and both will return to the charger at the end of their cleaning cycle.

It’s probably inaccurate to call the iRobot models “vacuums”. While they do have a small vacuum motor in them, their cleaning process is clearly patterned on a “floor and carpet sweeper” such as the Hoky or—given the spinning edge bush—the Leifheit Rotaro S. (There’s a thin, rotating “edge brush” at the front right that sweeps edge dirt toward the main brushes, much like the Leifheit.)

The Scheduler comes with an easily replaced NiMH battery pack, charger, two “virtual walls”, and various spares.

Overall, you can definitely tell Roomba units have been extensively cost reduced. The plastics, rubber, buttons etc are of reasonable but definitely not “high” quality. In the time I’ve had a Roomba, I’ve had to replace it twice due to failure. One failure was within three days of receipt, the other within a few months. Clearly, Roombas are not built to last, but they do come with a one year warranty. It takes a few weeks to get a replacement robot, should you need one. And, if you use a Roomba, you’ll probably need one.

Electrolux Trilobite (US Version - EL520A) - General Description
The US Trilobite EL520A is the only Trilobite available in this country, and streets as low as $1300. It cannot be scheduled automatically, but once turned on, it calculates the size of a room, and varies its cleaning time depending on what it finds.

Like the Roomba Scheduler, the Trilobite comes with a docking station that is placed along a wall, and the vacuum will return to the charger as needed. Unlike the Roomba, if the Trilobite runs out of juice in the middle of a cleaning cycle it will return to the charger and resume cleaning once full.

As you’d expect from Electrolux, the Trilobite has a real, rather strong (90W) vacuum, and relies on that—along with a beater bar with rubberized fins—for its cleaning.

The Trilobite comes with two internal NiMH battery packs (it switches between them automatically during operation), spare filters, and magnetic strips that can be used to prevent the robot from crossing room boundaries.

As mentioned above, Electrolux has released a new Trilobite in Europe—Trilobite 2.0 [ZA2]. The US model seems to have many, but not all, of the changes incorporated in 2.0—it’s more like Trilobite 1.8. Most notably, it has the redesigned fan, improved sensors, beater bar and the like. However, it lacks automatic scheduling and does not adjust its cleaning time based on the number of obstacles it encounters during the cleaning process. There may be other significant differences as well - there are reportedly over 200 changes from 1.0 to 2.0. I’ve tried to get more information from Electrolux without much success.

The Electrolux unit itself is beautifully manufactured. The plastics are of high quality, the industrial design—which resembles a horseshoe crab crossed with a trilobite—is witty and elegant. I’ve experienced no failures with my unit so far.

Roomba Scheduler - Operation
The Scheduler’s UI simple and easy to use: a power button and three operation mode buttons. The modes are:

• Spot - Spot cleaning moves around in a rough circle, and is designed to clean a dirt spot quickly
• Clean - Clean spends about an hour traversing the room, then returns to the dock
• Max - Max cleaning works like clean, but runs until the battery runs out

Any errors are communicated with flashing lights and “beep codes” that indicate the problem area. The unit also communicates effectively with “happy”, “sad” and “what have I gotten myself into” sounds that are witty and helpful.

Roomba primarily uses a front “bump” sensor to detect obstacles. On its right side, it has an infrared sensor that detects walls, and under the bump sensor’s lip it has a series of infrared sensors that detect stairs and other drops. Two wide, nubby, independently powered wheels with black rubber covers move the Discovery from place to place. A small vacuum is integrated into the rear dustbin

The Roomba seems to have a few basic behaviors: wall following, crossing the room diagonally, spiraling and various obstacle avoidance maneuvers. The robot usually starts with a spiral. When it encounters an obstacle (with its bump or stair sensors), it either “bounces” off diagonally, tries to go “around” it (if a chair leg or the like), or tracks it (a wall or corner).

In Clean and Max modes, the Roomba’s “dirt detector” notices when there’s over a certain amount of particulate matter passing some built-in sensors. When this occurs, the vacuum spends extra time circling that area.

These behaviors are mixed randomly. Due to the random element and careful basic behavior choices, most surfaces are covered during the cleaning period.

When it comes time to dock, the Roomba doesn’t seem to actively “seek” its dock. Instead, it continues its regular behavior until it intersects the IR beam emanating from the dock. When it finds that signal, it follows it until it reaches the charging base.

Electrolux Trilobite - Operation
The Trilobite has a small, graphical LCD screen that displays its UI. It also has four buttons: Power, Stop, a navigation button and a “Yes” button. It has three main cleaning modes:

• Normal - Normal mode measures the room size and calculates the amount of time necessary to clean it
• Quick - Quick skips the measurement phase and moves directly into a fixed-time cleaning mode
• Spot - Spot cleans a 10x10 area centered around the initial location

Other menu entries allow the fixed cleaning time and display language to be set. Any errors are displayed in the selected language on the LCD. Overall status is also communicated with various tunes much like the Roomba.

A large dustbin with a substantial filter is easily accessed under the top cover, which is released by a button at the rear of the unit. There’s a bump sensor at the front, but the Trilobite primarily uses its eight ultrasonic sensors, four pointing at about a 45 degree angle up, and four pointing out, to sense its environment. There are three additional infrared sensors on the bottom bumper, and additional sensors under its front lip. Two independently powered, narrow but large diameter wheels with clear urethane covers move it from place to place.

Like the Roomba, the Trilobite has a number of basic behaviors it combines during the cleaning process. In normal mode, it first uses a counter-clockwise wall-following to determine the size of the room. Once it re-encounters its dock, it moves into a cleaning mode.

In cleaning mode, the Trilobite makes diagonal runs, avoiding obstacles and changing speed and behavior depending on what it detects in the room. For example, if it encounters something it considers to be living (like a dog), it quickly “leaps back” to avoid it. If it approaches a “hard” object, it slows as it approaches, stops a fraction of an inch from its surface, and goes around. Steps are detected and avoided as expected.

Interestingly, the upward-facing ultrasonic sensors are used to detect when the Trilobite is under an object, like a bed. The sensors detect the boundaries of the object, and the vacuum uses that to ensure sufficient time is spent cleaning under it.

As with the Roomba, the Trilobite doesn’t really know where it has and hasn’t been, and it relies on a certain amount of randomness and time to ensure it’s covered the surface to be cleaned.

Docking behavior uses the wall-following technique, and moves in a counter-clockwise direction around the room until it encounters the dock. If the battery is depleted during a cleaning cycle, the Trilobite will locate its dock, charge, undock and complete the cycle.

Cleaning and clean-up
Overall, the Roomba and Trilobite do a pretty similar job cleaning a room. Neither “deep cleans” like a powerful vacuum with a beater bar (although the Trilobite gives it a try), but both manage to tidy things up nicely, rarely leaving a “missed” area.

Edging Performance
The Roomba definitely does a better job cleaning edges than the Trilobite. Part of this is due to the Roomba’s “edge brush”, which sweeps fluff and the like into the main brush’s path. But it’s also due to the fact that the Roomba bashes into edges, and doesn’t attempt to avoid contact with them. Although this does allow it to get closer to the wall, it has its downsides: my Roomba’s bumper is often smudged with paint it’s scraped off a baseboard or wall bottom, and this tendency isn’t helped by the sharp mold line on the bumper that’s right at the primary contact point. Should a wall be followed on the Roomba’s left, rather than its right (where the IR sensor is), near constant contact is made along the entire length of the wall.

The Trilobite does a reasonable job with edges (it makes a full, “edging” pass of the entire room during the measurement phase), but does not get as close—there’s probably 1/2” at the very edge that’s not directly cleaned.

Room Preparation
With the Roomba, it’s absolutely critical that all cords and delicate objects be moved before the cleaning takes place. All Roomba units are hungry for string, electrical cords, speaker wire and carpet fringe. Unfortunately, these items just don’t agree with its sensitive digestion and quickly get sucked in and tangled around the edge brush, main brush or rubber roller. When this happens, it plays a sad, sad song to apologize for the appliance it pulled onto the floor. It didn’t mean to be bad—it was just made that way!

The Trilobite, on the other hand, deals with most items—cords, fringe, even small objects—with aplomb. You wouldn’t want to leave a pile of papers or a magazine on the ground—both units will “read” them into bits—but a generally tidy room is easily handled by the Trilobite without any special care.

Both units have a way of preventing the robot from leaving a given area. The Roomba comes with two “virtual walls” that broadcast an infrared beam that the device detects and won’t cross. The Trilobite comes with a magnetic strip that can be temporarily or permanently installed that accomplishes the same thing.

I’ve found it’s far more important to “block” the Roomba into a space than it is to do so with the Trilobite. If the Roomba leaves a single room area, it’s unlikely to make it back to its dock, and will not clean the space effectively. Not so with the Trilobite: in our open plan house, the Trilobite can be switched on and will clean our lower level in one go, including entering the kitchen area, living space, reading area and the like. It needs to charge at the midpoint or so, but it does accomplish the task.

After Cleaning - Robot Needs Help!
In an ideal world, a robot vacuum wouldn’t just automatically top up its power tank—it’d empty its dust bin and take out the trash. Alas, this task is left to you, and there’s a pretty significant difference between the two units, especially if you have a pet with long hair (example: Ketzl, our Bernese Mountain Dog).

Dust Bins
The “dust bins” of both units are easy to remove. Roomba’s rear-mounted bin is designed in a “floor sweeper” kind of way, and it’s hard to avoid dumping fine dust and dirt on the floor when removing it. Once done, it’s easy to shake out particulate matter: you then disassemble part of the lower area where lint gathers by the vacuum filter. The Roomba’s bin isn’t very large, and should be emptied on a regular basis—if you’ve scheduled it to vacuum daily, I’d suggest checking it every few days, depending on the environment.

Trilobite has a large (1.2 Qt) sealed, plastic bin. Dust does not escape from it when it’s disconnected from the main unit: a flap closes over the intake, and the other end is covered by a microfiber filter that’s held closed by a magnetic cover: once open, dirt, fluff, etc is easily shaken into the trash. The 1/2” thick filter traps fine dust and should be replaced when necessary (as with most normal vacuums). The Trilobite automatically signals when the bin is full.

Brushes
Roomba’s brush mechanism must be disassembled and cleaned on a regular basis, and—in the “dog” case—gets seriously bound up with hair. The hair wraps itself around the brush, bearings and rubber bar, and requires a significant amount of time to cut, pull and remove.

Although newer models are easily disassembled (early Roombas required a screwdriver), hair can—and does—tie itself around the bushing on one side of the brush and bar, and—when present in sufficient quantity it’ll literally cause the plastic bearing cover to melt, deform and destroy itself. No doubt this is a known problem: a spare brush is supplied with the unit, as is a Roomba “cleaning tool” that has a razor blade and probe that makes the cleaning process easier. Even with that, it can take 20 minutes to clean the Roomba after it’s spent an hour vacuuming a room.

The Trilobite—since it relies primarily on its vacuum, rather than a brush—doesn’t have the same hair problem. Its bar occasionally gets a small amount of hair around it, but it’s made of aluminum (with urethane-looking fins) and doesn’t self-destruct. It’s easily cleaned when it needs to be, which isn’t very often.

Summary
The Roomba and Trilobite achieve their design goals in a broad sense: they automatically vacuum a room, and do a pretty good job of it. But a closer look reveals design differences and compromises that seriously impact the long term “live-with-it” factor that one must deal with after the initial “cool!” factor wears off.

Both are fascinating to watch do their thing, the Trilobite more so due to the intelligent behaviors it exhibits and the mechanical grace it shows in its movements (watching it carefully pick its way out of a jam, climb up onto a rug, pay special attention to under a bed, dock or follow a complex perimiter really shows what a good job Electrolux’s programmers did). The Roomba feels far more brute force as it bashes its way around the room at full speed (despite the fact that both devices rely on random-walk base behavior), but does an good job despite its lack of finesse.

It’s hard to emphasize this kind of thing enough, though. The more elegant approach of the Trilobite is a big advantage i. With the Roomba, as you watch it, you’re amazed it managed to do what it does at all. With the Trilobite, you’re surprised how well, cleverly, and carefully it performs its task. (This has its downside, too—expectations are very high given the overall “quality” impression and high price: when the Trilobite screws up, it’s harder to understand/forgive its failing. Maybe it needs to play a sadder song.)

At $300 for the top of the line model, Roomba is much, much more affordable, and its scheduling capability is handy (though not as handy as it could be with a larger, less messy bin). In a small, easily-blocked off, cord-free room without fringed rugs or hair, and rugged surroundings that don’t mind extensive “bump” contact, it does a good job. If you stay on top of its maintenance challenges—a significant timesink if you have a long-haired pet—it’ll serve its purpose admirably, although I have serious concerns about its longer term durability.

For me, though, the Trilobite is the clear winner. Its “no contact” approach works much better in most areas in my house, and its general charging and cleaning behaviors are better suited to an open plan space. It’s “vacuum-based” operation requires far less setup and maintenance with a pet in residence, and in that—and its overall elegance—it proves to be something that can be “lived with”, long term, with minimal compromise.