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.
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.
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
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
Futaba receiver with a PWM module to connect to pixhawk
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.
What is causing the airspeed to creep up artificially and thus causing the aircraft to stall?
Others with the same problem:
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.
Uploaded a lot more files such as the parameter file, kmz, .tlog, .rlog etc etc, you guys now have all I have.
I see what you mean about the throttle, its at 80-90% the whole time. Take off throttle setting is 90 (see param file) and the Thr_Max variable is also at 90. This crash looks to be an overspeed crash, but why is AUTO mode commanding 90% throttle the whole time?? THR_MAX reads:
The maximum throttle setting (as a percentage) which the autopilot will apply.
which to me means that it can never go OVER 90%, NOT fly AT 90% the whole way, am I wrong?
I don't know if it could be your recent problem but have you checked around your radio receiver? If you have a Short Plug sytem for Channel setting , you may have had an external element on or in the pin.
I have had this rare problem in the past and the copter was totally crazy, always at full speed .
A simple tape is strongly recommanded around the receiver.
I checked for shorts and the plug, nothing there Sobido, but good idea!
The impact was so hard it blew components off of circuit boards.
I'm so awesome.
So sorry for your crash.
How do you power you FC? When I had other problems (sonar) I rebuilt the power to FC and a separate to sonar. I added "switched step down power" and after that LC-filter to end at 5VDC.
I had a second "goodluckbuy" airspeed sensor that also failed in the same manner as the first, temperature reached 127F. I swapped it out for one I got from JDrones and although it is in a different aircraft it has performed as expected. It seems that the goodluckbuy versions are missing some sort of basic circuit protections but it must be withing the air pressure sensor itself or only visible when you have the actual build schematics.
I do not know what causes this airspeed creep problem nor the high temperature issue I just know that I need a GOOD SOURCE FOR HIGH QUALITY PARTS.
I want to pay extra if it means I can TRUST my components.
Thank all of you that helped to try and solve this problem, I will leave the files accessible in case someone can use them.
Glad you were able to finally fix this! Now, get out there and fly ;)
Built a new bird, it too has this problem. More pics are in the supplied link of the original post. Additional tlog is provided. $100 bucks to whoever solves this is back on.
We are going to try to revert the firmware to a known working version (3.1?).
I noticed that the airspeed indicated in the tlog was about 16 meter/second when you launched. Ground speed was 0. Was there that much wind?
As part of my preflight, immediately before launch. I put a sock over the pitot and use preflight calibration to zero the airspeed and altimeter. After the preflight calibration I remove the sock, pick the plane up and blow gently toward the front of the pitot until I see 7 to 10 meter/sec indicated airspeed. Airspeed should drop back to 0 after you stop blowing at the front of the pitot.
Pitot tube was covered via a plastic bag, look in Second aircraft folder for the pic. No, wind was not that high, that's just the airspeed creep. What equipment and firmware version are you using david?? I need a known working setup to compare mine to.
I am using 3.7.0, a HK32 Pixhawk and a HK Digital Airspeed Sensor.
Launching with the airspeed off by 16meters/sec would make flight control quite poor in the FBW modes. If Preflight Cal is not working you can directly enter the offset as a parameter ARSPD_OFFSET. Entering it directly as a parameter will let you zero airspeed, preflight cal is much easier.
preflight calibration does work, but then after a few minutes it goes back up! If you are using 3.7.0 then i'm in trouble, so are we! Maybe this is a hardware issue with the clone pixhawk I got??
Hard to see how the kind of differential pressure measurement errors you are getting would be caused by the pixhawk clone. Perhaps some sort of I2C bus problem? You could try just connecting the differential pressure to the I2C alone.
You do not need the remote GPS magnetometer.