Three Palms in a Robot

Palm Robot in Action See the Palm Robot in action -- 3.9MB fast start QuickTime movie.

Back in November, when the PalmIII PPRK Robot Kit was merely a blip on Slashdot, we decided it would be a fun pre-Christmas story to buy and build one. We'd talk about the build, how the thing worked, and a bit about the physics and software. It sounded like a good story at the time, and a fun one too.

We decided to order the bare-bones kit instead of the easier one. My editors wanted me to experience the "joy" of scientific discovery myself. I agreed, though I probably had too much coffee when we talked.

We waited a few weeks for Acroname -- the company that licensed the rights to sell the kits from Carnegie Mellon University where the kit was developed -- to wrangle all the parts. Finally the kit arrived, and in mid-December, I eagerly set to work. I had no idea what I was getting myself into.

Some pre-assembly required

The bare-bones model required some pre-assembly steps, which according to the documentation were "not extremely difficult but require some comfort and familiarity with soldering, small components, and tearing apart servos."

Did I have any of that? Of course not. I haven't soldered anything since junior high metal shop, I have no familiarity with small components, and servos makes me think of Mystery Science Theater 3000.

The soldering wasn't very difficult. But Step 3 read, "Using your Pontech controller as a guide, make sure to get the red wire on the '+' side of the controller when the socket is plugged in."

This wasn't at all clear. I had to take out the little red socket to figure out how it plugged into the controller, then worked backwards from there.

The next major step involved modifying the three servos so that they rotate continuously. To do that, I had to open up each servo, take apart the gears in it, replace the bushings with ball bearings, and then put it all back together again.

"Adjust the servo until it stops moving by turning the small brass pin that protrudes. This is the potentiometer that typically gives the servo feedback. Here, we disengage it physically from the servo gear and so the servo rotates continually, thinking it is never reaching the input position."

That's not that tricky; but what takes some dexterity is keeping that brass pin in the same position when you reassemble the darned things -- especially after your fingers get coated with ball bearing grease.

Also, getting the servo wheel off is hard. I ended up using a small pair of vice grips to hold the wheel when I took the screw off, because I couldn't keep the wheel from turning otherwise. And the ball bearings you put on are tight -- so tight -- I had to jam them on using brute force.

"Now, put the lid back on top of the servo," the instructions read. "This may be snug and require a bit of finesse [read: brute force] as the bearings seat tightly."

After finishing with the servos I had to glue the roller wheels together, which -- surprise! -- required 5-minute epoxy. After a short trip to the hardware store, I was back at it. I glued the wheels, then glued the base of the serial cable to the deck, the acrylic triangular slab that's the base for all the parts.

Then it was back to the soldering gun (my new favorite toy) to attach three wires from the serial cable to the DB-9 connector. The instructions were well-marked, and even though I mostly avoided the tech wing of my high school, I had little trouble.

The soldering and servo-rebuilding make up the pre-assembly steps, and now I'm ready for the "standard assembly."

Basically I needed to put all the parts together now, starting with bolting the little infrared sensors to the aluminum sides, then bolting the sides together to make a hexagon. This was a simple but clumsy process, since an individual nut and bolt assembly fit on about a third of my thumbnail. Once the hexagon was in place, I bolted the servos to the frame.

The little robot was starting to take shape, especially after I attached the controller and top deck of the robot. Then I went on to the wiring, which consisted of a lot of "plug-black-wire-into-jack-#2" and "plug-servo-connection-3-into-position-S3".

"Between the servo wires and the detector wires, your robot will look a bit like a teenager in the middle of an orthodontist appointment with wires hanging out in all directions," the directions read. They're not kidding.

Robots: Almost home

During the assembly process I talked to Steve Richards, the founder of Acroname, the company that licensed the rights to sell Palm robot kits from Carnegie Mellon.

I'm apparently not the only one building one of these. When I talked to him in late December, Acroname had been selling the kits for a little over a month -- and had finally been able to meet demand. He was selling one bare-bones kit to about every two easy kits.

"The Palm robot paralleled some of our development we were doing," Richards said, adding that Acroname had its own designs for several years, but "this is the first one that's been in the national media's attention."

"Robotics is at a strange point where people are asking what good is it," he said, likening it to "the way people were looking at computers, and what the Homebrew Computer Club was doing 20 years ago."

There are a lot of special-purpose robots around (and on the way), and we aren't reluctant to send robots to perform hazardous duty such as fighting fires or tooling around on the surface of Mars. However, robots haven't made it to the home in any measurable form, he said, in part because "We haven't seen the killer app come along."

There are robotic vacuum cleaner prototypes available, he notes, but for now they're priced out of widespread market acceptance. "What it's going to take for these things to be absorbed into our culture," he said, "is when the robot can do three important household tasks, like vacuum, shovel the walkway, and take out garbage."

The Palm-powered robot does none of these things, but for the moment that's not important. Though this kit is "a novelty device inside the house," it opens up a lot of opportunity for educational and research projects to further what can be done -- both with Palm devices, and with robots.

The final stages of the build were an anticlimax. I screwed the wheels on, and then mashed all the wires into a manageable lump so I could bind them in place with the two cable ties (one of mankind's greatest inventions).

Voila! I'm done. Or so I thought.

Next page: It's a sofware problem.

It's a software problem

Because I have only a Palm V at home, we had to cadge a Palm III to use on the project. Unfortunately, the first Palm I borrowed was at the end of its long and storied life, and it immediately crapped out. When I hot-synced it, the screen had disturbing vertical lines across the screen, though a soft reset, warm reset and hard reset restored it -- but just barely.

I exchanged it for a younger, healthier Palm IIIxe that my editor found.

The software to run the Palm robot is on the original PalmPilot Robot Kit (PPRK) page, and includes PenFollow, a stylus-guided navigation program and the PPRK Explorer program, which "allows your robot to explore [the] world around it. The robot can follow walls, convex, and concave corners."

Both of these require MathLib.prc, so I downloaded that and the two programs I was itching to try.

But when I tried to install these using HotSync, disaster struck. The hot-sync itself seemed to go OK. There were no errors in the log, but at the end of the hot-sync I got a "Fatal Alert" box on top of the Palm logo. Inside the box: "Fatal Exception," and a box to click that said "Reset."

I clicked the box and a second later it came back. I tried it five more times, before frantically making a call to my editor -- can I do a hard reset on this? He said that I could, and I did. I managed to clear the error, and I tried again.

This time I tried to install MathLib by itself -- but I got the same problem. I tried all sorts of permutations of installations and changing user names, but nothing worked. I called Palm support, and the college kid who took my call said, "try contacting the third-party software" -- which is exactly what I was afraid he'd say.

I sent e-mail to the guys at Carnegie Mellon, and they suggested something I'd already tried. "The programs definitely work on PalmIIIxe," the guy said, "since that is what I used to write and test them with."

After another call to Palm support and some digging on Deja.com, I was still stumped, and so were the support people. The second guy gave me a file number -- in case another support minion wanted to read his notes.

By this time I had hot-synced, hard-resetted, and cursed more times than I could count. Nothing worked. It was time to call in the experts.

The last gasp

I begged the name of a Palm expert who works with an O'Reilly expert, who referred me to his friend Frank. I e-mailed Frank my tale of woe and the link to the PPRK site.

"Drop me an e-mail with some more info on just what you are attempting to do and I will be happy to attempt to assist you in getting your robot working," he wrote. "In the meantime, I will look at ordering one of these robots myself!"

I wrote back:

MathLib.prc and robot1.prc were the two I tried first. I downloaded those off the site. I wanted to run the Explorer program, but since I couldn't get past the other two, it was a wash. I had an even older Palm III to begin with, but it suffered a horrible death when I tried to hot-sync it (but it looked dodgy to begin with).

Frank hot-synced into action:

I grabbed the first Palm I could find on the shelf -- a Palm IIIe, which ran PalmOS 3.1. This seemed to work fine (Just what you wanted to hear, right?). I installed MathLib.prc, Robot1.prc, and ServoTest.prc. In the absence of a robot, I could do very little (I just got shipping confirmation yesterday, so thanks to you, I have just purchased another toy).

The IIIxe runs 3.5. The older serial comms was actually emulated on 3.5 via a "serial manager" and there was possibly something not quite right there, though I thought the probability of that was very low.

He suggested deleting all the files from the C:\Palm\Robot\Backup folder ("Robot" is my name for my misbehaving Palm IIIxe), and I tried that -- no luck. I wrote Frank again:

Short of standing on my head and chanting in foreign languages, I've tried just about everything. I did a hard reset (I had to; it's the only way to revive the ailing machine after a fatal exception). I made a new name for the little device and hot-synced on that. A straight hot sync without any installation works fine. But as soon as I tried Robot1 or MathLib or ServoTest ... CRASH.

The Palm IIIxe was running System 3.5.0 and other basic software (applications, a date book, etc.). I was running Palm Desktop v. 3.0.1. On a PC. Windows 98. Low humidity. Good natural light. Plenty of dietary fiber.

In the midst of this, I read on the Palm site about "Palm OS v3.5.2 Update, a system update for Palm OS software versions 3.5.0 and 3.5.1. It fixes a couple of low-level system issues that in rare circumstances might cause certain third-party applications to crash."

Aha! My editor gave me the green light, and I downloaded 3.5.2. And I installed it -- and it worked! The upgrade was successful, no fatal exception death spirals at all.

But did it help with the robot software? No. Nothing helped; nothing at all.

A few days later Frank mailed me:

I finished the PPRK yesterday and it seems to run fine even though the floor was a bit slippery for the wheels. I think concrete or a very low pile carpet (like industrial, office carpet) would work better. I am going to move the Palm off of the device and add an infrared connection to make it a remotely controlled IrBot. Let me know how I might help you more. I am, unfortunately at a loss for whatever is happening with your HotSync.

Me too. The final irony was that the build -- the part I'm least experienced to do -- was a snap, but the whole project died because of software installation, something I've done hundreds of times. Not only that, everyone else -- at least the Carnegie Mellon guys and Frank -- have no problem with the software, but no one can figure out why I can't install anything.

And weeks after Christmas, I had a robot, a Palm, and no way to get them to work together.

The happy ending

Turning in a story where the damn thing doesn't work is no good, so my editor did the only sensible thing: He extended the deadline again.

That gave me the chance to beg a Palm off of my friend Ron who is an engineer at Palm.

I'd like to say I went through the whole process again, and successfully loaded the software on the new Palm.

But I didn't. I got Ron to do it for me. The mysteries of unsuccessful installations and multiple crashes will remain.

The Palm arrived, along with a note from Ron:

I still don't understand how you control a moving robot with a stylus-driven interface. I picture you and other techno-nerds on knees and non-dominant hands, styluses in dominant hands, chasing three-wheeled gizmos while stabbing furtively at a moving, low-contrast, low-resolution screen.

I was wondering the same thing myself. Was it going to be speedy? Would it scoot across the floor in an impressive fashion? Would I have to scamper to catch it? And most importantly, would it scare the cats?

I turned the Palm and the robot on and set it on the carpet in my office.

It worked! Sort of. It was pretty clear that even really low-nap carpet bogs the poor robot down, so I moved my desk chair and tried it on the plastic carpet protector, where it ran much better.

The PenFollow program was simple. Just hit "Start" and then draw a vector on the screen, and the robot takes off more or less in that direction. It was really slow at first, until I realized that the speed is proportionate to the length of the line you draw on the screen. A shorter line is slow; a longer line is ... well, not fast exactly, but not glacial.

I then took the robot to the kitchen. The robot moved well on the textured linoleum on the floor, squeaking as the little servos turned. It didn't always move in a straight line, however. I tried various directions, and it seemed that if one wheel had to turn more than the other (the third typically did nothing), the robot tended to curve away from the dominant wheel.

Palm Robot in Action View a QuickTime movie of the Palm Robot in action.

Once it was all said and done, we tried to beam the PenFollow app from the good Palm to the noncompliant Palm, just to see if it would work. It didn't. Normally on a Palm, if you choose Beam, you'll get a list of the all the applications and you can then choose which one you want to beam.

However, we tried that on the Palm with PenFollow on it, and the application didn't show up. I don't know what that means exactly, but it probably means that PenFollow is something other than a standard .prc file.

Well whatever. After this amount of time, I was just happy that the darned thing works, and I'm willing to overlook small details.

As a final test I set it down and drew a long line right at the cat. The cat sniffed, looked slightly worried, and then walked past it, giving it a bit of room.

Acroname's Richards is right. The robot is a novelty device, and it does open a lot of opportunity. I just wish it would scare the cats.

John Ochwat is a former editor for Upside magazine and contributes to numerous tech publications.

Discuss this article in the O'Reilly Network Wireless Forum.

Return to the Wireless DevCenter.

Copyright © 2009 O'Reilly Media, Inc.