ACRO bug (fixed in 2.9.1b): while doing flips in ACRO mode, if you switch to Stabilize while inverted your throttle will go to minimum. To regain throttle control you need to switch back to ACRO then back to Stabilize again (i.e. switch to stabilize twice). You never lose control of roll/pitch/yaw.
Loiter/AltHold/Auto/RTL bug: if you switch into these modes with throttle at zero motors will go to minimum until you raise the throttle.
Auto mode altitude bug (fixed in 2.9.1b): setting a waypoint altitude greater than 320m over home altitude may wrap around and instead be interpreted as a low altitude.
ArduCopter 2.9 is now in the mission planner and the downloads area!
The major improvement is we use inertial navigation to improve altitude hold. This increased reliance on the accelerometers means you must do some additional set-up before flying:
3. If upgrading from 2.8.1, modify the throttle and altitude PID values:
Here is the list of major changes (a more detailed list can be found in the release notes):
As per usual PIDs are optimised for the 3DR/jDrones quad with 850 motors and 10" props. If you're using more powerful motors/props and are seeing bad flight behaviour in stabilize, start by turning down Rate Roll P in 25% steps.
Special thanks to our testing team lead Marco and the dedicated bunch on the 2.8.1 release thread who put their copters at risk while testing the pre-release version. Some of their videos are here: 1 2 3 4 5 6 7 8
Please feel free to report issues you find in the discussion below and/or add them to the issues list.
If the AHRS_GPS_GAIN is set to 1, the ahrs will try to account for centrefugal forces due to changes in speed. This is certainly very important for airplanes but it's a bit unclear if it's important for copters or not. The annoying thing about having it enabled is that you see the HUD in the mission planner gets jittery if you don't have a very good GPS lock. Still, beyond that I don't think anyone has shown that it's harmful.
I'd be forever grateful if someone did a more objective test to show whether it helps or hurts but it's a difficult test to do unless you have some kind of external system that tells you what your real attitude is (like a vicon system).
Maybe a clue, but not a real test, when you configure DJI Naza you have to set the position of the GPS regarding the CG (for x, y and z axis) and if you do it wrong, there's some oscillations of the copter.
So it seems there's an effect.
Personally I always kept at "0" on all my test.
Randy many thanks for getting this out,your a true star,just need to start getting to grips with it,Marty.
With your post in mind, I just upgraded to the official 2.9.0 via Missionplaner. Without repowering or anything i could access the menues including the cli to do erase/reset. Somehow there is a magic spell on your serial com doing also evil to your gps update trails....
Anyway i couldn't resist, calibrated everything and took it for a spin on my quad. I have already repaired my faulty dampening (a loose alu-plate produced acc disturbance) over the 29.rx generations. Althold was doing very well on stock parameters (sonar deactivated). The rest of the flight was a little bit shakey because i didn't put in my normal rate_Pids... . I didn't do tuning or anything, because my fingers started to freeze in the cold. For me it's the best release (flying since 2.7.X on apm)!!!
P.S.: BTW I am also really looking forward for BLheli FW for my SIL-Chip Skywalker 20A ESC http://www.rcgroups.com/forums/showthread.php?t=1686498&page=27 so my quad will be perfect this weekend ! [VERY BIG SMILE ON MY FACE/]
excellent team ... i work a lot for my job whit open source sw developer team ... this is over the top for many reason passion, commitment, competence, vision etc. ...
Haven't been able to download it through Mission Planner yet..
"Update Failed Timeouts are not supported on this stream."
Guess will need to wait my turn :-)..
Randy, send me a PM with the specific data you want... I don't have the time to do any analysis myself, but I can likely get time in our MoCap studio in the next few weeks to capture internal and external observations (provided there's no commercial work going on). We have a very large studio with a 24 camera system, capable of 120Hz full state observation. That should be sufficient for your data needs.
Hi, just some observations in missionplaner:
While setting up RTL altitude and RTL final altitude i get an LED pin error (Requester) upon writing the changes. After resetting apm and restarting mp i can verify, that the values are written correctly.
Setting under advanced parameters MPU6000 filter to default in the drop down menue the value written to the variable in adv parameterlist reads: 0. The explanation text in the prior menue says that the default for arducopter is 42Hz. But when you change it to 42Hz the variable also reads 42 and not 0 anymore. Probably the default "0" will be interpreted as "42Hz" internally?
You're right. We've moved to github. We're now only using the google code for the wiki and downloads area. The issues are being moved over to github as well.
Yes, both "0" and "42" will be interpreted as 42hz on arducopter. Load up arduplane however and "0" will be interpreted as 20 (I think).
Ok, I've recreated the error you're seeing when you try to change RTL_ALT_FINAL. I'll ask MichaelO to have a look at it. My guess is that when you change the RTL_ALT_FINAL that MP screen incorrectly thinks that you're also modifying the LED_MODE. Must be a small bug.