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 you are going from -12 to -8 that is excellent, it seems -5 to -15 is an acceptable range and you are considerably better.
Looking at your log the primary vibration Z is excellent, but as you know there are several major spikes.
If these were from landing or taking off they are fine, but I would not normally think that big spikes like that should be encountered in this manner during flight even with strong flight maneuvers.
Thanks for that, I was wondering why it went into RTL.
We need logs with RAW and INAV turned on for us to help you.
Are you using the default Alt Hold PID values? You will have the wrong ones if you just loaded your old parameter file.
They were spikes from hitting the floor. I was flying very low. The rest was from trying alt-hold (but since I completely reset the APM, and I forgot to set alt-hold as a flight mode, so it was not actually trying to alt-hold, which explains my problem above and that is why I stated 'entirely my bad'!) and manually pushing the Octo (wearing a very thick sweater and my motorcycle gloves!!!).
Excellent description of the problem! Yeah I'm with Gary. Reversing rotation may help with the divergent yaw, but you gotta wonder if those excessive deflections could manifest in other control problems. Did you intentionally design your frame to flex this way? If so, why?
This looks fine to me. It isn't the best I have seen but shouldn't be a problem for a good alt hold.
The reason why your baro and sonar are moving away from each other is because your local barometric pressure is changing due to the weather. The best case I have seen on my quad of this was when I landed in the same place after a 10 minute flight and the baro read 5m lower than when I took off. I got a quick flight in before the weather came in. :)
Your z vibrations are more like +- 0.5m/s/s. When you look at the vibrations you need to remove the variations in the acceleration caused by movement.
So you don't have vibration problems.
A further thought Vince,
I know you went to a lot of trouble to shock mount those arms, but it places the mechanical torque delay at the worst possible point mechanically right in the middle between the torque (motor) arms and the frame center (APM) where the sensors and response mechanism is.
At least, temporarily you might want to try defeating your motor arm shock mounting system and converting to rigid and see if this problem doesn't go away.
Shock mounting the motors directly for vibration reduction (might) be OK and definitely vibration mounting the APM board itself will work, but it seems to me putting a noticeable flex point in the middle of your frame is going to introduce way to much hysteresis (actual physical delay) between the motors and the APM where the sensors and response mechanism are.
I think the majority of large vibrations are caused by loose objects moving around in the frame. Loose motors, unrestrained ESC's, loose arms ect.
Until I got the APM case all my work was done with solid mounted boards on nylon standoffs. With unbalanced motors and cheap HK props. And as you can see by the comparison graphs on the fist page, I have got relatively good results.
Now that I use the case I attach it using double sided foam tape:
"Peel-n-stick foam tape. 10x5inch 4mm thick" from HK.
Something worth pointing out is that all my testing during the development of AltHold and the new Loiter has been done with damaged props and a bent bell housing to achieve an acceptable worst case scenario.
The first step for any person with a vibration problem is to make sure everything is tight with no excessive movement. Then you can balance props and motors and add some type of vibration dampening to the APM board/case.
The only exception I have found to this is Marco found some props that he couldn't stop from vibrating even though he had great success with everything else. This may have been because the props couldn't handle the power of his motors and the blades were vibrating.
In that case your vibration or lack thereof is looking superb on your Z axis.
What he said!
I typed it all in on the previous page myself. LOL, gotta love NING.