Convert any RC airplane into a fully-autonomous UAV!
Just add the APM 2 autopilot to any RC aircraft and it becomes a fully-programmable flying robot with a powerful ground station and Mission Planner.  


Features include:

  • Return to Launch with a flick of your RC toggle switch or a mouse click in the graphical Ground Station
  • Unlimited 3D GPS waypoints
  • Built-in camera control
  • Fully-scriptable missions
  • One-click software load, and easy point-and-click configuration in the powerful Mission Planner. NO programming required!
  • Replay recorded missions and analyze all the data with a graphing interface
  • Supports two-way telemetry with Xbee wireless modules. 
  • Point-and-click waypoint entry or real-time mission commands while the UAV is in the air
  • Fly with a joystick or gamepad via your PC--no need for RC control!
  • Built-in failsafe will bring your aircraft home in the case of radio loss


All instructions and software are here.




APM 2 is an open source, Arduino-compatible, pro-quality autopilot. It is the most advanced IMU-based open source autopilot available today, and provides an entire UAV control system with scriptable missions with 3D waypoints, in-flight uploading of commands and powerful ground station software. 


APM 2 supports any kind of of vehicle with a one-click change of code. Available code include ArduPlane (fixed wing), ArduCopter (rotary wing), ArduRover (ground vehicles) and more.


Everything you need to create an ArduPlane UAV:


APM 2.5 autopilot with GPS ($179)

[Optional] Telemetry kit ($75).


You'll also need a at least a five-channel RC radio setup, a soldering iron, a mini USB cable and of course something that flies! (We're partial to the SkyFun delta wing (right) and
Bixlee 2   powered glider (left) or its equivalents ourselves).






Source code/firmware

Note: ArduPilot Mega requires no programming, but it's open source and you're welcome to modify it if you'd like. If you are going to play with the code, you can use the free Arduino IDE to edit and upload the code to the ArduPilot board.



Views: 557413

Comment by Nenad V on May 18, 2012 at 3:52am

I have plank flying wing with two motors Left and Right on leading edge, and moving horizontal stabilisator back, without rudder and elevons.Radio is Futaba6EX with R617FS receiver.I use Futaba elevon mixing on CH1 and CH2 for diferential  motors control and CH3 for horizontal stabilisator control.

Is it better for my flying wing to use Arduplane system with elevons mix, or Arducopter system ,tricopter version ,but vith control two motors and one servo for horizontal stabilisator.Is it possible  to make setap for this?

Comment by Malu Msooityo on May 21, 2012 at 5:53am

Hi Everyone,

Does anyone have an idea on how the communication range of the APM 2.0 Autopilot can be increased beyond that provided by the Xbee wireless bluetooth modem? I am working on this board and the range is my challenge.  I will welcome suggestions. Thanx!

Comment by Michael Smith on May 21, 2012 at 10:10am
Comment by Justin Boland on July 3, 2012 at 9:15pm

In case anyone else has Lisa's and my problem, it has been shown that too high a voltage on the APM will cause exactly this problem.  That thread is here: Xbee no GPS

Comment by Gavin Yeo on July 9, 2012 at 11:37am

is there a really easy step by step guide to install quadcopter firmware to ArduPilotMegaV1 128k version.???  I am helping out a fellow flyer find a solution for this board but it says 'Firmware is too big for 1280 please upgrade harware'.  Any links I can send to him to tackle? The easiest option is best - thanks.  Or will the Mission Planner be updated soon to take care of the older APM V1's with 128k.  I hope so!!

An expensive paper weight if he is not able to upload firmware anymore.

Comment by Jeff Zika on July 10, 2012 at 11:41am

Ok, this is the first post to Arduplane group so please bear with me. 

We are evaluating and testing autopilots for a high speed target drone, as in 200knot + and up to 10000ft alt. I have been working with an APM1 running Arduplane 2.4 in HIL mode with xPlane. These are some of the comments / concerns so far.

1. Trim is a real pain in the ass. The aircraft trim changes dramatically during flight due to configuration changes, pickup of towed target, dropping target, gear retraction or extension, etc. Is there any way to automate the trim changes? As it is now, every time trim changes are required it has to be done either in manual mode and switch back to auto, or manually using parameter changes through telemetry. 

2. The autopilot appears to command a switch to loiter or circle after waypoint passage if the angle between programmed tracks is greater the 90deg. This behavior is quite consistent. 

3. One programmed flight to 5000m completely corrupted the APM settings in such a way that switching out of manual commanded a full power dive in all auto modes. 

4. What is the maximum airspeed and altitude. The aircraft we are testing is capable of far in excess of 100m/s cruise speeds and climbs at over 7000ft per minute. (yes, it is prop!)

5. Waypoints don't seem to be written consistently. Saving waypoints to the APM some times (most times) does not overwrite existing waypoints or remove any in excess. This can be quite confusing since the aircraft takesoff in some apparent random direction that does not match the programmed route. Reading the waypoints shows the errors. This is a pretty major bug that needs to be addressed. 

6. During any auto mode, descents drop the throttle to idle but keeps the decent angle consistent (as it should) thus resulting in a drop in airspeed. The throttle should be managed to maintain a constant airspeed irregardless of climb or decent angle, within the capabilities of the aircraft of course. FWIW, the throttle increases to cruise setting with speed increase once the decent and level off is completed. 

7. Tracking a path between waypoints results in a snaking flight path. Tracking direct to a waypoint does not. Can't the same code be used for both?

8. Where is current wind speed and direction as derived from GPS groundtrack vs. heading available on the GCS?

9. Need to be able to specify loiter and circle direction as a parameter of a loiter waypoint. 

10. Is there any way to command landing gear retraction after successful takeoff and extension after passing last waypoint before a landing waypoint?

11. The drone we are testing will use parachute recover and catapult launches. Is there anyway to set a waypoint to deploy the parachute. 

12. There needs to be a way to ramp up the throttle slowly on takeoff. Full throttle at low speed results in a hard turn to the left which is NOT corrected by the APM. Normal takeoffs with this aircraft are nearly impossible because of this (prop is 24x24 4 blade... i.e. LOTS of torque)

The waypoint programming issue and autotrim (from flight data, not from RC settings) are really must haves for this to work for us. Any ideas if these can be added / fixed?

Best Regards


Comment by Uwe Gartmann on July 10, 2012 at 3:57pm

Hi Jeff

Do you think the APM v1 / v2 is the right solution for you? You are running a quite dangerous airplane. Your list of issues looks like a product specification that is find by professional aircraft manufacturers or military companies. Please understand me right. The APM platform is a cool hardware / software package for experimental usage. But for such a heavy and big airplane its is the wrong solution with the contributed software. I have an APM1 version here at home. Now unsued for several month because of huge complexity of the project and several iconstistence in the software. Please get a professional equipment for your and our safety. Not to forget, APM is open source, so you can extend the functionaltity of this product any way you like.

3D Robotics
Comment by Chris Anderson on July 10, 2012 at 8:32pm

Sorry, I renumbered the items when I posted to the list, skipping the ones that weren't issues. I hope you can figure it out from the responses. 

Comment by Jonathan Challinger on July 10, 2012 at 8:41pm


1. On trim, trim is done by integrators on our roll and pitch controllers. Read up on how PID controllers work.
Tuned correctly, the integrators will integrate out any change in trim.
I have vastly improved roll and pitch controllers in my personal branches. I am hoping to get it released but it is a drastic change and there will be lots of people who don't want to retune. This issue needs to be resolved before it can be released.

2. I often do a one-dimensional circuit with a 180 degree turn at either end and I have never seen this happen.

3. Unsure what would cause that, never seen it happen.

4. Not sure on airspeed. Very fast, I would imagine. Probably limited by the airspeed sensor. Altitude is limited by the specs of the barometer - 30,000ft I believe.

5. Never had trouble with this but there may well be bad bugs there. Perhaps this and 3 point to the user having bad hardware?

6. This is the result of throttle being controlled by unconstrained total energy. If you have too much potential energy (altitude), it will never turn the throttle on for any amount of airspeed error, instead relying on the airspeed controller to pitch the plane down until it reaches the desired airspeed. If this isn't achievable, then it will just pitch to the max pitch (assuming you have an integrator on airspeed.)

7. I believe the same controllers are used. The user's crosstrack gain is probably tuned too high. Note that track following is very poorly done, especially with a compass.

8. The mission planner shows these in the status tab. They are calculated on the ground station as far as I know. Wind estimation is something I am going to be working on soon enough.

9. Agree.

11. There are mavlink commands/waypoints to activate a relay, etc. You can write some code to do it conditionally, as well.

10 & 12. Takeoff command is NOT for rolling takeoffs. I learned this the hard way. This is, so far, intended for hand launches only. Gear extension: See #11 If you have trouble with torque, I recommend tuning the yaw integrator. P puts too much noise on the servo, but a (fairly large) integrator works beautifully. I use 5.0 in the simulator, and 2.0 on my plane. This will also tighten up navigation slightly, as the rudder feed-forward gain will typically apply *opposite rudder* during a turn. The reason it does this is most planes require opposite aileron to hold a bank angle. The solution is a yaw integrator, which will hold a coordinated turn and apply right rudder in reaction to the torque.
We could work up a feedforward gain for throttle and pitch to rudder, but someone would have to research the math on calculating P-factor torque. This would be very secondary to getting good roll and pitch controllers going, which I have working at the moment, but we need to work out a way to get them released without messing up anyone's currently-working gains.

Comment by Jonathan Challinger on July 10, 2012 at 8:42pm

I deleted my previous posts, but just note that Chris' post was in response to one of mine.


You need to be a member of DIY Drones to add comments!

Join DIY Drones


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Drone Delivery Challenge, is here

© 2015   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service