$100 Gift Card to whoever solves this: Airspeed Creep - Airspeed artificially increasing - Fixed Wing (ROUND TWO!) - Discussions

This is another post on this problem, this will be the most thorough. I am not the only one with this issue as it dates back to at least one year ago as far as I could tell from scanning these forums. Here is a link to a previous post I did that is the same problem. Disconnecting the airspeed sensor is the only solution, which is not acceptable on multiple levels.

DOWNLOAD LINK for tlog, rlog, waypoint files, parameter file, kmz file and pics. (RESTRUCTURED FOR CLARITY)

PROBLEM:

While sitting on the ground after awhile the airspeed will creep up to 20-31mph. This happens within 10-30 minutes of bootup, sometimes sooner. It only happens outdoors, today's temperature was 91deg F with no wind (1-4mph).

1. A Preflight Calibration will put the airspeed down to 3-10mph with a mean of 8mph, BUT it will creep up again.

2. Multiple calibrations does not solve this problem. Update: Calibration hangs most of the time when attempting to calibrate.

3. If the aircraft is sitting in my house with no wind and constant temperature the airspeed creep problem does not present itself within 9 hours of use.

4. The autopilot and the sensor have been replaced. Wires from the sensor and the I2C board has been replaced. No other wires have been replaced.

5. I can not make this problem happen by physically manipulating any wire or component.

6. If I blow into the airspeed sensor it reports back an increase in airspeed.

7. Max operating temperature of the airspeed sensor is 221deg F, a temp reading of the sensor put it at 127deg F for the Goodluckbuy version, 2/3 of them, not trying a third.

8. I have confirmed that the wires are connected to the proper pins for pixhawk, airspeed sensor and I2C board.

9. This is a NEW pitot tube, it is not clogged or dirty in any way.

10. I had an electrical engineer deconstruct the circuit using documents provided by the manufacturer of the 4250DO component, it looks to be correctly interfaced and the tracers on the circuit look fine.

11. Wire length has been shortened to less than 7 inches, the problem persists.

12: Disconnecting the Sonar does not solve the problem.

13: This very much seems to be a heat induced problem, either that or it is linked to spinning the motor (4 amp draw) somehow. All of these tests are done on the ground for obvious reasons.

*****14. POST UPDATE: So I built another bird (referred to as "second aircraft"). The photo of it is in the same link as the original posted link. New aircraft, new transmitter, new pixhawk, new airspeed sensor SAME Problem.

*****

15. POST UPDATE: Putting the bird in auto calibrate for airspeed (and flying manual for a long time, 20 minutes) does change the airspeed ratio as it should but this does NOT fix the problem. Original value was default of 1.9733, new calibrated value fluctuated from 1.0023 to 4.756.

16. POST UPDATE: When in a throttle controlled mode (auto, RTL etc) the bird does cut the throttle to ZERO as it should because the airspeed is reading 47mph when it was actually traveling closer to 20mph. It is trying to slow down to meet target airspeed (throttle stick was confirmed to be LESS than 50% so it was not interfering with the throttle nudge ability). So I know for a fact that it is not the TECS energy management logic that is faulty it is for sure a bad sensor input.

17. POST UPDATE: Changing the ARSPD_TUBE_ORDER variable from 2 to 1 does make the airspeed more stable. Two things, it causes Pixhawk to beep three rising tones (VIDEO OF THIS BEEPING LINKED HERE) when airspeed hits or appears to get close to zero (and does NOT report any errors) AND it does NOT solve airspeed creep

The weird stuff:

1. I once disconnected the sonar to troubleshoot this. After that, when I picked the bird up to see the affect on altitude THE AIRSPEED went to 15mph. I was able to repeat this consistently 4 times, then stopped and cried.

2. Sometimes with the airspeed sensor disconnected the sonar will report bad lidar health for no reason, indeed it once did not report anything at all (a zero for alt), a reboot or two solved the zero altitude problem but did not make the bad lidar health issue go away. That still happens occasionally (rare). The sonar checks out fine in all ways I can test it. It's good.

3. I armed the bird to let it sit so I could make a pure tlog file demonstrating this issue. Upon getting the issue to appear I tried to re calibrate it, it told me the bird was flying when it was not and therefore it would not perform the calibration.

Equipment:

Goodluck Buy v1.1 airspeed sensor (2/3 melted), 2 other manufacturer types tried as well, JDrone and another no name brand. All airspeed sensors tried thus far are digital.

V2.4.8 Pixhawk 1

Two 3DR gps/mag units

Castle Creastions Pro BEC

RFD900+ Telemetry Radio

I2C board

7S Power Module (not from 3DR, they don't make one)

Castle Creations ESC

Maxbotic I2C XL 1242 Sonar

4 Digital Hitec servos with some wire extensions to reach the autopilot

buzzer/switch/usb extension

Futaba receiver with a PWM module to connect to pixhawk

Theories:

1. Goodluckbuy has picked a manufacturer that is making these sensors in a different way than 3DR endorsed airspeed sensors were, thus causing this problem - I had two out of three of this brand fail by melting down at 127deg F (see pics). Not trying the third I just threw it away instead.

2. This is an airspeed algorithm issue - making the most sense at this point

3. Temperature is causing this issue somehow - No longer think this is an option due to multiple platforms being used and in much cooler temperatures (72deg F ambient to 103deg F ambient)

4. Jupiter has aligned with Mars and the age of Aquarius is upon us - probably the best cause in my humble opinion

5. Noise from the servos due to long (12inch) extensions is somehow playing into this (except for when the bird is indoors?) - No longer thing this as other platforms have long servo cables and work, also the signal inputs from servos are isolated from the inputs from the I2C components

6. GPS inaccuracies are feeding sensor data to an algorithm that over a short time reports back that the only way to make all that jumping around make sense is to say the bird is flying and flying at 20-31mph. - Not likely but I can not rule this out because I have not seen or understand the code itself

7. Could the Sonar be causing this somehow? - No longer think this because the NEW platform does not have a sonar and it too has the airspeed creep issue.

8. POST UPDATE: I now firmly believe that this is a software issue that started somewhere after 3.0.

The question:

What is causing the airspeed to creep up artificially and thus causing the aircraft to stall?

Others with the same problem:

http://diydrones.com/forum/topics/airspeed-sensor-issues

http://diydrones.com/forum/topics/throttle-reduce-and-eventual-stall-on-auto-mission

http://diydrones.com/forum/topics/pixhawk-barometer-temperature-compensation

I am offering $100 Gift Card to whoever can help me solve this. I flew for YEARS without this issue and now all of a sudden it's a problem. Will mail the gift card to anywhere in the world.

https://www.dropbox.com/s/2kpdnhmc1mj68sg/Showing%20the%20Problem%20-%20Copy.JPG?dl=0

Hi Chad,

Sorry it has taken me so long to respond on this thread. There is a lot to cover in this thread, I'll see if I can hit the highlights in this response.

First off, if you want to get back into the air quickly then you can set ARSPD_ENABLE=1 and ARSPD_USE=0. That will enable logging and reporting of the airspeed from the sensor but won't use it to fly the aircraft. Most aircraft will fly fine without using an airspeed sensor under most circumstances. When investigating airspeed sensor problems flying with the airspeed logged but not used can be a very useful diagnostic technique. Also note that you can change the value of ARSPD_USE while flying to enable/disable use of the sensor for flight control during a flight. (hmm, I later noticed you do this in one of your flights).

The second thing I'd note is you mentioned getting very large values for ARSPD_RATIO. Anything below 1.4 or above 2.5 is highly suspect and is most commonly caused by an installation problem, usually a kinked tube, blocked tube or positioning of the pitot where it can't get a good reading (eg. not in clear air).

Next thing I would note (and I think you know this already) is that the mapping from differential pressure as measured by the sensor and airspeed is non-linear. It is:

airspeed = sqrt(differential_pressure * ratio)

the significance of this is that when you see an airspeed on the ground of 3 to 5 m/s that maps to a much smaller error in flight. If we assume an ARSPD_RATIO of 2.0 then an airspeed of 5 read on the ground implies a differential pressure of 12.5. If we were to then fly at 20m/s then that 12.5 pressure error would give an airspeed reading error of just 0.6m/s.

I know that you are getting much larger errors than this. I mention it as most reports of airspeed drift don't take this into account. Users are often concerned about an airspeed error on the ground of 3 to 5 m/s, which maps to to an airspeed error at 20m/s of 0.2 to 0.6 m/s. They don't realise that the non-linear nature means that seemingly large ground errors don't map to large airspeed reading errors in flight.

Thanks for the pictures of the installation. There are a few things I notice in the pictures that could be improved, although none of them adequately explain the issue. First off, the pitot is too close to the nose of the aircraft. A pitot tube takes a reading of the difference in pressure between two points. One is the tip of the pitot, the other is the static port. It looks to me as though your static port is going to experience a fair bit of airflow from the fuselage. The tip is better placed, but really should be further out, but I think the biggest issue is the location of the static port holes in the pitot. The picture isn't really clear, but I think the holes in the side of the pitot are within 0.5cm of the fuselage, and next to a slanted part of the foam. If you can imagine the air rushing past the nose at that point you'll understand that it will change the pressure measured by the static port, most likely giving a lower static port pressure, which will result in a higher airspeed reading.

The second thing I notice in the pictures is the tubes going back to the sensor are way too long and can flop around under G forces in the aircraft. You want those tubes to be secure but not at all constricted.

Now on to your logs. I see 4 logs from you. Two of them are for the same flight (a tlog and DF log).

The first is 2016-09-17 12-38-45.tlog. That is a ground test where the reported airspeed goes up to a peak of 16m/s.

Assuming that there wasn't actually a lot of wind blowing over the sensor then this is indeed an example of extreme error far beyond the normal range. It doesn't actually behave like temperature drift, which is normally slow. I can see in the log that you redid the airspeed cal at 3:51:49 in the above timescale (in my timezone). That caused a drop in the reported airspeed as expected, but the rise after that is extraordinary.

The voltages in the log look fine. A tlog doesn't contain the temperature from the airspeed sensor unfortunately (that is only in the DF log). Your baro temperatures are higher than usual (up to 76 degrees C) but apart from that things look fairly normal. The high baro temperature may be a clue. We normally expect values in the 40 to 50 degree C range. Was it very hot weather?

Note that as the aircraft was not actually flying I can't see how the above result could be caused by the position of the pitot tube.

I would say that if I saw the above problem happening on the ground then the first thing I would do is disconnect both of the flexible tubes from the sensor. That should give a reading close to zero as the differential pressure should be zero. If it does give a zero reading and it didn't when the tubes were attached then you know it is a problem with the tubes. I have seen extreme examples like this in ground tests when some moisture got into the flexible tubes and created a pocket of compressed air in the tube.

I would also systematically turn off or disconnect other devices to see if one is associated with the error. For example, we have seen cases of extreme airspeed error with an early model PulsedLight LidarLite attached to the same I2C bus as the airspeed sensor. I notice you have a rangefinder enabled, can you tell me what sort it is?

Let's look at the 2nd log, 2016-10-02 14-41-18.tlog.

I've focussed in on just the part where its flying.This log had ARSPD_USE=0, so it was logging airspeed but not flying with it. I'd note that the aircraft starts to get into trouble while the airspeed is reading lower than ground speed. At the point the pitch and roll depart from the demanded attitude the airspeed is reading 24 and groundspeed 30. That is much too fast for this aircraft, and it is quite likely that the very high speed caused it to lose control.

There are a few things I notice in the log. First off, it has THROTTLE_NUDGE=1, which means the throttle stick does cause extra throttle to be put in in AUTO mode when above 50%. It kept the throttle up after you dropped the throttle stick though. That may be worth coming back to.

I also notice you had ARMING_REQUIRE=0. That is a very bad idea as it disables all arming checks. I don't think it caused the problem, but it will someday.

This 2nd log has a corresponding DF log, First Aircraft - Final Crash.BIN. That is useful for diagnostics as it gives us the temperature logged from the airspeed sensor. That shows quite reasonable temperatures of around 33 degrees C. The fact that the temperature doesn't show a lot of variation means it is unlikely to be I2C bus errors causing the bad airspeed readings.

On to log3, 2016-10-23 09-29-21.tlog. That one has ARSPD_AUTOCAL enabled, so it is trying to learn the airspeed ratio. The ratio drops all the way down to 1.0, which is much too low. That indicates that the sensor is seeing a much higher differential pressure than it should be seeing. That is normally a problem with the static port (see above) or a kinked or blocked tube.

I would not recommend flying with ARSPD_AUTOCAL enabled again until you get to the bottom of these issues. Just set the ratio to 2.0 and leave it there. We can always get the right ratio from a post-flight analysis of a log once the sensor is behaving sanely.It's getting late here and I need to get some sleep, but I'm happy to follow up with you some more on this. We may need to run some ground tests together to see if we can narrow it down. Please read the above carefully and answer the Qs I put in.

Cheers, Tridge

Replies

Ruedi Schubarth April 20, 2017 at 7:35pm

Chad/others-

Any thought given to the stated limitations of the MS4525DO chip (and others)? They all pretty much give 95% humidity (non condensing, even) as a maximum limitation. I'm in E. Texas, and the humidity is regularly above 95%. The TE data sheet ( Data Sheet ) even states on p. 13 that the MS4525 is for clean dry air applications only. Thinking back to RQ-7 days and how sensitive it was to rain, surely a consumer-level component would not perform well above stated limitations? Just a thought. I have a 3DR Aero sitting on a shelf waiting to fly, while I figure out a way to prevent humidity from affecting the P/S system on the hot humid days.

Still a head scratcher as you mentioned you've flown for years without issues, so that almost rules out environmental factors and points to firmware. Almost.
Moderator

Graham Dyer April 15, 2017 at 5:53am

So was this ever definitively solved? Chad?

I have the same slow ascending airspeed on the ground yet it creeps down to zero while flying, very bizarre. All tubes good, triple checked, everything else mentioned here OK.
Federico Lanzi April 2, 2017 at 5:32pm

Hi guys,

I'm facing the same issue with the airspeed sensor, no matter how many calibrations I make, after a while the airspeed increase progressively. (aprox from 0 to 15m/s in 15 minutes after calibration is performed)

Has anyone find a solution?

Thanks

Fede
Mike Feldmann December 5, 2016 at 11:20am

Hi Chad!

I had a problem like this with a differential pressure sensor a couple years age. Turns out the pressure sensing elements are very sensitive to sunlight. I had hooked up pressure probes to the sensor with transparent yellow, Tygon-like, tubing. In sunlight the yellow tubing seemed to act like a light pipe or fiber optic, exposing the sensing elements to light. Caused odd, bias-like, effects on the sensor outputs. May be a long shot, but you might want to try tubing that sunlight cannot penetrate.

Respectfully,

Mike
Developer

Andrew Tridgell November 30, 2016 at 6:06pm

Chad and I had a good call today. Looks like a possibility for the high drift may have been pressure on the tubes from other components in the fuselage. Chad will be investigating further.
Chad Frazer November 30, 2016 at 1:32pm

Since the original aircraft didn't make it I have a new aircraft with the same problem it is in the Phantom FX61 Folder linked here: https://www.dropbox.com/sh/yp768lo9qyhwppy/AADEM9Bl4fPD7tn3rHcNVwXx...

It has detailed pics and a fully converted spread of logs for review.

Phantom FX61 - All Files

Shared with Dropbox
Chad Frazer November 30, 2016 at 1:27pm

To answer your questions real fast before I call:

1. Temperature that day was only in the 80F range, 76C is about 168F. Here in Texas we do get up to 110F but not that day, I can not account for high baro temps other than the autopilot was directly exposed to the sun.

2. The rangefinder is the Maxbotic I2C XL Maxsonar.
Chad Frazer November 30, 2016 at 7:21am

Prepping, I'll call you about 8-9AM your time. TY!!
Developer

Andrew Tridgell November 30, 2016 at 2:57am

Hi Chad,

Sorry it has taken me so long to respond on this thread. There is a lot to cover in this thread, I'll see if I can hit the highlights in this response.

First off, if you want to get back into the air quickly then you can set ARSPD_ENABLE=1 and ARSPD_USE=0. That will enable logging and reporting of the airspeed from the sensor but won't use it to fly the aircraft. Most aircraft will fly fine without using an airspeed sensor under most circumstances. When investigating airspeed sensor problems flying with the airspeed logged but not used can be a very useful diagnostic technique. Also note that you can change the value of ARSPD_USE while flying to enable/disable use of the sensor for flight control during a flight. (hmm, I later noticed you do this in one of your flights).

The second thing I'd note is you mentioned getting very large values for ARSPD_RATIO. Anything below 1.4 or above 2.5 is highly suspect and is most commonly caused by an installation problem, usually a kinked tube, blocked tube or positioning of the pitot where it can't get a good reading (eg. not in clear air).

Next thing I would note (and I think you know this already) is that the mapping from differential pressure as measured by the sensor and airspeed is non-linear. It is:

airspeed = sqrt(differential_pressure * ratio)

the significance of this is that when you see an airspeed on the ground of 3 to 5 m/s that maps to a much smaller error in flight. If we assume an ARSPD_RATIO of 2.0 then an airspeed of 5 read on the ground implies a differential pressure of 12.5. If we were to then fly at 20m/s then that 12.5 pressure error would give an airspeed reading error of just 0.6m/s.

I know that you are getting much larger errors than this. I mention it as most reports of airspeed drift don't take this into account. Users are often concerned about an airspeed error on the ground of 3 to 5 m/s, which maps to to an airspeed error at 20m/s of 0.2 to 0.6 m/s. They don't realise that the non-linear nature means that seemingly large ground errors don't map to large airspeed reading errors in flight.

Thanks for the pictures of the installation. There are a few things I notice in the pictures that could be improved, although none of them adequately explain the issue. First off, the pitot is too close to the nose of the aircraft. A pitot tube takes a reading of the difference in pressure between two points. One is the tip of the pitot, the other is the static port. It looks to me as though your static port is going to experience a fair bit of airflow from the fuselage. The tip is better placed, but really should be further out, but I think the biggest issue is the location of the static port holes in the pitot. The picture isn't really clear, but I think the holes in the side of the pitot are within 0.5cm of the fuselage, and next to a slanted part of the foam. If you can imagine the air rushing past the nose at that point you'll understand that it will change the pressure measured by the static port, most likely giving a lower static port pressure, which will result in a higher airspeed reading.

The second thing I notice in the pictures is the tubes going back to the sensor are way too long and can flop around under G forces in the aircraft. You want those tubes to be secure but not at all constricted.

Now on to your logs. I see 4 logs from you. Two of them are for the same flight (a tlog and DF log).

The first is 2016-09-17 12-38-45.tlog. That is a ground test where the reported airspeed goes up to a peak of 16m/s.

Assuming that there wasn't actually a lot of wind blowing over the sensor then this is indeed an example of extreme error far beyond the normal range. It doesn't actually behave like temperature drift, which is normally slow. I can see in the log that you redid the airspeed cal at 3:51:49 in the above timescale (in my timezone). That caused a drop in the reported airspeed as expected, but the rise after that is extraordinary.

The voltages in the log look fine. A tlog doesn't contain the temperature from the airspeed sensor unfortunately (that is only in the DF log). Your baro temperatures are higher than usual (up to 76 degrees C) but apart from that things look fairly normal. The high baro temperature may be a clue. We normally expect values in the 40 to 50 degree C range. Was it very hot weather?

Note that as the aircraft was not actually flying I can't see how the above result could be caused by the position of the pitot tube.

I would say that if I saw the above problem happening on the ground then the first thing I would do is disconnect both of the flexible tubes from the sensor. That should give a reading close to zero as the differential pressure should be zero. If it does give a zero reading and it didn't when the tubes were attached then you know it is a problem with the tubes. I have seen extreme examples like this in ground tests when some moisture got into the flexible tubes and created a pocket of compressed air in the tube.

I would also systematically turn off or disconnect other devices to see if one is associated with the error. For example, we have seen cases of extreme airspeed error with an early model PulsedLight LidarLite attached to the same I2C bus as the airspeed sensor. I notice you have a rangefinder enabled, can you tell me what sort it is?

Let's look at the 2nd log, 2016-10-02 14-41-18.tlog.

I've focussed in on just the part where its flying.This log had ARSPD_USE=0, so it was logging airspeed but not flying with it. I'd note that the aircraft starts to get into trouble while the airspeed is reading lower than ground speed. At the point the pitch and roll depart from the demanded attitude the airspeed is reading 24 and groundspeed 30. That is much too fast for this aircraft, and it is quite likely that the very high speed caused it to lose control.

There are a few things I notice in the log. First off, it has THROTTLE_NUDGE=1, which means the throttle stick does cause extra throttle to be put in in AUTO mode when above 50%. It kept the throttle up after you dropped the throttle stick though. That may be worth coming back to.

I also notice you had ARMING_REQUIRE=0. That is a very bad idea as it disables all arming checks. I don't think it caused the problem, but it will someday.

This 2nd log has a corresponding DF log, First Aircraft - Final Crash.BIN. That is useful for diagnostics as it gives us the temperature logged from the airspeed sensor. That shows quite reasonable temperatures of around 33 degrees C. The fact that the temperature doesn't show a lot of variation means it is unlikely to be I2C bus errors causing the bad airspeed readings.

On to log3, 2016-10-23 09-29-21.tlog. That one has ARSPD_AUTOCAL enabled, so it is trying to learn the airspeed ratio. The ratio drops all the way down to 1.0, which is much too low. That indicates that the sensor is seeing a much higher differential pressure than it should be seeing. That is normally a problem with the static port (see above) or a kinked or blocked tube.

I would not recommend flying with ARSPD_AUTOCAL enabled again until you get to the bottom of these issues. Just set the ratio to 2.0 and leave it there. We can always get the right ratio from a post-flight analysis of a log once the sensor is behaving sanely.It's getting late here and I need to get some sleep, but I'm happy to follow up with you some more on this. We may need to run some ground tests together to see if we can narrow it down. Please read the above carefully and answer the Qs I put in.

Cheers, Tridge
Crady von Pawlak November 5, 2016 at 4:54pm

Hi Chad. If your AS sensor is based on the TE Connectivity Measurement Specialties 4525DO then your temperatures are well within the tolerances of the device and would not contribute to the errors you're seeing (the normal, uncompensated operating range is -10 to 85C).

I haven't personally used one of these but a quick look through the datasheet hints at a susceptibility to power supply noise/fluctuations even though the output is not ratiometric (this conversation appears to confirm that suspicion): https://groups.google.com/forum/#!topic/drones-discuss/ccPfL7jgdmk

If you can, I would try completely removing the flight controller and sensor from the aircraft and test the pair powered solely by a USB connection.

4525DO Datasheet http://www.te.com/usa-en/search.html?q=4525DO&source=header

of 5

This reply was deleted.