Arducopter 2.1 release

Ardupilot 2.1 is out and can be downloaded by the mission planner (or with Git). You must have the latest version of MP to be compatible. If you're compiling with Arduino, you must use the "mrelax" version of Arduino that is in our downloads section. This is because Arduino was never tested with code larger than 128K. And since our code is probably the most complex Arduino project ever, we found the issue. This altered version of Arduino allows you to specify a special compiler flag that makes it work again. Otherwise it's functionally identical to version 22. When we transition to 1.0 of Arduino, you won't need to use a modified version, since they have patched it for us.


This version has a few new features, but is mostly a bug fixes and compatibility with APM2.  The nav routines have been updated and well tested. I'm getting very reliable results now. 

One new feature that I snuck in was SuperSimple mode, which re-calibrates simple mode when you are flying with GPS > 20m from home. It allows you to fly in any direction in Simple outside of this radius. Check the wiki for more info.

Added Auto_land mode to help with Failsafe implementations.


Here's a video I took flying WPs using CH 7 to toggle record them. I flew back and forth over the park to se how straight a line I could maintain and how repeatable it was, then I recorded a few waypoints to the left and right, then I recorded a landing wp by toggling CH7 when the copter was on the ground. The landing could be improved, it was trying to maintain a location and didn't level out in the last meter to the ground as it should. I was missing the screw holding my Arm in place so it folded in just a bit, no real damage done. BTW, this video is W/O a sonar.


The next video is of the Loiter control. I improved loiter a bit with a bug fix and the stability patch from the stabilization. Wind was mild. Could be tuned just a little higher.



Here's a video from Dec 17 showing WP recording. The radio was on the ground the entire video. The 3DR frame did not have a sonar on it. The landing was recorded as well.



Tridge wrote a Geo - fence routine to restrict flight within a certain area for Arduplane. We'll port that over to AC. You'll be able to fly acro inside a safe area and have it go into AP if you loose control!

We need one more pass to finalize the Optical flow integration.

Finalization of the Z Accel code.


Have fun and fly safe,




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

Join diydrones

Email me when people reply –


  • A suggestion:

    The GPS derives velocity measurments in a completly differnt way than position.

    It calculates a three dimensional velocity. Internally almost all GPS generate a Vnorth, Veast and Vup/down.

    When a wind gust or other environmental change comes along the change will be seen in the velocity measurement before its seen in position. When I worked on my helicopter I used a proportional (only) position error to target a desired velocity. Then I used all three PID  terms to derive a desired roll pitch etc from the measured velocity.  This resulted in really stable position hold hovers.  The fact that your GPS spits out velocity as course and speed with limited speed resolution may make this hard for you to do, I don't know how hard it is to modify the special GPS firmware, but a version that spit out Veast, Vnorth and Vup/down to as many decimal palces as possible would be nice. The GPS I used for this spit out the V record as three binary floats.

    As an additional input my autoland code worked as follows:

    Set a target down velocity to  1m/sec or so.  Hold the target velocity when it touches down the vertical velocity loop tries to keep descending by reducing throttle/collective/thrust .  When it  detects that the throttle is at zero  it declares that it has landed.  This even worked well on a rocket where the hovering throttle varies widely as the wt of the vehicle changes 3 to 1 in flight.  See:

    This shows a breif takeoff,  hover at 6 ft or so then land cycle, 100% autonomous.


  • PID calculation in the library: the "I" term effect

    Reviewing the way the integral component is defined in the library (either APM_PID or APM_PI) I think that maybe it´s not fully correct (or I didn´t understood well the code)

    As you know, the integral "I" term in a PID controller is the sum of the instantaneous error over time (the duration of the error) and gives the accumulated offset that should have been corrected previously. The accumulated error is then multiplied by the integral gain (Ki) and added to the controller output.

    The integral term  in fact is the "area" below the curve e(t) along time and is given by

    The way it´s computed in AC2 code is:
            _integrator         += (error * _ki) * scaler * delta_time;
    This is called in every control loop, so no acumulation along time is done. It´s a kind of e(t) * constant, so another "p" term (much smaller)
        int x_iterm = g.pi_loiter_lon.get_i(x_error, dTnav);

    In fact this is the small "area" below e(t) but only width to the integration step time (delta_time) that is a very small number. This should consider instead a larger period of time (maybe not two much, since this effect is acumulative and could overshoot easily). I think this is why I term doesn´t change things in the present code.
    I don´t deeply understand the code, so sorry if I miss something.

  • Jason - Re: sensing landing

    Most full size aircraft (not little Cessnas) have 1 or more switches on the oleo struts known as a "weight on wheels" (wow) switch. As the plane settles on landing the strut compresses and either makes or breaks the wow switch. This signal is used to trigger many events, eg. disable radar transmit so as not to fry ground personnel with microwave energy.

    If there is a free input, perhaps a microswitch with an extended arm could be used in auto to shut down the motors. Maybe a looped zip tie to operate the switch so nothing digs into the ground. I hope you find this useful, unless of course it has already been thought of.

  • Can you contact me, I am intererested in a custom application.

  • This announcement about 2.1 is interesting and I'm anxious to try it.  But does it also fix the I2C problem?  The program really shouldn't be out of "beta" until this known, serious problem is fixed.  I'm still afraid to try loiter until it is.

  • Can anyone tell what is the difference when I use small dia prop vs larger dia props while climbing for maximum altitude. Motors and current consumption is not an issue.

  • Clearly this code is optimized to work along side the DIYDrones quad. But of course there will be many who will want to use their own designs. The difference that will be seen in the PID setting parameters is mostly a function of the Motor, ESC, and frame width and the prop. being the most crucial factor. The response that is seen from whatever PID setting will be mostly effected by the weight and efficiency of the prop. Whereas lift efficiency is allied to swept area it does not follow that a large dia. fine pitch prop will deliver the most stable flight dynamics. Motor response/stability is a key factor which improves with the arm being shorter and the rotational inertia being as low as possible. As the heavy lift concept seems to run into large frames and props upwards of 14 " there has been a tendency to loose stability in windy conditions at the same time.  Hence these Autoclaved 11x4 carbon prepreg props that have been developed to work with the Tiger Motor 4008 660Kv.As a fast response solution. They weigh just 14 grams. It has thus far been what I would say is a definite step in right direction for anyone wanting to lift a little more weight. Seen alongside a 11x4.5 APC3692317780?profile=original

  • Is 2.1 the recommended version to use if we want the most stable and reliable code? I have APM1.

  • Jason,

    Have you reflashed your ESC code or are they standard?

  • 3D Robotics

    Loiter is phenomenal. We tested it this afternoon and it was glued to one spot. Thanks Jason!

This reply was deleted.


DIY Robocars via Twitter
RT @donkey_car: Human-scale Donkey Car! Hope this makes it to a @diyrobocars race
DIY Robocars via Twitter
DIY Robocars via Twitter
Jun 16
DIY Robocars via Twitter
RT @GrantEMoe: I won my first @diyrobocars @donkey_car virtual race! Many thanks to @chr1sa @EllerbachMaxime @tawnkramer and everyone who m…
Jun 13
DIY Robocars via Twitter
RT @gclue_akira: JetRacerで自動走行したコースを、InstantNeRFで再構築。データセットは別々に収集 #jetracer #instantNeRT
Jun 13
DIY Robocars via Twitter
RT @SmallpixelCar: SPC 3.0 Now the motor also works. This car is doable. I just need to design a deck to mount my compute and sensors. http…
Jun 13
DIY Robocars via Twitter
RT @SmallpixelCar: My new car SPC 3.0.
Jun 7
DIY Robocars via Twitter
RT @SmallpixelCar: High speed at @diyrobocars thanks @EdwardM26321707 for sharing the video
Jun 7
DIY Robocars via Twitter
RT @SmallpixelCar: Today at @RAMS_RC_Club for @diyrobocars. Used @emlid RTK GPS and @adafruit @BoschGlobal IMU. Lap time 28s…
May 28
DIY Robocars via Twitter
May 15
DIY Robocars via Twitter
May 14
DIY Robocars via Twitter
May 13
DIY Robocars via Twitter
RT @f1tenth: Say hi to our newest #F1TENTH creation for @ieee_ras_icra next week in Philly. It’s going to be huge! 😎 🔥 @AutowareFdn @PennEn…
May 13
DIY Robocars via Twitter
May 11
DIY Robocars via Twitter
May 8
DIY Robocars via Twitter
RT @SmallpixelCar: Noticed my car zigzagged in last run. It turned out to be the grass stuck in the wheel and made the odometry less accura…
May 8