I often receive emails or comments about the Garmin GPSMap 96C that I bought and reviewed about 3 years ago...

Here are a few keypoints I felt like mentionning to people considering the purchase of this GPS Unit.

• I still like my 96c, it's lightweight, very durable, it's been tossed around in airplane cockpits, thrown in bags and it still works great!
• The screen is still in goodshape, it didn't scratch too much considering I have no protective cover for it. With regards to the screen and direct sunlight, a common concern for LCD screens, nothing to worry about. The screen is perfectly readable under all conditions.
• The battery life is fantastic! It lasts 20+ hours. And probably more without backlight.
• I was impressed with the GPS fix quality when I first got it, but not so much anymore since I've seen what those SirFStar III gps's are capable of... The 96 gps gets a fix rather quickly but has a tendency to lose it very easily when in a side pocket of an airplane, or under my arm when flying a high wing airplane...
• The unit can be painfully slow when scrolling with the directional pad... this is one of my biggest frustration with the GPS... menus are fast, no problem here, what is the slowest is the moving map... When panning out of the current view, it sometimes reloads the entire screen, which can sometime hang the screen and controls for a few seconds... very frustrating when you are trying to find a distance, an airspace altitude or a frequency....
• The tracking system is very convenient, I've logged almost all the flights I've done since I've had it...
• The price might be a show stopper for some... Considering the price of the car units... why the heck are the slower and older aviation gps units more expensive ?

I sure hope that Garmin comes up with a faster version with the same form factor. I'd definitely buy it :-)

If you are looking at buying a good GPS Unit now, the Garmin GPSMAP 96C is definitely a good buy! I'd recommend it to anyone!

...because it requires a logic I don't have hard wired in my brain...

With all the rendering differences there are between IE and Firefox, I wonder how there are still webmasters that have not gone completely nuts...
It must be taking some serious self control not to send hate mail to both the IE and Firefox developers...

Perhaps the web browsing world is so sketchy because the html and css specs were developed with absolute ignorance of their implementation... (kinda like Collada) and now web browser developers are having a really hard time to make one 100px wide table look the same everywhere...

I'm no longer partisan of one or the other... I don't care... :-)

And there are some concepts in css that even after a few attempts, I still don't get... thing that given their name, you would expect to do things that they don't actually do... or maybe they do... but only in IE, not Firefox, or vice versa...

What a nightmare...

This is why I'm impatient to start playing Silverlight 2.0... in the world where an element that is 100px wide WILL be 100px wide regardless of the freaking browser it's displayed in! And most importantly, where coding in C# in a browser will finally be real!

However, the downside of a full silverlight website will be that google won't probably index the content... and that some users using shady browsers/OS won't be able to see it...

</rant> :-)

It turns out... landing an airplane automatically is way harder than it seems... I've made some progress and changed the algorithm to another one that sucks even more...

I've come to realize that neither the angle nor the distance from localizer path are good approaches to the problem... The reason being because setting a rate of turn based on an offset doesn't mean that the airplane will eventually reach the approach path... it just means that it will end up making circles if the autopilot is turned on too far away from the ideal path...

One good thing though... the glide slope part seems under control, the airplane can reach the glide path quickly and maintain a constant descent rate...

The only problem is the localizer tracking...

What happens is that the airplane never reaches a stable state... and keeps oscillating around the localizer...

This can come from two things. I mentionned in my last post that this localizer tracking is made of a chain of 2 controllers. One that will take the error as an input, and spit out the desired correction in the form of a angle to the bank angle controller...

The problem lies in one of those, or even both of them... and might also be caused by another external factor...

1: The bank angle controller might be too slow to correct and adapt to the value set by the localizer controller

2: The localizer controller might be setting incorrect values with too much magnitude to the bank angle controller... or it could even be constantly setting values which resets the bank angle controller, causing it to constantly trying to catch up...

3: The airspeed controller is enabled during the approach. It is set to 65kts, and the flaps are fully extended. It's a given that the slower the air speed, the slower the airplane will react to control inputs and might have a tendency to become unstable and over-do everything...

I couldn't rule out any of those 3... It seems indeed that the regular heading controller also has problems stabilizing to a heading at 65kts and full flaps... But it gets much closer than the localizer controller...

It's not easy to figure out what controller is the culprit... Just tonight, when I was verifying the heading controller capacity to maintain a heading at a given speed, I noticed that the altitude controller had a tremendous amount of pain reaching the set altitude... Thinking that the culprit was the altitude controller, I started tweaking its parameters but nothing really stopped the oscillation around the defined altitude... In fact, the problem was because of the climb rate controller that had its derivative constant set to 0. The derivative constant playing a major role in stopping oscillations, it being set to 0 was not going to stop anything from going up and down :)

Oh well, I'll try again tomorrow... although I think it's not really worth it... The current algorithm for approach tracking doesn't seem very useful anyway... I've got some other ideas... and perhaps I'll find the motivation to read that paper from NASA about the Microwave Landing System which seems to have quiet a bit of information on how to approach the localizer and glide slope and follow it to the runway :)

Here's a video of one of the automated crash landings... autopilot is automatically turned off upon touch down... the rest was manual :)

To be continued...

The focus lately has been on improving the flight model of the Cessna 150... But I also worked a bit on some refactoring in the flight model like setting individual autopilot settings for each aircraft, making the flight model editor a bit easier to use...

Tonight, I played a bit with the autopilot and I wondered if I could use this system to make a fully automated landing system... This would be kinda cool to watch the airplane land on its own... I have all the peices in place to maintain a constant speed, a rate of descent and a heading or bank angle, which are the 3 components needed for an automated landing...

I started with the basics. Figure out what the aircraft position is with regards to the glide slope and localizer. (vertical and horizontal planes on which the aircraft has to be aligned when on a proper path to landing).
I had to use a bit of simple math for that to get the console to output the correct values.

There were several steps involved:

First one was to calculate the vector that would be the ideal glide path to the runway. Having a complete internal database of the currently loaded airports, this was pretty easy. I just had to substract the positions of the runway ends to get a vector coming from the approach end of the runway and pointing away from the it at a slight angle (5 degrees).

Then, the autopilot needed the angle compared to localizer.
This was done by calculating the dot product of the glide slope vector and another vector that comes from a substraction of the aircraft position and the runway threshold.

Then, to figure out if the angle is negative or positive, the trick is to compute the cross product of the same two vectors and then the dot product the resulting vector and another reference vector (the Up vector in this case). The sign of this dot product tells us if the calculated angle is positive of negative.

Of course, the two first vectors needed to be flattened to the ground (y = 0) so that the initial dot product only returned the angle on the horizontal plane...

Once this angle was computed, the next step was to compute the same but for the altitude difference between the ideal glide path and the current glide path of the airplane...

This one was a little trickier... Like the first one, I needed to "flatten" the vectors so that the angle would be accurately calculated and only the vertical difference in the vectors would be calculated by the dot product. The tricky part is that for this one, since the glidepath vector can have any direction I couldn't just set one of the components to 0.

The solution was to project the aircraft position on a vertical plane formed by the glide slope. Once projected this point could be used to compute the dot product between the glide path and the vector from the runway threshold to the "flattened" aircraft position. Same trick of the additional cross/dot is used to figure out the sign of the angle.

So these vector maths gave me 2 values. The localizer angle difference and the glide slope angle difference...

The next step was to plug in a couple of those PID Controllers I mentionned in a previous blog post. The autopilot had the following PID Controllers available at the time:

• Bank Angle Controller
• Climb Rate Controller
• Heading Controller (using the bank angle controller)
• Altitude Controller (using the climb rate controller)
• Speed Controller

The two new ones I added are:

• Glide Slope Controller (keeps the aircraft on the right descent path)
• Localizer Controller (keeps the aircraft aligned on the runway)

The first controller takes care of the vertical control. Its job is to adjust the rate of descent by feeding the ClimbRateController the appropriate values.

The second controller is in charge of the horizontal alignement with the runway by controlling how much bank angle should be applied on the airplane. It does this by feeding resulting values to the BankAngleController. 

For this approach mode, I enabled an additional controller, the Speed Controller so I could leave the controls and let the aircraft fly on its own :)

Tweaking the controllers took a bit of flying to figure out the appropriate constants. I included the KML of the tweaking session so you can whitness the difference between the first sketchy approaches and the almost "perfect" ones:)

Two things I'm unsure about the current system:

• I'm not certain the current angle based difference is good for the localizer. Perhaps a distance based would be better. (distance from the aircraft's position to its projected position on the glide plane)
• I need to figure out a way to get closer to the runway with the autopilot on. In the video, I disconnected the AP just before reaching the pond on final as the airplane was starting to overcorrect violently. This is expected as when the aircraft gets closer to the runway, slight corrections of trajectory result in much bigger angle differences. This is why, at least for the localizer part as I mentionned above, a distance based technique might be better as oppposed to an angle based approach. When close to the runway threshold, the distance from the localizer path will vary much less than the angle...

I'll try that tomorrow...

Meanwhile, here are the videos/screenshots:

This one shows the Cessna 150 on the approach path. The autopilot is triggered just a few seconds after the video starts. Here is the KML file of this video with annotations. Controls are clearly visible in this video. They are a bit jittery... I'll try to fix this... But it shows that the controller actually controls the aircraft surfaces.

Here's another one with a practice landing as dusk... This video includes a great cockpit view with instruments and moving yoke/rudder pedals...

One last, completely unrelated... a Cessna 150 taking off :)

Notice in these following screenshots that I have added the possibility to load my GPS Tracker paths for playback in FSP.

I would like to thank all of you readers who commented on my last blog post, and wish all of you a happy new year!

I guess I'll just keep going and have fun with the simulator, cause it's really what it's all about :) About if and when I'll go commercial, we'll see how things goes...

Couple replies to the comments...

Tom:
"... sometimes i wonder where you keep getting the energy of doing this FSP stuff."

I honestly don't know... I guess it's similar to when some people spend countless hours on something they are really passionate about... (art, sports...).
One of the things I most enjoyed working on this past year was the autopilot. Having a completely autonomous system that can fly an aircraft with different altitude, speed, heading settings is something I'm really proud of. Check out this kml file, it contains an entire afternoon of the Cessna 162 flying around from airport to airport...
And coding this was kind of like being a real test pilot, taking off, switching on the autopilot and seeing what happens next... only in this case, I didn't risk my life doing it :)
The worst thing that could happened is a few hours of "but... WTF is the airplane doing this!! What am I doing wrong, GRRR!!!"
But when it works... that: "Yessssssssss!!! it finally works!!!, I can go to bed now..." keeps me smiling until I fall asleep :)

I'm not sure about that... hehe... Especially because being a marketing guy and a coder at the same time would be a big dilemma...
Marketing guys go around BS'ing about a product (ex: promising impossible crazy features...) to potential customers... Then, they come back to the dev team with the new features to be added, in the same time schedule...
I don't think I could do this to myself ;)

Also, it appears that, I don't write enough technical posts, I'll try to make an effort, I promise :)
Believe me, whenever I finish a cool feature, I always want to post a technical article about it...the major problem is that I code FSP mostly at night... which makes me finish things around 2am when I'm really tired, and all my energy is gone into the coding, and none is left for the blogging... :-)

The issue here, is that I always associate blogging with posting the actual thing on the blog whenever I'm done writing... And this takes time. So from now on, I'll try to use a deferred blogging technique like some people do, which consists of writing posts offline, and actually posting them online once they are ready. I thought google docs would be a nice tool for that purpose... we'll see how it goes...

---

I recently got a new aircraft, a Cessna 150K provided by a friend of mine with much better 3D modeling skills than me! (Brian Kumanchik who flies out of Columbia Airport in California. Thanks Brian!)

This is an important milestone for FSP as it is the first airplane that comes from a "third party" developer ;-)

The details on the airplane are amazing, you can even see the break pads and hydraulic fluid pipes... and the best part about this plane is that the interior is modeled. My previous aircrafts had interiors but since it has always been the hardest part of aircraft modeling to me, having a nice interior is great for once!

The flight model still needs to be tweaked, but since it's very similar to that of the SkyCatcher, there won't be much work to be done here...

In other news, I'm in the process of revamping the flight model editor. I hated its design and it was not very practical. For example, there was no way to edit both left and right wings at the same time. For example, in the case of wings and flaps, where the parameters are symmetrical, a change in one of the wings had to be propagated manually to the other one, and I always ended up forgetting to do it... which resulted in wrong flight model characteristics on one wing compared to the other...

I now have a grouping mechanism to simultaneously edit the flight characteristics of symmetrical wings.

You might wonder why I haven't grouped the parameters of symmetrical wings in the first place... the reason is because in case of failures, I want these to be independent. Say I have a broken flap, of a stuck aileron due to severe icing... I'd like the option to only have one of the sides impacted by the issue...

I tried uploading some vidz of the C150 but I struggled with the new very buggy youtube multi file uploader... so it didn't happen...

To conclude this blog post, here is a slideshow of the new Cessna 150K in FSP!