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

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 f...

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-stal...

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

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%2...

Views: 2575

Reply to This

Replies to This Discussion

Looks like you are operating fairly hot.    Your rawtemp in your log is about 7000 counts.     I checked my Pixhawk raw temp in being logged and it is about 3800 in the shade.   I think the raw temp measurement is on the Pixhawk board.

I did notice that you have the ARSPD_TUBE_ORDER=2.   This is the auto tube order setting.   I have not always had good airspeed sensing performance with 2.

With the analog airspeed sensors I have found that 2 isn't as reliable as setting the order as either 0 or 1.    I try the dynamic and static pressure hoses connected each way to the differential pressure sensor.   Switching ARSPD_TUBE_ORDER=0 or 1 so that gently blowing into the pitot tube gives a positive airspeed indication.

One way of connecting the hoses always gives a lower noise reading after Preflight calibration.

I have found that commanded preflight calibration is useful.  This allows you to run the calibration on the altimeter and airspeed sensor after everything is warmed up.      I always close up the plane and after a few minutes cover the pitot tube and run preflight calibration.     This should zero airspeed to within a few meters/sec.   I also hold the plane up and lightly blow into the pitot while watching telemetry to confirm that airspeed increases.

Yes Sir, second link in the description, in black.

Gerardo Espino said:

Have you a photo of the aircraft and the airspeed sensor on it?

@David  Ok, I checked the schematics for the 4250DO sensor, dynamic part plugs into the top nozzle, static into the bottom.  I'll give that a go.

"This parameter allows you to control whether the order in which the tubes are attached to your pitot tube matters. If you set this to 0 then the top connector on the sensor needs to be the dynamic pressure. If set to 1 then the bottom connector needs to be the dynamic pressure. If set to 2 (the default) then the airspeed driver will accept either order. The reason you may wish to specify the order is it will allow your airspeed sensor to detect if the aircraft it receiving excessive pressure on the static port, which would otherwise be seen as a positive airspeed."

This has potential!

I looked at the rawtemp in some of my past logs, you are right, even inside my house at 76deg F its measuring at 50deg C, which is about 125deg F.  Why would it be getting that hot? Is that normal?

I ran a pixhawk board on the desktop here and got raw temp readings of no more than 3800.  So up around 7000 does seem high.    You could try running the pixhawk off usb power too and see if you get similar readings.

Perhaps one of the power source voltages, when you are running off plane power, is a little to high.   

https://pixhawk.org/users/tutorials/pixhawk_6s_mod    

Good check to do David, voltage at the airspeed sensor is 4.92V DC.  I think that's correct.  I still can't explain the high temps though.

I had/have simulair issues, therefore I took out the airspeed sensor and did some experiments on my testbench.

My test setup is as follows:
MS4525DP airspeed sensor (tested 2 different suppliers)
Modified pitot tube, no air leak.
Arduino UNO with same MS4525DP code as in Ardupilot.
short cables between sensor and CPU
10cm tube between pitot and sensor
setup in house a 20deg C

What I notice is the following:
There is a lot of noise in the airspeed dat 2 m/s pp
The airspeed sensor is very supply voltage sensitive : 10 m/s / volt ( 3.5 --> 5 volt, 0 m/s --> 15m/s)
Temperature dependency I did not check however I'm confinced it is a lot.
The supply current is very low, and I have no noticable temperature rise of the sensor

Conclusion:
My planes speed is around 10 m/s, with this low speeds the airspeed sensor is useless due to high offset drift (voltage, temp, ..., etc)

Before I did also test with the anolog airspeed sensor, that is even more supply voltage sensitive.

So.....Final report.

Impact at 84mph.

Airspeed calibration ON

Airspeed use OFF

Airspeed enabled ON

Airspeed tube order set to 0 (confirmed correct via manufacture specs and by blowing into the tube) - this did indeed improve calibration!  it was the best I've seen any previous drone that I've built. 

Took off fine, started to increase speed more and more despite having a do change speed command of 12m/s in the mission.  I heard it change from takeoff speed setting to the lower 12m/s setting.  After that she appeared to get faster and faster and I was unable to dial back the speed.  I know some of you will pick that statement apart, please don't bother, just look at the logs because what the pilot sees on the ground is rarely what is happening in the air.

This is fucking sad.

Logs labeled Final Crash linked here.

Chad,   Sorry to see the crash.    There is no small irony in the bin file.    The temperatures logged from both the airspeed sensor and the barometric sensor are both reasonable.    Airspeed seems pretty close to GPS velocity as well.

There was 100% throttle demand for quite a bit of the flight.     I usually bring up a troubled airframe through the modes.   I like to have Stabilize and FBWA to fall back on. 

FLWB turns on both speed and altitude control.   From a flight control perspective it is pretty much that same as Auto.     If the plane is going unstable in FLWB switching back to FBWA or even Stabilize gives you manual throttle control again.     Much easier to recover in FBWA or Stabilize than manual.

I have no explanation for 100% throttle, I know for sure I put the transmitter at ZERO throttle pretty quickly when I felt it was going too fast.  Does that match against commanded throttle?  I've not had the emotional energy to look yet.

I just checked my transmitter, it was on the correct model.  I also did throttle checks in manual and stabilize modes before takeoff as part of my checkoff list.

What is the last grey wall for?  It looks like my RTL path but my RTL altitude is set at 400 feet, that looks more like 700-800ft to me.  I've not seen that before on a KMZ file.  Is it new??

What is the waypoint wall highlighted???  It does not correspond to ANYTHING in the mission that was loaded!!  Mission waypoint file is now in the folder that is linked above in the first description as well as the KMZ file you are looking at below.

Reply to Discussion

RSS

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service