Skip to content

20220202 Dev Meeting

Jump to bottom Edit New page
Hamish Willee edited this page Feb 16, 2022 · 5 revisions

Agenda

General:

Notes:

  • COMPONENT_INFORMATION: dynamic updates #1790 adds support for component information dynamic updates

    • message contains the fields with CRCs for the two top level files, which include all other json files and their CRCs. The intent is that this will be emitted if something changes - e.g. a UAVCAN device is plugged/removed. The recipient can then see the change, re-read the files, and fully update its configuration.
    • HamishW - why notify on CRC update to two specific information files - does not look very extensible if you need new files or want to be more granular. Why not make an enum that lists the file that is updated and the CRC field for that file. That way it can be extended at will. Also you can send just the sub file that is modified.
    • BeatK.
      • There are only two top level files, which include all the others - there is no intent or expectation that we will need others.
      • If things are removed you need to send the whole file so that can be detected.
    • Let's get sanity check from JamesP too. Attempt to merge next week.

  • COMPONENT information walkthrough.

    • BeatK attended to do walkthrough but key stakeholder audience (James/Lorenz) did not attend.
    • BeatK: "What do I need to show to move us to point where this is considered stable". Does ArduPilot have anyone I could work with to help implement this to show the benefit?
    • AO Hamish. Reinvite Beat when have confirmed Lorenz and James will be able to attend.

  • Common flight modes update: https://github.com/mavlink/rfcs/pull/17

    • HamishW: Notes from last meeting (20220119-Dev-Meeting) show discussion but not what was agreed. Please confirm.
    • Julian not certain. His understanding was:
      • Cruise suggestion OK
      • Generally we'd prefer specific/less ambiguous flight modes that make sense for specific vehicles that generic "cover-alls". So would like to have Hold (say) for MC and "Orbit" for FW rather than "Hold" for both with a different interpretation.
        • HamishW FWIW continuing the thought, a boat might implement "hold" if it can hold in place, "orbit" if it can hold a circle, or "loiter" to hold within a radius but not necessarily by orbit.
      • Standard mode in Heartbeat makes everyone nervous. Probably needs to be separate message.
        • HamishW. I think that is cleaner. In any case, is only way we can break deadlock.

  • Finer grained information about offboard modes - ThomasS

    • GCS displays offboard mode, but a companion might want a GCS to display more useful information about what the mode is doing.
    • Suggestion was that the current Standard/Common modes implementation might do this - the flight stack could emit custom modes for each of these offboard mode
    • HamishW. NOTE, I think we were wrong here - does not "fully" meet the use case. What we want here is for the Ground station to understand is that if the flight stack is in offboard mode then the actual behaviour is controlled by the companion computer. We will need to think on this. Will start discussion.

Did not discuss:

Attendees: JulianO, ThomasS, Hamish, BeatKung - apologies JamesP

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