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.
Thanks! we've narrowed down on the issue. It's this commit. Rolling it back is easy but we want to investigate if there's another solution because this change saves about 3% of our CPU which we are horribly short of on the APM. Ideally we would like to be able to sense failures and then slow down the bus so that those that have very low noise boards can take advantage of the higher speed.
@Detlef, 8Mhz is good because we need to pull multiple values from the accelerometers and gyros. The faster we can get that data from the mpu6k chip into the main cpu the more time we have for other stuff.
I heard the Pixhawk was to be made available at the end of this month (i.e. now) but I think they're still at least 2 weeks away from opening the flood gates. Of course anybody who ordered the "developer" IRIS has a pixhawk already but I think they have uncovered some niggling issues (as with any product roll-out) and I expect they will want to resolve all those before starting to sell them individually. Let me qualify this by saying that I'm not really in the position to say so this is all my personal guess work.
Fair enough, I will add them all to the APM_Config.h file in a moment.
OK --- I have seen this point regarding the spinning Armed props:
You should not be next to the machine when you Arm it. To Arm a vehicle should be a deliberate and thought out process with the deterministic decision to ARM. OK here! So, to have the machine propellers begin to slowly spin indicating that the machine is active is an EXCELLENT Safety Precaution. If you are scared about the propellers spinning you should not be Arming the vehicle. Nor should you be standing close to a vehicle when you Arm it. Why? Read the posts about the unexpected flips, rocketing into the air, props going full throttle, fly-aways, etc...
Another point in favor of the props spinning on Arming: As we will sometimes be among others and some who may not be aware of activities - If the props start to spin when we Arm - Everyone Will Know Something Is Alive! Except infants, toddlers and dumb dogs - most will move back instinctively from the moving props.
My vote is: Armed - Spinning Props.
For the Safety and the advancement of this activity we as a community need to do and place advertised Safety features and functions. This consciously shows the FAA and other on lookers that we are aware and working to make our activities/operations, machines and presence a safe one. We need our propellers spinning on an Armed vehicle. This feature should be implemented as 'ON' by default to have the propellers spin. Then, if one wishes to change their own settings disabling the safety feature and to disregard caution it will be their own decision, choice, action and liable risk. This is like Air Bags and Seat belts. Except, here no one is hurt. We are saving each other and there are no age restrictions for this safety.
This is why I opted to put LED strips at the bottom of my quad arms when I first built it. When the quad is armed the LEDs are on and when the voltage drops to a certain level they start to flash. I prefer a visual light indication that the quad is armed compared to a visual prop spinning one...
I might as well chirp in too, I think props spinning as default is a good idea, people that are new to this, and are not expecting it need to get a little scared, this will get their attention without being dangerous. It will keep bystanders at bay too. Now maybe they will go back and read the warnings (or complain on the forum) Those of us who know about it will expect it or simply disable it. Having said that I disabled mine in favor of LED's and a buzzer, love the buzzer. Charles Lakins on here is selling this unit http://diydrones.com/forum/topics/apm-2-x-led-buzzer-modules?commen... which makes it super easy to install.
I've added a link to Charles's solution to the wiki as well.
I've got no problems with 3.1-rc5 and minimOSD. Flight mode and all other data display fine. Maybe its the minimOSD version you're using Steve. I'm using OSD extra 2.3 676... There are newer versions too.