Plane starts diving in all flight modes

[Yarillo]

1. Hello, recently my plane started losing control for no reson in all flight modes including manual. In this clip you can see two of such flights. The log is related to second clip. I want to mention, that i have been using ekf2 in the clip, because i was reccomended to use it instead of ekf3 to avoid the issue. But it did not give me any result. On ekf3 i have exactly the same behaviour, when i lose control and airplane goes into fast spiral descent. Manual mode does not seem to solve the issue most of the time. Also it manages to get out of the spiral, when throttle is being increased.

2. [00:02]

The servos have been checked and seem to work fine. I assume, that it could be the issue with pwm outputs, but it is highly unlikely. Also there is gps jamming present, so that could potentially affect ekf algorithm flow.

Ardupilot issue

1. Arduplane issue - Google Drive

[Lano (LanoAstur)]

The first thing to note is the anomalous behaviour of the barometer; could it be exposed to a draught that distorts the results?

The EKF2 estimates do not present any problems. The values from the airspeed sensor are the worst, but without compromising the EKF2 results.

The ARSPD_RATIO value is suspiciously similar (if not the same) to the default value. Have you calibrated the airspeed sensor?

The only “problem” with the GPS is that it doesn’t respect the 5Hz (200ms) refresh rate. Every 20s it jumps up to 220ms; this is typical of M8 GPS like Beitian BN-880 and similar. It is not ideal but Ardupilot tolerates it at the cost of a slight inaccuracy in the EKF2 estimation which, as I said, does not compromise the EKF2 result.

Finally the issue of “sinking wing and downward spiral” has to do with a stall due to lack of speed.

It gives the impression that you have the COG forward, which means that the elevators are continuously raised to compensate; the consequence is that you are left with very little travel in the elevators to manoeuvre.

In this flight section at FBWA you can see a nose stall (blue) and a wingtip stall (orange).

What defines it is the divergence between the attitude demanded by the FC and the attitude executed by the aircraft.

[kd0aij (Mark Whitehorn)]

@Lano The syntax for plotting baro altitude is “graph BARO[n].Alt”:

Since there are 2 barometers, you must specify the instance number for the plot to work properly.

@Yarillo Sure looks like you’re stalling to me…
Bet it doesn’t happen if you stay off the elevator and keep your airspeed up.

[Lano (LanoAstur)]

In multi-IMU controllers with sensor redundancy, it is possible to obtain independent readings for each sensor (BARO[0].Alt and BARO[1].Alt in the case in question) or a reading that is a combination of both (BARO.Alt).

In this case, if you look at the two IMUs, you will see that the erroneous reading comes from the second one.

[kd0aij (Mark Whitehorn)]

The BARO log message is documented here:
https://ardupilot.org/plane/docs/logmessages.html#baro
It contains the instance number and the altitude for that instance. It does not contain any altitude value representing the fusion of multiple instance values.
When you plot BARO.Alt (without specifying the instance number) in MAVExplorer, you’re just seeing the value jump back and forth between one sensor and another.
I’m not sure whether there is any fusion of multiple barometer static pressure values (in the EKF), or whether only the current primary value is used.

[Lano (LanoAstur)]

Regarding the second point, there is no merging of measurements in EKF. It takes measurements from one lane or the other but does not mix them.

Regarding the first point, what you say is correct. The Ardupilot records are for each of the sensors and there is no average value record. But in this case the graphical representation was made with MavExplorer and this software does handle an average value of the two sensors.

[Yarillo]

@Lano

I have used this setup for a year, had no issues at all, but then this popped up. The air speed sensor has been calibrated long time ago.
Regarding baros, there are two baros. One is on the fc and it is used for altitude reading, the second one is ONLY for temperature reading, it is mounted close to the propeller, so that’s why it may seem distrusted.
The cg is correct and I had never had any issues with it.
I was not stalling, because I know this plane really well and at throttle values I have been flying on it should stay well above stall speeds. Also it wouldn’t go out of a dive, when I pull stick on me, even though speed is above 100km/h already.
It would steadily descent in crus, without any stall sign, but clearly indicating, that it is firmware related.
I assume airspeed sensor could be clogged, but why does sensor give proper readings in log then?

Thank you for your replies.

[Lano (LanoAstur)]

Your records say that you use a Mateksys H743, this controller integrates two barometers.

The values of PIDP.I imply COG advanced.

The divergences between demanded and executed roll/pitch are clearly shown in the records.

It is clear that I do not know the aircraft but what the records say is what I transmitted to you.

[Yarillo]

So what is your suggestion for the next test flight?

Thank you very much

[Lano (LanoAstur)]

Check COG and if necessary (most likely) move it further back.

Recalibrate the airspeed sensor.

At start-up ensure that the pitot is covered (exposed to atmospheric pressure but isolated from air currents).

Check to avoid low speeds.

[Lano (LanoAstur)]

Something is wrong with your pitot, note the CONTINUOUS discrepancies (from -6m/s to +8m/s) with the ground speed. It is clear that they are different things and that depending on the attitude of the aircraft the difference increases, but in this case the discrepancy is continuous and significant.

[Allister (Allister Schreiber)]

Could you explain your calculation Airspeed - ground speed? To me, in a still air condition the result would be 0. (But that never happens.) Positive for flight with a head wind, and negative for flight with a tail wind. I’m curious to know how you infer the pitot is not good based on this calculation.

[Yarillo]

Thank you, i am gonna try with cleaned tube. Gotta record the log with that.

[Lano (LanoAstur)]

detail at the moment of maximum difference

As you say in an ideal no-wind condition the airspeed and ground speed coincide as long as the aircraft is flying parallel to the ground.

Let’s assume that ideal condition but with a climb of 32º and an airspeed of 16m/s. The ground speed should ideally be 16m/s*cos32º=13,59m/s. I repeat that we are talking about no wind.

In this particular case, at the moment of maximum difference between air and ground speeds (8.81m/s) the pitch is only -0.88º. For this reason, if we doubt the estimation of the pitot we start from the terrestrial speed (8.9m/s) to obtain the supposed air speed, it would be 8.9m/s/cos (-0.88º)=8.901m/s, practically the same result as cos(-0.88º)=0.9998.

wind speed at the moment of maximum difference between speeds

As at this moment the pitot reading is 17.59m/s, this difference (8.81m/s) should be due exclusively to the wind, but at this moment the wind speed is 5.83m/s, which could only be considered this maximum value if it was blowing in the same direction to that in which the plane was flying.

wind speed and direction at the time of maximum difference between speeds

Ground heading of the aircraft at the time of maximum difference

It so happens that the plane was flying very close to heading 190º, so we can estimate this 5.83m/s (in reality it would be somewhat less, but I still assume this value). And as I said in the previous paragraph, these “supposed” (because it would really be something less) 5.83m/s do not justify the 8.81m/s difference.

All this is just the method used by Ardupilot to check the quality of the Pitot readings and if necessary deactivate it to avoid accidents.

Using an Airspeed Sensor — Plane documentation (ardupilot.org)
Complete Parameter List — Plane documentation (ardupilot.org)

[Lano (LanoAstur)]

By the way, these are pre-flight pitot readings. There is an average reading of 2.29m/s.

But after the flight (with the electronics already warm) the average reading is 3,08m/s.

And from everything I mentioned before; the difference between the speed difference (8.81m/s) and the wind speed (5.83m/s) happens to be 2.98m/s which is quite close to the average pitot reading when the plane was stationary (3,08m/s).

What I think is that either the pitot is not well calibrated (arspd_ratio) or it was not properly covered at the time of the initial calibration.

[Allister (Allister Schreiber)]

Thanks for the response. I’m going to take some time tonight to read through this in more detail.

[LupusTheCanine]

Pitot miscalibration effect diminishes fairly quickly with airspeed. IIRC it should be below 1m/s at 8m/s.

[Graham_Dyer (Graham D)]

@Yarillo Can we see a photo of the plane? And where is your CG?