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.
Hi Peter, the sonar isn't used to calculate altitude, instead it is used to calculate the height over the ground in the same way terrain following radar is used by a fighter to travel at low altitude through mountains.
So when the sonar is engaged in Alt_Hold it will change the altitude to maintain a fixed distance from the ground. This lets you climb steps ect.
Previously this was done by changing keeping a fixed altitude but changing our altitude measurement to match the sonar reading. So if we had a sonar reading of 4m and wanted to be 5m altitude we would set our measured altitude to 4m and tell alt hold to go to 5m.
Now we only use the Baro and inertial navigation to calculate our altitude. So now if we are at an altitude of 10m and get a sonar reading of 5m and engage the terrain following we lock in 5m above the ground, we tell alt hold to stay at an altitude of 10m. As we move forward the sonar reading may change to 4m because we go over a retaining wall or up a large step. Because we want to maintain a 5m distance to the ground we request an altitude of 11m from Alt Hold. In this way we no longer use the Sonar to calculate the altitude, just the distance to the ground.
Hope that makes sense.
Hi Leonard, Thanks for the reply, much appreciated!
Just one quick question, is this new method operational both in MODE Alt_hold & in Missions ?
Yes, HUD is reacting accordingly to the quad (APM) movement, also heading.
I will consider those value (INS_GYROFFS_x) s as not being a problem, I will keep you in touch about my progress.
Thanks for all the good technical information.
Sorry, I am not sure about missions. So far my focus has been on the manual flight modes and RTL. I hope to run my first mission this weekend to test the new AUTO design.
The surface tracking is only available in alt-hold and loiter. It's not enabled from auto yet mostly because we were already running late on getting 2.9 out and didn't have time to think through all the possible problems of enabling it for auto modes. I guess it might be as simple as using the next waypoint's altitude as a desired distance from the ground is that alt is < the max altitude of the sonar. Otherwise take it as a alt above home.
If you set COMPASS_USE to zero then you will no longer be using the compass to correct your heading. So for example you'll find that when you restart your APM the heading will always be directly north. It won't be possible to do loiter or missions I'm afraid.
So when you saw it Yaw's 20~25 degrees, i guess you mean when you give it some throttle? I'd guess that Alexey is right that it's interference from the motors. Although it's not a perfect test you should be able to prove this yourself by connecting your APM to your mission planner, remove the props from your machine and attach the lipo battery. Then try arming the copter and increasing the throttle - i suspect you'll see that the heading changes. This is not a perfect test, because without props the motors will draw a lot less current than they will in the air so the effect on the compass will be much less than when you're flying.
Some other things to check - your COMPASS_OFS_X, Y and Z values. They should all be under 100. If they're very large you could try setting them back to zero and see if that helps. They're normally calculated automatically however and they may have gotten large in response to metal on the frame or interference from the motors. Could you also check your declination value? Please note that in the Adv Parameter List it's in Radians but on the Hardware Options screen it's in degres.
The Save Trim issue is likely a separate issue. Could you check what your AHRS_TRIM_X and AHRS_TRIM_Y values are? These numbers are in radians so you can convert them to degrees with excel (or just multiply the number by 57.3). The maximum they can be in 10degrees so there's a slight possibility that your accelerometer, board or frame needs a larger correct than the tolerance currently allows (in which case we can increase the tolerance).
P.S. between 2.8.1 and 2.9 I took some time to update the descriptions for every single parameter. So in case it helps you can find some explanations in the mission planner's Adv Parameters List screen.
Test Failsafe at night
That was the battery failsafe you were testing? looked pretty good!
I can't test is it. Because, I not have power module. But, I maybe order it next time.
I'm forgot attach log and tlog file on video.
This is a tx/rx failsafe side, not the battery, right?
Today I have made my first flight my homemade octocopter, and I have some issues:
1- Stabilize works great with stock values except in P that I have 0.90 because I use 400kv motors, but the copter starts to yaw slowly.
2- Alt hold not works as I wish, the octa is more like an kangaroo, I'm using an XL-EZ0 but I don't know if is a problem of sonar or the baro.
3- Position mode works great if you don't use the sticks, only the throttle is used. (windy day), but maybe I have saw an issue using this mode, when the copter is in Position mode, the mission planner shows "unknown" and the yaw value is freeze (but the copter is yawing slowly as I said) but while I don't touch the stick the mode works fine. When I try to change the position without leave the "Position mode" the copter flies well but when I release the stick start to fall and I have to change to stabilize mode to be able to get the control and in the mission planner shows the actual yaw value instead of the freeze value.
My config is APM1 + sonar + mediatek 1.9 + compass + 3dr radio link.
I have attached the logs and the video showing the position mode working (not when its falls).
P.D. I'm sorry for my bad English.
If I can get some sample data form good setups and from some known to be bad I can run some different algorithms to see if a simplistic one is adequate for a warning threshold application. Ideally some data with hover only and some with aggressive flight since more simplistic methods will be impacted to some extent by flight / handling induced accelerations.