3D Robotics

ArduPilot (Legacy) main page




[This original ArduPilot board, now called the "Legacy ArduPilot" is no longer produced or officially supported by the DIY Drones dev team, and this page is maintained just for historic reasons. However, there are still many users of it out there and it still works fine. The user group for Legacy ArduPilot users, for both thermopile and IMU use, is here.]


ArduPilot is a full-featured autopilot based on the Arduino open-source hardware platform. It uses infrared (thermopile) sensors or an IMU for stabilization and GPS for navigation. It is the autopilot used to win the 2009 Sparkfun Autonomous Vehicle Competition.

The hardware is available from Sparkfun for $24.95. An expansion board ("Shield") kits that includes an airspeed sensor, a 3.3v power regulator for 3.3v GPS modules and other sensors and cables and connectors for easy attachment of the XY and Z sensors, is available from our own store for $57.20.


User f

ArduPilot features include:

  • Can be used for an autonomous aircraft, car or boat.
  • Built-in hardware failsafe that uses a separate circuit (multiplexer chip and ATTiny processor) to transfer control from the RC system to the autopilot and back again. Includes ability to reboot the main processor in mid-flight.
  • Multiple 3D waypoints (limited only by memory)
  • Altitude controlled with the elevator and throttle
  • Comes with a 6-pin GPS connector for the 4Hz uBlox5 or 1hz EM406 GPS modules.
  • Has six spare analog inputs (with ADC on each) and six spare digital input/outputs to add additional sensors
  • Supports addition of wireless modules for real-time telemetry
  • Based on a 16MhZ Atmega328 processor. Total onboard processing power aprox 24 MIPS.
  • Very small: 30mm x 47mm
  • Can be powered by either the RC receiver or a separate battery
  • Four RC-in channels (plus the autopilot on/off channel) can be processed by the autopilot. Autopilot can also control four channels out.
  • LEDs for power, failsafe (on/off), status and GPS (satellite lock).


ArduPilot requires the free Arduino IDE to edit and upload the code to the ArduPilot board.

The code is currently optimized for the Mutiplex EasyStar three-channel powered glider and FMA sensors, but can be modified for other aircraft and sensors. It uses the rudder/ailerons and elevator to maintain level flight and navigate to GPS waypoints. It supports a desktop setup utility and ground station software. It also includes a "fly-by-wire" mode that simply stabilizes RC flight. The main code is ArduPilot2.x.zip in the download section of our Google Code repository, where x is the latest version.

What you need to make a fully-functional autopilot:

Open source extras:

  • If you want to build your own board from scratch, the necessary files and component lists are here.
  • [Note: you shouldn't need this, since this code is loaded on the ArduPilot board at the factory] Latest multiplexer code (for the board's second processor, an Attiny, which runs the failsafe system) is here.
    Instructions for loading this code are here.

Recommended UAV setup:


Airframe option one: Hobbico SuperStar (49" wingspan, $95, shown above). This is an inexpensive, good flying high-wing trainer with ailerons. It can be hand launched in a park or take off from a runway, and replacement parts are readily available in case of a crash. If you want much better performance with this aircraft, you can upgrade it to a brushless motor, speed controller and a LiPo battery. [If you don't already have one, you'll also need a balancing charger and power supply.] Note: any stable aircraft with both ailerons (for stabilization) and rudder (for navigation) can work, so feel free to experiment with what you've got.


Airframe option two (recommended for ArduPilot 2.x): EasyStar (shown above). Performance can be improved with the modifications described in this post.

You'll also need:

  • A six or seven channel RC transmitter and receiver, with at least one toggle switch (ideally three-position but two-position will work, too, although you will have to mix channels to have access to both autopilot modes in the air), such as the Futaba 7C.
  • Some servos (at least three for ArduPilot 1.0; at least two for ArduPilot 2.x) and at least three female-to-female servo cables to connect the RC receiver to ArduPilot.

Cool optional extras for your UAV:

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Hi ! Just installed Ardupilot (v2.4) with EM406 GPS on new kyosho calmato, a low wing .60 trainer with saito 100 4 stroke engine, all tests done, .h file adjusted, 2 waypoints route is loaded , take off, rise 150mts, right after turning WP or RTL mode the plane make a fast (180o) roll and start to flight upside down, it always do it even after making a 180 turn of the Z sensor. The Groundstation show everything ok (the horizon is right after and before the upside down turn) Is something I need to change to avoid the inverted flight ?
  • 3D Robotics
    I've responded on the other page.
  • Hi Chris

    I have some problems with my ardupilot, i already posted on arduino debugging tips page.
    I'm confused about where should i post problems about my ardupilot.

    i'm really thankfull that you have this kind of "debugging or troubleshooting" page.

    Feri Ametia Pratama.
  • Jason,
    Thanks for the reply. My test course is along a quiet, slightly meandering road where I live. 14 waypoints and slight changes in direction for the main, about 80m between waypoints. Allows me to drive with plane on dashboard, xbee telemetry to my laptop recording data to a file, which I then convert to a csv, then load into a spreadsheet.
    I could send you the spreadsheet of the log of the variables as I "drove" along a course on the ground.. The main concern seems to be the behaviour of the Roll variable compared to the roll_set_point; the former was often wanting to turn the rudder in the opposite direction to where it "should" be going. (in 482 data points, Roll was "opposite" 180 times, while R=roll_set_point only 64). I think this may be related to the IR data, as the x & y axis move around, and at some points seem to go unstable.
    GPS data looks good.

    I know the servos are OK, as I have tested direction, and previous version of airframe with these electronics worked fine before crash.
    I am controlling throttle by RC controller - haven't got to trust the auto on this yet...

    For the last attempted flight, I set the course using the windows based tool and wrote to the plane while at home. When I got to the field, (30 miles away, unknown if higher or lower), I set the home point with the pin 6 shorting pin as per normal procedure. Could this have confused the system about relative height? I haven't studied the code to see when the relative height of waypoints is set. From memory it was spiraling down.

    Thanks for your help & any suggestions welcome...
  • Developer
    I hope to do flight testing of 2.5 later this week. I will send you a copy of the 2.5 airframe tester tonight. I made some updates during lunch and want to verify it still performs. It has all of the hardware and sensor debugging that you'll need.
    Also, can you verify that you still get good GPS information from your plane when you test it on the ground?
    Does it spiral down or head straight down? Does the throttle cut out?

    Things that could cause it to nose down:
    - It thinks the waypoint is below ground
    - bad GPS data
    - home location is somehow not being set properly
    - throttle could stop because of bad airspeed input - check cables
    - IR signal is bad, blocked, etc - check cables
    - reversed ch2 servo

    The new throttle code has some minor bug fixes/enhancements. If you read in ch3 (by soldering ch3 in to pin 13), it automatically trims your throttle and gets rid of the "dead zone" in the header of 2.4. It also gives you access to the full range of throttle (0 - 100%) if you want it.

    V3 of the code will address many HW specific needs of the 1280 and IMU. V2.5 sets a good architecture to build 3.0 on. Ardupilot and Mega will continue to share almost all SW features.

    2.5.1 (quickly following 2.5) will add Remzibi OSD and IMU support through serial for the current HW.
    2.5.2 will enhance the event model API based on user feedback
  • Jason,
    Thanks. Can you help me understand 2.5 vs 3.0 vs incorporation of the replacement of the IR with IMU?
    I'm trying to debug a nasty problem that seems to have occurred since 2.4, but is also coincident with a nasty crash/rebuild, which may have damaged some hardware, but now the plane wants to nose-dive when switched to auto mode; I want to know how much time to invest in 2.4, or move on...
  • Developer
    Nigel, I'll be doing a big 2.5 post later this week covering as much detail as possible. There is far too much to get into detail on the podcast. It will also cover how people can submit bugs and new code.
  • David,
  • Nigel, you can subscribe to this rss feed
    DIY Drones Podcast (MP3)
  • Chris, Thanks. I had not realised that there are podcasts available. I have looked on your blog, but it is not clear how I can download this podcast (maybe not yet available), or any previous ones. Could you point me to the URL?
This reply was deleted.