Thank you for the feedback! We will report it to Ardupilot.
Warmly,
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)!!!
But the perhaps somewhat too high initial calibration of ARSPD_OFFSET (not to bee mismatched with ARSPD_RATIO ) does not matter at speeds for exampel above 10 m / s .
See: New Airspeed sensor (MS5525) for ArduPlane 3.8 - #35 by WickedShell
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.
Regards Rolf
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.
ar_4525.zip (877.0 KB)
ar_MS5525.zip (677.9 KB)
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.
Thank you
Alex
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.
1 Like
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.
Have you tried manually adjusting calibration while in Loiter while watching the realtime plotting of airspeed vs GS. It seems this would be easier than trial and error of numerous flights, analyzing the logs each time.
Has anyone made a GitHub issue out of this? I havenāt seen it. It is unlikely to get fixed if not tracked in GitHub.
Thx 223Wylde, I am familiar with the parameters and what they do. Also how to calibrate. We make a lot of builds.
Also they are explained crystal clear on the wiki
I was just no clear on the issue with this new sensor. But I get it now. Just wanted to be sure that I understand the problem correctly.
Also the tube order. I prefer not to use 2 (auto detect), but rather 0. It should not be that hard for the manufacturer to let us know which one the top one is.
I see what you are doing to combat it, that was my problem. I cannot ask customers to keep manually finding the correct offset, when all they had to do before was cover the pitot tube with the cover and hit ādo pre-flight calibrationā in mission planner.
Why I wrote here is to know if there has been any progress at all. As far as I see the issue was identified quite a while ago and based on the thread here.
Meanwhile I think Iskess is correct. If it is not reported then it will not be fixed. I just got mine couple of day ago and have not installed them, so I donāt think I am in the best position to make a report, without a first hand experience.
Jordi should report it on Github, he is the one selling them.
I agree 100%.
I am going to send mine back in the meantime. Can risk this is customers UAV. It can make near stall landing speed very risky.
There is definitley an issue as multiple people have confirmed. Even know someone posted on Pixhawk2.1 (The cube) facebook with the issue on this sensor.
I really donāt understand why Jordi has not made any effort to remedy this. Last time he posted here was a year ago. It just needs a few bad experiences and the product will be doomed and go down in history as like the Lidar blue did. He seems like a nice guy, I am sure he doesnāt want people refering to this product as āsomething to avoid, due to bugsā.
All I have seen so far is a couple of posts announcing the product (which seems was not beta tested properly) and a warning on the reseller item listing about setting manual offset.
Really if I was out to make money with this, I am sure I would make more effort.
It is such a pity, as from the reports, it would otherwise be a superior sensor to the one everyone is using now.
HE did say that he would report it, back in August, but I too do not see any sign of it.
@Jordi ?
Is the issue here poor instructions, a driver problem, or something else? Would be good for everyone to get a definitive answer and resolution.
Jordi stated earlier in this post (August 25th) he would send my info to the developers, so this should get corrected.
Iād assume heād open an issue in GitHub so it could be tracked but I donāt see one. It may not get dealt with otherwise.
Not sure what the typical process for submitting issues is, but this is Jordiās Blog post so Iām sure heāll see these follow-up comments.
They seem to be busy adding a lot of quad plane stuff to the most recent releases, but I argue getting this issue resolved is more important than a lot of the additions/fixes Iāve seen recently.
We discussed this issue on the Devcall yesterday. I will be heading up the investigation on this issue. I will have more info soon.
Finally some progress. Thanks Phil, very happy to hear this. Looking forward to it.
There was a minor bug which caused a small positive bias (~1 m/sec) in calculated airspeeds when differential pressure is near zero. That is fixed in this PR: https://github.com/ArduPilot/ardupilot/pull/6980#issuecomment-330829612
I have not observed drift greater than about 1 m/sec over 8 hours with my MS5525 (purchased from mRo 2017/6/27)
1 Like