ArduCopter-3.0.1 released!

ArduCopter 3.0.1 has been released and is now available in the Mission Planner,, GitHub and the new Downloads Area.

Warning #1: Compass calibration and reducing interference is far more important than with 2.9.1b

Warning #2: GPS glitches can cause sudden and aggressive position changes while in loiter mode.  You may wish to reduce the Loiter PID P to 0.5 (from 1.0) to reduce aggressiveness (see image below of where this gain can be found in mission planner).

Warning #3: optical flow is not supported but will be back in the next release (AC-3.0.2 or AC-3.1.0).

Warning #4: loiter turns does not maintain altitude.  This bug will be fixed in AC-3.0.2.

Warning #5: This release has only been lightly tested on Traditional Helicopters.

Improvements over 2.9.1b include:

  • Inertial Navigation for Loiter and Auto meaning much more accurate control (Randy,Leonard,JonathanC)
  • 3D navigation controller follows straight lines in all dimensions between waypoints (Leonard,Randy)

         WPNAV_SPEED, WPNAV_SPEED_UP, WPNAV_SPEED_DN, WPNAV_ACCEL allows configuring speeds and acceleration during missions

  • "compassmot" to compensate for interference on compass from the pdb, motors, ESCs and battery.  (Randy,JonathanC) (Set-up video here)
  • Safety improvements:
    • simple Tin Can shaped Geo Fence
    • pre-arm checks to ensure all calibration has been performed before arming (can be disabled by setting ARMING_CHECK to zero).  (video description here)
    • GPS failsafe - switches to LAND if GPS is lost for 5 seconds
    • stability patch improvements to stop rapid climbs in very overpowered or overtuned copters
  • Circle mode improvements including "panorama" when CIRCLE_RADIUS set to zero (Randy,Leonard)
  • SONAR_GAIN parameter added to allow better tuning of sonar surface tracking
  • CH8 auxiliary switch (same features as CH7)
  • works on PX4 (some minor features still not available) (Tridge,PatH)

How to upgrade:

1. Make sure you are using Mission Planner 1.2.59 or newer (get it here)

2. Click on the MissionPlanner's Hardware, Install Firmware screen.  The version numbers should appear as "ArduCopter-3.0.1", then click the appropriate frame icon and it should upgrade as per usual.

3. Reduce the Loiter and Alt Hold PIDs if you have modified them from the defaults.  The modified PID values for the 3DR frame can be seen in the image below.

Note: Nav parameters have been combined with Loiter so do not be concerned if you can't find them.


4. Although not directly related to this release, if you purchased an APM prior to March of 2013, update your PPM encoder to the latest firmware (instructions here).

5. Try out the new version in stabilize mode first, then alt-hold, then loiter and finally RTL and Auto.

Numerous How-To videos are available:

Special Thanks to MarcoDaveC and the large number of testers on the pre-release thread who put their copters at risk during the extended testing period.  Some of their videos can be found hereherehereherehere and here.  Thanks also to MichaelO for the MP changes required for this release.

All feedback welcome.  Please put your questions, comments (good and bad!) below.

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

Join diydrones

Email me when people reply –


  • @ MHA

    Re. TBS Discovery geometry - take a look at the Discovery manual. The angles you want (55 deg and 125 deg) are the angles between the centre line and the motor axis to CoT point.

    Max Levine did an earlier post re the set-up.

    Hope this helps.

    I'm in the process of designing a similar frame to accommodate a 3-D printed brushless gimbal and want to ensure that the props are out of the field of view, so have been down this route recently.

  • Any news if the gps glitch fix wil be implemented in rc3?

    And when can we expect rc3?

  • Moderator

    Further to my problem with my external magnetometer working but the APM not seeming to recognise it's output.

    1) The onboard-magnetometer-disabling-trace is cut, ext mag (HCM5883L) is mounted 10cm above the frame, compass-dance done.

    2) The magnetometer is giving valid magnetic field strength in x,y, and z directions (Mx, My, Mz), visible in the status tab in MP and apparent in both the logs (attached) and the pics below.

    3) Sometimes the APM sees this data, sometimes it doesn't! No discernible pattern.

    Is there anything in code that could cause this oddity intermittently with an external magnetometer?

    Pic1: Rotating just the Mag, 'Y' value changes but yaw/heading (red) does not. (incorrect)


    Pic2: Rotating the Mag, 'Y' value changes and yaw/heading changes. (correct)


    Ext_Mag_working_2013-09-29 18-16-19.tlog

    Ext_mag_not_working_2013-09-28 12-01-44.tlog

  • Testing again 3.1-rc2.

    I did notice that INS_MPU6K_FILTER is default as 0 zero, when installing the firmware after on a reset/erase on APM2.5.

    Is that normal to be zero as default? Usually I did have it as 20 in previous releases.

    Also I did notice that the vertical speed on Auto is like 2x slower on 3.1-rc2 comparing to 3.0.1, although WPNAV_SPEED_UP is 250 on both. Something is weird.

    I can increase this value, but I would like to know the correct value.

    I am doing missions at 80m altitudes like this and time to arrive as such altitude is like almost doubled.

    Search Results for “criro1999-aerial” | 360Cities
    Search 360Cities’ large database of 360° panorama content for your VR, advertising, game, or publishing project.
  • I'm going to pop this processor loading thing up into a new reply.  Joe Abrams has questioned the validity of my testing, in a somewhat disrespectful way, over at RCG (along with his snarky comments here).  Also, I want my findings to NOT be true.  So I am offering a bounty of $50 to anybody who can prove this is NOT a real problem, and show me where I've gone wrong. Seriously.

    First, I'll present my test methodology:

    The problem started when I was trying to use my H8 for a specific video shot, which is nothing more than a simple climb to altitude while holding position.  I have the camera on an AlexMos type gimbal, and I've got the Camera Mount running, but only in a minor way. I'm simply using it to do Ch8 to Ch11 pass-through, without even any stabilization, in order to simply control the pitch of the AlexMos.  I've been struggling with poor performance of Alt Hold for a while, fiddling with the PID, and could never get it where I was happy with it.  On Tuesday was the first time I tried using Simple mode in Loiter, and the results were quite bad, so I stopped until I could figure out what was wrong.

    So on Saturday, I took my Nerf Quad (a Tarot F450 frame) and started doing a specific test, in a controlled manner, to load up the processor.  The first problem was that it's a quad, not an Octo.  Randy had a good idea to program it as an XOcto or Octa-Quad.  You can do this easily if you just switch motor wires 2 for 3, it's obvious when you look at the motor matrix that you can do this.

    So that's what I did.  A series of tests, in Quad mode, and in XOcto mode, while turning various features on and off.  Each flight I attempted 2 climbs in Alt Hold mode, and 2 climbs in Loiter.  Then I would download the logs and have a look.  Pretty simple.  You will find all of my data logs here, and you will find all the log titles fairly descriptive:

    Here's sort of how I got started on this path.  Early on, I noticed that the climb rate was different between Alt Hold and Loiter.  This, despite the fact that they use the EXACT same controller.  Obvious I was holding full up throttle in both tests, and you can see the DCRate which is Desired Climb Rate, is exactly the same in both.


    So why is that?  It's because of this line in the Alt Hold controller:

    controller_desired_alt += target_rate * 0.02f;

    That 0.02f is the rate that we are integrating the target rate.  It's a hard-coded assumption that this function runs 50 times per second.  If that function were not to run 50 times per second, then the target altitude would not increase at the desired rate, and the actual rate will fall behind the target rate.  So that was my first clue that the Alt Hold controller was not running as often as it should.  The AH controller is run under the "50 Hz loop".  But this controller does not necessarily run at 50 Hz.  It tries to, but it will get the boot if the processor is running too slow for the main 100Hz loop to run at 100 Hz.

    I proved this out by hacking up the program such that the AH Loop calculates how often it is being run, and replace that 0.02f with the real rate it's running at.  Now the WPAlt should ramp up at the correct rate.  This test is contained in the datalog with "timer" in the title.  So here you can see that this fixes the ramp rate problem.


    But this just masks the problem, it does not solve it.  The problem is not the climb rate, that is just a symptom of the problem that the 50Hz loop is not running fast enough.  And that was in Quad mode!  So, I kept going, to see how bad it gets.

    Here you can see some tests with a Quad.  I can actually infer what rate the 50Hz loop is running by looking at the actual climb rate.  In the first example, it climbs at 200 cm/s in Loiter, with a target at 250 cm/s, so I would guestimate it's running at about 40Hz.  With Mount turned on, it appears to be running about 38Hz.


    Ok, so what about Octos?

    Well, first we have an XOcto, without Mount or Simple Mode.  Doesn't look too bad, but I can see the AH is only running at 20Hz!:


    Now, let's turn Mount on.  Uh Oh!  Look at that Baro.  You can hear the motors surging.  This is because as the processor slows, the scheduler starts booting Baro Accumulate, which is what filters the baro:


    And finally, we come to XOcto with Simple and Mount running.  This is where the process completely breaks down.  Look at the baro data!  It's gone to hell, and it's dragging WPAlt with it!  This thing tried to fly away, fell to the ground, all sorts of stuff.  I tried running this test several times, but it kept crashing.


    All of this testing was done with the EXACT same machine, in exactly the same environmental conditions, over the span of about 2 hours.

  • Quick question. Do I have to re-calibrate everything (compass, accell, radio, compassmot) after loading a newer firmware?

    I did not do this after loading 3.1-rc2. If this is needed, I will have to report back with my Loiter results (funny thing the word Loiter in Dutch almost sounds like "Leuter". You don't wanna know :p)



  • Can anyone tell me if ROI is working on this or the 3.1RC2 beta?

    I tried both ROI, and DO Set ROI

    With ROI I set a waypoint, then set ROI then more waypoints, and when it hits the ROI item it just sits in loiter forever.

    With Do Set ROI it goes to the next waypoint looking at the ROI Lat-Lon as set, however on the following waypoints it goes back to facing towards the next waypoint.

    So Do Set ROI works, but I have to set


    DO Set ROI


    DO Set ROI

    Any idea's?

    Also when setting ROI or DO SET ROI there are 4 zero's, lat lon, alt and grad. Any explanation for what these do, or how they should be set?

  • Hi,

    I have been trying to get an Octa-quad working correctly and I have one problem I cannot solve. it is the same problem as I brought up here a while ago.

    the copter works great except in althold or loiter when I try to control the throttle it does not respond properly, very slow to ascend or descend and the motors spurt. say I am in loiter, I move the throttle to full and for 3 or 4 seconds nothing, then it may start to rise, then stop "hover" then another spurt of power and up again. descending is the same,in loiter, I decrease throttle to zero, sometimes it will still hover, then after some seconds it may start to descend, again in spurts.  also in land mode it sometimes just hovers then when it does descend it is very slow.

    It does this with even the 3.01 stable FW, it also does this with any FW I have tried from after august (RC2 I just tried)  but the very first FW I tried on this Octa-quad did and still does seem to work properly it is the firmware dated 2013-07-27-01:07. with this it seems fine.  also I have tried this with a PX4 on the same octa-quad, just swapped the APM25 and the throttle control problems go away with any FW I have tried (I have other worse compass problems with the PX4, so Ive about given up on it)

    I dont know what to try, I have rebuilt this copter a couple times. there are some big differences in the params from the FW that works and the ones that do not, I will attach a pic of the differences. I also have a log file.

    thanks for any help,


    2013-09-29 19-29 1.log

    parm diffs julyFW to althold throt problemFW.jpg

  • I'm testing 3.1rc2  for 3 days. Everything was perfect. But today;

    Loiter was engaged  full time at the video it flew unknows location with 11 sats and 1.47 hdop. My gps working 5hz but i saw gps time strange jumping. This may be a problem?


    2013-09-28 22-37 59.log

  • Hi All,

    Little help please..

    1. This is the first time I am using HK ESC F20A stock firmware (not SimoK as I usually used) but I still cannot calibrate the esc, anyone using the same ESC and succeed to calibrate the ESC?
    2. I'm using HK 3.01 and Radio calibration was repeated several times and successfully calibrated. But compassmot error said "Throttle not zero, exiting", is it because the ESC's not calibrate?
    3. Assuming the ESC is not yet calibrated, I cannot arm the board even if the ARMING_CHECK parameter was set to "0" = Disabled. Is it normal to unable to arm even though ARMING_CHECK parameter was set to "0" with ESC not calibrated yet?

    Thanks in advance.


This reply was deleted.


DIY Drones via Twitter
21 hours ago
DIY Robocars via Twitter
RT @Heavy02011: @diyrobocars : A Home-brew computer club* for Connected Autonomous Driving on Jan 23rd, 2021 #Meetu…
21 hours ago
DIY Robocars via Twitter
21 hours ago
David Hori liked Isabella Domi's profile
DIY Robocars via Twitter
RT @Heavy02011: ⁦@diyrobocars⁩ Autonomous Driving Assembly at #rC3. join us at ⁦@f1tenth⁩ ⁦@DAVGtech⁩ ⁦@DWalmroth⁩…
DIY Robocars via Twitter
RT @chr1sa: New car designs coming for our next @DIYRobocars @donkey_car virtual race on the 23rd. Choose any one you want at race time Le…
DIY Robocars via Twitter
RT @RoboticMasters: Thanks to @EllerbachMaxime and the Sydney Uni Capstone Students the @donkey_car @diyrobocars simulator is getting a ma…
DIY Robocars via Twitter
Jan 6
DIY Robocars via Twitter
Dec 28, 2020
DIY Robocars via Twitter
An interesting line-following simulator to use with with your robocars:
Dec 23, 2020
DIY Robocars via Twitter
Dec 23, 2020
DIY Robocars via Twitter
An improved version of the @IntelAIResearch OpenBot:
Dec 14, 2020
DIY Drones via Twitter
An improved version of the Intel OpenBot
Dec 14, 2020
DIY Robocars via Twitter
Dec 10, 2020
DIY Robocars via Twitter
RT @KN_Richardson: Delivery 📦😬 Early xmas present from @ccbdcdt ! Sims ready, will put h/w together over Christmas break. Didn’t need to mo…
Dec 7, 2020
DIY Robocars via Twitter
RT @RoboticMasters: Did we mention there's new car models in the #donkeycar simulator too? Here is an RB16 from team @redbull @donkey_ca…
Dec 7, 2020