ExtLibs: ArduPilot: Mavlink: try and pull AP firmware type from version string

[IamPete1]

With more configurable types it is harder to tell the vehicle firmware type from the mavlink type enum. This changes to use the version string if it is available.

For example on a fresh setup there is no frame class setup, so it defaults to generic and then we endup with no param descriptions or mode names.

[peterbarker]

This might not work for some people who have changed the announcements. I guess those guys will just not get this new detection.

This might do bad things in the case that the version string contains a (e.g.) company name and that company name contains one of the other vehicles.

I'm generally not in favour of any GCS parsing our statustexts - it's a bad pattern as we can inadvertently break things by seemingly innocuous changes in ArduPilot (e.g. my recent attempts to stop sending through the MCU ID as hex digits in a statustext would break MissionPlanner).

I wonder if there's a better way to differentiate the vehicles than the statustext.... if it is fundamentally the APM_BUILD_TYPE we are wishing to convey, perhaps we could put that into a mavlink message somewhere.

[IamPete1]

I could use longer strings and make it case sensitive. So from plane to ArduPlane V, that would minimize the false positives.

New mavlink messages would be great, but this is a pain point now on current firmware.

[IamPete1]

Changed to case-sensitive, starts-with and the full firmware string excluding the version numbers. Still works and should be much less likely to false positive.

We could also move this to only try if the mav type fails, but I think going forward there will be more cross over of mav type between vehicle builds.

[tridge]

it is pretty common that vendors change that version string

[IamPete1]

I'm not really sure how else we can do better (without mavlink changes). MAV_TYPE is no longer a good way to tell the firmware vehicle type. In the mean time this change helps some most of the time.

[IamPete1]

This PR would fix such issues as this:
https://discuss.ardupilot.org/t/bicopter-no-tuning-tab/92626

[davidbuzz]

not perfect, but an inprovement

[davidbuzz]

@meee1 ?

[peterbarker]

We probably do this until we can convey it in mavlink properly.

[IamPete1]

@meee1 I have rebased this, we discussed on the call and the conclusion was that this was better than what we have now, but we will try and add a firmware version into a mavlink message somewhere, however that will only work once that AP fix is done and in the wild, in the mean time this fix helps most on current firmware although it does not work in every case, such as where manufacturers have changed the firmware name.