I had airspeed dump bogus data to autopilot probably due to a bad cable or i2c hub thing. Airspeed read 2ms on the ground but right after airborne pegged at 110ms control was given over to autopilot without me knowing this.
Autopilot system cut power to zero and as a result started to lose altitude
Ground speed reads 13ms
altitude is dropping
the nose is down
the autopilot cant bring the nose up above the horizon.
Airspeed is 110ms and pegged
How come the EKF didn’t go “Hey wait a minute here” and ignore airspeed and use gps?
There’s no way it could be going 600mph and the rest of the numbers agree with each other (GS is matched to decent rate at pitch angle) it should only take a second to id the bad data stream…
The airspeed sensor is definitely a common point of failure and unfortunately there’s no redundancy available. I once had some dust get blocked in the pitot tube and while flying it read only a few m/s so the plane went at 100% throttle and couldn’t control itself during turns and crashed.
The only thing I can suggest is to set AHRS_WIND_MAX to a value of 4 or 5. This way if the the gps speed is saying 10m/s and your airspeed 3/ms and AHRS_WIND_MAX is set to 4m/s, then your plane will still be airborne by flying using gps speed.
From what I know I don’t think the EKF places much faith on the gps.
During my last flight, on 27th of March with a Skywalker 1880, using Pixhawk and AP 3.3, I also noticed the same behavior (airspeed being roughly zero on the ground but in air jumping all around). I went back and looked at my previous flight and saw some weird behavior of the airspeed sensor. https://drive.google.com/folderview?id=0BzzUBqpwxqRCU2VuWGxJYWpWV1E&usp=sharing
The morning flight looked pretty good (9-50-24), the one during noon shows much larger noise (12-14-20) and the airspeed during the afternoon fligh looks terrible (16-33-44). I would appreciate any comments or suggestions, since on the 27th I changed the whole sensor and the problem stil existed. The temperature on the differential pressure sensor has spikes also, but the barometer and its temperature sensor looks absolutely calm.
After many additional flights the air speed system has been has been solid. I believe the issue was with the I2c board or cable. I replaced the I2c board, the cable from sensor to i2c and from i2c board to pixhawk. The issue was not with the airspeed sensor its self.
I had another crash with APM:Plane 3.3 and Pixhawk last weekend, and based on the discussion here and also on a parallel thread in Google (https://groups.google.com/forum/#!topic/drones-discuss/hfHEZQO1SVg) I also have to suspect the faulty I2C bus. I just wonder why things look great in one flight and get all messed up in another one!
I’m having serious problems with airspeed sensors. I’m running ardupilot 3.6 on three fixed wing build and my airspeed sensors are completely out of sync. Before every flight I before a preflight calibration, but the one plane will think its flying at 18 m/s when it is actually flying around 11 m/s. Whenever I start up the planes, the initial airspeed idles around 9m/s (even indoors) and after the calibration will idle around 2-3 m/s. I’ve bought three replacement airspeed sensors and see the same behavior. What could be causing this problem?
I am using the 3DR digital airspeed sensor. The problem that I am seeing is that two planes flying at the same speed visually are recording different airspeeds into their diagnostics. This difference is ranging from 2-7 meters per second, i.e. one plane is flying at 11 m/s and the second plane thinks its flying at 18 m/s but is actually going 11. This also causes huge altitude errors because of the effects on TECS I believe. These incorrect airspeed sensor readings are causing a lot of problems. We have also tried doing the ARSPD_AUTOCAL.
My guesses for problems is that the sensor has because faulty after two months of use, the silicon tubing we are using between the pitot tube out on the wing to the sensor in the cockpit, and/or EMI.
Replace the tubing
AND:
the df13 cable from the sensor to the I2c splitter.
Replace the I2c Splitter its self.
The DF13 cable from the I2c Splitter to the pixhawk
Twist the df13 cables by rolling them btween you fingers starting at one end this reduces interference.
After having some problems with obstructed airspeed sensors, I’ve been playing with the AHRS_WIND_MAX parameter. I had this parameter set to 17m/s, but after reading your post I changed the value to 4m/s.
I tried to simulate the faulty pitot tube covering the dynamic tube with tape.
I didn’t get the results expected and the plane is still flying like crazy at full speed.
Do anyone knows if there are some other parameters related to this?
I did some hipòtesis, I hope you could help with it.
I have the parameter ARSPD_TUBE_ORDER set to 2, meaning it auto detects the static and the dynamic tubes. Do I need to specify which is each one, 0 or 1, to make AHRS_WIND_MAX work correctly?
Can this parameter be set to 1 or 2, and work properly?
The other point is, if I remove the pitot tube and fly using only GPS speed do I need to plan the missions in a different way?
Meaning, the DO_CHANGE_SPEED value type (0=as 1=gs) should be set to 1? Since now, using a pitot tube, i’ve been always flying with 0 with great performance.
I’ve been trying to fly disabling the airspeed sensor and using only GPS and the controller was setting throttle about 20% over normal flights using airspeed.
Should I plan the mission in a different way?