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.
Just finish running autotune and I'd like to report that it works perfect for my quad! I think v3.1 now ready for it's official release.
Thanks to Randy, Leonard & members of Devteam!
Thanks for the link to Scott Berfield's blog. I've added that link to the external leds and buzzer wiki page and maybe someone will transfer over the information to the wiki at some point.
I'm 99% sure that the issue with your board is hardware related. Maybe the solder joint on that led is broken. I can't think of any software configuration issue that could lead to just that single led not working.
Ah, excellent. There's a fairly big vibration dampening wiki page here which is the collection of many discussions on the forums. I use 1/4" dubro foam but I hear moongel is better except that it breaks down when it gets hot.
The vibrations come from the motors and if you're using an 880kv motor and 3S battery (i.e. 12V) then the motors will spin at about 10,560rpm at full power which is 176hz (10560/60seconds). the ArduCopter loops run at 100hz although the accelerometer collection runs at 1khz.
Ok, thanks for the report. I'll have a look into that. It's weird though because the mission planner can see the flight mode and they're listening to the same mavlink info. We've made some unrelated changes to the GCS mavlink messages so perhaps something has gone wrong.
Anybody else tried -rc5 (or one of the earlier release candidates) with a minimOSD?
There's certainly reasons on both sides of this argument and many of the same points as above have been brought up on the drones-discuss list as well where I asked for feedback. Personally I like them spinning (I didn't use to) but I'm leaning towards turning the feature off by default for the next release. Mostly because historically that's how it's operated. We can see how the community goes with it and consider again switching it on by default for AC3.2 release.
Now that I've started playing more with the Pixhawk one thing that I really appreciate is it's tone-alarm and it's LEDs. That RGB LED actually works on the APM as well in AC3.1 and anybody can connect a piezo buzzer to the APM's A5 pin but not many do yet i think probably partially because 3DR doesn't sell them.
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.