ArduCopter 3.0 is ready for widespread use.  To make the transition easier, this time we are asking people to voluntarily upgrade from 2.9.1b for the next month or so before we make 3.0 the default firmware downloaded by the mission planner.  The new version can be found in the Mission Planner's Beta firmware's link,, GitHub and the new Downloads Area.

Warning #1: A bug was found in the FENCE in which if you lost GPS it could lean at extreme angles as it tried to maintain an invalid position.  This is fixed in AC3.0.1-rc1.

Warning #2: This release has not been fully tested on Traditional Helicopters

Warning #3: GPS glitches can cause sudden and aggressive position changes while in loiter mode.  You may wish to reduce the WPNAV_ACCEL to 100 and Loiter PID to 0.2 (from 1.0) to reduce aggressiveness.

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.

2. Click on the MissionPlanner's Firmware screen and click the "Beta Firmwares" link on the bottom right.  The version numbers should update to "ArduCopter-3.0.1rc2", 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. If you purchased an APM prior to March of 2013, update your PPM encoder to the latest firmware.

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

Special Thanks to MarcoDaveC and the rest of the beta testers for putting 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.  

Added by Craig:

Please watch Randy's videos on setting up and flying APM-Copter 3.0 before you go flying.  They are excellent!

3DR Quad Set-Up Suggestions
AC 3.0 "Live" Compass Calibration
AC 3.0 CompassMot Setup      
AC 3.0 Pre-Arm Checks            
AC 3.0 Fence                               
AC 3.0 Maiden Flight Checks   

Views: 134270

Reply to This

Replies to This Discussion

I'm not sure I get it either.

The advantage of not using this is that even without radio failsafe enabled on the APM, the PPM encoder will send throttle low and CH1,2,4 = 1500 us. This will drop the copter from the air.

By bypassing the encoder with the solder pad and using ch5 for ppm we have the risk of copter dropping out of sky if APM failsafe is not set? That is what I would expect to happen.

I think some minimum fail safe should be set by default in case of radio loss. At least a slow descent and land. If the user wants to enable more sophisticated actions like RTL then it can be set, Dropping out of the sky should be almost impossible with the default settings. It's even more important for the less experienced.

Reminds me of a jogging drone that would self locate based off a color pattern on the joggers shirt. If it ever got blown off course too far and couldn't relocated then it would just land itself until the jogger walked in front of it again and it detected the image.

Bill, as soon as your receiver is capable of cutting its servo (PWM) or PPM outputs during radio loss, or set CH3 to a value < 975 us, then the radio failsafe situation will be signaled to the APM regardless if you are using PPM or PWM mode. Then the APM code will mute CH1,2,4 and 5 during radio failsafe to avoid problems if those value are not set correctly on your receiver during failsafe.

The only small problem actually is that the APM code can't differentiate between a receiver fault or a receiver failsafe condition. In both cases the APM will switch to radio failsafe mode and the same event will be logged. Obviously this is not a big problem and will be solved as soon as we'll use 800 us to signal a receiver hardware fault and 900 us to signal a receiver failsafe instead of 900 us in both cases.

More, when we'll switch to the 800 / 900 us signaling method, the signaling will be independent for each channel. Actually only Channel 3 is able to go to 900 us. This will permit a better situation analysis for the APM code.

To my knowledge we are supporting almost all receivers using the actual PPM encoder behavior. This did ask a large amount of discussions, user reports, testing and a few months of development before to get there.


Steve, first it is not recommended at all to not use the radio (throttle) failsafe. It is clearly explained in the wiki :

  • The Throttle Failsafe is the single most important failsafe.
    • The Throttle Failsafe will attempt a preset flight recovery if you lose your RC radio link.
    • Your RC radio receiver must be configured correctly for the Throttle Failsafe to work correctly.
  • Failsafe flight recovery actions depend on the flight context.

How it works.

Your RC transmitter outputs a PWM signal that is captured by your receiver and relayed to the APM. Each channel on your transmitter has a PWM range usually between 1100 – 1900 with 1500 being its neutral position. When you start your radio calibration on the mission planner, all your values will be at 1500. By moving your sticks, knobs and switches you will set your PWM range for each channel. APM monitors your throttle channel and if notices a drop lower than THR_FS_VALUE (Default is 950) it will go into failsafe mode.

RC transmitters usually have a default range for each channel that goes from -100% to 100%, however most transmitters will allow you to extend this to -150% and 150% respectively. In the default setup, bringing your throttle to -100% will translate to a value close to 1100 and bringing it to -150% will translate to a value closer to 900. What we want to achieve is to let your receiver know that the throttle can go as low as -150% but keep the APM control range between -100% and 100%. Meaning that when flying, our throttle values will range between 1100 – 1900. But if we lose RC range, the receiver if set up properly, will drop to the lowest known throttle value of ~900. This value falls bellow the THR_FS_VALUE and will trigger the APM to go into failsafe mode.

If you don't use it, your copter will soon or late flyaway or drop from the sky during radio loss, except if you did set RTL or LAND using CH5 and your receiver failsafe capabilities. But it will be a poor's man failsafe unaware of the flight situation.

Regarding the difference between bypassing or not the PPM encoder when using a PPM sum receiver, it's safer to use the PPM encoder in passthrough mode, because it will send the 900 us CH3 value to the APM (to signal radio failsafe) only 250 ms after a receiver hardware failure.

If you fully bypass the PPM encoder and your receiver stop working or stop sending a PPM sum signal, then the APM code will wait 2 seconds before entering radio failsafe mode. This is longer. A 2 seconds freefall is about 20 meters altitude drop.

I did choose 250 ms for the PPM encoder failsafe because it is only about 30 cm of freefall and is large enough to tolerate a few missing receiver frames.

The difference is not so important because full receiver failures are rare. The main reason for the presence of this PPM passthrough mode on the PPM encoder is to get a simple PPM connection without modifying the APM board.

I'm not sure I get it either.

Thanks for the log file.  It is interesting to see the behavior of the Simon K ESC.  As Leonard said, there is a patch in the works for improving performance with that firmware.

Craig and Leonard, thanks. After digging into log.pde, I found the same info.

Still puzzled why my Roll/Pitch doesn't seem to follow DRol and DPit.

Guess it's time to take a closer look on my frame.

Yes I know and always use it but I was thinking it could be made easier to implement and enabled by default. Press a button in MP that instructs the user to turn off their tx and then it would record the low throttle value and set up a minimal failsafe like auto land or rtl. For me it doesn't matter as I always use it but for new users it might be better. Maybe could be added to the prearm checks.

Unfortunately the transmitter and receiver can be set up so the value sent when the TX is off is the same as the low throttle position.

Have the mission planner issues been resolved?

Which version / Which issues?

Mission Planner (Versions: 1.2.56, 1.2.57, and 1.2.58) having issues with connecting to the terminal. 

I've been holding off from updating because several members posted having difficulties when connecting to the terminal or something not working properly.

How to upgrade:

1. Make sure you are using Mission Planner 1.2.59 or newer.

The biggest issue with the recent releases has been that in previous versions when you selected the Terminal tab it automatically connected to the cli on the APM.  Now you have to connect manually and that was not sufficiently explained.  We made that change to prevent sending an accidental re-boot command in flight.

Thanks for the heads up. I'll update to the new version.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service