An issue has recently come up with my quadplane: When powering up, the airspeed often shows 11m/s. This is in dead calm air/idoors, so it’s not a case of wind causing this. The issue is intermittent, after a few attempts on powering up it sometimes goes away, but if not then it actually prevents me from arming and I cannot fly at all.
To confirm, I have the 3DR airspeed kit. I actually replaced the little board itself but that made no difference at all. Should I try replace the pitot and tubing too?
This is normally indicative of a lack of communication with the airspeed sensor. If you look at your DF logs, when you are seeing in 11m/s of airspeed whats the temperature on the airspeed sensors?
Jaques
Typically we do a pre-flight calibration via the GCS, after the systems are warmed up as part of our pre-flight checks to avoid this. This is particularly important for quadplane use to control transition speeds properly. Use a piece of heat shrink, closed on one end with a zip tie, to cover the pitot tube for better calibration results.
I’ve had the same issue on PX4v1, when powered from USB ~4.8-4.9v, i2c speed airspeed sensor initializes just fine. However with PM power verified 5.25-5.30v AS fails to initialize properly and just gets stuck on 11-12m/s reading.
I assume, because PX4v2 has diodes to separate PM, USB and Servo Rail VCCs, there is a drop of about 0.35v from Power Module which negates initial voltage spike which, I suspect, affects the AS. the workaround was to power AS from the 3.3v line, which is well within the specs for the sensor. However, I would not want to overload 3.3v LDO, so I’ve just used 680ohm resistor in-series on the VCC line of the AS powered from the 5v of the i2c port, in my case this drops voltage to around 3.6v (still well within specs 3.3v-5v), but the initial voltage spike is greatly negated.
I had the same thing happen to me today as well.
In my case, I bet on the I2C cable being too long: 2.2m. Yes I know I’m pushing the I2C spec, but it was working on the bench.
Naturally, after driving 1.5hrs to the field, the sensor decided not to work.
Hi Jeff, this is not a calibration issue. I always do a calibration (with a plastic bag over the pitot) when powering up my aircraft. My particular issue is likely an electronic fault, since when it happens, the airspeed shows exactly 10.8m/s and gets stuck there, regardless of whether I try a pre-flight calibration. I have now changed the 12C board and wiring and so far it seems ok, although time will tell if its sorted, as the problem was intermittent.
I mentioned the calibration as a way to resolve the issue as in our experience that has been the most common cause. You didn’t mention in your post that you done the calibration, or how you do the calibration, every flight. When you say you changed the “little board” do you mean the airspeed sensor?
As you now say, if it is intermittently getting stuck on the exact same value, it’s very unlikely it’s a pitot tube, hose, or mechanical issue with the airspeed sensor. In that state if you blow into it does it change? It could be I2C wire length or signal noise (did you change the cable routing with the I2C board?) or power issues on the I2C bus. If it gets stuck on a value it sounds like either the AS is sending a particular value and failing, or the autopilot is only displaying the last value. To test which it is you could try plugging in the AS into another autopilot or another AS sensor in, if you have either available. Also maybe try another GCS to confirm that the value is from the AS at all.
For quadplane flight, should you suffer from a AS failure you can switch the AS sensor off in parameters whilst flying, and it will continue to work with GPS. Also when using an airspeed sensor be careful with the stall prevention settings, as a low AS reading will result in limited control surface outputs that can lead to loss of control. I’d also advise to set the Q-Assist speed higher than your wing stall speed but below your normal cruise speed to prevent stalls. This will only work reliably with a functional airspeed sensor or in low to moderate wind with GPS only. This is only general advice that I share from experience, but you might already be doing anyway!
Again, please consult your DF log and look at your airspeed temperature. What you should see is readings of 0.0 degrees that correspond to your fixed readings of 10.8. This is indicative of an I2C failure while talking to the sensor. Master plane (within the last week or so) has a digital noise filter, and some bad data rejection patches added that improve the reliability of the I2C bus with noisy sensors, but it won’t solve all problems.
When you are getting the exact same value there will be a bad airspeed health event associated with it, which will then lead to the autopilot not using the reading.
To comment on an item mentioned here, do shield the pitot tube from the wind during calibration, but don’t press against the pitot port, or trap air against the pitot/static holes as this will create a pressure differential that will throw off your airspeed calibration. (IE if your heat shrinking tubing is a tight fit or pressed up against the pitot hole this will cause a problem).
Thx Wshell for the update.
It’s good to know that some airpseed error corrections are being implemented to avoid potentially nasty faulty airspeed related flight issues. This was a the primary cause of why we failed at the last Outback Challenge as a mis-calibrated digital airspeed sensor caused the FC to limit control surface authority via the stall prevention, in turn meaning we could not bank fast enough to turn inside the geofence. Although it was actually doing 32m/s and way over the set stall speed of 16m/s which it thought it was doing. In our case we only had 300m of distance to do a 180degree turn, and only some 7-8 seconds to respond in flight.
Would you know if it is possible to weight between what airspeed is being used, between measured airspeed with a pitot tube and GPS calculated airspeed? Comparing either might also be helpful, or maybe from two GPS units, to see which is actually creating the error.
@JeffBloggs The bad data rejection has to do with bit flips on a digital communication, and unlikely to see the same bit flip on two subsequent reads, it won’t prevent a mis calibrated airspeed sensor from propagating through to the rest of the system.
Due to the internal structuring at the moment we aren’t able to run both the synthetic airspeed estimate and a real airspeed senor simultaneously. I’d agree that. that is the next step forward on improving the sensor’s fallbacks. @MagicRuB has put some effort into this and can explain it better.
Backtracking a bit, @jacques_eloff do you have a particularly long I2C cable, a lot of other I2C devices as well, or any of the I2C bus routed along a RF antenna (IE the telemetry antenna to the GCS).
Firstly, thanks all for looking into this issue, I will do another more thorough read through to try get my head around this. In the meantime, I can respond to @WickedShell’s last question regarding I2C cable length: In my case it is not particularly long, I think it is around 200mm or so from the Pixhawk’s I2C port to the I2C board and then the about the same length from the I2C board to the airspeed sensor board.
Hi, I had the same problem, airspeed readings were never zero, even at home. I solved this issue setting ARSPD_TUBE_ORDER to 0 and then do a PREFLIGHT_CALIBRATION in the ACTIONS tab.
Now reading are almost always zero in no wind condition.
My airspeed sensor is digital and remember connect the longer extension on the pitot tube to the cone that protrudes from the top of the airspeed sensor board and the shorter extension on the pitot tube to the cone protruding from the base of the board.
Setting the tube order to 0 means that any readings the opposite direction due to sensor error are being clipped to 0 automatically. This can mask having a large reported error on the airspeed sensor, because the sensor could be off by 5 m/s one direction, but because you are clipping to 0 you aren’t seeing it.
Depending on what sensor you are using being near 0 in a no wind situation is indeed possible, but if you have a MS4525 or MS5525 it’s probably an indication of bad sensor calibration/offset, and not something that should be considered a reliable indicator for flight.
Thank for your comments. I have this airspeed sensor:
I don’t understand what do you mean with “readings the opposite direction”. It’s supposed planes flys in one direction, never backwards. Thank you for your help, I’m beginner in this matter.
The sensor simply reads a differential pressure, it can be positive or negative. When you specify the tube order we will only look at positive or negative readings. The problem is related to the fact that the sensor has a offset we must account for. This offset is the actual value to read as 0 airspeed. The problem can come when you are telling the airspeed library to only look at positive values, but the actual value for 0 is -50 pascals.
The sensor you’ve linked is a MS4525, and when in a no wind environment it should be reporting a fairly noisy signal between 0 to 2 m/s. (It will get better as you move faster, but at low speed the error is magnified)
Thank for your clear explanation. The fact is my airspeed sensor is reporting a signal between 2 to 17 m/s and this seem to much for me. Here I send the tuning screen. I’m inside a closed room and I’ve done a previous PREFLIGHT_CALIBRATION.
MS4525 is known to be light sensitive. I haven’t caused any problems with artificial light sources but I can produce large errors when exposed to sunlight. Any chance of light hitting the sensor in your current setup?
Right now is night at home, I’ve try with all room’s lights off but the error persist.
At the flight field the sensor is inside the plane and not direct sun light is in contact with the sensor.
