20200415 Dev Meeting

Agenda

General:

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

Notes

Call 1

• Lorenz sends apologies - away on urgent business
• Previous actions
  • Joe - what about action item "Lorenz will design for a non-hacky solution that meets BazookaJoe reuqirements in coming 2 weeks."? No information - please contact Lorenz directly.
  • James P: No result from chasing PeterB re nested inclusion of dialect files. HamishW notes that PeterB has been helpful in other discussions.
• RomanP - needs message or command to test control surfaces. What is best way forward (message or command). What ranges can be used for IDs. If we use a command, can we dynamically configure what the field meaning is.
  • Discussed above. Info/links provided.
  • General support for the idea. Action for Roman to create a PR for discussion.
• #1339 Protocol-level discovery which mission items / commands are supported by an autopilot (associated doc)
  • Everyone likes the idea of using the component definition file for this.
  • Assumption is that whole file is always requested (i.e. no need to just request part)
  • Assumption is that hash will need to be added to the message.
  • Jonas noted we can add additional metadata of commands/messages (for example, if we have access control, to verify what actors can send what messages). Good idea when such infrastructure exists, but main requirment for now is design to not "prevent that in future".
  • Assumption that 32 bits for supported info types might not be enough. Let's reconsider at point we remove WIP.
  • Action: JulianO : Propose mission XML for inclusion in the component definition file, along with any updates to the interface to support this. Has to work alongside other data.
  • AO HamishW - chase up GCS vendors on what other info we might get in component definition file. [via JamesP email list]
• #1322 Add ESC_STATUS mavlink message (Ricardo Marques) - what is best way forward for message
  • Agree that as this is for control not just for GCS information, ArduPilot messages are not sufficient.
  • Need to note in description that this message is intended to only be supported on high-bandwidth link (e.g. from companion computer, not to GCS).
  • Concern that this is not extensible to more esc - propose strategy.
  • Review use of timestamps - where are they generated (autopilot or ESC), will they actually differ.
  • AO on Ricardo to update PR with new proposal and comments on how above concerns (and other changes) are being met.
• AO HamishW to add James to MAVLink github org so he gets notified of new messages automatically.

Attendees: HamishW, JulianO, JonasV, Abraham (NXP), Bazooka Joe, Ricardo Marques, JamesP, RomanP