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:

Hiatus - Infrared Camera

This being a vacation project some interference from school work was unavoidable. So let's see one of those things.

For a bigger project a normal web cam was converted to record the IR specter of light.

A 2 MP camera was chosen because it was cheap, had high fidelity, was easily disassemble, had plenty of room in the casing for modifications and was supported on Windows and Linux:

Nothing against any other brand, just happens that CANYON's model CNR-WCAM420 got closes to this parameters.

Next steps are obvious - disassembly, getting rid of the IR filter on the lens, finding the right negative film strip and replacing the IR light filter with visible light filter made from previous selected exposed film strip:

This would give us a black and white to slight red tinted image, depending on the driver and it's white balance auto correction:


Next step was modding the case and designing an IR LED lightning to make it see in the dark:

To achieve this two narrow and four wide angle IR LED's were used and wired in to two arrays which were turned on and off asynchronously every 14 ms:

Couple last additions included changing and modifying the wiring of one of the blue mini LED's in the cam to red to only light up when the IR LED array is switched on and extending the casing to accommodate for the array switch with some clear Plexiglas.

Final result looking like this:

And was used like this:

Infamous "reversed polarity"

There were some problems with the analog to digital conversion board (the Demodulator).

Basically the sound input did not match expected bit output. And since we're fresh out on oscilloscopes, the next best thing was an USB sound card, baudline signal analyzer and a test signal composed of a start bit, all zeros and, stop bit and half a sinus wave for debuging:


From this it was discovered that for some reason the audio signal was inverted and (since WAV files shorter then 5 milliseconds weren't recognized as audio clips, so the rest was filled with silence) that the start bit should in our case be composed of two bits, first one setting the threshold to one and the second one to zero, so that the transition from hight to low will be registered (since it obviously does not from zero to low). Probably the same thing should be applied for "stop bit" as well.

All this means the audio samples containing bit info have to be regenerated and then can the module be retested.

Including GPS in the Mix

Processing new information brings new knowledge.

First things first, one absolute thing to avoid is putting the plane in the stall position. Listen to the sound of the wind just before the crash:

This includes aircraft speed and airfoil angle of attack (which is what happened in this case).

This set of experiences also includes aircraft dynamics such as roll and pitch tolerance during navigation maneuvers (using rudder for course correction puts the plane out of stable flight position), using ailerons for larger and faster turns (requires pitch and roll coordination) or climbing and descending (which was, surprisingly to me, more depended on aircraft speed then motor power or thrust).

And with GPS data we can visualize the flight and put it in to perspective:

The data indicates the flightpath was around 850 meters and it lasted for about 72 seconds. That puts the aircraft average speed at good 11 meters per second (40 km/h), which is consistent with the GPS measurements.

Next issue to solve is the GPS speed measurement spikes (accruing with the change of GPS accuracy or used used satellites in computing), which could be done with checking for accuracy changes and substituting with kalman filter values (to avoid needles calculations).

And the altitude offset (kind of important to know the correct altitude), caused by mathematical model used to calculate altitude from the center of the earth, with possible fix by manually adjusting for the WGS 84 model of Ellipsoid for planned flight path. Quick research shows that mathematical model of sea level in the Europe region is about 30 meters about actual sea level, combining that with (rule of thumb) 3 times the GPS accuracy margin, the GPS measurements came within map altitude. With enough altitude clearance probably good enough, but landing will take some more work!

Accelerometer and Orientometer sampling and smoothing is progressing well:

One thing left is to manage or wrap around the transitions in orientometer such as compass going from 350° to 10° trough North, which would be transition for 20° but is computed with kalman as transition for 340°.

"Demodulator"

When looking for alternate ideas to transmit data off the G1 other then the serial connection (which would require Linux kernel modification on the Android platform, but we're saving that for another time), the idea came to do it "old school".

So my electronically gifted little brother came up with this design:


We output plain pregenerated analog audio signals describing bits with the same modulation as the serial line to an amplifier and a micro controller which in turn converts them to the digital serial stream.

P.S. First test was done using the Christian Bale Terminator 4 outbreak remix ... looks like swearing would look like a string of p, @ and P characters :P

Learning Kalman Filter

After some research for what and advice for how, the data smoothing will be done with Kalman filter.

Some filter modeling tested in Octave:

Filter modeled to trust sensor measurements over state prediction (motor off) .

Filter modeled to trust state prediction over noisy measurements (motor on).

Next stop, implementation in to the sensors app, check time complexity and take measurements with known positions (for reference and better filter model) for dynamic adaptation.

Flying Lessons - How Not to Fly

Every one likes videos, so here are some examples of how not to fly:

Things learned include:

• Center of Gravity! (Specially when the plane has taken some damage already. Nose heavy will cause it to stall, tail heavy will cause it to turn over when turning using rudder)
• Different trim values required for flying with motor on or gliding with motor off (flying straight when motor on, will cause it to turn slightly right when gliding with motor off)
• Perception! (Plane flying towards or away. Successfully stabilize the plane first, attempt maneuvers later)
• Taking in to account speed gains when dropping plane. Also speed losses when climbing.
• Trees! (Sometimes getting the plane down damages it more then the crash itself
• Response delay introduced by various elements (crosswinds, momentum, servo delay ...)
  

On a side note, the plane was named post usable service as AVI@TOR 01 (Aerial Vehicle Intended @(Academic Testing) Or Research).

Flight No. 10 - Data Analysis

One more flight with interesting data, now visualized for better understanding.

Flight video, which unfortunately ended in a tree:

The raw sensors data was smoothened using GNU Octave (language for numerical computations) Data Smoothing Package to clean the raw telemetry of noise (vibrations, sensor deviation, ...) and then the smoothened values plotted against raw values.

Orientometer data with smoothed and raw values:


Accelerometer data with smoothed and raw values:


Next the smoothened data was visualized and animated (using Octave and imageMagick) for better perspective and to be checked against the flight video to see how it matched.

Orimetometer data visualized and animated:

Accelerometer data visualized and animated:

Next step in sensor telemetry would be to implement the real time data smoothing in to the sensor software.

Flight No. 9 - Sensor Telemetry

With the "Crash O Meter" app loaded it was time for almost fully equip test flight.

First two small "jumps", to shake the sensors and get some baseline readings, then a short flight with a violent landing:

Accompanied accelerometer data:


Accompanied orientometer data:


And since the plane was still flyable one more try with SonyEricsson C702 phone, just for fun:

Sensors App - Crash O Meter

No denying it, the "landings" are still hard, so this would be a good time to finally use the sensors on G1 and get some data:


After figuring out Services on Android, a quick app named Crash O Meter was hacked up to record onboard sensor data in to a coma separated file (CSV).

Flight No. 8 - Where all Things Come to Die

Was actually a huge success!

A whole training circle completed before a mistake related to perception (plane facing toward the pilot would perform left banking maneuver with aileron control pushed to the right), resulting in almost total destruction:

At this stage the cockpit is composed mostly of glue.

Flight No. 7 - Training Wheels

Some thing felt strange, so to test them out the plane was "pimped" with some training wheels for "on the ground" training.

Good thing too, since it lead to the discovery that the elevator was wired reversed and with that the ailerons might actually be useful for roll correction.

Flight No. 2,3,4,5&6 - Beginers Mistaks

A few quick Throw -> Crash -> Glue sequences to get some experience.

Unfortunately one of them ended misfortunately:

Resulting in a broken plane, broken glasses, scraped elbow and broken transmitter antenna.

But there was also a very important lesson learned! A plane carrying three quarters over designed weight requires some work on launching technique, namely with 951g (where's recommended weight being 650g) a lot faster starting speed is necessary to swing it in to stable flight.

On a plus side, there was a cool looping performed before the last crash.

First Flight - Manual

Status before the first flight:

First flight was supposed to be without any payload for reduced weight and increased maneuverability, but I misjudged the extra weight of the heavier wire used because of the motor, so the plane became nose heavy and the fort three attempts at flight looked like this:

After adding the payload (namely the G1), the center of gravity was restored and the plane took off. But it started immediately turn to the right (miss adjusted rudder) and here I made my first piloting error. In the attempt to level the plane with the elevator I accidentally also moved the aileron control (located on the same controling lever), causing the plane to bank and crash:

Resulting in this:


Things to be considered before the next flight:

• readjust the rudder for the extension
• increase the speed/strength of the plane launch/throw
• increase tail weight or decrease nose weight
• stronger propeller attachment (came lose after every crash)
• move or remove aileron control pending more experience
  

Assembly and Modifications

So, the fun part began ...

First of the fabrication of motor mount for stronger outrunner brushless motor, to compensate for the intended extra weight.

Next the carving of the airframe to create the extra room for the motor mount, stronger wires and the payload area.

Following by the modification of the wings with the aileron mod, which consisted of mesuring, cutting out the aileron plates and carving out the servo space.

After all the cutting and carving came the gluing phase. Pretty straight forward, airframe, elevator, rudder, payload door. Some deprom foam was added at the cut out edges of the payload door for a tighter fit, since cutting them out weakened the airframe. Also, the rudded was extended to give it more authority to cope with the increased weight and stronger motor.

On the wings, the aileron plates were attached with enforced paper strips, connected with a steal wire to the servo motor and the connecting control wire glued inside the wing withing the hole for the reinforcement tube.

After it all set, came the carving of a tight fitting space for the G1 and the motor regulator. Once it all fit together, were the payload doors equipped with a strap made from duct tape and secured with Velcro.

Obligatory electronics test and color coding of the wires. Interesting fact: 250W old computer power supply did not produce enough current to start the motor, so the test was servo mechanism only and as a result motor connections were color miscoded.

After weiring it all together and performing another test with a charged battery, the polarity of the motor was corrected and with the 803g without payload and 1047g with was ready to fly.

No markings or tail number as of yet due to a writers block in the naming department.