Blogs

Finally caved in & built a traditional rotating actuator.  Didn't like
the weight or complexity of these, but they're the only way to keep the
distance between coil & magnet constant throughout the motion.  Having a
minimal distance between coil & magnet is where the maximum force comes
from.

The test article was made from balsa.  Medical tape once again came in
to shield the mechanical shaft from the wire.  It has 3x more wire than
actuator #1.

It certainly caused a lot more motion, but yet again, not enough force
for a full wing actuator.  Forget about moving the entire wing in our
mass budget.  Variable pitch is out.  It can move a 1" x 13" x 1/16"
flap against gravity, for a short time.  It might work in a ducted fan
VTOL.









Next, another solenoid with the 1" flap.  Pretty good deflection with
this one.  Quite an alignment problem.  The permanent magnet needs to be
halfway down the solenoid to get the most thrust.  Any lower & it's
attracted downward.  Any higher & it's not deflected as far.  This leads
to a gnarly wing stand.

Really disappointing to not be able to move the entire wing, but that's
why we don't have variable pitch wings on airliners.

Thus begins another round of solenoid tests with 1" flaps & another $2
of magnets.  A vi ate ing does suck money even without any flying.



Efforts continue on improving radio weather resistance with
polyeurethane.



The 900Mhz Marcy 1 ground station sees daylight again.



Marcy 1 flight computer, covered in dust, insects, & polyeurethane.



New wing attachment required some fancy woodworking.



Didn't like this wing attachment, but it was the only way.



To fit the solenoid in.  We do not claim any crash resistence.









This one stayed up for 6 seconds at 3.3V before the TO-220 voltage
regulator fell over.  With this kind of Amp suckage, you're not likely
to get an increase in lift without a decrease in motor output.  Next
comes making a more efficient actuator.



Straight from RCGroups lore, it's CA glued pieces of plastic.







This 4ohm 4g monster held for 10 seconds at 3V.  It even actuates at
2V.  With BJT + magnets, it probably weighs over 6g.  BJT's serve us better than

MOSFETs because they can handle back EMF.

The smallest servo is the GWS Pico, weighing 5.4g.  That could move the
entire wing, but burns out quickly.  The only other redeeming quality of
actuators is the price.

The main drag on this operation is the fact that actuating the wing is going

to suck a lot of power.





Next, in the Marcy 1 weight reduction department, it's spray paint
stenciling.  That was real unpleasant to carve out.





It's very inconsistent.  We have many wings yet to crash.  Should have used
transparency instead of paper.  The lighter the spraying, the better.  1 pass is all it can handle

before it bleeds.

A new board for Vika 1 started.



This one's intended to minimize GPS interference.  It has a shielded
oscillator at 40Mhz.  40Mhz is the dead zone.  It was the 1st Vika 1
board we ever laid out.  It was laid out in 2009, before Major Marcy, & before

we were confident in crystals.



There's nothing new in it.  Once again, forgot to put the GPS voltage
converter on it, provide enough pins for everything, provide capacitor
pins.

It's exactly 1 year to the day since the 1 & only time Major Marcy said anything to
us in real life.

It's a dark anniversary.  Now that 1 year has passed, it really is
final.  There was a bet whether we'd ever be in a photo with Her.
Mathematically, it seemed likely, 1 year ago.  It never happened. 

While She was very reclusive, only associating with a handful of people in real life,

was really freaked out by men who didn't demonstrate traditional male dominance,

it was the laying of a very negative judgment on our work to have a heroine Air Force

Major want nothing to do with us.

From the video description:  "Northrop Grumman video showing its Proteus manned test aircraft (left) and a NASA Global Hawk unmanned aircraft (right) conducting the first simulated autonomous aerial refueling at high altitude. Proteus (acting the the tanker) and the Global Hawk (as the receiver - its the reverse of the normal way) flew as close as 40ft apart at an altitude of 45,000ft in a risk-reduction flight for the US Defense Advanced Research Projects Agency's KQ-X program. Wake turbulence between the aircraft as well as engine performance and flight control responsiveness in the stratosphere were evaluated."

{via Robots.net}

First bit of work: software setup.

Please take a look and let me know what you think!

http://code.google.com/p/ardupilot-mega/wiki/BeginnersSoftwareSetup

Hello Guys,
I am here for the latest update, I would say that many were waiting ... We are finally back to fly .. it starts from where I stopped with QuadFox V3, but now with much more power 'you can use to fly our beautiful quad.
What I posted and 'the first official flight after the failure of Sunday's pre-flight test due to malfunction of the GyroZ OilPan, promptly replaced by Jordi , thank you Chris and Jordi for your support ,Diydrones of which' was timely in sending, sent from the United States Sunday arrived today mounted and here is the first flight. Only preliminary tests. I used the firmware version published Sunday .I put new IMU and flies as I suggested no major problems except the ones I had already' seen in pre-flight test, but going to be solved improve some operations, particularly the libraries that I rewrote the management of the radio, the problem I have is' above them.
The test that I did use Arducopter NG 32, Multipilot32 as CPU, OilPan as IMU, ESC Chinese engines from 6 € robby recovered from my old mk, rx Graupner 12 ppm scan analog output sum .. 3S 20c Lipo Battery
I also remember that for those interested in doing another online seminar tomorrow on the product roadmap of Multipilot32. I predict that the stable version for standard users will be 'available within a month of work today. The actual and the 'pre alpha version only for Developer and Hard coder who know what they do when they hold a pre-review software.
I put online the RoadMap presentation , this is the link

http://www.virtualrobotix.com/profiles/blogs/arducopter-32-roadmap-webinar

Greetings
Roberto

I finally managed to fly with APM on Sunday. Here are some photos and a video of loitering. Well, it was flying a pattern which first looked like a figure 8 and then the olympic rings. Any idea why? Will check everything again and fly a real mission when I can.
Preliminary conclusions: Manual mode is good, stabilize is very convincing, FBWA and FBWB work, loitering must be checked. PID parameters appear to be reasonable, no sudden movements.

It was awesome to have the model fly with me hands off for the first time!

The setup:
Reichard Proxima II glider, 2,78 m wingspan.
HS82MG AIL and FLAPS, HS65HB ELE and 9g cheap servo for RUD.
Dymond AL3548 outrunner 630 watt, 900 Upm/V and 60A Dymond regulator.
11,1 V 3300mAh LiPo battery
13" x 6,5" folding propeller

Radio:

Futaba T8FG with RH6008HS RX
Ch1: AIL with Y-cable
Ch3: Motor
Ch4: ELE
Ch5: RUD
Ch6: Flight mode control
Ch7 and Ch8: Flaps, not connected to APM but directly to the RX.

APM:

APM, IMU, Mediatek GPS MT3329, XBee 900MHz wire. Powered by a separate 1000mAh LiPo at 7,4 V (solder jumper removed).

Portable PC ASUS Eee 1000H with XBee 900MHz&duck antenna and HappyKillmore's GCS (that I can't look at when I'm flying anyway).

FlycamOneIII

Next improvements to be done are:
Connect the airspeed sensor.
Find a better way to mount the APM and associates under the hood whilst maintaining access to buttons, connectors and view of LEDs (transparent hood, holes).
Sort out the chaos of servo-cables in the fuselage.
Variometer based on a high precision pressure sensor, I2C/SPI.

Other issues:
Flaps are controlled manually on two separate channels to slow down for landing. It would have been nice to have differential ailerons, but I understand it's a matter of priorities. None of the other mixes (e.g. butterfly) will work because of the y-cable so we might as well accept to live without them in the APM domain, for the time being.

The model is quite beaten up, it has 55 hours of flying on it and a few crashes too. A brand new copy sits in the basement and will be used to build a perfect Proxima with APM when all tests and trials are completed. I will come back to you to discuss particular technical issues in the appropriate sections of the forum.

Cheers from
Parapendioper, Italy.

InvenSense MPU-6000

I think it's perfect!

Specs:

- Tri-axis gyroscope and tri-axis accelerometer in one package

- Programmable scale ranges:

    - Gyro: ±250, ±500, ±1000, and ±2000°/s

    - Accelerometer: ±2g, ±4g, ±8g and ±16g

- Output: rotation matrix, quaternion, Euler Angle, or raw data format

- Digital Motion Procssing (DMP)

- 16 bits DACs

- Sample rate at least 1 kHz

- Digital temperature sensor

- 400kHz FastMode I2C or SPI

- Support for external I2C magnetometer

- No need for calibration

- Support for programmable interrupts

- Price: $15 (1-99)   Farnell: 43,33 € (1-9)

- Size: 4 x 4 x 0.9 mm

Trimming is an important part of control design. By finding natural equilibrium points in a system, less control effort is required to keep the plane flying as desired. This software lets you compute trim points for aircraft ranging from the easystar and quadrotors to f16's and 737's. Anything that can be modelled with a JSBSim model will work.

There are many JSBSim models already developed for flight simulators like FlightGear that can be used as low fidelity models. For higher fidelity models, wind tunnel data can be used within the JSBSim file as done with the easystar model in mavsim. All of this software is open source and available for download.

download: https://github.com/openmav/mavsim
wiki: https://github.com/openmav/mavsim/wiki

If you find any bugs please post them here:
https://github.com/openmav/mavsim/issues

Here's a cool new product from the Maker Shed: Blink RC. It's a wifi-to-RC board, which can let you replace your RC gear with a smartphone or other wifi-enabled computer. From the announcement:

The BlinkRC from the Maker Shed replaces your standard remote control receiver in your car, plane, or boat, and allows you to control it with your smart phone. The more adventurous can try creating an application on your computer that takes advantage of the open messaging protocol and the BlinkRC’s (3) output channels and (2) analog input channels. Now you can control a variety of different servo’s and sensors from almost anywhere that has WiFi or Internet access.

A few thoughts:

1) Looks good! But...

2) $125!!!

3) Wifi range limitation makes it inappropriate for most aircraft applications

4) Not open source :-(

Here are the full specs:

• 802.11b/g/n connectivity
• Onboard low-profile WiFi chip antenna
• Onboard U.FL-R-SMT-1 external WiFi antenna connector
• Infrastructure or Ad-Hoc Modes
• Transmit range up to 330' depending on environmental / antenna considerations
• Requires 3.5vdc to 5.5vdc regulated input (typically from ESC)
• Three (3) Output Channels for Servo/ESC control
• Two (2) 0-20v analog input channels with 8-bit resolution
• Reverse Polarity Protection on Battery input
• Optional plastic enclosure
• FREE download of iPhone controller app
• FREE download of PC compatible controller app
• FREE download of Droid controller app (coming soon)
• FREE download of Blackberry controller app (coming soon)
• Dimensions: 2.8" (L) x 1.0" (W) x 0.25" (H)
• Weight: Approximately ~4oz
• Outputs: Three (3) Universal/Futaba J Style Connectors
• Inputs: Two (2) .1" Header Connectors w/ +5V and GND Available for Sensors

The MAVLink mailing list is currently very actively discussing which route to take to CAN-MAVLink integration. Especially engineers working in their day jobs on ARINC 825 or CANaerospace could bring important feedback to the table, so please share your knowledge.

Google Groups MAVLink CAN discussion

 Since this design will be very likely the reference design not only for the first 2-3 autopilots implementing it, but might also become the DIYDrones community standard, I'd like to invite all potential developers and adopter to join the discussion (on the mailing list please, not in the comments).

Further reading:
http://de.wikipedia.org/wiki/CANaerospace

http://en.wikipedia.org/wiki/ARINC_825

Hi Guys I have for some time been developing this flying camera, I say camera as this is a departure from the norm. Whereas most people make a copter that just happens to have a camera mount this is different. The operator fly's the camera and the uav follows the envelope that is required to stay within the shooting angles selected. I am new to arduino so any help is what I need most. It has a number of other features such as the ability to land on water.

Hello,

I'm still working on my Interception/Injection board for my Spektrum Dx6i, here is the news :

• the interception is working like a charm, I can monitor all of the 6 channels on the groundstation (the 9 gauge on the left), It can be plugged to usb or over bluetooth.
• the flying board is (for now) equipped with GPS an a 3 axis accelerometer (gyro is on the way)
• both boards have a rfm22 (the same used by OpenLrs), for now only the flying board is transmitting the GPS and the Acc data.
• First try developping a quick GroundStation as demonstrator, with horizon, altimeter and speed, Acc Data and even a google map ;) The GS is working on Win32 and Windows mobile, I'm planing on porting it on Android when I'll have an Android

Hi Guys!

If you have not seen this yet check it out!

It is the Devil Ray 2.4M flying wing  made by Chris McNair.

We asked him to make one for us to use in the Australian Outback UAV Challenge. And before you ask we have an ATTO IMU onboard!

The Devil Ray has the option of 3 different wing sets 1.8m, 2.4m and a 3.6m. (We have the 2.4m)
With all the extra gear needed for the OBC, PTZ camera, 500ml water bottle, failsafe systems, transmitters, modems etc..
We loaded it up to 6.75Kg total weight. With all this extra crap on board it still had a easy take off and climbed nicely.
I still remember being impressed that even in manual mode (just over half throttle) it was doing 90-100Kph and was only pulling 15 amps.
(This is better in Autonomous!) We have a 6S 10,000mAh pack on board.
It has a very large speed envelope and handles great in the air.
The marked CG point was perfect and there is heaps of room inside which made it easy to balance. Landing speed is a crawl and has proved to be easier than the 12’ Telemaster to land.
I have an attached a couple of photos below.
I know Chris has refined the design (since making ours) and is now selling them with multiple options ranging from marine application that is water proof to a retract landing gear option for clean smooth flight.
The fixed landing gear option is nice but does add a bit more weight due to the very large wheels for our flying fields.
The Devil Ray is definitely worth having a look at if you are in the market for a high efficiency flying wing with a very large payload bay.
It also brakes down into a nice size carrying case or box.

If you like what you see you can contact Chris at chris@attopilotinternational.com as they are now available.

Cheers

Scott (Melbourne UAV)

www.melbourneuav.com

www.twitter.com/melbourneuav

The Willow Garage team who are running the Robot Operating System (ROS) project posted today on the MAVLink integration with ROS that you've been reading about here for a while. What it means is that MAVLink-compatible autopilots (including ArduPilotMega now and the UAVDevBoard soon) can serve as ROS nodes, which will allow for easier multi-UAV mission control and coordination with other robot system.

From the post:

Users of Micro Air Vehicles (MAVs) will be happy to hear that the MAVLink developers have released software for ROS compatibility. MAVLink is a lightweight message transport used by more than five MAV autopilots and also offers support for two Ground Control Stations. This broad autopilot support allows ROS users to develop for multiple autopilot systems interchangeably. MAVLink also enables MAVs to be controlled from a distance: if you are out of wifi range, MAVLink can be used with radio modems to retain control up to 8 miles.

#set filesystems from read-only to read/writemount -o remount,rw /

#set the date and time
date -s "2011-01-31 20:58"

#extract Perl binaries
cd /mnt/usb
tar xfz usr_arm_ext3.tgz -C /mnt/storage
#create a symbolic link to the storage directory for binaries
ln -s /mnt/storage/usr /psp/usr

#add the symbolic link to the global PATH variable
export PATH=/psp/usr/sbin:/psp/usr/bin:$PATH

#extract Python binarries (appears to actually be 2.6.3 --whatever)
tar xfj python_chumby_2.7.1.tar.bz2 -C /mnt/storage

#copy and extract toolchain from silvermoon
#might work for falconwing, not sure yet (it should)
#cp /mnt/usb/silvermoon_toolchain.sh /mnt/storage
cp /mnt/usb/falconwing_toolchain.sh /mnt/storage
cd /mnt/storage
./falconwing_toolchain.sh
#./silvermoon_toolchain.sh

#move back to usb and extract openssl
#NOTE: aircrack-ng uses functions that were deprecated in openssl v 1.0.0c
#Use version 0.9.8q
cd /mnt/usb/
tar xfz openssl-0.9.8q.tar.gz -C /mnt/storage

#move to openssl-0.9.8q and config
cd /mnt/storage/openssl-0.9.8q/
#use the prefix to store the binaries on /mnt/storage in order to not modify /usr
#plus, there probably isn't enough room on /usr unless the partitions have been
#successfully modified
./config --prefix=/mnt/storage && make && make install

#move back to usb and extract aircrack-ng
cd /mnt/usb/
tar xfz aircrack-ng-1.1.tar.gz -C /mnt/storage
cd /mnt/storage/aircrack-ng-1.1
#first, the common.mak file needs to be edited
vi common.mak
#now change the following line
-I/mnt/storage/openssl-0.9.8q/include/ -L/mnt/storage/openssl-0.9.8q/
#this points to the openssl headers for compilation
make && make install DESTDIR=/mnt/storage
#add the new bin dirs to the PATH variable
export PATH=/mnt/storage/usr/local/bin:/mnt/storage/usr/local/sbin:$PATH

#libnl (netlink library) from Chumby sources, a dependantcy of iw
cd /mnt/usb
tar xfz libnl-2.0.tar.gz -C /mnt/storage/
cd /mnt/storage/
./configure --prefix=/mnt/storage && make && make install
#set the PKG_CONFIG_PATH variable for iw
export PKG_CONFIG_PATH=/mnt/storage/libnl-2.0

#pkg-config is also required for compiling iw (detects the version of libnl)
cd /mnt/usb
tar xfz pkg-config-0.25.tar.gz -C /mnt/storage/
cd /mnt/storage/pkg-config-0.25
./configure && make && make install

#now compile and install new iw-0.9.22.tar.bz2
cd /mnt/usb/
tar xfj iw-0.9.22.tar.bz2 -C /mnt/storage
cd /mnt/storage/iw-0.9.22/
make && make install DESTDIR=/mnt/storage
export PATH=/mnt/storage/usr/sbin:$PATH

#elinks web browser (optional)
cd /mnt/usb/
tar xfz elinks-0.11.7.tar.gz -C /mnt/storage/
cd /mnt/storage/elinks-0.11.7/
./configure --prefix=/mnt/storage && make && make install

Recently I've been reading about the Robot Operating System (ROS) from Willow Garage and thinking about ways that it could interface with a UAV system to take advantage of many of the robot navigation and task planning routines that have already been developed for other platforms.  After going through some of the ROS tutorials, I started coding a publisher node for APM, it reads telemtry data via serial in the GCS Standard format, and publishes the data as ROS messages that can be subscribed to by any other ROS nodes.  My chosen language is Python:

#!/usr/bin/env python
import roslib; roslib.load_manifest('apm_talker')
import rospy
from std_msgs.msg import Int16MultiArray, MultiArrayDimension
import serial
import struct

def parsemessage(mtype, mdata):
 ddict = dict()
 if mtype=='\x01':
 ddict['SystemStatus'] = list()
 ddict['SystemStatus'].append(int(mdata[2].encode('hex'), 16))
 ddict['SystemStatus'].append(struct.unpack_from("h", mdata[5:7])[0])
 if mtype=='\x02':
 ddict['Attitude'] = list()
 ddict['Attitude'].append(struct.unpack_from("h", mdata[2:4])[0])
 ddict['Attitude'].append(struct.unpack_from("h", mdata[4:6])[0])
 ddict['Attitude'].append(struct.unpack_from("h", mdata[6:8])[0])

 if mtype=='\x04':
 ddict['PressureAlt'] = list()
 ddict['PressureAlt'].append(struct.unpack_from("I", mdata[2:6]))
 #if mtype=='\x05':
 #    ddict['StatusText'] = list()
 #    ddict['StatusText'].append(str(mdata[2:len(mdata)-2]))
 return ddict

def talker():
 pub = rospy.Publisher('apm_data', Int16MultiArray)
 rospy.init_node('talker')
 ser = serial.Serial("/dev/ttyUSB0", 57600)
 while not rospy.is_shutdown():
 f = ser.read(size=1)
 if f=='\x34':
 f = ser.read(size=1)
 if f=='\x44':
 f = ser.read(size=1)
 data = ser.read(size=int(f.encode('hex'), 16)+4)
 datadict = parsemessage(data[0], data)
 for signal in datadict:
 msg = Int16MultiArray()
 msg.layout.dim = [MultiArrayDimension(signal, 1, 1)]
 msg.data = datadict[signal]
 pub.publish(msg)
 #rospy.loginfo(msg)

if __name__ == '__main__':
 try:
 talker()
 except rospy.ROSInterruptException: pass

This is fairly basic, and it doesn't cover the entire APM message set.  There is still work to do to decide how the APM messages should be translated into ROS topics and messages to allow for the most flexibility when using it with other packages - for example, ROS seems to use quaternions when representing robot attitude, so it will be necessary to convert from the APM Euler angles.

More details on my projects blog including code for a subscriber node, and some details on how the whole thing is run.

Hi folks - this is by first blog post here, so let me know if I'm commiting a faux pas in any manner :)

I've decided that the compass support on ArduPilotMega needs beefing up.  I'm working on this in a few ways:

1. Added MicroMag3 support - this is accomplished, though I still need to refactor to make things part of a better OO-design.

2. Added a LUT for both magnetic declination and inclination so that these values are populated by the GPS.

3. Looking to improve the drift correction algorithm.  I like in an area where the inclination of the magnetic field is about 70 degrees from horizontal.  Many people assume that the magnetic runs tagent to the earth's surface - this is significantly untrue.  Becuase the magnetic field vector is so close to vertical here, it actually provides a much better estimator for pitch and roll than yaw if the plane is horizontal.  Thus, I intend to modify the drift correction in the DCM to use the magnetic vector as a truly 3D vector.  This means that depending on the orientation of the plane, it will correct for pitch, roll, and/or yaw with varying levels of accracy.  Has anyone already looked into this?

4. Make a calibration wizard in "setup" and have it store the values in the EEPROM.

Cheers,

John

This is a Current (And Airspeed) Sensor for $1.45.

I raised this question a while back, and was reminded again by the Post below which asks how to stuff all of this into a small box. (Beautiful Glider)

Small planes should remains a primal focus because they reduce the real and regulatory risks and allow broader participation in more fields/parks, etc...

So I'm offering a size reducing part - add a current sensor in exchange for the whole pitot/airpressure spaghetti.

The Airspeed theory is simple - at a given RPM, power consumption is proportional to airspeed, The faster the plane, the less the motor consumes to turn the prop. One can either detect the rpm, or determine that ESC's are essentially RPM = Throttle. Then a bit of data collecting will show the relationship.

http://www.goldmine-elec-products.com/prodinfo.asp?number=G16976

I just bought a Gluonpilot to test it out, and this post will record some first impression.

First, Gluonpilot is a single-board, open source IMU-based autopilot created by Tom Pycke in Belgium. Tom is a long-time autopilot designer and one of the best in the business, so this is solid gear. It's available for $322 with GPS from his store.

The hardware is a nicely-designed two-sided board, a little wider than APM but shorter. It uses a fast dsPIC processor, and supports six RC channels in and five channels out (with the option of driving two aileron servos). It has 1 MB dataflash onboard, and a pressure sensor (no magnetometer). It uses a FTDI cable for programming and communications with a desktop setup utility.

When you first get the board, it comes with cables to connect 4 RC channels, which is a little confusing because you need the 5th channel to control the autopilot. After a little digging around on the wiki, I figured out that you need to solder on two more pins to some spare holes and find some jumper cables to connect the 5th (and optionally 6th) channels.

The code is pre-loaded, so you just need to connect the included FTDI cable to the board (make sure the black cable is closest to the edge) and plug it into your PC. If you're using Windows Vista or 7, the FTDI drivers will be automatically loaded.  The Gluonpilot instructions say the board can be powered by the FTDI cable, but I found that wasn't the case with servos connected. It shut down my USB hub like that, so I had to power the board with an ESC while using it on the bench.

Setup

Once you've got it plugged in, you can start the configuration software (Windows only).  There you can set up your RC, check the sensors, download datalogging files, and do some mission planning. Overall, it's a very nice and simple setup process, similar to the ArduCopter Configurator. Everything is handled by one app, and once you've got your FTDI working, communications is fast and easy. Changes are written to the board via this app, and you can even update your firmware with it. No need to mess around with code.

Here's the RC setup screen:

I found the RC setup a little confusing. It turns out that the servo output 1 and 2 are both for ailerons (I guess for people who use two aileron servos without a Y connector?), so for regular configurations, you actually have to skip Output 2 and put the elevator on Output 3. I eventually figured that out by re-reading the manual, so no biggie.

You can also see the sensors working in this screen:

Ground Station

The configuration also has a very simple Ground Station that looks like this (you can also use it to open Google Earth and see a moving map)

But the good news is that the terrific Happy Killmore GCS also supports Gluonpilot, so I'd suggest you use that instead.

Unfortunately, there is no dedicated port for an Xbee for wireless telemetry, so you'll have to plug wires onto the FTDI port and unplug them when you want to change Gluonpilot configurations or change your mission. That means you'll need to put the autopilot in a place in your plane where you can get easy access to it and deal with some fiddly wire swapping at the field. I hope in the next version of Gluonpilot, Tom adds a dedicated Xbee connector (although I'm not sure if the dsPIC he's using has a spare serial port for this).

Mission Planning

Mission planning is done via a scripting language. The configuration utility lets you enter commands pretty easily, but there is so far no point-and-click waypoint entry as you can find in most other autopilots, so it's a bit of a hassle to look up lat/lon on Google Maps and copy them over.  So right now Gluonpilot is better for relative waypoint (go 100m north of current position). Here are the available commands:

Final thoughts

I haven't had a chance to fly Gluonpilot yet, but by all reports it's very solid. Now that it's supported by the HappyKillmore GCS, it has a proper Ground Control Station. The only other big missing software piece is a point-and-click Mission Planner.  Otherwise, it seem to be in very good shape and quite mature for a one-man operation (no surprise if you know the inimitable Tom!)

Tom has flown a quadcopter with Gluonpilot, but given that it doesn't have a magnetometer or any way to add one that I can find, that doesn't seem like the best fit for this board.  Instead, it seems perfect for fixed wing aircraft, especially those with easy-to-access cockpits where you can plug in the FTDI cable and swap wires to add the Xbee.

Tom is also planning to add an on-screen-display (OSD) interface with a daughterboard, so that will be cool to see. 

Overall, this seems like a very good launch from a top autopilot designer. It's somewhat similar to the UAVDevBoard (similar processor) but is easier to set up and the hardware is more sophisticated, with a built-in pressure sensor and datalogging (although it doesn't have as strong of a community yet, and it costs twice as much).  Overall, at this point I'd recommend this for people who want an easy-to-use autopilot for fixed-wing aircraft and don't mind not being able to click on a map to enter waypoints.

Next, I need to fly it and see it it works as well in the air!