Warning #1: PX4/Pixhawk users upgrading from AC3.1.5 (or earlier) may need to re-do their compass and accelerometer calibration because AC3.2 also uses the backup compass and accels. Pre-arm checks have been added to ensure this has been done.
Warning #2: on the APM2.x the logs must be downloaded using MAVlink instead of the terminal.
AC3.2-rc14 is now available for BetaTesters through the mission planner’s Beta Firmwares link. The full release notes can be found in ReleaseNotes.txt and changes from -rc13 can be seen below.
Feel free to raise issues found during testing on this discussion or in the new support section in the APM Forum.
It’s a big release with “the onion” restructure and a bunch of new features (including these 57 closed items) so we need to re-test almost everything including all flight modes, all mission commands and all the new features. Marco and I will be maintaining (and adding to) this testing list. Issues reported will first be checked by Jonathan, Marco and I and then confirmed bugs/issues will be put on the github issues list (and then hopefully fixed).
Thanks especially to the beta testers who put their copters at risk testing each release. Enjoy!
Changes from 3.2-rc13
1) Safety Features:
a) fail to arm if second gyro calibration fails (can be disabled with ARMING_CHECK)
2) Bug fixes:
a) DCM-check to require one continuous second of bad heading before triggering LAND
b) I2C bug that could lead to Pixhawk freezing up if I2C bus is noisy
c) reset DCM and EKF gyro bias estimates after gyro calibration (DCM heading could drift after takeoff due to sudden change in gyro values)
d) use primary GPS for LED status (instead of always using first GPS)
Replies
We need a copy of the log to see your issue.
I don't have log, i can not fly - it is prearm error. Can i log it? I use pixhawk 2.4.5.
I never done it but there is a way to log the parameters even before arming. You need to change the LOG_BITMASK parameter from default 43006(Nearly all) to 131070 (All + Disarmed logging).
Again I never done it, but I heard Randy talk about it. Try it. It should give you a log to post...
Randy
I know your insanly busy but... if you could look at this log [ or anybody else feel free! ] for me I'd really appriciate it. I've been having no problem with 3.2 at all ... flies just great but I had some weird glitch where the copter just dropped until I quickly put it in stab and nailed the throttle. It's around line 33700. Drone share log analysis said there was a over roll incident at that point too. I've looked at RC in and RC out but I'm not sure what I'm looking at for sure. Sure would like to know what happened! Thanks
220.BIN
Richard,
As Julien says it appears to be a false positive on the landing detector. It's a bit amazing with all the checks we've put in place that this is possible but it appears so. All the landing detector checks are satisfied for a full second.
The vehicle is in PosHold mode and is slowing down after flying forward fairly quickly (about 15m/s). As the vehicle leans back to slow down the wind likely catches the bottom of the props providing additional lift. The altitude controller pulls the throttle down stop the vehicle from climbing meaning the average motor output drops well below the 25% landing detector requirements.
The frame has a slightly larger than normal motor imbalance meaning the front-right motor runs about 200pwm lower than the back-right motor (so perhaps the COG of the vehicle is a bit far back). This slow motor hits it's minimum value which satisfies the "motor-hits-minimum" requirement of the landing detector.
The vehicle's rotation rate stays well under control with the vehicle rotating below the 30deg/sec that is another landing detector requirement.
The barometer also reports the vehicle is not climbing (because it's not).
This whole situation persists for more than 1 second and the landing detector fires and the vehicle gives up doing attitude control and tumbles.
We will need to add some more checks to the landing detector, I'll think about that and we will add it to the AC3.2.1 release. My guess is we will add a check of the desired climb rate to ensure it's negative.
Until then I think there are some things you can do to reduce the chance of this happening again:
1. reduce the THR_MID to 450. Your vehicle hovers at between 42% and 45% anyway and this lowers the average throttle requirement down to 22.5%
2. adjust the COG of your vehicle. Move it forward and right a bit.
3. decrease the braking speed in PosHold mode using the PHLD_BRAKE_RATE parameter. Making it lower will probably mean the vehicle leans back more slowly which will lead to less lift meaning the overall throttle will remain high.
COG is really really close. I have feeling the biggest issue is the shape / size of my home built quad. see pic. It has a very large flat surface area that probably acts a bit like a wing on a fast deceleration. At any rate I made the changes to mid throttle and pos hold braking as per your suggestion. I also have dual rates on my TX I had set max elevator to %70 [ this kept it under 15 mps or close at full forward stick ] I reduced this to %62 also perhaps this will help as well. Really crappy weather around here but as soon as I get a chance I'm going to go to a safe place and do my best to duplicate the problem. If not I guess I'm good to go. I made a note of the changes I made so I can put them back and after a fix is in and make sure I can't duplicate it again with the same settings as before.
I'm sure there is a reason 2-3 seconds isn't used for landing detection instead of 1?
.
Richard,
Increasing the timing of the landing detector is another good idea. The longer it gets the longer people need to wait for the motors to slow down but adding 0.5sec would probably be short enough that humans would barely notice.
Randy
I wonder if another safety could be if the baro detects a sudden and large drop [ 10 meters? ] in alt within .5 seconds after 'land' it would try to return to that alt and mode it was in just prior? .5 seconds isn't enough for somebody to walk up to it to pick it up.
Randy thank you very much for the detailed analysis! I have felt basically grounded since I did not want to fly until I knew what the deal was. I will make a few adjustments as you suggest. I will check COG when I get home from work. I thought I had it fairly close but I will double check. You and the devs have busted your butts on this I'm sure it's the last thing you wanted to hear. On a related subject I'm going to report over to AP2 again about the lack of ability to see the line items with the detail MP does. That detail in your first pic 4th columb to the right is something I can't see with AP2.
Ouch... I saw this yesterday but didn't pay much attention to it.
Richard, are you saying that you were flying with your copter and the controller all of a sudden cut the motors in mid-flight because it thought the vehicle has landed????
If so, this is a serious problem. If it can happen with 3.2, then I think it can happen with any of the previous releases.
I still do not understand. Or maybe it is because I misunderstand something here. How on earth landing detector decides that the vehicle has landed or even comes in and starts applying its checklist during mid-flight?
I am hoping I am missing something here. I looked at your home-made quad and it didn't look extraordinarily different in shape and size than any other commercial ones to me.
Could you please tell me a bit about the moment this happened? Were you just flying manually/stabilize? Or was this an auto mission? I am not so good and quick at checking logs.
Thanks
-
19
-
20
-
21
-
22
-
23
of 373 Next