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.
Yes, it could be a lock-up.
Are you forgetting what just happened to me? There is no way to prove it was a lock up. It isn't just a coincidence that the reports are happening with 2.9.1. It's easy to say there haven't been "any lock-ups," because There is no way to prove them because the logs just stop. It's far easier to blame other things. I don't think people have just suddenly decided to fly with weak or uncharged batteries to see what would happen!
Pablo, this is very much like what happened to me. I had a fresh battery and it was in good condition when the logs just stop and my quad crashed 160 feet from where they stopped. I had never had anything similar to this happen to me in 2.8.1 or previous. It's hard to prove a lock up but the evidence is mounting that something is drastically wrong with 2.9.1. I'm sure the devs will get this sorted out. Don't believe the brownout theory unless you have overwhelming evidence that it is what happened. It's far to easy to blame the pilot.
I agree it could look the same. But I have been flying with all my logs turned on while doing all my testing. I haven't had anything that resembles a brown out or lockup. It doesn't mean it can't happen but I don't believe it is happening here.
It looks good Pablo. The only thing I can suggest is hooking up a digital servo (or something else to draw some current) and checking the voltage output.
Unfortunately I have a lovely video of my quad crashing on a holiday and I believe that it was simply one of my connectors slowly vibrated loose. Your problem could have been as simple as that.
The Alt_Hold has a narrow deadband, 20%, so the short answer is that it is probably climbing because you are telling it to. By the sounds of it you are right on the edge.
Can you stop it climbing by moving your throttle down a little?
If you send me a .log file I can tell you exactly what you need to set Thr_Mid to so that your hover throttle corresponds to the middle of the dead band.
This isn't a problem with your tuning parameters. The terrain following feature is a new one so we haven't got it really working perfectly yet. As you say, it can be a bit abrupt.
Hey Pablo, I noticed that you have a gimbal attached. Was this attached and turned on at the time. Did you have the camera on board (I hope not).
The reason I ask it because a stalled servo can draw a significant amount of current. I had a problem where I had to remove my servo's before I plugged in the USB or I would get repeated brown outs. I know that the USB isn't the same as a BEC but ideally the power that drives the servo would come from a separate BEC.
The other thing that may help make things a little more reliable is I don't use the single lead servo plug's like you have here. I get a 8 (or even 3's) and put multiple connectors in each plug. I just feel more comfortable that a single lead can't work loose, instead 3 or 8 have to come out at the same time.
Tony would like you to believe that 2.9.1 has some major change it it that is creating random brown outs but the changes between 2.9.1 and 2.8.1 aren't very significant and it is highly unlikely that this is the case. I would suggest carefully going over all the likely causes of the problem before putting it down to a problem with the code. Even if it turns out to be a problem with the code you end up with a more reliable copter.
I wasn't aware of the flip issue but i'll have a look at it. It's certainly handled different than everything else.
Sorry, I should have said, "we haven't had any cases of proven lock-ups in a very long time". ....and before anyone says, "ok but you won't find them if you declare them all as brown-outs" please remember I do very much want to find any and all issues with the code abs I'm spending pretty much all my time now looking and testing all kinds of things (yesterday for example was the GPS).
Documented and reproducible cases are really valuable in helping me pin down issues.