20190306 Dev Meeting

Agenda

General:

• Update from 20190220 (relevant previous calls)
• Tagged: issues, PR. A few choice items:

HamishW

• Doc Mission partial upload/download
• 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.

CHECK Status

• @JamesP and @MichaelS (or Lorenz/Thomas) to engage with Local and body frames and add comments. Discuss next week.
• @WickedShell File format discussion - Attempt to re-engage in next two weeks.

Last week AIs

• JulianO: Report back on possible System ID allocation approaches and GCS discovery mechanisms/publishing heartbeat when not connected.
• DONE HamishW: Connect Rust team (Michal) to Lorenz for meeting.
• DONE (ArduPilot#10584, PX4#11514) HamishW: Merge 1083: Update RSSI values to 0-254, 255=not used and notify JamesP in AP issue.
• MichaelDb: PR to update STATUSTEXT_LONG with fields to allow longer messages.
• DONE HamishW - Respond to RADIO_SETTINGS with invite to dev call and reasoning.

Notes

Call 1

• Forwarding of unknown messages in C library not supported #1092 - Discussed issue and next steps. Action on Hamish/James to progress via Tridge.
• Mission Upload Protocol - what should GCS do if it doesn't get MISSION_ACK to know completion status.
  • Problem is that if MISSION_ACK not received GCS does not know if mission completed - what should it do?
  • More generally, if Drone doesn't get mission item it will re-request, so the drone always knows if it has a valid mission. However the GCS basically waits for next request - which might never come, so it could be left "mid mission" forever. HOw should it handle this case - monitor for each request or should it just have an overall mission timeout?
    • QGC currently has timeout on every mission item request waiting for next one. Just times out if it doesn't get final ACK
  • ArduPilot sends MISSION_ACK multiple times - GCS expected to ignore if receives subsequent, and if it doesn't get any, assumes that upload was invalid.
  • Alternative is for GCS to resend last MISSION_ITEM until it gets the ACK or times-out.
  • Action on Hamish to further discuss options with Don, Michael(s) and see if there is a common approach
• Added fields for RTL and LAND time estimates #995
  • Fields we know we need are: RTL, SMART RTL, LAND, NEXT MISSION ITEM, WHOLE MISSION, CURRENT TASK
  • Current task is inferred by GSC from other messages.
  • Also suggesting add an available flight time (or battery capacity) field that others can be compared against. This is aggregated from battery or other information.
    • Note, some discussion about whether this info provided by BATTERY_STATUS or smart battery messages already. Argument against using those is that battery information reflects possibly multiple batteries and the way in which they affect available flight time might depend on many things the GCS cannot infer. Using a field that explicitly states the flight time ensures that we have something unambiguous.
  • Action on Matthias/Alessandro to update the PR as discussed and make it WIP.
• COMMAND_INT/MISSION_ITEM_INT definition danger spot - Deferred - insufficient time to handle properly and would like MichaelDB thinking on this.
• Last weeks AIs and Actions/status checks not covered - deferred and need to be done next meeting.

AI:

• HamishW, JamesA Forwarding of unknown messages in C library not supported #1092
  • DONE: Hamish to summarise issue and requirement and ping James.
  • James to raise with Tridge for discussion.
• **IN PROGRESS:**HamishW - discuss with GCS vendors what they see as best way to handle lost Drone-originating message in GCS.
• Matthias/Alessandro - update Added fields for RTL and LAND time estimates #995 with message discussed as WIP

Attendees

HamishW, JamesP, JulianO, Matthias Grob, AlessandroS