Recently, my team tested a large quadplane model, and ran a satisfactory flight in AUTOTUNE mode. However, I noticed from the log analysis that there are some noise issues with our airspeed sensor; see the screenshot from our log below:
From the log, the airspeed gets frequent sudden spikes to zero throughout its flight. Also, the NKF4.SVT values frequently exceed 1. According to this link the EKF will reject the airspeed data when this parameter goes above 1; that means that my airspeed sensor’s readings are not being used through many parts of the flight due to the noise issues.
Right now, we don’t experience adverse issues as we are flying under RC control. However, this is still a cause for concern when we perform AUTO flights in the future. What I am curious to know is:
- What problems will these airspeed noise and EKF rejection behaviour give when we perform autonomous flights?
- How do we go about reducing the airspeed noise?
Below I have attached the flight log, param file, as well as other info that may be handy:
- Our airspeed sensor and pitot tube are mounted along the right wing, shown in this picture:
Any help will be really welcome!
too long i2c wires? use shielded wires, or better use long pressure tubes.
also the sensor is very close to one of the quadmotors.
Thanks for the reply! Just to give a bit more info: We avoided the need for excessively long i2c wires by using a I2C - Cat6 extender system with the following connectors: https://learn.sparkfun.com/tutorials/qwiic-differential-i2c-bus-extender-pca9615-hookup-guide?_ga=2.53437102.702448980.1536918502-1594996185.1535701754
Below is a photo of airspeed sensor setup before we integrated it into the aircraft, note the I2C - Cat6 connection that we used to connect the airspeed sensor to the Cube:
(Sorry for the poor resolution, this was the best photo we could get from the preliminary setup!)
Nevertheless, our airspeed sensor is indeed poorly positioned, and the pitot tube is the stock tube that came with the MS4525DO. We are trying to look into ways to better position the sensor and source for longer tubes, but I don’t foresee the work being completed before our next test flight. Hence I am curious to find out if there are any adverse consequences if I fly with this kind of noise during an autonomous flight.
It looks like a cabling issue. The key thing to look at is the ARSP.Temp reading, which is the airspeed temperature:
The good news is it shows the issue even when you are on the ground. I suggest you put a good logic analyser (eg. Saleae Pro) on the I2C pins and see if you can spot what is happening. Also try without the differential extender.
It will probably fly OK, but it is risky. I suggest you fly with ARSP_USE=0, which means it will log the airspeed sensor but not use it. It will use a synthetic airspeed estimate instead. Make sure you set TRIM_THROTTLE to a value a bit above what you expect to be needed in cruise flight (ie. at least 50 on your airframe).
btw, your ARSPD_FBW_MIN looks a bit low for that airframe. Are you sure it stalls at below 13m/s ?
Also, your vibration levels are far too high:
you need to add some good isolation foam below the cube (the internal isolation of the cube is not suited to the frequencies in your airframe). This is causing significant pitch estimation errors in flight.
Thanks @tridge ! Airspeed sensor temperature was not something I had thought to look at previously, and my understanding of I2C is pretty limited. How does the airspeed temperature affect the performance of the sensor?
Nope, stall speed is definitely higher than that, will need to sort this out when we tune our TECS.
Thanks again, and will check in when I have updates!
it doesn’t (or at least not much)
The reason the temperature log is useful is it is unaffected by the pitot setup. So if the temperature is going crazy then it is confirmation the issue is with the i2c link, and not with the physical setup of the pitot.
I know that from the airspeed log that was already very likely, but I usually check the temperature to be sure.
Many thanks for the advice! Our next flight test is coming soon so we will see what comes out of it (:
I’m back after our next flight test with good news and bad news.
The good news is we seem to have found a fix for our airspeed noise problems: It turned out that the airspeed sensor’s mounting was loose. Securing it and moving it slightly further away from the aileron servo reduced the airspeed noise for our next flight, without any of those annoying spikes to zero.
The bad news is… we crashed. After looking through the logs for the past couple days, we weren’t able to make much headway into what caused the crash, so we have created another post here to seek help.
Many thanks for the help!
Your mention that the sensor was close to servo matches something I noticed today.
I was running on USB, watching my airspeed in the tuning window and when I plugged in the battery, the airspeed went from nice and quiet to 2-4 meters/second. And it was at least somewhat repeatable.
I had a small power cable running next to the MRO 5525 airspeed sensor. But it wasn’t close to the I2C cable.
I believe that the evidence says that the airspeed sensor itself is sensitive to nearby power sources. I’ve tried all sorts of things with the I2C cables in the past…but I didn’t make sure the sensor itself was totally free of EM influences.
The I2C signals are digital and not that fast. They ought to be somewhat resistant to EM interference. The airspeed sensor is at least partially analog with no such guarantee.
To doubters, my quick fix was to tie wrap the power cable to the I2C cable at a bulkhead in order to pull the power cable away from the sensor. Granted, the power cable now crosses the I2C cable at almost a right angle…but there is a little bit (.75") of parallel path. I’ll probably find something else to route the power cable away, but the new routing seems to allow the airspeed sensor to work much better.