Endurance Flights

Time for some more flying lessons!

This time on a new location and with a new goal, to see how long can the plane be up and about.

One of many flights tested altitude endurance:

Flight path and accompanying raw altitude and speed data from the internal GPS receiver:

Two interesting things to note. First one is the altitude drop in mid flight below starting point, although the fly by was low before going for the elevated altitude, was still higher then the starting point, which clearly demonstrates the error with which the altitude in calculated. Still needing to be resolved.

And the second is the zero meters per second speed. While spikes over a hundred meters per second are an anomaly due to GPS accuracy changes, the zero speed readings are actually correct due to winds and the gliding nature of the plane, which was more then on one occasion caught in a wind which suspended it in place (once even moved slightly in reverse).

That's where this data comes in:

Also one of the challenges will be to try to detect those kinds of wind gushes trough the accelerometer and program the auto pilot to act accordingly.

And one of them tested just plain how long can the plane fly with half a battery:

Mandatory flight path and it's meta data for reference:

And accompanying accelerometer and orientometer data:

The thing learned is that open space provides a lot of maneuvering room for errors and until the issues with altitude, speed smoothing, force detection and the "wrap around" of orientation data is resolved, that will come in handy!

Interface Test - Inbound Serial

FlightGear control, this time over a cable from Android on serial protocol:

This means all the peaces to control the plane from the phone now work. Albeit still in a stage of development:


Unfortunately there are still some issues with buffer size and how audio is handled, resulting in minor odd delays here and there and an occasional corruption:


Next stop from here, optimization, autopilot programing and building of an serial servo control board.

Talking Droid With Data

Using the ability to dynamically generate audio stream from preset data samples (audio samples were substituted with raw binary data), it was time to pull out some useful information.

To test all required controls a GUI was designed to fly a virtual plane manually:


Orientometer inside the phone for elevator and aileron control, and two slide controls for rudder and throttle control:


Next stop, matching protocol declaration for FlightGear simulator.

Talking Droid on the Fly

New technology, new samples and dynamically generated content. It works so far:

It looks like it's repeating itself, but it's repeating itself dynamically.

Learning to Talk Droid

The plan was simple, prerecord audio samples corresponding to ASCII character and play them in a loop.

It turns out that the Android's SoundPool class makes everything easy but also completely useless! Whilst the initial problem of refusing to play audio clips shorter then 5 ms was "solved" by lovering the number of expected corrections per second, it also introduces a small delays in execution of sounds in succession.

While the initial delay of first sample being played to actually hearing it, thus getting the info out of the phone could be tolerated, the tests showed that there is also a delay up to 50 ms between sound clips played, being in succession or simultaneously.

Useful for game programing where there is a large number of sounds to manage and play depending on events, but using this for continuous operation would amount to unpredictable lag which would render the atempted correction useless.

Luckily with the Android version 1.5 and even more improved so in 1.6 came the ability to directly access the phones PCM stream, providing the ability to generate sound on the fly.

So the next solution explores this possibility and so far it's promising: