Yesterday I had same problem in RTH, after landing the motors accelerated and the quad flip left. (Arducopter 3.6.7)
Landing detection (code is here) is quite tricky and it checks these things:
- the average throttle output is near minimum (less than 12.5% hover throttle)
- the airframe is not accelerating (not falling or braking after fast forward flight). must be accelerating less than 1m/s/s
- vertical speed is within 1m/s of zero
- if we have a healthy rangefinder only allow landing detection below 2 meters
- all the above must continue for 1 second
I think the cause of @Tom-fly’s bad landing could be a motor imbalance which causing two motors to be higher than the other two and stopping condition 1 (“average throttle output must be near minimum”) from being true.
I have asked Michael Oborne to make 3.6.6 available through the MP so people can try and run multiple tests with both versions. I think we shouldn’t jump to the conclusion that these cases are all related or that they’re caused by the 3.6.7 change. The inability to correctly detect a landing can depend on the environment which is always changing.
I will review Corrado’s log in a moment
I had a look at the logs and although the vehicle did lean back quite a lot (to 45degrees) I think it did eventually detect the landing and disarm. My guess is that it just got unlucky and it landed a little bit off the target as it touched down and then it fought harder and harder to try and get back to the target by leaning over.
In the graph below the blue line shows the PSC.TVY (position controller target velocity in east-west direction) we can see right from the beginning it’s off from the actual velocity (PSD.Vy in orange) and this builds up (this is velocity controller I-term build-up most likely caused by slightly off position vs the target).
I think the 3.6.7 change was not relevant in this situation because the AC_Loiter::soften_for_landing function is only called when “land complete maybe” and we log when “land complete maybe” becomes true and it’s right at the end of the log after the leaning has already happened.
Re the ReleaseNotes that last entry covers both 3.6.7-rc1 and the final 3.6.7 release. The two were the same except for the name.
Thanks very much for these report. As mentioned above, although I’m sceptical that 3.6.7’s small change is the cause of these land-detection issues, I’m also often wrong and if we have a bug I’d like to find it.
I think MP will (hopefully) make 3.6.6 available soon and if anyone here feels like doing back-to-back tests with the two versions to help prove if one is better or worse than the other that would be greatly appreciated.
Txs for the log. I think this issue with the land-detector is also not caused by the change in Copter-3.6.7 because, like Corrado’s log, the lean happens before the LAND_COMPLETE_MAYBE event appears in the log.
To be clear, I’m not saying that our land-detection always works. It doesn’t… often because the vehicle is slightly off from it’s target position and tries to fight it way back to the target (by leaning over) but it can’t because it’s landing gear has already touched the ground… but so far it doesn’t look like a regression I think…
Maybe only an unlucky situation but on the machine it happened we have had probably more than 2000 landings and never had a problem, than updated to 3.6.7 and happened twice. Went back to 3.6.6 and made 2 flights with more than 30 rtl each and didn’t miss a beat. On top of that all of a sudden 4-5 different repoorts of same prob from different sources. I think it is worth investigating a bit. I went back in the forums and this kind of problem it is very very rare and never showed up as intense as it did in the last 2 days.
Just my 2 cents
The flip at landing is a recurrent problem since AC3.4 that isn’t that rare, even if we reduce it a lot since then. But here there is a troublesome coincidence between different unit that flip on landing.
I get the same analyse that Randy, the I-term soften change cannot cause this as the flip appear before the soften.
But those flip appeared on RTL. So we may have an issue somewhere else that was only triggered by recent changes.
My landing failures are always down to point (1) I think. The motors are spinning fast enough for the copter to think it is still flying. Wouldn’t it make sense to look at the throttle input in some circumstances?
Flew again today, still with 3.6.7. First landing was in loiter, detected well, copter went idle and disarmed the motors.
Then I attempted a mission, marred by GPS glitches - it should’ve been a racetrack at 80m but copter shot up to 250+. Recovered, landed in loiter and this time around landing was not detected, switching to stabilize didn’t help either, one prop hit the ground then CRASH_CHECK disarmed the vehicle.
Here isthe log, I hope it is useful to find the problem, tomorrow Iwill try both 3.6.6 and 3.6.7
Can’t seem to be able to find 3.6.6 or convince MP to show it, even if it’s there in the pulldown menu for older firmwares.
Anyone can help me with the apj for Holybro Pixhawk 4 ?
If the latest beta MP is loaded then AC3.6.6 is available.
Re the climb to 250m, it is caused by the EKF becoming confused because of high vibration levels. the Z-axis is about 40m/s/s which is in the grey zone (which stretches from 30m/s/s to 60m/s/s) which means that altitude control will sometimes work but sometimes it will have problems.
We are discussing more ways to improve resistance to vibrations and I expect we will add a vibration failsafe to 3.7.0. The underlying cause though should still be fixed so please check this page re vibration isolation hardware.
Not a great answer for small racing copters however - seems at odds with the desire to support more FC’s. And unfortunately the vast majority of people will think “well CleanFlight/BetaFlight/… manage to make it work so ArduCopter must be broken”
Thanks for looking at it, Randy.
It’s actually a Pixhawk 4, with one IMU mounted on a piece of hard foam, just like the Kakute, and the FC itself is mounted using a double layer of silicone sticky tape. And being a Pix4, all the wires are silicone AWG 28 - there’s no servo-style wires of thicker gauge running to it. And it’s a very compact copter, at 650 mm diagonal with 15 inch props, so the Z-axis vibes may be generated by prop airflow near the frame.
Now, after running a proper log browser, thanks to @ChrisOlson, some data became evident. Due to not wanting to squint while looking at the copter, my test flights were flown mostly facing north. And all the GPS glitches occur with the copter tilted to and accelerating north. No glitch was experienced flying E, W or S.
What happens is everytime the copter leans north, the GPS flickers by one or two sats, hdop flickers as well and the GPS VZ takes a beating, generating a glitch
The big yellow sinusoid is the latitude, those sharp blue/red spikes are numsats/hdop, the green/green/dark red curves are altitudes (desired, gps, baro) and in purple the misterious GPS VZ parameter
… but to be clear, the altitude hold problem is not related to the GPS quality. It is possible to make the EKF use the GPS altitude (by setting the EK2_ALT_SOURCE parameter) but by default it uses a combination of the accelerometers and barometer. In this case it is the vibration that is affecting the accelerometers and causing the troubles so I think some changes to the vibration isolation are required. It also may be possible to reduce the EKF’s reliance on the IMU (and increase it’s reliance on the barometer) by reduing the EK2_ALT_M_NSE parameter (mentioned here) but the best solution is a physical solution.
It happened 2 times to me today, that the copter did not recognize the landing. I landed manualliy once in Loiter mode and once in Position Hold mode, both times after touching the ground, I could not disarm and the copter speed around. The good thing which is working is the crash detection. But unfortunatel I broke 3 of the 4 propellers so I could not try a third time.
I never had an issue with that copter before (approx. 100 flights) It seems that it was after upgrading to 3.6.7. I do not know which version I was running before.
Could you please tell me when you did make changes on the landing detection, so that I can go back to that version before.
Is there anything planned to improve the landing detection?
Is it perhaps an idea to force disarm of copter if both sticks are moved to bottom right/left.
i experienced a similar situation recently where it landed in RTL mode, but it did not disarm while on the ground and holding the stick down and to the left would not disarm. It was still in RTL mode when I tried the stick, but maybe if I had switched to pos hold for example, it would have disarmed? Maybe not since the copter did not know it had landed even tho it was sitting on the ground… is it possible to disarm with the sticks in flight?
i had to unplug batteries to shut it down
something that might help diagnose the issue is, in my case, the landing was very hard… most of my landings are gentle and have never had a disarm problem in those cases
I programmed now a switch on my transmitter where I can use the emergency stop of the motor. Think that is a better solution then catching the copter by hand
My craft is also suffering from the “not detecting landing - bouncing up and down” error… Usually in assisted modes (anything from Althold to Loiter), when I am trying to land, the craft lands let’s say perfectly, it is still turning the motors on higher than needed rpm, and it is pulsating. Throttle is set to minimum… And, of course, it is not disarming…
Today I was trying to land in Sport mode, the descent speed was a little bit fast, and the craft bounced back into air for about 50 cm and continued to jump… I pushed the Th to raise the craft and land again gently, but in that time it turned about 45 degrees, and has flown into a tree not far from me, even after I cut the Th… Two motor mounts broke off, but the craft, the props looks OK…
Usually (and this will be the normal procedure for me from now…) I can only land normally if I switch to Stabilized mode for the final descent.
If I had to guess, and we do without a .bin log, I’d say barometer not covered and vibrations.