Planet Linux Australia

Syndicate content
Planet Linux Australia - http://planet.linux.org.au
Updated: 22 min 6 sec ago

Tim Serong: How to Really Clean a Roomba

Wed, 2017-05-03 13:04

The official iRobot Roomba instructional videos show a Roomba doing its thing in an immaculately clean house. When it comes time to clean the Roomba itself, an immaculately manicured woman empties a sprinkling of dirt from the Roomba’s hopper into a bin, flicks no dust at all off the rotor brush and then delicately grooms the main brush, before putting the Roomba back on to charge.

It turns out the cleaning procedure is a bit more involved for two long-haired adults and three cats living on a farm. Note that the terminology used in the instructions below was made up by me just now, and may or may not match what’s in the Roomba manual. Also, our Roomba is named Neville.

First, assemble some tools. You will need at least two screwdrivers (one phillips, one slotted), the round red Roomba brush cleaning thingy, and a good sharp knife. You will not need the useless flat red Roomba cleaning thingy the woman in the official video used to groom the main brush.

Brace yourself, then turn the Roomba over (here we see that Neville had an unfortunate encounter with some old cat-related mess, in addition to the usual dirt, mud, hair, straw, wood shavings, chicken feathers, etc.)

Remove the hopper:

Empty the hopper:

See if you can see if the fan inside the hopper looks like it’s clogged. It’s probably good this time (Neville hasn’t accidentally been run with one filter missing lately), but we may as well open it up anyway.

Take the top off:

Take the filter plate off:

Take the fan cowling off. Only a bit of furry dusty gunk:

Remove the furry dusty gunk:

Next, pop open the roller enclosure:

Remove the rollers and take their end caps off:

Pull the brush roller through the round Roomba brush cleaning thingy:

This will remove most of the hair, pine needles and straw:

Do it again to remove the rest of the hair, pine needles and straw:

Check the end of the axle for even more hair:

This can be removed using your knife:

The rubber roller also needs a good bit of knife action:

The rubber roller probably really needs to be replaced at this point (it’s getting a bit shredded), but I’ll do that next time.

Clean the inside of the roller enclosure using a hand-held Dyson vacuum cleaner:

That didn’t work very well. I assume Neville managed to escape into the bathroom recently and got a bit wet (he’s a free spirit).

Rubbing with a damp cloth helps somewhat:

But this Orange Power stuff is even better:

See?

Next, use your knife to liberate the rotor brush:

Almost there, but we need to take the whole thing off:

Yikes:

Note to self: buy new rotor brush.

One of Neville’s wheels has horrible gunk stuck it its tread. Spraying with Orange Power and wiping helps somewhat (we’ll come back to this later):

Use a screwdriver to pop the little front wheel out, and cut the hair off its axle with a knife. The axle could probably use some WD40 too:

Remove the entire bottom plate:

Use that hand-held vacuum cleaner again to get rid of the dust balls:

Use your fingers or a screwdriver to remove small chicken and/or duck feathers from the wheel housing:

Use a chopstick to scrape the remaining gunk out of the wheel tread:

Voila!

Here’s what came out of the poor little guy:

Finally, reassemble everything, and Neville is ready for next time (or, at least, is ready to go back on the charger):

Stewart Smith: API, ABI and backwards compatibility are a hard necessity

Wed, 2017-05-03 13:00

Recently, I was reading a thread on LKML on a proposal to change the behavior of the open system call when confronted with unknown flags. The thread is worth a read as the topic of augmenting things that exist probably by accident to be “better” is always interesting, as is the definition of “better”.

Keeping API and/or ABI compatibility is something that isn’t a new problem, and it’s one that people are pretty good at sometimes messing up.

This problem does not go away just because “we have cloud now”. In any distributed system, in order to upgrade it (or “be agile” as the kids are calling it), you by definition are going to have either downtime or at least two versions running concurrently. Thus, you have to have your interfaces/RPCs/APIs/ABIs/protocols/whatever cope with changes.

You cannot instantly upgrade the world, it happens gradually. You also have to design for at least three concurrent versions running. One is the original, the second is your upgrade, your third is the urgent fix because the upgrade is quite broken in some new way you only discover in production.

So, the way you do this? Never ever EVER design for N-1 compatibility only. Design for going back a long way, much longer than you officially support. You want to have a design and programming culture of backwards compatibility to ensure you can both do new and exciting things and experiment off to the side.

It’s worth going and rereading Rusty’s API levels posts from 2008: