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:
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 (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.
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 Marco, DaveC 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 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.
Ok, so the good news is that it switch to RTL eventually. The 2 second delay is the designed delay between when the ppmsum stream stops arriving and when the AC decides it's time to initiate an RTL.
I'm afraid that setting the receiver failsafe so it cuts the ppm stream doesn't work particularly well with the APM2. The problem is that the ppmencoder normally (ie. if you're using the most up-to-date value) overrides the missing values with numbers around 1500 except for throttle which goes to 900.
By the way, AC3.1-rc5 (available through the mission planner's firmware, beta Firmwares link) has some improvements in the failsafe handling in particular it ignores flight mode changes and switch movement changes if they happen during the failsafe. This probably wouldn't have helped in your case.
Thank you Randy.
I found the 2000ms delay in radio.pde. Why doesn't it continue to check for the throttle pwm being less than the f/s value even when valid_channels is 0? With this check while waiting for the timeout it would have switched to RTL after 3 cycles as it would do with PWM f/s set.
The board is a genuine 3DR board bought a few weeks ago. Shouldn't it have tje latest PPM encoder?
Btw: This is the sequence of events
8730 Roll/Yaw/Pitch_in go to their min values (900)
8878 Err 2,2 (Radio late frame)
8879 Mode RTL
8880 Err 5,1 (failsafe occured)
How do I calculate the time between lines, e.g. 8730 to 8878?
Thanks for your help
Hi Randy .. I have been sitting back reading and learning with all the emails I get everyday of the chit chat on this forum page.. I notice you say in the above I quote " 3.1 rc5 it ignores flight mode changes and switch movement changes if they happen during the failsafe" This concerns me as, if we have a situation where the machine decides it is going to come home due to fence RTL or other failsafe .. If we want to regain control (because we see an obstacle in the flight path) we will not be able too ?
Randy does this comment you advised earlier still apply in rc4 to get better throttle height control stability?
"Re Throttle Accel vs Throttle Rate, generally you should only need to tune the throttle accel P and I terms. Remember to keep the ratio of P to I the same as the default. I.e. raise or lower both by 20% (or whatever)."
In the Wiki it seems to recommends tuning THROTTLE_P which I am assuming is THR_RATE_P as its listed under the full parameter list and not THR_ACCEL_P?
"The same is true for Altitude hold. Throttle Rate P needs to be adjusted to get optimum altitude performance."
"My copter increasingly swings up and down in alt hold. It eventually get’s down to the ground: Your THROTTLE_P is too high or low. You don’t need a lot of P to do alt hold. Think of how much you move the throttle to hold alt perfectly. Not much! That’s what you need P to do. I will ramp up as your battery goes lower to make up the difference."
I also assume its best to fine tune Roll/Pitch RATE P first before doing the throttle tuning?
I will wait to see how Randy answer the ^^^^ question. I wonder it myself as well...
I tried alt_hold again with sonar_gain set to 0.2. It was much better however my quad still moved up and down with times but never stayed on the same height. If I remember correctly the last time my alt_hold work perfectly was in 3.0-rc2 but ever since then it has not worked the same again...
How high were you flying? As the air pressure changes with change of weather this affects the baro and on some days you can get very noticeable high variation drift. Or your Throttle Rate P might be a bit high.
Im flying around 2m above the ground (maybe less) when I change to alt_hold mode...
Here in Lyon France the menu for the day is rain and wind (40km/h) so i will just replace the dampeners with nylon spacer to make new test when weather permits.
One other question :Yesterday most of the time the auto tune would not start or arbor the procedure after few twitches !!! Do you thing I should put the default pid's for this beta version 3.1-rc5.
No, your current pics should be fine. I will look at your logs as soon as possible but I am in hospital with my son at the moment so it could be a while.