For years I've got my daily news fix from the BBC news site. It was well arranged and would give instant access to the top world stories and, when I was feeling nostalgic for good ol' blighty, the UK. There were always a few interesting tidbits. And it was free, too.
Then, a few months back, some genius in marketing (I presume) decided that the page needed a New Look. Ever since, I just can't find any news on it. It's not just me, I have a colleague (Iranian) who has exactly the same feeling. Somehow, they just messed it up. I guess all the same news is still there, but it has lost its interest and salience.
Today I signed up for a subscription to The Times (the London one). Goodbye BBC news. I'm sorry to have lost a friend.
Monday, 6 September 2010
Tuesday, 31 August 2010
Flying under the Golden Gate Bridge
I did it! On Sunday we flew the helicopter under the Golden Gate Bridge. It was pretty exciting. The picture shows us just approaching the bridge from the east. We're at 100 feet, about half the height of the deck.
The sight-seeing operators do this all the time. I was astounded when I first saw the red Jetranger that does these flights around the city zoom under the bridge. It's quite legal. There's a special exemption to the regulations that allows helicopters to fly pretty much anywhere without the distance requirements that apply to airplanes. (Take a look at FAR 91.119 if you're interested).
I'd discussed it with my instructor a few months ago. The plan was to fly through the SFO Class B airspace up to the city, under the bridge, then back again by the same route. Unfortunately though, since the incident earlier this year, SFO Tower is being much more cautious about Class B transitions. During the busy part of the day, they are generally not available. And indeed that's what San Carlos tower told us . Our second plan was to cross the hills at route 92 over to the coast, and go round the Class B. Although it was cloudy, there was plenty of room under the clouds to do this.
But then San Carlos handed us off to Norcal Approach, who cleared us through the Class B at 3500 feet. I've been given this transition before and it works well. Sometimes you have to ask for it, a bit like Special VFR. So we climbed before we got to the clouds, flying over the undercast and also the SFO departure corridor. It was very pretty, the airport and the city were both visible through gaps in the clouds, although I didn't manage to get a decent picture.
Then a very rapid decent once we were past the Class B surface zone, down to 700 feet and ready for the big adventure. We went over the south end of the bridge, slowed right down in a left descending turn, and at a stately 40 knots or so passed under the bridge at 100 feet. It was over all too quickly.
Although it's perfectly legal, we were both a bit nervous that people might react badly, so we climbed well away from the bridge, back over the south end, and then across the Bay to Oakland for the transition back south.
More pictures on Flickr.
Monday, 30 August 2010
Audrey Hepburn and the Eiffel Tower - twice!
There are two movies that feature both Audrey Hepburn and the Eiffel Tower (well, I suppose there could be more). One is well known and you will find it by googling those two subjects - Funny Face, one of her hallmark movies. It's a great movie, which we saw at the Stanford Theater last night. (One of the really nice things about living near Palo Alto is this movie theater, lovingly and expensively restored and specializing in classic movies, mostly pre-1960).
By coincidence, we had watched the other one the previous night at home. Any guesses? It's the Lavender Hill Mob, one of the greatest of the British Ealing comedies, from 1951. The main characters are Alec Guiness and Stanley Holloway, with other classic stars from the time like Sid James and Sidney Tafler. The Eiffel Tower has a central role in the plot, including a fantastic scene where the two heroes run down the emergency staircase. And Audrey Hepburn? In 1951 she was still an unknown. She has a tiny walk-on part at the beginning. You wouldn't recognize her unless you were looking. It was only when the closing credits rolled by that I saw her name.
Going back to Funny Face, there are some wonderful period-piece scenes. For avaiation fans, the scene of the TWA Constellation taking off is enough to make the whole film worthwhile. Then they land at Orly, where on short final they fly over Notre Dame and the Champs Elysees. Funny, this never happens when I go to Orly.
Another great detail is the Isetta, a 1950s "bubble car". It's a weird little thing, with a single door which is also the front of the car. For the movie they gave it a funny pweep-pweep horn, which the real thing didn't have.
By coincidence, we had watched the other one the previous night at home. Any guesses? It's the Lavender Hill Mob, one of the greatest of the British Ealing comedies, from 1951. The main characters are Alec Guiness and Stanley Holloway, with other classic stars from the time like Sid James and Sidney Tafler. The Eiffel Tower has a central role in the plot, including a fantastic scene where the two heroes run down the emergency staircase. And Audrey Hepburn? In 1951 she was still an unknown. She has a tiny walk-on part at the beginning. You wouldn't recognize her unless you were looking. It was only when the closing credits rolled by that I saw her name.
Going back to Funny Face, there are some wonderful period-piece scenes. For avaiation fans, the scene of the TWA Constellation taking off is enough to make the whole film worthwhile. Then they land at Orly, where on short final they fly over Notre Dame and the Champs Elysees. Funny, this never happens when I go to Orly.
Another great detail is the Isetta, a 1950s "bubble car". It's a weird little thing, with a single door which is also the front of the car. For the movie they gave it a funny pweep-pweep horn, which the real thing didn't have.
Saturday, 31 July 2010
o hisashiburi desu nee!
Just looked at my blog and realised it's months since I wrote anything. (The title is Japanese for "it's been a long time, hasn't it!"). A lot has happened in that time. I got a wonderful hexapod (six-legged) robot from Micromagic Systems, with lots of intentions to write software to do all sorts of clever things. I figured out the math for how to make it go where I want to, which involved re-learning a lot of things that I never really learned in the first place, like matrix math. I got a lot of code written, too.
But then real life intervened - I gave myself a new work programming assignment, and I really can't do two big, new pieces of software at the same time. So I haven't touched that in several months.
The maze solver got put to one side when the hexapod showed up. I'd realised that you just can't track the rotation angle of the 3pi by monitoring the motors. So I had to make the compromise of requiring mazes to always have 90 degree angles in them. I started to make the necessary software changes when, again, real life got in the way.
Then we went travelling, first to Japan where we had the immense good fortune to attend a friend's traditional Japanese wedding, then to France on holiday.
I'm still flying - I've got (at least somewhat) back in the groove with the Pitts, and I fly the heli once a month or so. My precision autos are getting better, and there are times when I think that autos are the most fun you can have with or even without your clothes on. (Maybe that's just a sign of advancing age though!). I've also started work on my CPL-ASEL (commercial license, that lets me get paid for flying, should I find anyone willing to do so), though that hasn't gone very far for all the above reasons.
The Divisumma still sits on the corner of my desk, with its very attentive operator. It still seems to be working.
And that's about it, four months of my life summarised in a couple of paragraphs. Hope to get time to keep this blog a bit more up to date in the next few months.
But then real life intervened - I gave myself a new work programming assignment, and I really can't do two big, new pieces of software at the same time. So I haven't touched that in several months.
The maze solver got put to one side when the hexapod showed up. I'd realised that you just can't track the rotation angle of the 3pi by monitoring the motors. So I had to make the compromise of requiring mazes to always have 90 degree angles in them. I started to make the necessary software changes when, again, real life got in the way.
Then we went travelling, first to Japan where we had the immense good fortune to attend a friend's traditional Japanese wedding, then to France on holiday.
I'm still flying - I've got (at least somewhat) back in the groove with the Pitts, and I fly the heli once a month or so. My precision autos are getting better, and there are times when I think that autos are the most fun you can have with or even without your clothes on. (Maybe that's just a sign of advancing age though!). I've also started work on my CPL-ASEL (commercial license, that lets me get paid for flying, should I find anyone willing to do so), though that hasn't gone very far for all the above reasons.
The Divisumma still sits on the corner of my desk, with its very attentive operator. It still seems to be working.
And that's about it, four months of my life summarised in a couple of paragraphs. Hope to get time to keep this blog a bit more up to date in the next few months.
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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)