20190626 Dev Meeting

Agenda

General:

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

Discussed:

• Common Flight Modes proposal
• Generic message responders - best approach + adopting them
  • We have a bunch of specific commands for requesting specific messages be sent. E.g. MAV_CMD_REQUEST_AUTOPILOT_CAPABILITIES sent to get back AUTOPILOT_VERSION
  • We created MAV_CMD_REQUEST_MESSAGE as a generic requestor for getting back any message.
  • Problems are:
    • commands return an ACK which is not needed (uses bandwidth). Some messages (MAV_CMD_REQUEST_PROTOCOL_VERSION) sent as broadcast but commands are only supposed to be sent as peer to peer (handling multiple acks).
    • No one has implemented this.
  • QUESTIONS:
    • CAN/SHOULD we have REQUEST_MESSAGE instead of MAV_CMD_REQUEST_MESSAGE which can be sent to individual or broadcast (I think so)
    • Can we get commitment to implement this for a subset of existing messages so we can deprecate the specific senders?
    • Open issues around this are #1155 Common.xml: Clarify MAV_CMD_REQUEST_AUTOPILOT_CAPABILITIES, #1154 Common.xml: Clarify Protocol version protocol
• #1159 Proposal for an opaque, tunnel message

Open Issues last week Action Items (last week)

• Add routing C++ code example: It is too hard for the average developer to figure out how to do routing without full parsing. Addresses #1092 and action item taken by Julian and Lorenz

• Open Drone ID: Needs feedback on where the standard is going, welcome in common and upstream

• Manual control extensions: Need additional fields, but should stay well-defined (#1147)

• Charging station autopilot type (#1146): Preferred approach is to instead introduce a vehicle type "charging station" which then can be built out generically

• Add Open Drone ID messages - Upstreaming these messages is considered welcome on the call.

• #714 Add C++11 headers to c_library_v2 - probably better to create a CPP library. AI @Lorenz to create this.

• #1138 common: add ACCELERATION message - @Lorenz propose LOCAL_POSITION_NED_COV as alternative.

• #1146 Add a constant to MAV_AUTOPILOT for a COEX Pelican charging station - Needs more detailed discussion in dev call. Invited them to attend

• Status updates

Discussed Common Flight Modes proposal

• Proposal is pre-alpha/early thinking

• Idea is that:

  • there are a few common flight modes across every stack - mission, position hold, loiter. We would like to make these part of the spec so that a GCS could implement them without having to know anything about the flight stack.
  • Custom modes could be defined in an definition file (like camera API) so that a GCS could provide a UI without having to understand the semantics.
  • Hope to further refine the idea in the next call.
  • Discussion/progress major proposal: [Events Interface]
  • @WickedShell File format discussion - Attempt to re-engage in next two weeks.
  • Upload mission - discuss with GCS vendors what they see as best way to handle lost Drone originating messages
  • JulianO: Report back on possible System ID allocation approaches and GCS discovery mechanisms/publishing heartbeat when not connected.
  • Lorenz/Hamish - What is happening with Rust team (Michal)
  • MichaelDb: PR to update STATUSTEXT_LONG with fields to allow longer messages.
  • Minimal or fully specified XML? Direction of defaults? https://github.com/mavlink/mavlink/pull/1100
  • Doc Mission partial upload/download - I need to update further.
  • COMMAND_INT/MISSION_ITEM_INT definition danger spot - MatthiasG
  • SET/GET message interval clarifications - persistence, what stream?
  • Ways to resolve conflicts in requests from multiple sources - GCS, Developer APIs, etc. Both different telemetry rates and safety critical systems.

Notes

Call 1

Discussed the following issues

AI:

See above!

Attendees

? HamishW, JamesP, JonasV, JulianO, Lorenz, Stone, Mike Lyons, MatejF