There was a NOVA episode about this crash (an earlier commenter linked to it, but here it is again: http://www.pbs.org/wgbh/nova/space/crash-flight-447.html).

I won't go into the findings of the NOVA team, but I will point out that your educated guess is completely wrong.

The airbus does have a considerably more advanced and automated autopilot system than Boeing provides. However, that only is engaged during "Normal Law" flight. When any of the sensors on the plane detect a fault, an alarm chimes, and the system informs the pilot that "Alternate Law" is engaged. In Alternate Law mode, the pilot is allowed to use the full control capabilities of the plane, not the restricted range that the sensors believe to be safe.

After alternate law engaged, the pilot can control the engines, and all control surfaces to whatever degree of capability he'd like. The plane in question definitely switched to Alt. Law mode; this fact was radio broadcast back to the Airbus HQ shortly before the plane disappeared. There's a high probability that the pilot was mislead by weather radar readings that said that he could shoot through a "hole" between two storm clouds, but which masked the fact that there was a third (much larger) storm further beyond. Once he was stuck in the middle of all those storms, it was game over.

The pilot and the passengers were not at the mercy of an autopilot that refused to allow corrective action; it is probable that bad data presented to the pilot did not allow him to correctly act.

I doubt this has to do with ITAR. I've worked on a DARPA-funded project which was covered by ITAR restrictions. I did not need to undergo a background check; I just needed to demonstrate American citizenship (read: show my passport to my boss).

You say that you're writing a lot of "C-like" embedded C++. Are you doing fully OOP style coding and using 'new' and 'delete'? Or are you mostly taking advantage of conveniences like namespaces, scoped variable declarations, etc?

If your code is really more C-ish, you could take a look at the Apache Portable Runtime (http://apr.apache.org/). The APR is the library that Apache httpd is based on; they cover most system-level utilities (sockets, files, etc) you could need in a portable way. The APR is more 'C-like' in that a file descriptor is an opaque handle which you pass in to functions like apr_file_puts(), etc., rather than doing the C++ thing of file->puts()..

But if you're ok with the syntax, it's Apache licensed (corporation friendly), well tested (httpd is pretty ubiquitous after all) and actively maintained.

Millions watch it every day. And take what they say seriously. The 30 minutes you saw were probably representative of the whole day. The talking head changes, the unapologetic agenda they advance doesn't.

I used to work on autonomous UAVs as an engineering competition project in college. This was a couple of years back, so the technology's probably changed a bit. But here's some advice to get you started.

First of all, I would not bother trying to program the entire system myself. There's an awful lot to do, simulation is challenging, and failed tests are expensive and will set you back a lot of time. So you should focus on integrating existing stuff as much as possible. There'll still be crashes/failures/etc, but it's more manageable.

One UAV autopilot was called the MicroPilot (http://www.micropilot.com/). This worked okay, but as of 2005 had really terrible documentation and the UI would let you set certain controls to invalid settings, leading to some problems. So double-check everything on the flight line. The MicroPilot was based on the "Magic" board which contained GPS and gyros and an FPGA; you could in theory program that yourself. I can't find this board in a quick Google search, but it's out there somewhere.

Another competing brand was called the Kestrel. Haven't used it, but know that others have had success. (http://www.procerusuav.com/productsKestrelAutopilot.php)

Other similar things to look up are "FMA Co-pilot" and "picopilot." These are not fully-integrated GPS/gyro/altitude/controller setups, but they can work with external gyros to maintain straight and level flight, etc.

We had good success getting "flying wing" foam airplanes to fly stably under autopilot. A more "traditional looking" plane has lots more room in the fuselage for components, but they're harder to fly. A fat foam wing can fly very stably; a fuselage can be built down the centerline, and some components can be embedded into hollows in the wing. If you do this, reinforce the wing with carbon-fiber spars. We used a custom design based off of the MotherShip (http://www.flyingfoam.com/products.html) because we needed additional lifting capacity. We added a tail-prop electric motor to this. Buy that from a hobby store, as well as the ESC.

Gas engines are also available, but you can't do that with a flying wing; you'll need a fuselage to hold a fuel tank. Gas engines are a bit more finicky than electrics, but can provide more overall lifting power.

We transmitted video via a Black Widow (http://www.blackwidowav.com/) AV transmitter. It was hooked up to a relatively nondescript digital camera and transmitted a TV signal back on UHF; we could watch this on a TV powered by an inverter off a car battery in the field.

A small embedded controller (e.g., an Arduino) would be useful to program for operations like managing a high-resolution camera. If if can also read in data over a serial port, it can be interfaced with the micropilot to provide higher-level operational instructions (e.g., download new mission goals). A micropilot will keep a log of all its sensor data so you can review it afterward. This is valuable for tuning the wing.

You can build a gimballed camera into the bottom of your plane without much difficulty; hook up those servers to the aileron servos, but wired in reverse.

One project which was difficult to make work was bilateral communication with the airplane. You'll of course have your primary RC receiver on board to allow manual takeover of flight control, but talking to an on-board Arduino is challenging. You'll need some sort of radio modem. We tried serial radio modems that operated at 900 MHz and 2.4 GHz, but usually encountered unacceptable signal corruption / interference to make this practical. Modern hardware may have eliminated the design flaws that we saw 5 years ago though.

Good luck with your project!

And that, boys and girls, is why financial institutions and other things with real-world consequences are in the world of *adults,* and not third graders. Seriously, if you make "April Fools Day joke trades" with your retirement fund, your really do deserve exactly what you get.

If you press the little button in the lower-right corner of the screen, and then select "list" mode, you get turn-by-turn directions.