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, firmware.diydrones.com, 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:
WPNAV_SPEED, WPNAV_SPEED_UP, WPNAV_SPEED_DN, WPNAV_ACCEL allows configuring speeds and acceleration during missions
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.
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 Marco, DaveC 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 here, here, here, here, here 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!
I also have xbee telemetry and mine works fine. I think your problem is that your are connecting to the MP before going to the terminal. tab. This is how I do it: Open MP (dont connect to APM) -> connect flight battery to APM -> wait 3-5 seconds -> go to terminal tab -> then click the "Connect APM" button...
Brilliant! Just what I need as well. When are planning to release it Randy?
Not so sure about the mechanical problem part though - my air frame and motors are tip top?
Thank you for reviewing my logs.
Actually, my PID were pretty fine, my CH6 tuning was only about +/- 20% of the nominal rate P and I wasn't doing any PID tuning before crash.
My failsafe value are neutrals, except for RTL switch.
The frame is a 450 clone with 1000kV motors, 2.2Ah battery, 30A ESC, 10x4,7 prop, all soldered connections.
I wouldn't say it's correct that the Tx failsafe should be disabled. That implies that when the tx/rx lose contact the tx/rx does nothing. That's not correct. You need to set-up the tx/rx failsafe so that it pulls the throttle below the FS_THR_VALUE (which is by default 975) and then you should enable the APM side's throttle failsafe so that it RTLs when the tx is turned off and and bench test that that all works.
I've raised an issue on the issues list here. I don't agree that it's a "bug" but I do agree that we need to cater for all the popular tx/rx systems including FrSky. As mentioned on the dev list, there is another potential solution which is that some FrSky units at least allow you to set-up the failsafe so that the receiver simply stops sending signals to the APM. That would also trigger the failsafe and the ppmencoder would store the last good values. If an FrSky user out there could give this a try and report back that would be greatly appreciated.
Apologies to all those people who's logs I haven't been able to look at over the past few days. I'm on vacation so I've fallen behind a little bit and there's a couple of small issues that Leonard and I are trying to sort out before we push out 3.0.1-rc2 and hopefully the final release to the mission planner. The issues in case you're wondering are:
1. make the red arming light double flash when your APM fails the pre-arm checks (done!)
2. smoothing out the nav controller's outputs so that SimonK ESCs don't wobble while in Loiter
I just use Frsky failsafe to switch to RTL. Simple and never failed me. I must learn to use the Arducopter FS one day.
I learned the hard way that it's best to use both. Set receiver failsafe to output 900 throttle AND RTL mode.
Great, thanks Randy. The reason I called it a "bug" is that the behavior disagrees with the documentation. You could also argue that it's not a bug, but incorrect documentation instead.
I would try the "no pulses" FrSky failsafe, but wouldn't that increase the failsafe delay, thus making it more likely to crash into something before failsafe engaged?
You are right David. The wiki is not adequate.
The receiver failsafe must be set to hold mode for Ch5, or to a value corresponding to a mode different from acro or stabilize to avoid disarming with the actual code.
We have this hold behavior in the PPM encoder failsafe. If the receiver Ch5 become dead, then the PPM encoder hold the last good known value.
Cutting receiver ouputs during radio loss is a solution with FRsky, but will add one seconde delay before switching to radio failsafe because the PPM encoder will hold throttle channel during 1 second before to switch throttle channel to 900 us to inform the main APM code about a radio failsafe situation.
Randy, this is only true with PPM encoder 2.3.16. For earlier boards with 2.3.13 version, the behavior is to switch Ch5 - Ch8 to failsafe values instead of holding.
I think that we should add the correction to avoid recognizing a ghost mode, and perhaps add another protection before disarming, like watching baro altitude (do not disarm if baro alt is > 10m)
>> That would also trigger the failsafe and the ppmencoder would store the last good values
I've always had RTL on my main mode switch which is a 3 position switch combined with a mix switch to get 6 modes. Now I'm thinking to put RTL on a dedicated switch like ch7 or ch8 but I'm wondering how it would work. A couple of examples I can think of:
You are in alt-hold mode or any other auto mode and then RTL via ch7 or ch8 but then before it completes the RTL, switch it back off. Will it go back to the auto mode that the 3*2 position switch is in?
What if you change the 3*2 position switch during the RTL? Does it interrupt the RTL? If I switch off the ch7 RTL in that case does it go back to the current mode or the one prior to the switch?