VTOL - Disk scaling theory improvement, now he has problems

[robustini]

Bug report

The excellent "disk scaling theory" feature present in the Plane and requested by me and others was implemented by @IamPete1. Unfortunately I discovered the hard way that it can often cause problems that are difficult to manage during the flight if you don't realize that the scaling is wrong. Or rather it is working based on a sensor system that has problems. Link to the logs of two flights, one without problems where the average scaling remains at 1 (no scaling), the other with a consequent crash where the scaling has already started at the takeoff at a value of 0.5 (gain halved).

Issue details Currently the automatic scaling of the PIDs in VTOL relies only on the airspeed, so if this sensor has problems an excessive scaling is performed, which led my tailsitter to exit the flight envelope. The oddity is that between the good flight and the problematic one I have not changed anything in hardware, same parameters, only the firmware which in any case should not have something that has compromised the scaling. I had previously had this problem but having to perform some calibrations in VTOL I took off and I kept the tailsitter at 2 meters, detected the problem I was able to make it land unscathed. So If disk scaling doesn't have a sanity check it could become disastrous.

Please describe the problem In the logs plotting "Sscl" inside "QTUN" we notice excessive scaling. Currently this automation is based only on airspeed. In my opinion, however, it should be based on three things, in order of importance:

1) barometer: for a tailsitter that would be enough to perform a correct scaling 2) airspeed: less priority on the barometer, also because in VTOL during pitch or roll shifts the airspeed increases and the PIDs should not decrease, but even increase 3) attitude angle: UAS leveled scaling should not intervene too much, but increase dynamically if the attitude angle moves from 0

In a tailsitter the disk scaling at a barometric altitude that changes little should be 1, so like disabled. With the barometric data rising faster than x then it should scale down the PIDs by lowering them, and if the pressure drops it should increase them. With the airspeed the negative data cannot be had, and it is already a limit to be overcome. In case of improvements it would also be useful to have the actual scaling in the log according to what is set but with the possibility only to log it without actually performing the scaling.

Version 4.4 DEV

Platform [ ] All [ ] AntennaTracker [ ] Copter [x] Plane [ ] Rover [ ] Submarine

Airframe type Tailsitter

Hardware type Irrilevant

Logs

https://drive.google.com/file/d/1K8_CGQqBGH6OsdcgoN3ZEfwLSaGYi5R8/view?usp=sharing

[WickedShell]

Regarding just the airspeed issue, you're using a MS4525 which is incredibly prone to long term failure. Your offset is 1997.133179 pascals which is a badly failed sensor. Anything on these sensors with an offset greater then 300 should be considered failed and thrown out. I've seen vehicles take off that start with an offset of 500 and over the course of the flight completely fail to be reporting 1PSI of pressure.

The MS5525 also has the same issue, but it is less prone to it then the 4525. I strongly recommend looking into getting a DLVR based sensor at this point.

We should handle the failure better, but that sensor with offsets that high cannot be relied upon anymore.

[robustini]

Unfortunately I agree, this airspeed is bad and I will replace it as soon as possible. Regardless if the airspeed has problems, a sanity check is imperative with the disk scaling enabled.

[robustini]

This is the noise of that airspeed sensor with covered pitot at the ground, with the system armed but stopped motors.

[robustini]

And that's what I can't explain from the log with the issue. The scaling starts from 4 with an armed system but throttle to a minimum, in my case motors off. The disk scaling with an airspeed value of 2.8 m/s, so in line with the value even before increasing the throttle, goes to 0.4, it shouldn't. If it is based on airspeed alone there is an error somewhere, it cannot scale more than half with that airspeed value.

[dcamatti]

Dear All, it seems to me that scaling is applied according to the airspeed value even when the drone is in VTOL mode, when the measured airspeed is zero and when any measured value is noise. Addenda, being involved in aerospace engineering and flight dynamics since after my PDH in 1994, I never saw anyone applying a scaling to PID according to a quantity (airspeed) which is not involved that condition. How can the airspeed affect the stabilization loop during any hovering mode? Why should we use a quantity, not useful to apply any scaling, which is affected by noise and offset? Is is a complete nonsense to me. Other systems apply relevant scaling according to different flight condition using only involved phisical quantities and not other quantities. If I am wrong, I will be more than glad to evaluate any motivated reason for that. Many thanks. Daniele