Add AirspeedFit

[robertlong13]

Log-based airspeed calibration tool, inspired by the built-in autocal.

I've been testing this out for about a week and it's working great.

[IamPete1]

This is what Claude thinks:

I'll leave you to decide how much you care about those issues. I have had a play about and I have not been able to get it to break, and its in dev, so I'm inclined to just merge it.

I thought there was a python script for this somewhere, but I have looked in AP and in pyMAVLink and I can't find it. I was just thinking to run the same log and make sure the result is similar to this.

[IamPete1]

I have spotted the sneaking, but as the comment says, I think its harmless.

[robertlong13]

I thought there was a python script for this somewhere, but I have looked in AP and in pyMAVLink and I can't find it. I was just thinking to run the same log and make sure the result is similar to this.

Yeah, never was one to my knowledge. I've wanted one for years and made several of my own but was never quite happy enough with them to PR to pymavlink. My latest one I was finally happy with but then decided to vibe-port it to a web tool.

In terms of the Claude review, I've taken about half of the suggestions. I know you posted it casually as a "take it or leave it", but I've written up full responses to each point:

1. Sure, easy enough to guard. Fixed
2. Same. Fixed.
3. Not a bug: find_end_index is always called with a +1. Confusing, yeah, but the same pattern is in the other three tools and I blindly copied it (which is point 9).
4. Yeah, a failure to find the USE param should be loud. Fixed.
5. Not a bug: that's the sensible fallback. This is only used for the Avg EAS2TAS display aid.
6. Wind uncertainty isn't propagated because I don't have one. Wind covariance wouldn't be an honest uncertainty metric (false confidence at low q, though that's' counterbalanced by a worse fit, the problem is weighting those two factors). I don't plumb a ratio uncertainty to UI precisely because I have not come up with a good way to quantify it with enough rigor to stand behind it. I kept ratio_stderr in the core because it's a semi-useful debugging tool and isn't trivial to slap back in.
7. This one is silly. auto_window is a heuristic; it unavoidably has many issues (fixable by manually setting the window), and this isn't even one of them
8. To Pete's point, I shouldn't be re-implementing the time stuff. Fixed.
9. This is a decent point, but for another PR, and even then, probably unlikely. We are slowly accumulating these "select a region and we'll analyze some data there" tools, but it's not that much boilerplate and I'm not sure it's worth the fuss.
10. Won't fix. Minor correction too, it's on slider release, not on slider drag. It could be optimized, but I'm skeptical it would speed up enough to pay for the legibility cost.

[IamPete1]

I was wondering, is it correct to use a temperature from a outside source? Doesn't that mean that the calibration will be a bit off when used in flight because AP is not using that temperature. That is to say, would we be better to have the ratio a little off the "true" value such that the airspeed still comes out right because AP is using the "wrong" temperature.

There was some discussion about getting a accurate air temperature on board, even boards without heaters the flight controller temperature is usually much too high. One suggestion was to use the lowest temperature out of all the various things that report temperatures.

[robertlong13]

I was wondering, is it correct to use a temperature from a outside source? Doesn't that mean that the calibration will be a bit off when used in flight because AP is not using that temperature.

Short answer, yes, it's very correct to use an outside source during calibration. After that, ArduPilot basically doesn't rely on EAS2TAS anymore.

The Full Answer

A pitot naturally reads EAS once it's calibrated, it doesn't have to be converted. Once the ratio is set, it will always read the correct EAS regardless of air density. Every major consumer of airspeed wants EAS anyway: cruise speed, min/max speed, Q_ASSIST_SPEED; they are all EAS.

The only real consumers of EAS2TAS are the in-flight auto-calibration (because it's using ground speed as the truth source, which is a true speed) and the TECS (because energy calculations need true speeds). The TECS still takes its set point input as EAS but converts to TAS and uses that everywhere internally for the energy calculation. If you calibrate your airspeed ratio using a good EAS2TAS, but fly with a really bad EAS2TAS, you are having a small impact on your TECS tune (and that's true no matter how you calibrate your airspeed sensor; what really matters is matching the EAS2TAS you tuned your TECS with), but it won't impact the actual EAS it tries to hold.

I've always recommended people manually set BARO_GND_TEMP before using the in-flight airspeed cal, and then they can let it autoset afterward if they want (because it doesn't matter nearly as much after cal), but I just recently learned that ArduPilot/ardupilot#26915 actually broke BARO_GND_TEMP (and all temperature measurement/setting in AP_Baro); the new get_EAS2TAS_extended has a hard coded assumption of ISA air temperature (arguably that's better for most people than the auto-set BARO_GND_TEMP, but it's not better than a manually set BARO_GND_TEMP being silently ignored). So that trick doesn't work anymore. If you fly on a day that's 10 degrees different from ISA, you probably shouldn't use the in-flight autocal. I'll probably open a PR to fix that or compile out BARO_GND_TEMP when the advanced atmospheric model is enabled so it doesn't mislead.

I've given a lot of thought about better OAT measurement, but apart from having a dedicated OAT sensor or manually setting the temperature, I don't know any great guesses. BUT the good news is that the temperature is hard-coded to ISA on all our F7/H7 boards, so the temperature measurement literally doesn't feed anything.

"All devices that report temperature" is pretty tough. I'd hate to learn that one of my 16 CAN nodes is reporting a hard-coded 0 or -273 or was supposed to report kelvin but reports c because the manufacturer didn't read the spec right.

[IamPete1]

Thanks for the explanation! Are you happy for this to be merged?

[robertlong13]

Yup, I'm happy if you are!