20210609 Dev Meeting

Agenda

General:

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

Notes

• MAVLink router - official repo is mavlink-router/mavlink-router - Is the story clear/do we need to help review?

  • Multiple forks - Auterion, ArduPilot, MAVLink.
    • This is partially due to not being able to get changes in to main and urgent product need. Either way though a bit confusing for users
    • AO: Julian to remove the MAVLink version (backing up)
    • AO: Julian to see if can sync Auterion version back to match the master
    • AO: HamishW to make sure there is a clear link from MAVLink docs to the main version.

• add a new message about atmosphere #1646 - does it make sense?

  • JamesP open to idea of humidity data being sent, but need a lot more info about how it is expected to be used. The current comments don't make sense.
    • AO to add comments.
  • HamishW- I'm not OK with fields used or the name either. As "raw sensor data" maybe.
  • Seb - how generally do we add sensor data?
  • Use named variables on some platforms. More generally, prototype what you need offline, when you have proposal/prototype, stick into development.xml to discuss.
  • Hamish - do we need this kind of named data in common (e.g. DATA16)

• Add MAV_CMD_DELETE_IMAGE command #1647 - seems sensible. Any objection?

  • Looks broadly good - names of files definitely not issue.
  • Julian provided late feedback that better to not reorder sequence - agree, mostly because if something misses that update it holds unreliable understanding of the index. AO Julian to post.
  • Hamish to review tomorrow.

• Add doc on payload control options #362

  • MAV_CMD_PAYLOAD_CONTROL_DEPLOY, MAV_CMD_PAYLOAD_PREPARE_DEPLOY, MAV_CMD_NAV_PAYLOAD_PLACE (at least some added in PR) - are they implemented anywhere? and if so, how are they supposed to work)
    • These are a bit like the orbit - "non-primitive" type messages. Not clear what payload is. We might now do as separate goto and payload messages.
    • Are they kruft/can the be deprecated and removed?
    • AO HamishW - propose deprecate and get confirmation from Lorenz - see https://github.com/mavlink/mavlink/pull/1648

• COMMAND_PROGRESS message proposal #1635

  • Was discussed as possible way forward to "rationalise things". Can we agree a way forward for this. Are we going to far with current protocol - should we instead to COMMAND protocol v2.
  • James: More likely to get this in than alternatives as it is non-breaking and works with existing stuff. Will think about this some more.
  • Hamish: Apologies - I keep introducing scope creep. Action on me to look at proposal again and make sure it makes sense.
  • Seb: Very interested in this - already run into cases where have to monitor arbitrary things to know what is going on.

• James, did you get these looked at Fix up enum generation and Replace IDX with simple ifndef to remove build order dependencies #537. The first one in particular is blocking safe use of development.xml.

  • AO James follow up with PeterB.

Attendees: MatejFranceskin, JulianOes, JamesP, Seb - Neptune UK, HamishW