PC-Doctor's Robotics Lab

In August 2007's IEEE Spectrum they had an interesting article about Microsoft's robotics lab.

I do have some highly speculative and mildly interesting thoughts about PC-Doctor's role in such an industry. Before I get there, though, I want to comment on how, when Bill Gates wants to put together an "elite" team of programmers to do something that's new for Microsoft, they take people who have been Microsoft employees from birth. After all, if they've learned anything outside of Redmond, they might not want to do things the Microsoft way!

Okay, that's all the ranting I'm going to do. Other than that, they seem to be doing some cool stuff over there. Essentially, they've created a robotics lab who's goal is to create some software tools that will standardize the way sensors and actuators are hooked together, and they also want to make a centralized database to hold navigation information. The goal is to make home robotics happen on a large scale.

The article says that the current market for robotics is about $11B. That's not much from Microsoft's point of view. However, it's pretty easy to imagine that, if home robotics does get to the point where everyone has a few robots in their house, then it'll be a heck of a lot bigger than that.

Okay. We're finally past the ranting and background material. Why should a PC diagnostics company be interested in this?

A robot or two in everyone's home is a lot of hardware to manage. Camera lenses can get dusty, bearings can start to fail, DC motors can overheat, batteries can lose power, dogs can chew the video cables, and dust bunnies can be unreachable because of obstacles. There's a lot of diagnostic possibilities.

From our point of view, the best part of Microsoft's entry into the market with a bunch of Windows geeks is that they're almost certain to want to make robotics into something like Windows. Windows is incredibly good at getting a bunch of strange hardware to work together despite the different manufacturers not even knowing about each other. Anything that a bunch of Windows programmers will create is almost certain to have similar abilities. This is critical for PC-Doctor. We wouldn't be able to create a diagnostic for each IR camera out there. We'd have to make a single IR camera diagnostic that could work with a large fraction of IR cameras out there.

Would our diagnostics for robotics be substantially different from PC hardware diagnostics? To some extent, they wouldn't have to be. There's certainly a CPU and memory bank on the robot that has to work. For the purposes of a highly speculative blog post like this, let's ignore that.

Certainly, some diagnostics could be very, very different. A fancy robot contains a variety of sensors and actuators. A Roomba, for example, has a steering servo, a drive motor, a pressure plate on the front, and a sensor on the bottom to detect stairs. This is about the minimum number of sensors you can have on a useful robot. (That's why Roomba is successful. It's $120.) Testing these sensors and actuators in meaningful ways might not look a lot like PC hardware.

One difference here is that, if you want to test a sensor on the floor that detects stairs, you'll have to find some stairs. That means that the diagnostic would have to actually use the robot in order to test it. If you want to test the DVD drive on a computer, you don't really have to worry about the graphics card. To test a stair sensor, we'd have to figure out if it's even possible to test it. (It might be in a single floor house. It might be a Roomba and not have any useful navigation capability at all!)

Another difference is that a lot of robots have sensors that measure how well the actuators are working. For example, a motor that controls an arm joint might also have a angle sensor on that same joint. Feedback would be used to ensure that the arm is moving correctly. It's tempting to assume that this would reduce the need for diagnostics. However, the feedback loop actually creates more opportunity for diagnostics. For example, you could keep track of the amount power required to accelerate the arm under various circumstances. If that varies over time, then something bad might be happening. If you wanted to get really complex, you could test an angle sensor by pointing the camera from another robot at the arm and moving it. That would require multiple robots and be a lot of fun to write. (Hey, Ken! Can I write that one?)

Obviously, there's no market for this yet, and we don't have a robotics broom closet in the back of our R&D lab. (I suppose I wouldn't be talking about this on a blog if there was.) It is a fun topic to think about, though.

This originally appeared on PC-Doctor's blog.