Sunday, 21 March 2010

Robots: Pololu 3pi

In the last couple of months I began to get a bit frustrated, technically speaking. The big programming project that I've been working on for the last year has finally come to an end - now we need to find some customers for it before we decide what to do next. So I scratched my head and decided that maybe it would be interesting to find out more about robotics.

A week later I'd read a lot and decided what I wanted to do to get started. I sent off an order to Trossen Robotics (there are of course quite a few suppliers, but these people seem to have a very good range) for a few bits and pieces from the Phidgets range, which are a great way to do robotics direct from a regular PC. I also ordered a Pololu 3pi, to get some quick experience with embedded programming. The 3pi is a small, round (10 cm across) robot made for following lines, with two independently-powered driving wheels, some infra-red sensors to see the lines, a microcontroller, some buttons and LEDs, and a tiny display.

I was amazed by how easy it is to work with the 3pi. I've never done anything with tiny microcontrollers before - my day job involves embedded programming too, but with a 400 MHz PPC with 1GB of memory, comparable to a PC. The 3pi has an Atmel 328p, which has 2 KBytes of DRAM and 32 KB of flash to hold the program. Compared to the PDP-8 I worked on in 1973, this is luxury. But when you're used to writing complex frameworks in C++ with Boost, it takes a bit of a mental gear-change.

Atmel provides a really excellent C compiler, actually GCC, and an IDE, loosely based on Visual Studio. It takes less than half an hour to download and install them, download the examples from the Pololu site, and be up and running. Then it was off to Office Depot (which I hate - never shop anywhere with "Depot" in the name - but they are just around the corner) for some paste board and black tape. Within a couple of hours I had my 3pi running round mazes, using the sample code.

"Every schoolboy knows" that if a maze has no loops in it, you can solve it by just turning left (or right) at every opportunity, until you reach the goal. So the interesting challenge is to solve mazes that do contain loops. The wall-hugging strategy will never actually get stuck in a loop, but it won't find the goal either, except by chance. (Actually it does kind of loop, because eventually it gets back to the start of the maze, and since it can't recognize that, it just starts over).

Solving looped mazes requires knowledge of absolute position. (If you have a useful upper bound on the size of the maze, I believe you can do it without such knowledge, but it's a lot harder to figure out how, and will take a lot longer to find a solution). If you know where you are, then you know when you reach an intersection you have already been to, assuming you have enough memory to keep track. (Remember, only 2 Kbytes of DRAM). The 3pi has no explicit position measurement, not even encoders on the motor shafts. The only way to track position is to integrate the motor speeds. It took me about a week to come up with working code to do this. It would be much easier to do in floating point - but the cost in both code space and computation time is unacceptable. I absolutely hate doing scaled integer math, it's a constant trap of overflows and underflows and just plain getting it wrong. But it's the only way.

Once I eventually got the code to work, I was surprised by how little of the available compute power it took. According to the simulator that comes with the Atmel IDE, keeping track of position every 10 mS takes about 0.5mS, i.e. 5% of the CPU. That's good, because it leaves plenty for doing other things, such as following a line, and keeping track of the maze structure.

Although the IDE includes a simulator, in the end I had to get the code working with Visual Studio as well, so I could get a "brain dump" of the computations at every 10 mS interval without having to step through them with the debugger. It's very easy to do this - just create Visual Studio and Atmel IDE projects in the same directory, and they work off the same source files. Of course a few #ifdefs are required to get things to compile in both environments.

One complication I ran into is that the motor speed response is not linear with the applied voltage - which is not a surprise. At lower voltages, a greater proportion of the power is used to overcome friction. Also, the two motors are not absolutely identical, so if you apply the same voltage to both of them, the 3pi gradually curves around. I wrote some code to calibrate the motors, which for the moment is a manual process although it would be a lot better to automate it. With the motors calibrated, it looks as though it should be possible to get a position estimate that is reliable to within about 1%. That should be good enough for mazes up to a couple of meters across.

That's about as far as I've got, at the moment. I'm now in the middle of writing the code to actually solve the maze. This is logically tricky but at least it doesn't involve any fixed-point math. More on that later, if and when I get the whole system to work.

Friday, 19 March 2010

Divisumma Diary - It Works!

The Divisumma has been sitting on a corner of my desk in full working order for a couple of weeks now. There's a picture of it at the bottom, complete with case and very attentive full-time Divisumma Operator.

Progress since the last posting involved several more variations on the Battle of the Springs, and a lot of lubrication. The problem with springs is that they age, losing some of their strength. Replacing them with new springs is a risky business, because in many cases the exact strength of the spring is important.

I mentioned before the problem that multiplication sometimes gave the wrong answer. At the same time, I noticed that the key that allows you to transfer the result of a multiplication to the multiplier register - for example when computing powers or strings of products like 123 x 456 x 789 - no longer worked.

The Divisumma uses a clever trick to speed up multiplication. If it needs to multiply by 4 or less, it uses repeated addition. For 5 or more, it instead adds an extra one to the next digit, then subtracts. So to multiply by 9, it subtracts once, then adds an extra one to the next digit. If you multiply by 99999, it only performs two actual arithmetic operations, effectively multiplying by 100000 and subtracting 1. The effect is to halve the time to multiply, on average. As you can imagine, the mechanism to do all this, purely mechanically, is frighteningly complex. As ever, I'm lost in admiration for the designer of the machine, Natale Capellaro.

The error in the multiplication could be explained if in certain cases, a value was added instead of being subtracted. To cut a long story short, the problem turned out to be where I had replaced a spring, the long spring 277 from the Battle of the Springs, by a stronger one. It completely solved the problem there, but unfortunately the static end of the spring is not really static, it's a little hook on the end of something that moves. The stronger spring was holding it a fraction of a millimetre away from its correct resting position, and that was enough to block two pieces of the machine: the lever that decides whether to add or subtract, and the lever that causes the multiplication result to be transferred.

So I had to revert to the original spring, and solve my Battle of the Springs problem another way. The service manual says that in certain cases, to get things to work, you should "act upon" various cam followers and the like. So indeed I "acted upon" the little lug 150a, until it stayed out of the way of lug 286n when it was supposed to. It's now twisted quite a lot, I'm sure more than the spirit of "acting upon" would demand, but the machine now works.

Another spring problem caused an equally odd problem. Sometimes, an add or subtract would trigger a total operation, wiping out the value just entered. Curiously, this was related to the length of the number just added. If it had just one digit, the problem didn't happen. If it had 12 digits, it always happened.

The immediate cause of the problem is the mechanism for printing the result of a multiplication or division. This uses the total machinery, and it does it by pulling down the total key at the end of the cycle. It's almost as if a big arm reached out of the machine and pressed the button down. The arrangement for triggering this is amazingly complex, with flimsy levers that run the whole length of the machine. It turned out that the mechanical shock to the machine when the digit carriage was restored, was just enough to trigger one of the pieces of this.

The mechanical stresses in the machine are pretty high. There is very little time to restore the digit carriage within the overall quarter second or so main cycle - maybe 50 milliseconds, to move something quite heavy through 5 centimetres or so. So when it hits the stop, it is moving fast and there is a lot to absorb. Designing these machines to work reliably, considering everything that was going on, was a lot harder than just getting one to work on a bench in the lab.

Anyway, the fix in this case was just to use a new, stronger spring. Problem solved.

Then it was time to put the machine back in its case. The first step was to replace it on the steel base. It hadn't been too hard to get it off - there are just five bolts that hold them together. But getting the holes lined up again was nearly impossible - they have to be correct to within less than a tenth of a millimetre or the bolts just don't engage with the nuts. And two of these bolts are completely inaccessible. Luckily I had just bought these bolt-handling tweezers from Micromark, which were exactly what it took to weave the bolt through the levers and get it to the right place. Even so, for one of them I had to hand-turn the machine to a certain point in a division cycle, to move a lever out of the way and give me access. I can't imagine how they did this assembly in the factory, there must be a trick that I missed.

After that it was just a matter of putting the case back on, cleaning things up, replacing the ribbon, and now I have a perfect piece of retro-computing sitting on my desk. I even use it occasionally, instead of firing up the Windows calculator.

Thursday, 18 March 2010

Flying the Helicopter

It's been a long time since I wrote anything about the heli. I've been flying it generally about once a month since my checkride. That means training and currency flying - apart from the one flight with my wife, everything has been with my instructor. And that means lots of autorotations. They're one of the most fun aspects of flying helis anyway, plus you need to be good at them in case the engine ever stops.

Most practice autorotations are done down to the flare, about 10 feet above the ground, and then you re-apply power and fly away, or hover. That's because the greatest danger - mainly to the aircraft - is in the very final phase. But if it ever happens for real, you need to know how to get the last bit right too. That's called a "full down auto", when you actually land. I've done quite a few of those, my instructors hands poised ready to take over in a heartbeat if necessary. But actually the last couple I've done have been fairly good, resulting in a gentle touchdown and a short roll-out, or I suppose it would be more accurate to call it a scrape-out, considering the absence of wheels.

Another variation on autorotations is the 360 degree auto. This is what you would have to do if you had just flown over the only viable landing spot in sight. Chop the power, then execute a steep (30 degree or more) banked autorotating turn, keeping a sharp eye on rotor speed, airspeed, altitude, and the outside world, all at the same time. The trick is to touch down exactly under the spot where you chopped the power. Let's say I'm getting there.

And then last weekend, something completely different. We've been talking about doing a mountain checkout for a while - we had it arranged a couple of months ago but on the day it was snowing hard in the mountains. Last Sunday, the weather was perfect, so two of us together our instructor flew up to Tahoe, then on to Reno and Truckee before returning home. I flew the outward leg, about 90 minutes from Palo Alto, first in a straight line to Jackson and then following Route 88 up to Kirkwood before cutting across to the pass and then a steep descent into Tahoe. Much easier in the heli than in the plane, where you just about invariably end up flying out over the lake to lose altitude. It was a beautiful flight, with the unparallelled visibility that you can only get from a heli.

We had the heli deliberately loaded up to gross with some ballast, so we got to feel what a high-altitude take-off and landing is like. Also, at altitude you need to watch power carefully, since the limit is lower there. But overall it was fairly straightforward. We went on to Reno, and then I flew the leg from there to Truckee. And learned something important.

In an airplane, your take-off options are limited. You use a runway, and there aren't many of them, and the tower always tells you which one to use. It's something they take seriously! But a heli is capable of taking off from anywhere you like - the ramp, a runway, a taxiway, the grass - and most towers are happy to let you do so, as long as they approve it. But at Reno we ended up with a misunderstanding - the tower expected me to do something different from what I actually did. Nothing bad happened, and they were nice enough about it, but it was an excellent lesson. In the heli at a towered airport, always make certain that what you are about to do is what the tower is expecting you to do.

Flying around Tahoe was a great piece of heli-tourism too. The views were wonderful, especially on the legs where I was sitting in the back, and could take some pictures. Here are a couple to be going on with while I get them all organised and onto Flickr.