Servers by jDrones

Why quad doesn't want to disarm after landing? . Happened two times now (Arducopter 3.6.7)

(Corrado Steri) #11

Just going over the 3.6.7 release notes i noted this :“Landing flips reduced by reducing I-term build-up”

So it looks like that part was manipulated on last release and maybe there is chance it made things worse?

Just read it better and found out release notes were referred to 3.6.7 rc1 so maybe it got better. I am kind of afraid to test rc1 now.

(Abhijit Paul) #12

How to downgraded 3.6.6? I’m also facing issue in 3.6.7

(Corrado Steri) #13

What kind of issues?

(Corrado Steri) #14

You can compile your own and load it as custom, or try the new beta 3.6.7 rc1 that has a fix for the problem in the release notes.

(Abhijit Paul) #15

In Rtl flight mode.using pixhawk 2.4.8.
After landing it’s not disarm automatically.

(Antonio Rosillo) #16

Yesterday I had same problem in RTH, after landing the motors accelerated and the quad flip left. (Arducopter 3.6.7)

(rmackay9) #17

Landing detection (code is here) is quite tricky and it checks these things:

  1. the average throttle output is near minimum (less than 12.5% hover throttle)
  2. the airframe is not accelerating (not falling or braking after fast forward flight). must be accelerating less than 1m/s/s
  3. vertical speed is within 1m/s of zero
  4. if we have a healthy rangefinder only allow landing detection below 2 meters
  5. 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

(rmackay9) #18


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.

(rmackay9) #19

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.

(rmackay9) #20

@ThePara Para

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…

(Corrado Steri) #21

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

(Khancyr) #22

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.

(Andyp1per) #23

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?

(Cornel Fudulu) #24

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.

(Antonio Rosillo) #25

Here isthe log, I hope it is useful to find the problem, tomorrow Iwill try both 3.6.6 and 3.6.7

(Cornel Fudulu) #26

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 ?

(rmackay9) #27


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.

I’m going to go a step further from now on I think and recommend a flight controller with built in vibration isolation like the Cube, the CUAVv5 or the Holybro KakuteF4.

(Andyp1per) #28

I’m going to go a step further from now on I think and recommend a flight controller with built in vibration isolation like the Cube, the CUAVv5 or the Holybro KakuteF4

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” :frowning:

(Cornel Fudulu) #29

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

(rmackay9) #30


… 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.