Skip to content

20190918 Dev Meeting

Jump to bottom Edit New page
Hamish Willee edited this page Sep 19, 2019 · 2 revisions

Agenda

General:

Notes

Call 1

  • Common Flight Modes Microservices
    • Lorenz
      • Discussion of broad goals. Note that this is scratchpad - in no way defines mechanism, just first broad suggestion of approach that might work.
      • Aim of first discussion mostly to get agreement that this is something that we want to be able to do
      • Should be able to add a new mode to flight stack without having to recompile the groundstation to support it.
    • Hamish: Also nice to have easy mechanisms to set/get modes without having to do logs of setup - e.g. takeoff should not require user to think about arming. Lorenz agreed but is orthogonal problem.
    • JamesP - we should start with small set of non controversial modes.
    • JamesP - modes have same name on different flight stacks and vehicles. Do we go something truly common or do we have a full set and then choose.
    • JamesP - Camera API seen as complicated due to XML compared to the old messages
      • Lorenz noted that the complicated bits are optional
        • you have a basic API for simple camera API that is similar to old camera messages.
        • XML file is optional, but allows complicated scenario to be supplied by the vehicle.
        • We want something that captures this same idea for flight modes - simple methods for what is common, with optional flexible methods for extensions.
      • JamesP - Perhaps also flight-stack-definable modes that can be part of the basic API too.
    • General agreement that any XML format would be optional part of the spec.
    • Action on Lorenz to do first evolution of spec/requirements.
  • #207 Document Tunnel protocol
    • Lorenz interested in providing a generic end to end tunnel that implementers can use without having to think about the encoding or anything else.
    • No particular objection to way ids for tunnel encoding formats are being reserved. Just waiting on Julian to complete discussion.
    • Some objection to enabling support for documenting opaque tunnel encoding formats; we don't like tunnels, so we think they should be rare and publishing encoding format not needed.
    • Action on HamishW to document this for:
  • DONE #1231 common.xml: NMEA 0183 passthrough message
    • Strong opposition - either messages are useful in MAVLink context or they are not. So lets see whether the set does as needed. Action on Hamish to share that info.
    • In particular, NMEA is a pretty common standard that might be useful to capture in MAVLink.
  • #1228 common.xml: add AIS message
    • Action: JamesP to do due diligence and confirm these are sane.
  • James managed to get the two fuzz testing PRs in, but still working on the multiple-level includ PRe. Not likely to be in immediate future.

Did not discuss:

AI:

See above!

Attendees

  • HamishW, JamesP, DennisM (stifael),
  • JulianO unable to attend
Add a custom footer
Add a custom sidebar
Clone this wiki locally