Skip to content

20210120 Dev Meeting

Jump to bottom Edit New page
Hamish Willee edited this page Jan 20, 2021 · 8 revisions

Agenda

General:

Notes

Agenda

  • Doc outdated: Camera Protocol #298 - generic request message - can we drop support for existing cameras. Can I add a protocol bit for this? If not, revert/add note to docs?

    • JamesP does not impact APM but likely it is worth making the break.
    • Lorenz, probably this is amenable to fixing.
    • DONE AO Hamish to ping Lorenz and Gus to find a way forward (added a note here and in slack here)

  • Proposal for more robust COMMAND_LONG response #1558 - command response might be an information type.

    • Not an acceptable solution as every single command requires bespoke handling.
    • The problem of possibly dropping messages is a direct consequence of the fact that MAVLink is deliberately not a reliable transport.
    • The solution is to resend in the application layer. If this is a significant problem we could define a "microservice" for this - effectively just send command, set timeout on ack, wait for second response.
    • DONE AO Hamish to post response.

  • DONE 1556 Move docs into mavlink/mavlink repo - opinions?

    • All - no compelling argument presented.
    • AO JamesP to close with reasons.

  • Component information and events interface #1531

    • APM review positive; overall can proceed with development with confidence.
    • Two questions for Beat to answer through any channel:
      • CompInfo would be useful for configuring whole device, not just MAVLink stuff. Any thought on configuring UAVCAN etc?
      • Concern that events definitions might disappear off public servers, resulting in vehicles not working/updating properly. Not mavlink "problem" but would be perceived as such and affect confidence. Possible suggestions are to mandate on-device presence of definitions, or MAVLink hosting. Thoughts please?
    • DONE AO Hamish to post above to Beat
    • AO Hamish to provide draft docs of the component information microservice.

  • Mission checksum message

    • ArduPilot makes heavy use of mission updates from companion computer, so AP will have to find some way to turn this off in certain networks/devices. But, notes that this is done for historical reasons, and is probably not the "right" way to do these kinds of things
    • OK with this to proceed. First implementations will provide a better idea of what works/does not.
    • AO James to do final check.
    • DONE AO Hamish to update issue with "please proceed".

  • Lorenz did you do Travis fix for building C libraries?

    • No
    • DONE AO HamishW to add issue.

  • MAVlink Governance Policy

    • Looking good - move into the RFC process.

  • Criteria for inclusion into supported language list as discussed here.

    • Mavgen languages are supported. In practice the C and Python libs are "best supported" because of demand. However there are increasing numbers of tests and will take bug reports, fixes on others.
    • There are non-mavgen languages that have varying levels of support.
    • James suggests that we should engage more with them rather than fire and forget.
    • AO hamish to add the second Java implementation to table.
    • AO Hamish to add a "support statement" to the list.

  • common: add MAV_CMD_CAMERA_TRACK_SCENE (JonasV)

    • Adds tracking of whole image. Needed because when tracking a whole image you don't want the highlight rectangle displayed.
    • Lorenz. This is really optical stabilisation - semantically different. Rename.
    • Requires implementation before can be merged.

  • FTP protocol incompatibilities - append vs overwrite + upload in fewest steps question

    • JamesP not yet had a chance to follow this up. Will continue to do so.

Attendees: HamishW, JamesP, Lorenz, JonasV

Add a custom footer
Add a custom sidebar
Clone this wiki locally