Skip to content

20190710 Dev Meeting

Jump to bottom Edit New page
Hamish Willee edited this page Jul 11, 2019 · 8 revisions

Agenda

General:

Discussed:

  • #1171 Mission checksum package

    • Idea and implementation good in theory, but problematic because new command will be rejected by existing firmware, and the solution of using a compatibility bit is not really scalable.
    • Proposal is that we implement the MAVLink Microservices Versioning protocol - argument being that this is what it was designed for and will allow us to solve these sorts of problems "as a class". Mission hash is a good test case as mission hash is worthwhile, and this sort of use was not what compatibility bit was designed for.
    • JamesP suggested that he'd like to see prototype of versioning before we could fully commit. Also concerned that ArduPilot might not feel it worthwhile to implement.
    • JamesP Also that ArduPilot supports partial and dynamic mission waypoint generation - so implementing this might be resisted by some users. Lorenz pointed out that they don't have to implement this feature - that is a benefit of the protocol - using system can check whether flight stack supports it.
    • AI JonasV and JulianO to start looking at this in 4 weeks, and plan to deliver prototype versioning protocol in 3 months.

  • #1178 Add PROTOCOL_VERSION and friends to minimal.xml

    • Clarification of standard.xml, minimal.xml and common.xml.
      • Minimal. The minimal set to establish a MAVLink link to something.
      • Standard. The set of messages that are well understood, implemented in many real systems in the same way, managed, and near stable - ie the main microservices. Nothing "work in progress:.
      • Common.xml. A set of messages/services that people are expected to target, but that have not been broadly adopted and might still change.
    • We'd like many message to move from Common to Standard, tidy up common to remove "cruft", minimal should be a subset of standard. This should be managed using public process.
    • AI HamishW to create issue around which we can discuss this.
    • This particular item can be merged.

  • #1176 COMPONENT_INFORMATION and #1169 Support for a component version

    • Considered a good idea, but not yet fully reviewed/discussed by Julian
    • Needs to be tested against some real use cases, e.g. camera to see where it might work/not work.
    • JamesP looping in PeterBarker to see if he can contribute.

  • #1167 Add OpenDroneID messages

    • JamesP. This should be paused - messages still in Flux / too early. Some interest as it appears t use the same message set as Google Wing (which provides "ok to fly" info as approved by Australian Gvt).
    • Lorenz concerned the openDroneId team perhaps not got sufficient resource or sufficiently embedded in industry to get traction and solve these issues. Not clear scope of what they are doing - we see more value on collaborating on things like security model.
    • AI Lorenz, JamesP, TomPettinger to set up meeting and see if we can better understand project goals and direction.

  • #1168 PARAM_EXT_SET and PARAM_EXT_VALUE not correctly truncated

    • JulianO Yes, not well designed, but already too late to just change.
    • For camera case where this is mostly used there is a good link. So in real cases it will not be swallowing up the whole bandwidth - or if it is you have bigger problems that fixing this message will not fix.
    • We hope that this will get fixed by next iteration of param protocol. Will not do anything about it now.

Did not address these agenda items. :

Notes

Call 1

Discussed the following issues

AI:

See above!

Attendees

HamishW, JamesP, JulianO, Lorenz, Stone, @holmnikolaj !

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