I think it requires two parameters to be set to specify the barometer interference based on wind direction. One Partner company setup the wind estimate and reported that it was working well but I don’t think we’ve had enough people try it to have an estimate on how accurate it is.
I don’t think this made it into any code branch yet, but it’s an interesting puzzle to solve. I may take a swing at it sometime this Winter. Support for airspeed sensors is already fairly mature in Plane, so it shouldn’t be difficult to at least implement support from a data-only perspective. Incorporating it into the nav controller would be quite a bit more difficult. I’ll follow up with any results if I do start down this path.
As I think through this a bit more, mounting a pitot-based sensor atop a 360° servo and pointing it in the direction of the highest magnitude relative wind seems like a very interesting concept for Copter airspeed. You’d have to use a slip ring to avoid wrapping the wiring. But now I can’t seem to get my brain to avoid conceptualizing things, and I may need to try this sooner than later!
Any thoughts as to mounting the sensor on a gimbal of sorts?
EDIT: I’ll clarify this thought a bit, since it’s surely a strange idea and possibly very impractical. Perhaps it’s possible to use the attitude behavior that @Jeffuasa is monitoring as a means by which to “aim” the pitot tube in the correct direction to directly measure airspeed. Or perhaps the existing wind estimator could reveal enough information to provide that orientation.
Alternatively, I suppose you could use multiple pitot tubes (3 to 4 of them) to estimate an airspeed velocity vector, independent of the Copter’s orientation with respect to the wind.
Failing all of that complicated stuff, simply having forward (X axis) airspeed reporting is better than nothing!
So truthfully I’m think using this data could be quite difficult to use without super effective filtering.
My thought of an airspeed sensor on the gimbal is that i think it would be helpful for test scenarios or model building where you want to know the wind direction and speed as best possible.
It could be an additional input for Paul’s body drag and a wind speed estimation work. Practically, speaking on a copter having a gimbal for an airpseed sensor seems like overkill engineering with failure points for not enough gain?
The one positive to a gimbal is it would allow you to keep the pitot probe in the linear range for errors induced by sideslip (or dual axis angle of attack.) Pitot-probes are only linear for airspeed error in a range of +/-15-20 degrees or so. After that you must use a wind tunnel to gather the coefficients for the probe. And then once on a vehicle, repeat the process in air using various calibration methods.
Personally, I’m impressed how well ArduPilot copes with using probes without calibrating them in a wind tunnel.
Instead of using multiple pitots to measure wind speed orientation. You would use one multi-hole probe that has ports for total pressure, static pressure, angle of attack pressures, and side slip angle pressures.
All of that makes plenty of sense. I can appreciate the risk vs reward assessment regarding the complexity of a gimbal-based setup.
A multi-port pitot/alpha/beta/static probe would be fantastic if the expense could be mitigated. I’m all too familiar with just how expensive that hardware can be (direct message me for a pretty good story on that topic!).
Fly a straight line for X seconds. Then enter a standard rate turn in either direction, maintaining the power setting. Do a full 360deg turn taking more than say 10sec.
If the conditions are perfectly calm, the air frame should fly directly back over the initiation point - no wind. Any wind, moves the circle, the amount of which indicates the strength of the wind. With some math, seems like the FC could figure this out. This procedure could part of a Copter flight mode, using a set power setting and AIL input for consistent results.
The above is how the Pitlabs OSD figures it out. You can also plug a digital air speed sensor into it if you want.
@hendjosh I had implemented the airspeed sensor in a personal branch back in AC-3.3. From my experience with the helicopter on which I mounted the airspeed sensor, I had to be going 8 m/s before the airspeed cleaned up and was usable and I think I used a 1 hz low pass filter to help with that. I think this brings up a good point regarding how it would be used to control aircraft speed. I think that there would have to be a transition point at which the speed controller moves between ground speed and airspeed
This is an interesting application. In airplanes, airspeed is almost always measured along the x axis of the aircraft because the aircraft will always be flying into the wind or crab to fly wings level. Fixed wing aircraft and most helicopters are inherently designed for this because of the vertical stabilizer (and in the case of helicopters, tailrotor) which keeps the aircraft pointed into the relative wind. Plus in manned aviation, they make a point to maintain balanced flight (i.e. zero lateral acceleration). With multicopters, they don’t have an inherent directional stability and so there isn’t anything that naturally points them into the wind. So I think some sort of omnidirectional wind measuring device is important or they maintain balanced flight by zeroing lateral acceleration. In thinking about this, aligning the airspeed sensor along the aircraft x axis and then maintain zero lateral acceleration when using airspeed is one way to tackle this.