No way to transmit airspeed reference

[philipoe]

MAVLINK currently has no message to transmit den current airspeed reference. However, the airspeed reference is very important due to safety reasons (e.g. stall). The airspeed reference is also internally adapted by many autopilots, i.e. the airspeed reference that a user expects based on what he sets in the waypoint items (e.g. via QGC) is NOT the one that the vehicle is actually tracking, e.g. because of the "groundspeed undershoot" or "accelerated stall" functionality of PX4. Surprisingly, the HIGH_LATENCY and HIGH_LATENCY2 messages actually do contain the airspeed reference.

So overall we think it is really important to add that. Question: Into what message should it be added? NAV_CONTROLLER_OUTPUT would work for example. There is already an airspeed error in there, but in our opinion an airspeed ref makes more sense. The Only complication is that we'd then also need to add the true airspeed (TAS), because what is transmitted in the VFR_HUD message (at least by Pixhawk) is the indicated airspeed (IAS).

[dagar]

I agree it would be much more valuable to have in place of aspd_error and alt_error.

Options

1. Add new extension fields (mavlink v2 only) to NAV_CONTROLLER_OUTPUT (https://mavlink.io/en/messages/common.html#NAV_CONTROLLER_OUTPUT)
2. Review the entire thing and create a new message.

I don't have a preference at this point.

Thoughts? @WickedShell @auturgy

[WickedShell]

I'd prefer to extend rather then create a new message at the moment. Regarding VFR_HUD IAS is what you want sent to the GCS, although the field is not (and should be) annotated for what is being sent.

[peterbarker]

We did discuss on a recent ArduPilot devcall an airspeed mavlink message. Notably including an instance number and a type (which might be synthetic). tridge suggested it could be an array in a single message instead ('though would you then need an array of types to go with it?).

[hamishwillee]

I've added DevCall label (thought that is a month away) to make sure this does not stall again.

I'm a bit confused about some of this.

@philipoe @WickedShell :

The only complication is that we'd then also need to add the true airspeed (TAS), because what is transmitted in the VFR_HUD message (at least by Pixhawk) is the indicated airspeed (IAS).

I'd prefer to extend rather then create a new message at the moment. Regarding VFR_HUD IAS is what you want sent to the GCS, although the field is not (and should be) annotated for what is being sent.

Can, should this be dealt with now (ie outside of the airspeed reference discussion)? I think you're saying that the docs need to change as shown. Will anything else be assuming some other meaning of airspeed here - e.g. True airspeed (and how should we deal with that?)

We did discuss on a recent ArduPilot devcall an airspeed mavlink message. Notably including an instance number and a type (which might be synthetic). tridge suggested it could be an array in a single message instead ('though would you then need an array of types to go with it?).

@peterbarker So can you clarify for the dim (me) among us:

• you're proposing a new airspeed message that includes all the types of airspeed? e.g. true airspeed, indicated airspeed, airspeed setpoint?
  • Any other types? Anything else?
• I'm a bit confused by the instance number/type. Are you suggesting that we use an array and assume that item 1 (say) is true airspeed, 2 is indicated etc.

[peterbarker]

On Wed, 12 Dec 2018, Hamish Willee wrote: * you're proposing a new airspeed message that includes all the types of airspeed? e.g. true airspeed, indicated airspeed, airspeed setpoint? + Any other types? Anything else?

Sorry, I'm not proposing anything - I haven't given the matter a great deal of thought, just thought I'd note here that it did come up in the devcall. My understanding is that the proposed message would be for airspeed measurements; probably true-airspeed, but that didn't come up in the call. We already carry data sufficient for calculating an indicated airspeed, I think.

* I'm a bit confused by the instance number/type. Are you suggesting that we use an array and assume that item 1 (say) is true airspeed, 2 is indicated etc.

No, you'be looking at something like one of the following: ``` <enum name="MAV_AIRSPEED_TYPE"> <description>Type of airspeed sensor.</description> <entry value="0" name="MAV_AIRSPEED_SYNTHETIC"> <description>Estimated wind speed</description> </entry> <entry value="1" name="MAV_AIRSPEED_DIFFERENTIAL_PRESSURE"> <description>Pitot-sensor-like devices</description> </entry> <entry value="2" name="MAV_AIRSPEED_MASS_AIRFLOW_TEMPERATURE"> <description>Thin-wire-resistance-thingies</description> </entry> <entry value="3" name="MAV_AIRSPEED_ANEMOMETER"> <description>Spinny-whirly cup thingies</description> </entry> </enum <message id="xx" name="AIRSPEED"> <description>Vehicle speed relative to the medium it is in (e.g. water or air).</description> <field type="uint32_t" name="time_boot_ms" units="ms">Timestamp (time since system boot).</field> <field type="uint8_t" name="instance">Sensor number</field> <field type="uint8_t" enum="MAV_AIRSPEED_TYPE" name="instance">Sensor type</field> <field type="float" name="speed" units="m/s">Speed</field> </message> <message id="xy" name="AIRSPEED"> <description>Vehicle speed relative to the medium it is in (e.g. water or air).</description> <field type="uint32_t" name="time_boot_ms" units="ms">Timestamp (time since system boot).</field> <field type="uint8_t[4]" enum="MAV_AIRSPEED_TYPE" name="instance">Sensor type</field> <field type="float[4]" name="speed" units="m/s">Speed</field> </message> ``` Now this is, of course, assuming a new message.

[hamishwillee]

Thanks for information and clarification @peterbarker .
@auturgy @WickedShell @dagar @philipoe Another idea for this message: #929 (comment)

Would this do what is needed? Is it better than the other proposed types? Basically I'd like you people who actually fly with an airspeed sensor to help come to a consensus.

[dagar]

Ideally you want to see what the controllers see and use.

• indicated airspeed
• true airspeed
• airspeed setpoint (tecs)

With that in mind sending all individual sensors with type is not necessarily that valuable. Ultimately there's a single airspeed (through voting or fusion) that's used by the system. Sending data from all individual sensors can be useful for diagnostics, but I find it wasteful for normal usage.

[hamishwillee]

@philipoe

• THoughts on @dagar comment? No way to transmit airspeed reference #929 (comment)
• Can you guys confirm that irrespective of this broader discussion VFR_HUD airspeed docs should be clarified to state that the airspeed in the message is always IAS? Do we know of any exceptions? Basically if we can separate out that I can get a PR in for that to be clarified while we discuss the need for another message.

[auturgy]

@hamishwillee yes to your suggested doc clarification (IAS).
I think it’s time for a dedicated message, and this is probably important enough to discuss consuming a mavlink1 ID for.

[hamishwillee]

Thanks @auturgy . IAS discussion pulled to #1041

I think it’s time for a dedicated message, and this is probably important enough to discuss consuming a mavlink1 ID for.

I don't know. Would be good to get response to @dagar concern in #929 (comment) .

I tend to think that you consume a mavlink1 ID if you want to do something that is relevant to a mavlink1-only system. Is this such a case?

I guess it depends on the rate/bandwidth this is expected to consume to determine whether it is worth including "everything" vs some specific fields.

@dagar I'm not sure what message you're proposing - is it just a single field with the setpoint?

[peterbarker]

n.b.: don't use 0 as an enumeration value as it will interfere with mavlink2

[auturgy]

Re mavlink1 only system: OSD is what I was thinking. I’m not actually too concerned, but thought that for completeness it’s worth flagging for discussion.

[hamishwillee]

n.b.: don't use 0 as an enumeration value as it will interfere with mavlink2

@peterbarker In what way? Is this for extension fields - when system receives a message sent by an implementation that doesn't have the extensions fields then the recipient will see zero values for the extensions fields. So using 0 could just mean "not supported"?

[peterbarker]

@hamishwillee Sorry, that omment of mine was pretty much stream-of-conciousness as I was also taking meeting notes at the time. What it should really be is enumeration value 0 should be MAV_AIRSPEED_TYPE_NONE. That's needed by the "send a pair of arrays approach.

tridge also noted that the pairs-of-array approach doesn't allow mavlink2's zero-trimming feature to work as well as it could. Without having arrays-of-tuples we can't really do better with arrays. Might be better off with just named fields?

[hamishwillee]

Re mavlink1 only system: OSD is what I was thinking. I’m not actually too concerned, but thought that for completeness it’s worth flagging for discussion.

@auturgy Thanks. Probably is worth flagging - though the original request was for an airspeed reference, and you don't need that on OSD.

OK, to summarise status, the options proposed are

1. Add new extension fields (mavlink v2 only) to NAV_CONTROLLER_OUTPUT
2. Add a new airspeed message that includes airspeed reference - just the first option from peter below)

     <enum name="MAV_AIRSPEED_TYPE">
       <description>Type of airspeed sensor.</description>
       <entry value="0" name="MAV_AIRSPEED_TYPE_NONE">
         <description>Estimated wind speed</description>
       </entry>
       <entry value="1" name="MAV_AIRSPEED_SYNTHETIC">
         <description>Estimated wind speed</description>
       </entry>
       <entry value="2" name="MAV_AIRSPEED_DIFFERENTIAL_PRESSURE">
         <description>Pitot-sensor-like devices</description>
       </entry>
       <entry value="3" name="MAV_AIRSPEED_MASS_AIRFLOW_TEMPERATURE">
         <description>Thin-wire-resistance-thingies</description>
       </entry>
       <entry value="4" name="MAV_AIRSPEED_ANEMOMETER">
         <description>Spinny-whirly cup thingies</description>
       </entry>
     </enum

     <message id="xx" name="AIRSPEED">
       <description>Vehicle speed relative to the medium it is in (e.g. water or air).</description>
       <field type="uint32_t" name="time_boot_ms" units="ms">Timestamp (time since system boot).</field>
       <field type="uint8_t" name="instance">Sensor number</field>
       <field type="uint8_t" enum="MAV_AIRSPEED_TYPE" name="instance">Sensor type</field>
       <field type="float" name="speed" units="m/s">Speed</field>
     </message>

I interpret @dagar comment to mean that we should go with option 1 because the only information we actually care about is the reference - the second form is interesting for debugging, but inefficient.

I think for the particular use case, people who are interested in the reference (setpoint) will already be using NAV_CONTROLLER_OUTPUT for the other information. The won't be interested in the other forms of airspeed information and forcing them to watch for another message with just airspeed will complicate their code. I propose we add that whatever we do for a new airspeed message.

I like option 2 because it is flexible; you don't have to send for every sensor or every type. If you just want to send the reference you can.
But I'm not sure that if we send the problem case of airspeed reference in NAV_CONTROLLER_OUTPUT this is really needed? Ie isn't that the only missing info from other messages

[hamishwillee]

FYI confirmed @dagar thinks that it would be slightly useful to extend NAV_CONTROLLER_OUTPUT with:

<field type="float" name="airspeed_setpoint" units="m/s">Airspeed setpoint (synthesized) used by controllers.</field>

0 is valid value, so not sure what we do for systems that haven't updated.

However as Daniel and no one else seems that interested, I propose we just close this. OK?

[bduva002]

Hello all,
Dose anyone know if this went any where? I am looking for the second option proposed above to get the airspeed. Currently I get airspeed from the VFR_HUD but there is no time stamp for this message. Also when I am running HIL_starplane occasionally the velocity drops to zero. Not sure why.

If the second option dose not go through just being able to get the airspeed with a time stamp would be great!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[hamishwillee]

Closing, insufficient interest.

If someone else needs this feature please create a new proposal explaining the specific use case you wish to address and how you would most like to address it. Feel free to link to this item to show that you've considered the options.