Hi folks,

Time for an update on my Android-powered fixed-wing drone project, which I’ve just picked up again after 1.5 years of neglect.  After trying a few different approaches, I’ve come up with a fairly simple auto-thermaling algorithm which works very well. The glider flies itself up to 200 meters AGL, then cuts power and drifts around within a 200 m geofence until it finds lift (or gets too low).  On finding lift it calculates the approximate core of the thermal and attempts to follow it as it drifts with the wind.  Provided the thermal is strong enough to keep my heavy junk afloat, it generally succeeds and keeps going up until the thermal drifts away and it hits the edge of its geofence.

I fine-tuned it on virtual x-plane thermals before testing it on real ones.  Some real-world results are shown above.

If I let it keep going, it would probably continue climbing until the thermal topped out.  Maybe one day, in the middle of no-where, with telemetry and a camera or two.

While the android setup does work well and has novelty value, it is heavy, clunky, not a real-time OS, and involves a potentially flakey Bluetooth link.  So I’m looking at moving to either an Ardupilot or the Matrixpilot/UDB, and porting my thermaling code over.  If anyone else out there is working on similar systems on either of these platforms, I’d like to bounce some ideas around. 

Here's a fun little project I've been working on for ~6 months now.  It started when I looked at my phone and thought this has everything needed for an autopilot - 3-axis gyros, accelerometers, magnetometers, GPS, fast CPU, plus a nice big touch screen and more wireless modems than you can point a stick at.  The only problems are (1) it's a multitasking operating system, not real-time; and (2) needs extra hardware to drive servos and switch between manual and auto control.

I solved the first problem by buying a used Samsung Nexus S with a faulty screen (discolouration) on ebay for $80, installing a stable, bare-bones version of android 2.3, rooting it, and disabling CPU throttling.  50Hz servo update loops and 110Hz sampling loops are no problem - timing is reliable and it only uses ~5% CPU (using floating point everywhere and some bloaty object-oriented code). 

Second problem was solved like this:

The Ardupilot legacy board doesn't actually run any ardupilot code - it's just a convenient and cheap way to get an Arduino and a multiplexer.  It just takes servo commands from the phone and uses the Arduino servo library code to drive the servos.  Most of its time is spent sampling the baro sensor.  It samples at around 20kHz, and using 4096x oversampling I get 4 16-bit samples per second with an altitude resolution of around 15cm and noise of about +/- 30cm.  The bluetooth link looks scary but works fine.  It's done about 10 hours of autonomous flight with no issues, and only drops out if I take the phone at least 10 meters away from the plane. 

Waypoints are selected on a google map interface:

Gains etc can be easily adjusted:

And, of course, a flight video:

Behind the scenes it runs the DCM + complimentary filter code.  I've added some extra features over the last few months:

Autonomous thermaling (works well in warmer weather)

Hardware in loop simulation with X-Plane and MS FSX over WiFi

Wind and airspeed estimation

Dead reckoning (using gyros/magnetometer and estimated speed - can work through short GPS dropouts)

Android-to-Android Telemetry over WiFi or mobile internet (later requires sim with public IP - hard to find)

Features I plan to add:

Waypoint addition/modification from Android groundstation (if/when I can convince a telco to give me public IPs)

Fly-by-wire(less) over mobile internet (ditto)

Photo/video taking at specified locations with onboard camera (will require mounting under wing)

I'll post about some of these over the next few weeks.

Hi folks,

I've been working on a small C# program to enable hardware in loop simulation with FSX.  It's working nicely now, so I've posted the code up at http://code.google.com/p/fsxio/

I've been using it to test my Android autopilot (subject for another blog post when I get around to it), but I've designed it so it should be easily adaptable to other projects.  It communicates with FSX using the simconnect API, and sends the sim data via UDP using the X-Plane 10 binary protocol, with the same units and axis conventions as X-Plane (so I can re-use the same parsing code). Only difference is instead of a "DATA" header, it sends "FSX!" in the first 4 bytes of each packet.  The sim data output in this version are: latitude, longitude, true altitude, groundspeed, indicated airspeed, body-fixed-frame accelerations, body rotation rates, roll, pitch, true heading, magnetic heading, and gps ground track.

For input, it listens on port 49005 for incoming UDP packets, and sends the received aileron/elevator/throttle/rudder positions to FSX.  I use the mini-SSC protocol for the control data, because it's really simple (255 for sync byte, channel from 0-3, position from 0-254). 

Data are sent each simulation frame, which is usually faster than the graphically rendered frames. Ideally FSX simulates at 63 hz, but sometimes dips to 40-50 hz on my core2 duo machine.  I couldn't figure out how to get useful body-frame accelerations directly from FSX, so instead I take the world velocities, differentiate to get accelerations, then build a rotation matrix with the sim roll/pitch/heading, and rotate the earth-frame acclerations into the body frame.  It's a bit inelegant, but works well.  There is some noise on the resulting acceleration values, but it's less than a typical MEMS accelerometer and works fine in the DCM algorithm.  I've also included a simple model for gyro noise and bias drift.

If you want to play with/modify it, check out the entire directory and it *should* compile....

Here's a quick video of the setup doing it's thing: https://www.youtube.com/watch?v=zdPcyU4q6AQ&feature=youtu.be