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.. Here's the latest log and kmz files with the RTL glitch.
There are about 9 RTL's that were triggered by clicking the transmitter switch into RTL mode. I just clicked the switch once.
My hex was bobbing for a while as it turned around and came home.
RTL seems to be the onlyl flight mode that's bunged up. No other modes do this.
You say that is APM 2.5/2.6 is near its CPU limit and almost no space to grow new functions. Does that mean that Arducopter-3.2 (example) can have new functions that will work on Pixhawk but not on APM? Or you will hold back the development to accomodate APM CPU? I mean, when are you step up to pixhawk on a firmware?
We definitely will not hold back the development to accomodate the APM. So what we're doing is making it easy to turn on/off functions with a simple #define. AutoTune is a good example, we can add a single line like this to the code and it's enabled.
#define AUTOTUNE ENABLED
We can then turn these on/off depending upon the board. I'm sure AC3.2 will have features that will be pixhawk only.
So it looks like you were constantly hitting radio failsafes as the copter gained and lost radio contact. Each time it lost radio contact it would reinitialise RTL. This is not great behaviour really because you're already in RTL so it's a bit pointless. I'll add a fix in for AC3.1 that won't reinitialise the flight mode if you're already in it.
Thanks for the report!
10x5 props seem quite large for 900kv motors. I don't see this problem running 1000kv motors, 4s and 8x4.5 on a 'discovery style' quad, fwiw
I am running with APM2.6 with a modified original arducopter (lots of early crashes). I have been using V3.0.1 quite successfully until I had a rogue magpie attack at 10m up. I had only recently got the APM2.6 and external GPS and was quite happy with the work all the developers have put in. The only thing was the Loiter instability that worried me.
Are you saying that future versions of ie. V3.2 will not be usable with the APM2.6 setup?
Is there some way of documenting, for those who do not need all the fancy functions, a table of resources required versus functionality so people can pick and choose what they REALLY need without red-lining the CPU.
I have been waiting for feedback from users about beta version -r3. Is it worth having a go?
thank you so much Randy,this will be a great feature also will you please update the wiki,Marty.
I have some fail save questions:
I have set Low_Volt (what is now called FS_Batt_Voltage) to 14V. At 13.7V Land mode was triggered but the copter remained in some Loiter state. Where can I define "what action to take". I am preferring RTL. The 13.7V might come from a mixing of decimal separators in the German version - but I am not sure.
For the Fence Action one can select "RTL or Land". Can these be specified somewhere?
Thanks in advance,
Randy thank you for the synopsis on the beta code and APM transition. I wish I knew about this End of Life (EOL) notice of Arudino APM2 before I just purchased a new APM 2.6 and ublox GPS today from 3DR. I thought there might be fixes coming for the GPS and loiter issues and the better GPS would help with the glitches over my Media Tek.
This pretty much explains why things have been quiet on the issue fix front since 3.0.1 was released and if I interpret this correctly we will never be able to achieve a reliable stable autonomous flight mode with APM2 due to the unpredictable GPS fly away and loiter issues outlined in the 3.0.1 Warning notes. I stopped using the mission planner and setting any auto mode flights now for safety and cost reasons ( lost 2 complete frames on trying to debug the current code issues)
It sounds like the real reason these problems have not been fixed is it related more to the overloaded CPU in the APM2 and limited memory to load more sophisticated feedback algorithms / flight control solutions? . I can see now most likely timing issues in data processing are a direct result to APM2's overloaded CPU condition in flight. Not really GPS glitches from the unit or external factors. I never did by the whole satellite dropout explanation as the logs on all my flights never revealed loss of 3D lock rather there were time base issues I could not explain (gaps in the data streams from sensors especially GPS once in the APM for processing. In others words position info was correct it just never made it to the APM in a consistent timed manner in certain circumstances. I suspect there were cases of the old "garbage in garbage out syndrome". It also covers off on another observation I made that the Telemetry running back to the base station aggravated the situation. Again even dropping the telemetry update rate still does not relieve the CPU enough. For example I have less run away and bad position issues with Telemetry off (yes I verified radio / GPS interference.
Wow so pretty much APM2 is dead and there will be no more backwards compatibility in the code since Pixhawk and PX4 use proprietary code versus the more open and portable Arduino. Not to mention as you say no new features will be seen in APM2 specific to pixhawk.
I am sorry but I cannot learn a whole new and proprietary programming environment now I have become so used to Arduino. This is a personal note but I feel 3DR have abandoned their loyal arucopter supporters. It is very clear now there will be no APM3 32 bit development. I hate the look of this new PX4 and pixhawk equipment by the way. I know this is a subjective view but the APM2 looks really fantastic, The pixhawk looks like my TV remote and ergnomic mouse combined yuk:-)
You know all I wanted from the start is an autopilot that could maintain a stable hover good enough for photography and maintain a stable altitude so I could turn the copter around and make small adjustments without worrying about it suddenly falling off to one side or dramatically loosing altitude. Don't get me wrong you can get this at times but its unsafe / unpredictable.
Also and more importantly at a distance if I got into trouble, I wanted to be able to bring the copter back home to land safely. 3 years later APM2.6 cannot be used reliably in auto mode due to the GPS runaway glitch, cannot be used reliably in loiter due to another bug with means the copter falls out of the sky on turns or darts off unexpectedly. And as far as fail safe goes roll the dice on it being able to make is home due to again GPS and inability to keep up with its position at any given time due to . due to an overloaded CPU and memory constrained design.
So now you say all of these basic things are coming with growth in pixhawk overtime. Funny I remember the same thing when APM1 was at its limits. It is no wonder people are moving in masses to DJI and other commercial solutions which have these basic autopilot flight mode features with reliably and stable operation.
I do not want to seem ungrateful either this is not a reflection on the fantastic developers and efforts everyone in the forum has made. I also accept you will reach the resource and programability of any given hardware design. But with Arduino at least this transition made sense. Move from APM1 to APM2 and so forth. Now there is an abrupt cessation of development of APM2 and no further way forward with arduino meaning I have several autopilots which will never be capable of the basic things I mentioned before.
Perhaps we will see a code split and another group start to continue with Arducopter in the Arduino space on faster development autopilot boards leaving those who want to re-learn everything on PX4 / Pxhawk to go that path. I will certainly not be able to afford all the new equipment I have to buy to do this in the short term.
That's great news. Do you plan the same thing for parameters ARM_DELAY and DISARM_DELAY ?
you are right. After good experiences with NAZA I became fun of the concept and the Features of APM. But after one year with over 50 Testflight during 7 hours to tune the AltHld the best Result was +/- 2m. And this only with reducing the Rate Roll/Pitch from the ideal Value down.
I am shure I'm the only stupid on the world with such a Patience. But I couldn't belive th
at such a Primary function should not be correct implemented in APM 2.5 with 3.0.1 while permanently a lot of funny gimmicks are implemented.
Now my Hexa hold the Altitude within +/- 2m and is difficult to control like a dead leaf in the wind. Of course I did everything recommende like reducing Vibrations, magnetic effects etc.
Also every combination of params, Testing in a jig.
So during this time I could "Profit" of the Feature Stabilize and Hold Position ....
Flying with Wookong and NAZA between all this Tuning Tests where nescessary in order to see from time to time how it could make fun.
Replacing APM by NAZA Light with 30 Min Tuning Flights and the Problem was solved.
And now where the APM Patchwork became hols the developpers escape to Pixhawk
Try NAZA Light and you will find your dream.
I had this when I had a broken antenna wire. After several rapid RTLs coming from the MP it then said 'Disarmed' and the copter fell out of the sky. No chance of finding the log for that.
I think we all get a bit complacent with our range checks because of the RTL safety net.