Friday, August 20, 2010

Flying with Ardupilot Mega

I'm experimenting with the ArduPilot Mega source code and settings and have finally succeeded to get it working properly using a FlightGear simulator and the board setup through a serial USB link. I've made a flight, slightly rough around the edges, around San Francisco airport in the simulator with some tweaked waypoints. You can find that file here.

The biggest problem in getting the link working has been the communication between the PC and the arduino board and FlightGear. FG may reduce or increase framerates and start buffering data when the interface program is not consuming them fast enough. The current interface is almost ready for real use, but can I think still increase the speed in which it passes data around.

In order to get stuff working, you should check the source code out of and make sure that you're pointing to the correct library location. Download the which is used for the communication with the USB 'ground station' (the flightgear link). Then reduce the NAV_P gain in the APM_PID_Gains.h file to something like .5 and reduce the other P gains too (you'll notice if the gain is set too high when it becomes unstable in flight and increases the roll or pitch constantly).

As I said, the flow of data was the biggest problem, so communication with flightgear is now attempted to be optimized. FlightGear does not care too much if there is nothing to read, but writing more than it can handle will buffer data on the IP buffers. So you should aim to write 1-2 Hz less than the link setting. Also pay attention to the frame rate that FG is able to put out, because that is the minimum update frequency you can use.

Reading from a port should be done as fast as possible and ideally outside of the main "50 Hz" loop. Since Arduino attempts to follow a 50Hz loop, you could attempt to follow the same in the interface application, but there's a possibility that you overload the link. The older XPlane app issued the attitude and additionally the GPS at 5 Hz, but I modified that to output XPlane attitude @ roughly 42.5 Hz and GPS @ 5 Hz. That leaves a bit of space to get rid of any overload that might occur on the arduino side.

Reading from the serial port should also occur as fast as possible. This way, you can keep everything in the same loop once you use a couple of global variables for whatever data is read from the links. Once something can be written, then just set up the packets and kick it out the door.

There are probably some configs to change in the Arduino source code before thinsg will work for you:
  • I have airspeed sensor set to 0.
  • The example waypoint file has been modified to allow the cessna to make the turns (better:).
  • GCS_PROTOCOL is set to 3.
  • GPS_PROTOCOL is set to 3.
  • GPS_IMU is included.
  • The #ifdef GPS_PROTOCOL != 3 before the is commented ( around line 610 in main source file, inside update_GPS function).
I first ran in STABILIZE mode and verified that I got responsiveness on the sticks. If your interface is buffering too much, reading too slow or writing too fast then you may get responses after 5 seconds. That will never converge to a model that can fly properly.

Then after STABILIZE mode you can quickly verify FLY_BY_WIRE_A and B to see if that works out. Then I loaded the waypoints and turned on AUTO mode. For that to work, just start flightgear and pause it. Zoom out a bit with Shift-X until you see the throttle stick. Hit "H" to see the HUD to get more info. Then make sure the switch is set to manual with throttle at zero. Start up the interface. Wait for the servo's to wiggle and the interface to print "Ready to Fly". Now you can switch to AUTO mode, but you have to control the throttle manually. I basically set throttle to full.

Because I don't have a rudder attached (nor is this set in the ardupilot.xml file), the plane veers off to the left due to the propeller torque until it lifts off the ground. The ardupilot mega will then slowly turn back to the heading it had when it was going 3 m/s (12 knots). Initially I used 10 degrees pitch, but noticed that it tried to drill itself into the ground. Making that 20 degrees again fixed it. Also make sure that your NAV P gains are correctly set, as these will determine how eager the autopilot is to get to the setpoint. Since the stock cessna of FlightGear is a bit slow in relation to an easystar, these P gains probably have to be reduced. It will then be less strict in following the waypoints, but allows for easier flight.

Have fun!


Terence said...

I just put together ArduPilot Mega. As the software ist in alpha stage every comment and hint is very useful, as there are many errors which can be caused by hard- and software.

After many trys I got the ArduPilot Mega running. I am about to install it into a EasyStar model airplane.

A flight simulator can be a good tool to avoid damage for the first test.


Sebastian said...

I would like to connect APM to FlightGear as well. But I don't get it running. I am working on it since a few weeks and I read every comment on it at DIY Drones but couldn't solve it.

Maybe it is the same problem you had with the communication.

What do you mean by the senstence:
Reading from a port should be done as fast as possible and ideally outside of the main "50 Hz" loop

Which reading command do you mean?
I cannot find the "serial read" only the serial.print to get the informations to flightgear.

Is it possible to get your code with your changes?

Did you change anything at the ardupilot.xml from the official homepage?


Gerard Toonstra said...

I rewrote the entire thing to work under Ubuntu using standard serial implementations there. The comment about "reading as fast as possible" refers to the loop one is creating between the PC, FlightGear and APM. There are four operations:
- Read from FG
- Write to FG
- Read from APM
- Write to APM.

If any of these operations start to delay significantly, you'll get delays in the others for certain. Different timings or frequencies may get you different results and the frequencies of FG are approximations (depends on framerate). So the best thing to do is read out each buffer on the PC as much as you can, but only output from the PC according to the frequency FG and APM can handle. (essentially control whenever it writes by verifying if x ms have passed inside the loop).

FG version 1.9, the version on Ubuntu, cannot easily handle buffers running full. The lines are buffered in the IP stack and it reads each one of these in sequence. This can lead to buffers having 30k in there, or 1-2 minutes of delay before your commands arrive.

Yes, I will opensource this soon. Write me if you are interested in the source file now. It will only compile on Linux probably, but was written with automake in mind. It has a dependency on "ardubus" that you need to remove. This is a messaging bus to relay telemetry on the PC to whatever other app is currently running, which can then use it to perform other calculations (like calculate bearing/distance from a ground station), which is then also publishing new information. Anyway, that'll become apparent as soon as the entire project is released.

Mark Grennan said...

I'm trying to write some better documentation on conning the AP Mega to the simulators.

Can you tell me how you changed the "Rates" for the GPS and data?

mark at grennan dot com

martin said...

I'm not sure if this will help anyone here,however I just wanted to make anyone who reads these comments from either the UK or European markets aware, there is a new diy drone store open in the UK,



Gerard Toonstra said...

I bought my stuff from, which does seem to be cheaper for the UK at least.

Ardupilot said...

For the UK I came across a store that has good prices at Unmanned Tech

ArdupilotMega said...

The shop URL is

Ardupilot Mega UK