I have been working for a while on a quad tilt rotor mini talon conversion, and I have so far not yet transitioned to fixed-wing flight - I’m not fully confident that everything is correct.
I have tuned the plane thoroughly so that it flies pretty well in QLOITER.
It’s not brilliant in windy conditions - correct detection of wind direction is essential to the flight performance - and this is something which often seems ‘wrong’ in the logs.
Looking at logs from my most recent flight, which was flying up and down the field directly into/away from the wind direction, I can see that CTUN.As is behaving in the opposite manner to expected. i.e. it seems to be groundspeed minus wind speed when flying into the wind and groundspeed plus windspeed when flying away from the wind.
If CTUN.As is used as the threshold value for determining whether the aircraft has reached transition speed (could someone confirm this please? ), this issue could mean that the aircraft will not complete the transition phase even if it is well above the stall airspeed.
Looking at the synthetic airspeed (CTUN.SAs), the logs appear to make sense, with the speed being groundspeed + estimated windspeed in the correct direction.
I’d appreciate some pointers as to what could be wrong with CTUN.As, and would be interested to know a bit more about how this is calculated.
Do these two methods (airspeed sensor & wind estimation) for estimating wind/airspeed cancel each other out? could it be an incorrectly estimated wind from static hover which is making CTUN.As move in the wrong direction?
Thanks in advance for your help.
However, during a flight today I noticed the live airspeed reading behaving completely erroneously, i.e. it woud read ~30kmh with the plane in stationary hover, then dropped to near zero as I accellerated forward. This behaviour was reflected in the logs:
Forward flight upwind/downwind:
I believe having correct CTUN.As is critical to the VTOL>FW transition, as it is one of the ‘measures of success’ used to determine whether the transition was successful, so please could someone explain what’s going on here, and if anyone else has seen the same issue.
For ref. I am running the following version/board:
Firmware
ArduPlane V4.5.6 (bbf0b066)
ChibiOS: 6a85082c
Official release:
Plane-4.5.6
Sorry, can’t post the full log due to excessive size (all raw IMU logging was enabled). I have attached the param file, I can provide further screenshots of log data if there is anything specific you would like to see?
EDIT- just noticed the param file from 2nd half of today’s flight has the ARSPD_USE disabled, whereas the flight started with it enabled???
I am using a single Matek 4525 airspeed sensor with the included pitot/static tube. The tube is covered on boot-up up until the aircraft is ready to arm (note - aside from the scaling ratio being a little off, i’m fairly happy with the readings from the airspeed sensor).
I’m interested in learning more about the method used to calculate CTUN.As, and any parameters which affect it.
Have you gone through this? Using an airspeed sensor
Yes, been through that a few times. I’ve used airspeed sensors before on ArduPlanes with no issues; this is the first time I’ve used one on a VTOL.
Anyways, I’m not so interested in the sensor itself, rather what Ardupilot is doing with that data in order to calculate the CTUN.As value, which seems to be the value used by the autopilot to make some flight-critical decisions.
Following a further review of one of the logs, I located the moment at which the sensor ‘went bad’ - i’m guessing due to excess difference between measured airspeed and groundspeed.
It can be seen that CTUN.AsT switches from 1 (using sensor) to 2 (using EKF3_SYNTHETIC), and at this moment there is a massive jump in CTUN.As.
Whilst one approach to this problem may simply be ‘make the airspeed sensor more reliable’, I need to be confident that in the event of a problem with the sensor, the aircraft does not try to use completely erroneous data (which would probably result in a crash) and instead uses an estimation which is ‘almost ok’ (such as the values seen in CTUN.SAs).
I’d be very interested to hear from a dev how the EKF3 fuses data from Airspeed Estimation, [Weathervaning & Wind Hold] (Weathervaning and Wind Hold — Plane documentation) and the reading from the airspeed sensor itself to estimate the wind speed and direction, and therefore the estimated airspeed.
Ok so an update, but no real progress:
I moved the Static port of the sensor inside the fusealge and covered with a piece of open cell foam, which seems to have helped with the readings a little. When the Airspeed sensor is healthy, the CTUN.As and the measured airspeed correlate closely; however if the sensor becomes unhealthy (which could happen for a variety of reasons), the CTUN.As is still changing considerably.
It could be related to incorrect estimation of wind direction; even with a healthy Airspeed sensor, the wind direction is never quite right:
In this flight, the wind was light and coming from the west (approx 270 degrees). But as the graph shows, the estimated wind direction is ~90 degrees out. (Please could someone clarify: should the reported direction show where the wind is coming from or where it’s going to? I remember on previous Arduplane builds the wind indicator showed the direction wind is coming from)
What I’d like to be happening is that on a Q_ mode launch, the wind estimation is driven by corrections required to keep stationary/level (direction is critical for a Qplane at this point - accurate weathervaning). Once the plane is flying forward (in Q or FW modes) the airspeed sensor becomes more useful and could be given more ‘weight’.
More info on how EKF3 is calculating the wind direction would be much appreciated, thanks
According to forecast, the wind that day was north-north westerly approx 3.5m/s, however the wind from that log doesn’t correlate (even between the two EKF instances, there is a huge variation):
Update from a quick flight today - light winds from North-West.
Looking at the graph, the wind estimate seems to be about right be the second half of the flight, after flying up and down the field a few times. However, the initial estimate is still well off (this is the estimate generated whilst staying fairly stationary in QLOITER). I see the ability to accurately estimate the wind direction in the initial VTOL takeoff as something very important to a successful VTOL flight - work still to be done here.
There does at least now seem to be decent correlation between the various air/ground speed measures (note, i’ve not recently tried forcing a fault with the airspeed sensor to see what happens):
