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.
Don't touch the Rate terms until you can fly confidently with Alt_Hold. Then you can adjust the Rate terms for feel if you wish.
For some reason I'm unable to extract the contents of the attached rar files.
In any case, my guess is that you have stumbled upon an issue that Marco reported a few weeks ago. It seems that if you raw the copter quickly and continuously for a bit (maybe 30 seconds, maybe more?) the compass offsets will become incorrect. The likely cause is that the compass has some lag in it's readings and this is throwing off the offsets learning algorithm. An incorrect heading (or a heading that is not updating) could lead to a loss of yaw control.
I think you can resolve it by clearing out the COMPASS_OFFS_X, Y and Z values but the underlying issue remains (for now) and it will reappear if you do the continuous yaw for a while.
I've raised an issue to capture this here.
For this particular issue I'd really like to see the tlogs 'cuz then we can hand them over to Tridge and he'll likely whip up a solution.
whenever I download logs I nearly immediately copy them into a separate folder.
Enabling too many logs will negatively affect performance. You can see it for yourself by looking in the dataflash logs' PM message. These messages are only put in the logs every 10 seconds or so so they can be hard to find (which is why I use excel to find them). In anycase, the 3rd from last column is the "num slow loops", the next is the number of loops since the last PM message (should always be 1000) and finally the time (in microseconds) of the slowest loop. If you turn on all the dataflash logging you'll likely find that >30% of your main loops are running late. Turn off all but the default logging and you'll likely find it falls to about 6% or 7%.
I'm a little surprised that it took so long to come down. When I do the radio failsafe my copter comes home immediately.
If, after using auto-trim, your copter is flying level then that's a good thing. If you find that when you put it back on the bench, the HUD is not level then all that means is that your copter needs to maintain a little tilt to stay in one place or that your APM is not perfectly level with the frame. So there's something a little out of alignment somewhere but if it's only a few degrees then i wouldn't worry too much.
From looking at your logs, compass offsets of X:-26, Y:-107, Z:12 is a-ok. What you had before: Y=343 was terrible. If the Y offset builds up again to that level then we definitely need to find the cause. It's most likely something metal in your frame that is very near the APM or interference from the motors. You might be able to make it better by moving the APM further away (even 1 or 2cm can make a significant difference).
We are planning to add some motor interference-rejection code into 2.9.2 or 2.9.3 but I can't promise that for the moment.
Guys I did the new calibration and I see my Yaw 330 degree is this normal or it should be 0?
I value is 0 except the yaw
Hi, I zipped up the tlog's from today, the newest one is from the copter that did not seem to have the problem, but I dont think I did a very fast yaw on that flight, after crashing (or high speed landing :) ) but 2 of the thers should have what you need. actually I saw the yaw thing, well like I said, where it would yaw past where I let off the stick, but only for about a quarter of a turn, then it would work again, but it would feel kind of sluggish after.
I zipped them this time. Let me know if there are any problem's with the compression and I will try again.
I was really thinking this was because of the esc's, either being too close to the apm, or vcc from them.
LOL... Front-REAR... Didn't catch that one. I meant of course REAR-right.
I wanted to add this too,
First, my param's from before the flight, I am not suree if the compass offsets will do any good, as this was the first flights for this copter, but I thought I would attach them anyway, also, the parameters for the same apm, from an earlier build, just for something to compare the compass offsets to, if needed.
secondly, I dont think it has anything to do with the yaw thing, but I noticed this on the same APM, on a different frame/motors/esc's. 3 of the offsets would fill in with NaN, where there were values before. I had noticed it happen 2 times, so I took a screen shot. it didnt happen again, so I forgot about it till now. I will attach the screen shot. (one of the places is highlighted in the jpg