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.
It looks pretty good. A couple of comments:
Perhaps it's implied but just in case, ThrOut will follow ThrIn in 'manual' flight modes like Stabilize or Acro. It also won't follow when your copter leans over far too much (i.e. goes up-side-down).
GPS:RelAlt is actually exactly the same value as the InavAlt. It's of course very odd that we put the combined baro+accelerometer alt into the GPS message..it has absolutely nothing to do with the GPS. That'll be fixed in an future release.
For NTUN messages I normally look at the DVelX vs VelX and DVelY vs VelY. X = North-South, Y = West-East. If they don't track well then the compass is normally off. maybe inteference from the motors or orientation is incorrect.
It looks like a mechanical failure. Perhaps of the back right motor or ESC. You can see the Roll (green) suddenly diverges from the Roll-In (red) as does the PitchIn vs Pitch. Positve Roll means it rolled right, positive pitch means pitched back so it rolled right and back indicating the back right motor or ESC probably failed.
Looks like you conveniently had MOT logging on so we can see that just before the crash motor #4 (the back right one) was running the slowest. This kind of thing can happen if the ESCs aren't calibrated.
The Crash Detection kicked in by the way (ERR 12) at line 2998 which shut off the motors.
A hex can somewhat survive a motor loss but it loses yaw control so best case it will spin a lot on it's way down. This is not a software thing but just the physics of the configuration...in this way a Y6 is actually much better.
In log #9 it's only in loiter for 2 seconds, in #10 it's in loiter for almost 6 minutes and according to the GPS it deviates less than a meter that whole time. The hdop does jump up-and-down between 1.8 and 2.4 during the logs so if these are the logs showing the problem then it would be the GPS position that was drifting.
I just had a look at your logs and according to the GPS position the copter was always within 1m of the target...actually much less than 1meter. So if those were the correct logs then I'd say it was the GPS position that's at fault.
Ah, but it doesn't become a quad. In the example below we've lost the left motor (red X) so we cut the right one (pink X) but then check out the motor direction vs the quad. The copter can't decouple the yaw control from the roll or pitch. The only way to maintain yaw control is not to cut the pink motor but rather to reverse it's direction as required to make it maintain yaw. This is what the Aztec hexacopters do. We need special smart ESCs to do this though.
Whether it has 4 or 5 motors, the issue remains on how to control yaw. Basically if we try to control the yaw we end up introducing a roll which means the copter flips over...which is much worse so we just have to give up on controlling the yaw. In the code though we don't actually make these choices directly, they're the outcome of competing I terms in the PID controllers for roll, pitch and yaw.
..but please try for yourself! I have by disconnecting two opposite motors and then try to take-off. I don't think it will go any better having 4 motors vs 5 but I'd be very happy to be proved wrong and it might add to our understanding of the problem.
Command and control links that are secure and away from standard equipment is one of the reasons for the allocation moving forward of off the top of my head 7ghz freqs by WRC. When that is all rubber stamped the new frequencies will be the only ones approved for UA operation, private or commercial. Worldwide.
Ok thx...i think New x(or New Y6) is the way to go...also same size props on top and bottom as well...
I think in a 'motor out' case we should not try to control the yaw anymore but just let it spin its way back home. Perhaps even boost the spinning for some gyroscopic stability. That way we dont have to shut down a working motor.
i whole heartedly agree, some kind of protection should be in the immediate future.