Skip to content

20230104 Dev Meeting

Jump to bottom Edit New page
Hamish Willee edited this page Jan 4, 2023 · 9 revisions

General:

Notes

  • COMPONENT METADATA: translation

    • Actual schema and described behaviour look like they match the agreed translation structure. Agreed can be merged.
    • Separate to this (but seeded because this affects translation metadata for actuators)
      • JamesP can't remember the associated actuator metadata being approved/agreed, and if approved can't find record of the reasons.
      • Hamish recalls approval but not reasons. Also discussion on working out how you would do dynamic addition of actuator data. Also can't remember what validation was done.
      • Concern is that it is not generic enough to be "standard".
      • Hamish
        • it should be possible to use the approach for both ArduPilot and PX4 because both systems now configure geometry and outputs using parameters. It won't be possible to use this approach on something that does not use parameters for said configuration.
        • It is possible the precise metadata definition works for ArduPilot but impossible to be certain of without an implementation. Beat can really only do best effort here.
        • But the json format should be extensible.
        • AO JamesP to outline concerns and reasonable steps Beat or others might take to address them.

  • Changes to standard flight modes #1915

    • the "user selectable mode" makes sense if you accept all the rest of the changes.
    • Very concerned about this whole PR
      • The original RFC that was approved had a simple requirement "Define standard flight modes such that a GCS can be used with an unknown flight stack", which was translated to: "Define standard flight modes. Provide mechanisms to discover available standard modes, activate standard mode, determine current mode".
      • This PR adds lots of things that make the whole thing a lot more complicated and that have nothing to do with that requirement; they are really about modes in general/better management of unknown modes. For example, you don't need to know if a standard mode should be advanced or user settable - it's a standard mode so that should be up to the GCS to decide. If it needs to be hidden, then that should be a property of the standard mode definition or it isn't standard.
      • This would not have gone into RFC without far more discussion around the use cases we want to address above the original one above.
      • Not sure that the modified version would be allowed out of WIP
    • Further need to be sure that this will appear upstream PX4 and tested both with and without companion.
    • Not sure how to progress this - don't want to backtrack on Beat, but also don't want to allow this to go further and have it either pushed on us as "already in production" or have to backtrack at last moment because communities won't accept the changes into common.xml.
    • AO Hamish. Present this to Beat. Ask for possible alternatives that do not use this PR at all. As for list of use cases to address.

  • message_definitions: add all_with_development.xml #1924

--- Not dealt with last meeting ---

Attendees: ? Hamish, JamesP, JulianO

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