Vox has suggested that this would be bad news for feminists. That effect might be overstated. I say this for three reasons: (1) Men are still going to want the real thing, (2) such robots would be prohibitively expensive for the foreseeable future, and (3) those with the money for these robots, will be able to get the real thing.

01/29/2007: Drawing off the example robot design in the LEGO Mindstorms NXT kit, I decided to do a little ad hoc work of my own.

In this example, I used two servomotors instead of three, and–in the rear–decided to let it slide instead of use the small wheels that were part of the LEGO example. This is because, using the rear wheels caused the bot to tilt forward. I didn’t like that at all.

For the sensors, I added the contact sensor, the ultrasonic sensor, and the sound sensor.

For operational programming, I used three different loops to test the sensors. Here are the pics of the robot and the program:

01/15/2007: Programming the LEGO Mindstorms NXT robot arm was easy. Getting the steps (and power settings) sufficient so that the clamps would grasp the ball without grasping the platform, and releasing the ball cleanly, took a bit of trial-and-error.

If you activate the clamps the moment the contact sensor is pressed, the clamps will grasp the platform and this will result in a fumble. The robot will drop the ball.

When the contact sensor is pressed, you need to move the robot arm upward–rotate the z-axis servomotor 9 rotations. This allows the clamps to grasp the ball cleanly.

Once the clamps grasp the ball, I rotate the z-axis servomotor an additional 5 rotations. This allows the robot arm and clamps to clear the platform.

Then, I rotate the x-y axis servomotor 15 rotations.

Once that is done, I rotate the z-axis servo down 5 rotations. Then, I release the ball onto the platform by activating the servomotor that controls the clamps.

Then, I rotate the z-axis servomotor upward 5 rotations.

Finally, I rotate the x-y servomotor 15 rotations, back to its original position.

01/14/2007: Well, I decided to dedicate an afternoon and build a more complicated robot with my LEGO Mindstorms NXT kit. I figured I’d construct their robot arm.

Turned out the directions were quite easy to follow. Here are some pics of the finished product:

I have completed some of the programming, most of which entails just figuring–based on the placement of the balls for pickup–the number of rotations for which to operate the servomotor as it rotates about the z-axis once it has picked up the ball.

Basically, this is how it will operate:

(1) The robot will move down the z-axis until the touch sensor contacts the red ball.

(2) Once the contact sensor is activated, the servomotor moving the arm down the z-axis will stop, the servomotor controlling the grips will cause the grips to clasp the red ball.

(3) The z-axis servomotor will rotate five rotations upward.

(4) The servomotor controlling the rotation about the z-axis will be activated, and will turn 18 rotations, then will stop.

(5) The z-axis servomotor will rotate–at 25% power–five rotations downward,placing the ball on the platform.

(6) The servomotor controlling the grips will release the grips at 25% power.

It is one of the coolest toys–for children and adult (children) alike. The kits allow for easy construction of robot concepts. They come with three servomotors and four different sensors (light, sound, touch, distance). The servomotors are calibrated so that one can program the motion for as little as one degree of rotation, and with variable power settings. There are also built-in regulators to protect against back EMF, which can fry a motor.

And the programming interface–developed by LabVIEW–is a neat graphical tool that allows anyone from novices to experienced programmers to work with relative ease. The programmable controller–the NXT “Brick”–is also BlueTooth compatable.

12/04/2006: I’ve been experimenting on and off with Linux for most of this year. I have an extra hard drive, which is exclusively Linux. (My other one has Windows XP, and I use it for work-related stuff when I’m away from the office.)

Thus far, my experience with Linux has been mixed. I had Fedora Core 3 and Fedora Core 4 on my system, and–while it had potential–I had trouble getting it to recognize all the devices devices on my laptop. My sound card and wireless card–even my Orinoco card–were effectively useless.

I downloaded the ISO for Ubuntu Linux, and was able to install it with relative ease. As a bonus, it recognized my sound and wireless cards. The only complication was the video: it defaulted to 800×600 resolution. (It was having some trouble with my NVIDIA card settings). I was able to get that problem fixed pretty easily, as the Ubuntu folks have a good blogger community.

Total cash outlays: less than $1.00 (the cost of a blank CD).

Like other Linux installations, Ubuntu includes OpenOffice 2.0, which MS Office users will find quite easy to handle. In addition, one gets the ability to add a plethora of other open source applications for everything from mathematics tutors to Bluetooth interface software to CAD. I loaded BibleTime 1.6, and enjoyed that every bit as much as QuickVerse.

The real test was at my secret office: Barnes and Noble. The wireless card worked like a charm. Ubuntu Linux handles my Dell Latitude D800 quite well, booting in about a third of the time that my Windows XP does. (And you can’t beat the price for Linux!)

Over the years, I’ve heard the case against Microsoft. Critics told me they monopolized the software world. No one can compete against them. They control the market.

All hogwash. I’ve long said that Microsoft is as safe as can be until the next software paradigm hits, and other players start developing competing products.

A few years ago, I loaded Red Hat Linux 9 on an old laptop, and–while powerful and stable and secure–it was very unpolished. Novice users would have had trouble using Linux. At that time, Linux was an operating system that non-programmers would have found quite difficult. Derived from Unix–which was designed by and for programmers–Linux had a long way to go before it would be a prime-time operating system for non-geeks. For all its faults, Microsoft was still the better product in terms of useability.

Now, however, Microsoft had better become wary of Linux; thanks to outfits like Ubuntu and Red hat, Linux has shrunk the user-friendliness gap once enjoyed by Windows. Linux is ready for the big time.

If I can find a way to program my LEGO Mindstorms NXT robot kit with Linux, I will become an exclusive Linux developer away from the office. (UPDATE: this is very doable, as Michael Collins has illustrated. I will have to play with this feature during my Christmas vacation.)

Isn’t it interesting that I can buy a $400 gizmo for my dashboard that will bark at me if I miss my turn in the dark but a pilot can’t find the right runway on a foggy morning?

The answer to that question is even more unsettling: The pilot’s union has fought more technology in the cockpit because their members want to be “jet jockeys” and not play second fiddle to a jet that can easily take off and land by itself.

The joke is that the typical passenger with a laptop has more computer horsepower than you’ll find in the cockpit. Since the vast majority of plane crashes are “pilot error,” isn’t it time for an upgrade â€¦ that doesn’t have to look out the window to see if the jet is on the correct runway?

While the case is strong for more in-cockpit technology, it should serve as a complement–and not a substitute–for a pilot who is meticulous with his or her checklists. Airlines will not be safer if pilots begin relying on technology to maintain safety.

After all, when–not if–such technology fails or malfunctions, the checklist–with all its mundanities–is the difference between a safe flight and a disaster.

Some have made comparable arguments with respect to medicine, as very impressive decision support technology–using Artificial Intelligence (AI)–exists that allows computers to perform medical diagnoses. Many financial companies use this technology to augment their management of client portfolios.

However, in the real world, batteries die at the darndest times; circuit components break down; power surges destroy electronic components; hard-drives crash; databases get corrupted; programs crash when memory runs out (and the amount of available memory is often inversely proportional to the immediacy of the situation). Automated systems do fail.

Engineers, pilots, physicians, database administrators, network analysts, and application developers are well-acquainted with Murphy’s Law: when those systems fail, they will fail at the worst possible times .

With pilots–as with physicians–technology can be very effective as a redundancy: a fail-safe, if you will.

However, there remains no substitute for a pilot performing pre-flight and pre-takeoff check, or a physician who researches, speaks with the patient, interprets verbal and non-verbal communication, runs tests, researches topics, and arrives at a conclusion that can withstand the scrutiny of peer (or even judicial) review.