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.
Nice video... and bareback in the water no hands too holy C**P! :)
GPS_position +previous_GPS_speed*1/5 should match the next GPS position aquired 200ms later. So GPSGLITCH_RADIUS should be much lower than the default 10m, i use 1 meter (100cm) with success. 10 meters won't filter much glitches.
And one more thing:
If you accelerate more than previous speed by a GPSGLITCH_Radius/0.2, you would be filtered out by first condition, no need to add an extra ACCEL condition for gps.
my two cents
That's a cool video!
Thanks for the reply Detlef. The board is an original APM 2.5+ that I purchased in July from 3drobotics.com. I've done the reset/erase to no avail also. I am hoping it's not a HW issue. I'll just go back to 3.0.1 for now.
In my case I would have blamed cheap grade chinese components but if it happens to 3DR boards as well then I hold off buying an original which I would have almost done this week. Every time I go back to 3.0.1 my APM acts normal - not the slightest move when sitting on the desk with the MP connected - and it flies very stable.
Maybe our two boards have more noise coming from the accelerometers or gyros but the new 3.1 software must also be more sensitive for that in order to pick it up since the 3.0.1 doesn't seem to care. I also tried last night all the MPU filter values without any positive change.
seems that it has no influence to the system. Did not change anything, left by default to Zero, Compass_orient ROLL180 as I used this before. Test flight with autotune was ok, as expected.
Yeah - she is definitely braver than I am :)
By spinning, I don't mean that motors should spin at rpm high enough to get the copter off the ground.
If set up right, motors should spin at low rpm nowhere enough to move the copter. This way even if there is a motor spinning at wrong direction or reverse flight control, copter wouldn't flip at all.
I generally handhold my copters to do direction check at low rpm level to make sure all motors are spinning at right direction and all controls are working fine. This saved me two crashes already due to miss-wired etc
However, I do agree that in case of a crash where the copter is up-side-down position, continuously spinning motors may make the matter worse.
I believe the code can be modified to overcome this issue as well. Say for example in normal flight conditions (even if someone is doing stunt maneuvers), copter shouldn't be upside down for more than a second. The code can be modified (or another parameters could be added) so that if the copter is in up-side-down state for more than 2 seconds (for example) motors shut off automatically. And this should not be difficult to do at all...
What's the horse think of the vehicle flying around it?
I fly regularly down in the paddocks. They are very used to it now :)
Yeh, the idea is that a ACRO beginner can start with a large acro_balance_XXX and work down to 0.25 to make it more and more acro like, then start using the switch to turn it off competently.
ANGLE_MAX is the maximum angle in stabilize, so it doesn't have anything to do with flipping or rolling. With ACRO_TRAINER set to 0 there is nothing to stop you. Just start with plenty of altitude and hit stabilize and full throttle if you get in trouble.
This could be caused by the increased rate that we are reading the sensors in rc5.