20230830 Dev Meeting

General:

• Update from relevant previous calls
• Tagged: issues, PR.

Notes

• #2029 common.xml: MISSION_CURRENT progress notification

  • Use case is valid and having in MISSION_CURRENT makes sense.
  • Might as well provide a percentage as well.
  • Count down is a little more useful than count up.
  • Remaining time until next item is executed is what we think most are interested in. But counts etc are fine.
  • This should be reserved for things that can't be guessed/inferred such as wait times or turns - not for travel time.

• #2015 Add VELOCITY_LIMITS msg

  • Interesting and useful use-case.
  • Using a message is good as you need to stream this, but should clearly be setter. We see command does not meet use case.
  • If there is a regulatory requirement then you really need confirmation it is working. This is also kind of required by users, who may be seeing an unexpected slow down not related to their own behaviour - a UI needs to be able to show this.
  • Further, if you move a zoom knob and the vehicle slows down it is good for tuning to be able to show the limiting is working.
  • Hamish not sure whether latching last state is a good idea.
  • James unsure about whether or not limits should apply in failsafes. Matthias says not according to design. HamishW things perhaps that should be stated? FWIW
  • This can go into development.xml with a setter/getter.
  • Comments added in https://github.com/mavlink/mavlink/pull/2015#issuecomment-1700090555

• #2031 common: extend MANUAL_CONTROL with auxiliary continuous inputs

  • We like the design. Final check and it can go in.

• Fix Wireshark dissector and add snapshot tests #817

  • Can we add this to review?
  • AO James to ask Peter.
  • DONE

NOT Discussed

• #2027 {Sponsored by Intelliterra} Added MAV_CMD_DO_SET_EMERGENCY for manual emergency setting

  • Its mandated even if not particularly compelling.
  • Julian not opposed.
  • We could do via existing message. I think command better. Any direction from Flight stacks?

• Move enums in description to real enums 1997

  • What do we think? Necessary? Is there a general rule?

• all.xml minus development.xml?

  • Last week proposed replacing add all_with_development.xml #1924 with "all - development.xml".
  • Now proposing generate WIP warnings on the use of WIP messages in C code #240 - get it in as "default off WIP test". That is useful for Beat. And once in is easier to flip this if we can show it is flawed.

• XSD - can we get these merged?

  • mavschema.xsd - max, min, increment on field #811
  • mavschema.xsd: add superseded tag #809 #809
  • XSD Schema - there can be at most 7 params #814
  • #821 XSD: MAV_CMD missionOnly attribute
  • Add altitudeOnly attribute #824 (part of MAV_CMD_DO_GO_AROUND - isAltitude attribute discussion #1994

• mavlink_msg_xxx_decode by mavgen_c does not handle extensions of message properly #684 - pymavlink bug fix

• Mission feasibility message and command - discord and historical pr

  • JulianO This could be done as events in the same way as PX4 prearm checks (feasibility checks are run regularly and cached. If the feasibility changes then there is an update of all the issues). Reasoning is that this allows for standard and custom feasibility checks and also translation of those texts. This could possibly also be done as a message emitted on feasibility change that had both a standard and a custom enum value field - but then you'd have to re work out all the integration for meanings of fields, translations etc.
  • Comments on PR https://github.com/mavlink/MAVSDK/issues/2103#issuecomment-1680187221

Attendees: Hamish, JulianO, JamesP, MarcinZ, MatthiasG