VFR_HUD: edit airspeed comment to also allow CAS if available instead of IAS

[sfuhrer]

The "airspeed" field in VFR_HUD should be equal to the calibrated airspeed (CAS) if available, as that is corrected for sensor/pitot and placement errors. If no CAS is available IAS (indicated airspeed) can be used.

[dagar]

I'm fine with this change, but I don't know if others would consider it a change in behavior.

Anyone feel strongly one way or the other? Maybe @WickedShell or @auturgy?

[auturgy]

Im not hard over on it, but it would go against normal aviation convention. VFR_HUD” is used for more than it’s initial design, but in the context of feeding data to an ASI, by definition that’s IAS, not CAS.

…

On 9 May 2020, at 1:06 am, Daniel Agar ***@***.***> wrote:  I'm fine with this change, but I don't know if others would consider it a change in behavior. Anyone feel strongly one way or the other? Maybe @WickedShell or @auturgy? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[sfuhrer]

@auturgy I really do not know much about aviation standards, but have seen a couple of examples of HUDs displaying CAS and not IAS on google, e.g. this. I don't really understand the reason why you should show IAS to the pilot, if you already know that there are some instrument and position errors on the airspeed reading, and you have gone through the process of calibrating it correctly and thus have a different CAS than IAS. It feels like I'm missing here something.

@hamishwillee I don't know much about mavlink processes, but I guess changing fields in the messages isn't really a possibility. But maybe adding fields is possible?
In the end I'm just trying to find a way to send CAS to the groundstation, such that the user has the same airspeed displayed as is also used internally.

[hamishwillee]

@auturgy @TSC21 @dagar @WickedShell If no one is actively opposed to this then I plan to merge it tomorrow morning my time. I don't see a case where someone using a HUD would prefer the uncalibrated version if calibration is possible.

@sfuhrer If there are objections, then we can add an extension like this:

<extensions/>
<field type="float" name="calibrated_airspeed" units="m/s">Calibrated airspeed (CAS), or NaN if CAS is not available. </field>

The downsides of this is that the message no longer benefits from zero-byte truncation (even if CAS is not supplied) and that it only works on MAVLink 2. Also if sent by a system that does not support this field the value will always be zero, which might be a problem.

This can be improved but it makes the field use a bit weird - e.g. the below allows zero truncation and make it clear that if 0 is received it is actually "not supported" rather than 0 airspeed.

<extensions/>
<field type="float" name="calibrated_airspeed" units="m/s">Calibrated airspeed (CAS).  NaN is should be used in used in place of a 0 measurement. 0 should be used if CAS information is not available. </field>

Or you could just make your new field the same as the one your were proposing, but specify NaN for CAS not supported.

[auturgy]

No objection, just a comment :)
As a note (and relevant to why aviation general uses IAS): for FW vehicles, make sure that what you send here matches whatever you are using for stall measurement and prevention.
fwiw ArduPilot fills this field from a variety of sources depending on vehicle type and available sensors, so the specificity is somewhat misleading anyway (ie rover, boat, etc).
I would object to changing this actual message though - it would break a lot of things in a lot of disconnected places.

[hamishwillee]

Thanks @auturgy - I'm sorry, I'm confused by "I would object to changing this actual message though - it would break a lot of things in a lot of disconnected places."

What I think you are saying is that you wouldn't want an incompatible change - you'd be "ok" with the proposed change to the text (kind of) or to a compatible extension.

[WickedShell]

I'm pretty against the extension idea. It's a large waste of bandwidth for most stuff, if you really want it then sticking it in some different more airspeed oriented message would be more reasonable.

I'd support @auturgy's comment that general aviation at least seems to only fly on IAS, not CAS. Particularly since backup gauges aren't ever CAS. You only really start getting CAS as a possible option once you swap to a glass cockpit.

[hamishwillee]

@auturgy @WickedShell @sfuhrer So I see that general aviation uses IAS but
a) this HUD is used for all sorts of vehicles so it isn't IAS anyway.
b) the fact that they do this sounds like "because we don't or can't support CAS" more than "we actually prefer a less reliable and predictable airspeed measure".
c) the change says "CAS if we can send it, IAS if not". But from a recipient point of view they don't know what they are getting. We're not forcing the system to send CAS if they don't have it, and indeed if they choose not to what can we do.

So I am still happy to merge this.

Two last options:

• we make this more general to reflect that this message is used as a HUD for all vehicle types and have a description like

  Vehicle speed. For aircraft this is typically indicated airspeed (IAS) or calibrated airspeed (CAS). For ground vehicles it is typically tachometer measurement."

• we allow the sender to be specific if they want by specifying the type in an optional extra field that can be zero-byte truncated by default (zero cost). This way the sender can choose to be specific and absorb the cost if they so wish. I see this as "nice to have"

If the second option you would do something like:

    <enum name="VFR_HUD_SPEED_TYPE">
      <description>Type of airspeed data in VFR_HUD</description>
      <entry value="0" name="VFR_HUD_SPEED_TYPE_DEFAULT">
        <description>Vehicle speed is default assumed appropriate for vehicle type by autopilot. Typically IAS or CAS for aircraft.</description>
      </entry>
      <entry value="1" name="VFR_HUD_SPEED_TYPE_IAS">
        <description>Indicated airspeed (IAS).</description>
      </entry>
      <entry value="2" name="VFR_HUD_SPEED_TYPE_CAS">
        <description>Calibrated airspeed (CAS).</description>
      </entry>
    </enum>

New extension

<extensions/>
<field type="uint8_t" name="speed_type" enum="VFR_HUD_SPEED_TYPE">Type of speed indicated by field airspeed. Default depends on vehicle type and system: nominally IAS or CAS for aircraft.</field>

And the field itself

<field type="float" name="airspeed" units="m/s">Vehicle speed. The  speed type depends on airframe. For aircraft it is usually either calibrated airspeed (CAS), or indicated airspeed (IAS).</field>

I lean towards making things more general. Let's make a final decision in the mavcall tonight.

[TSC21]

Nothing against this change.

[sfuhrer]

@hamishwillee for me your summary makes very much sense. CAS=IAS, unless the user or the manufacturer of the drone deliberately calibrated the airspeed (and the flight control software they use even support CAS). In that case they would probably expect that the airspeed readings on the groundstation to reflect this calibration, as this is then also what the flight controller uses internally.
For me the extra field would not be necessary. I would expect that the airspeed displayed is equal to the CAS if I've calibrated the sensor, and IAS otherwise.

[hamishwillee]

As discussed, the requirement here is that the sender be allowed to send CAS. The field has therefore beeen generalised to state that the format is dependent on the vehicle type. It also notes that either CAS or IAS are typically used as either can be used by pilot used to estimate stall speed.

This can be merged once CI passes.