Just completed another airspeed calibration flight, results seem much better, it adjusted the airspeed ratio parameter from default of 1.99 down to 1.96, and now airspeed matches groundspeed on the crosswinds every time around.
Weather conditions were much better today, wind was from the southwest steady at 3m/s, I circled constantly for 8 minutes with a constant throttle setting and with the AUTO_CAL enabled. Temp was 80 deg F, and humidity was 70%, I’m located in southern Minnesota, so we get fairly high humidity often.
The only thing I’ve noticed that’s unusual is about every other calibration on power up seems bad, the airspeed will show 4-5m/s with the cover still on the pitot tube. Then if I just reboot, it will typically be in the normal 0-2m/s the next time and will be fine, so not sure if the airspeed calibration on power up needs some tweaking?
Will fly some test flight lines later this week and will let you know how it goes, so far so good!
If you have crosswinds, your airspeed will be affected a lot by the wind.
You can even calculate wind direction and speed with that, that is why your
data doesn’t match, so is very normal to have different ground speed from
airspeed. When flying real airplanes we have the same situation and
we learn how to compensate it.
Hi 223Wylde,
Do you cover the pitot tube with a baloon while booting/arming. I always do this and I get good results. I am still using the old sensor and yet to try this new one.
Actually, flying crosswind is the only time airspeed should be very close to ground speed, flying downwind groundspeed is always higher than airspeed, upwind groundspeed will always be lower than airspeed. So when enabling the AUTO_CAL parameter, that’s why you constantly have to fly level circles with a constant throttle setting, so the flight controller can compare the upwind leg to the downwind, and adjust the airspeed ratio accordingly, when it gets it right, the airspeed will be dead-on.
And yes, I always keep the pitot tube covered when booting up, you cannot have any air moving across the tube when it performs the self-calibration, I’ve always had excellent results using the older sensor that way. So, this is why I’m not sure what’s causing the initial values (with cover on) to be 4-5m/s sometimes, and 0-2m/s other times.
Ok, did a couple more flights today, the plane still flies around 3-4m/s slower than it reads airspeed, I think I’m finally getting the problem cornered. The first sensor I tried always resulted in a -1,400 to -1,500 offset, and it typically ranges between 0-4m/s after powering up. It still stays within that range even if you run the preflight calibration after initial power up, I did that several times, and calibration offset changes slightly, but it stays pretty consistent. So, installed another new MS5525, and airspeed offset is very different, always around -110, but airspeed still drifts between 0-4m/s after a few minutes just like the first sensor.
So, I think the main issue is how the airspeed offset is calculated, when I manually reduced the airspeed offset on the second sensor from -110 to -100, the airspeed stays zeroed and only ranges from 0 to 0.1, never goes above that. Will try another test flight tomorrow to see if this solves the main problem which I believe is the self-calibration not zeroing-out the sensor close enough on power up.
@223Wylde I haven’t read the full history here, and I’m unsure if you have auto tube order set, but I strongly suspect you don’t. If it’s not on auto tube order then negative airspeed’s rather then flipping the sign will be clamped at 0 m/s. So you can still be having problems or be wildly mis-calibrated but it would look like 0 m/s before you takeoff. Adjusting the offset by hand till you aren’t seeing spikes is an indication that you are moving into this region. Basically use caution as you preform that test as you might just be shifting values by more then expected till you encounter a serious problem.
5 m/s error in pressure reading on the ground would be an error of 0.7 m/s moving at 16 m/s, so the climb to 4 on the ground does not point at the source for the error of 4 in flight.
I’ve tried it both ways, and I’m seeing the least variance when setting the tube order to zero, and connecting the impact pressure tube to the top port. Either way, the main problem is, the airspeed readout always drifts upward from zero on the ground over time, which causes the plane to be flying that same amount of offset slower, I can tell its hanging on the edge of stall when in RTL, because when orbiting over me, the nose starts to bob a bit. I had the minimum airspeed set to 18m/s, and I know by observing the aircraft its actually flying approximately 14m/s, stall speed for the aircraft is 12m/s.
If I manually adjust the airspeed offset down to zero it out, the worst that will do is cause the aircraft to fly at a higher airspeed than readout which would be much safer.
I wanted to go back to the old airspeed sensor until I have time to help troubleshoot this, but I cannot get the older 4225 to work with the Pixhawk 2.1.
Basically what happens with auto tube order is we just always assign the absolute value of the reading as the current airspeed, when you set a tube order, whatever would indicate a negative airspeed is disregarded as 0.0.
For what it’s worth I can confirm 4525’s work with a PH2.1.
Without knowing more about your setup it’s hard to say, but it’s very possible your getting fuselage interference. Have you validated this setup on the airframe in flight with an older sensor/firmware?
Yes, I’ve flown hundreds of flights with the same airframe that I’m currently testing this new sensor on with Pixhawk 1s and the older airspeed sensor, and its always been spot on once calibrated, so its not fuselage interference, I have the pitot tube and sensor mounted the exact same way, only differences are the new parameters and settings added to the firmware for the new sensor.
Not sure what calculations are performed during the self-calibration on power up, but I’m guessing that algorithm needs to be adjusted slightly to zero-out this new sensor correctly, the offset seems to be off by about 10% each time.
Is there any documentation yet for settings using the 4525’s and PH2.1?
4525 and PH2.1 does just work (at least on I2C2, and I’m 95% sure it works on I2C1 as well). The ARSPD_TYPE needs to be set to 1 but other then that it should just work.
I flew another test flight yesterday with the MS5525, and as usual it was initially ranging from 1-5m/s after power up, this is with the pitot tube covered, I then ran a pre-flight calibration action 2 or 3 times, that helped reduce the range a little, but it was still ranging from 1-3m/s. So, I then wanted to test manually zeroing the sensor, so I reduced the offset from -95 to -85, after that, it was reading from 0.0 to 0.1 on the HUD. I flew a set of flightlines that were 90 degrees to winds aloft, and the wind was quite light, and the airspeed matched the groundspeed along the flightlines within 0-1m/s when cruising along the flightlines in both directions, and when returning to launch, I can tell airspeed was matching the MIN_AIRSPEED parameter which was set to 18m/s.
So, this method of manually zeroing the sensor works, you just have to adjust the offset until you get the airspeed to readout values just above zero.
I still think the self calibration algorithm needs to be adjusted for this sensor, its not the same as the older 4525, and once zeroed, its a far superior airspeed sensor.
Please let me know if there’s anything else I can do to help get this issue resolved.
In my experience with a lot of available airspeed sensors this is true not only for this sensor but for all airspeed sensors (analog, I2C-MS4525D0 and I2C-MS5525)!!!
We have encountered this fact with our tiltrotor VTOL, in which the stall speed is 8-9 m/s and valide measurement of airspeed in this magnitude ist critical for perfect & successful forward transition. Even at this lower speed, the new sensor chip (MS5525) has proven to be more reliable than the previous sensors (MS4525D0) because its noise is significantly lower and so we have better results in real life after more then 50 flights with our VTOL with identical little bit to high initial calibration of ARSPD_OFFSET.
By the way: the former MS4525D0 is much more infrared-sunlight sensitive than ms5525 .
A much larger source of error can be calibration of ARSPD_OFFSET with sunlight-irradiated sensor due to opened canopy and shadowed sensor while flying with closed canopy.
Thanks for the info Rolf, and for testing the MS5525 sensor, its mounted in an enclosed bay same as the older 4525, so never exposed to sunlight either during calibration or operation.
The most significant issue for me is the current MS5525 self-calibration always errors 2-3m/s on the slow side, and with my fixed wings at 12m/s stall speed, that’s not good!
I had Pixracer installed on a small foamy. I was using 4525 sensor. I got this new sensor and just replaced it. I am attaching two logs flown on the same day within few minutes difference on the same frame. This is an excellent opportunity to compare the performance of these sensors. I notice that sometimes the reading of the new sensor suddenly goes to 0 but recovers immediately. Seems to have slightly less noise than the old sensor.
Yes, that’s exactly what I’ve seen as well, and additionally, I fly survey missions at 400’ typically with fixed wings, the other aspect that’s immediately apparent is with the new sensor, motor surging is pretty much completely eliminated regardless of settings, that’s huge for me!
Hi guys, any update on this issue since?
So if I am correct in my understanding…
ARSPD_AUTOCAL works as supposed to, it is only the start up (and pre-flight) calibration that does not work right. Hence requiring to set offset manually in the parameters?
Also must this be done each time. Just got a set of these and hesitant to install as I could do the offset, but not sure if my customers can manage it every time they fly a mission. Seems counter intuitive and worried that they would question the decision to even put this one on…
We are on fixed-wing to this is important especially for landing.
Also forgot to ask, seems that I am the only one not seeing this as obvious.
For correct tube order. On this device with one is top and which is bottom. That is for setting tube order 0.
The old one was easy to know that the one further away from the board was top. This was I am note sure and cannot see any markings. Really would like to skip guess work or trial and error.
Thanks
Alex
Alex, ARSPD_AUTOCAL is a separate parameter, you have to enable it manually (default is disabled), and if enabled need to fly in circles for at least 5 minutes, it then it adjusts the ARSPD_OFFSET value by comparing the groundspeed to airspeed over that timeframe to adjust the ARSPD_OFFSET accordingly. In addition, during power up, the pixhawk will always perform a “self calibration”, you cannot disable this and its simply trying to “zero out” the airspeed to zero on power up during all the other initialization checks, this is the reason why I always keep the pitot tube covered during power up being you don’t want any air moving over the pitot tube when it does this. The only problem I’ve found with the new MS5525 sensor is that it will consistently calculate both the ARSPD_CAL value and the self calibration ARSPD_OFFSET value too high which results in the aircraft thinking its flying much faster than it actually is, and depending on the aircraft, this can result in a stall when performing an RTL or other Auto flight modes. Jordi has stated earlier in this post that he will pass along my information to the developers to get this corrected. Until then, you should use caution with any auto flight modes with this sensor, I know my fixed wing aircraft extremely well, so I know the warning signs when they are approaching stall speed independent of what the sensor is indicating.
And tube order does not matter if you have the ARSPD_TYPE set to the default (2 I think?), it will figure out the order based on differential pressure as Wicked Shell stated on August 23rd earlier in this post.
This really is a superior sensor as I stated many times in this post, and until they get the calibration issue sorted out, you need to manually adjust the ARSPD_OFFSET parameter to correct it as I described, but please use caution if you do, you need to understand what you’re doing otherwise you risk a stall.
Sorry, ARSPD_CAL is the parameter, and if you enable it to calibrate, make sure you disable it before the next flight, very dangerous to keep enabled all the time.
