20191211 Dev Meeting

Agenda

General:

• Update from relevant previous calls
• Tagged: issues, PR.

Add a constant to MAV_AUTOPILOT for a COEX Pelican charging station #1146

MAVLinkFTP: Require support of compressed (text) files #1275

Notes

Call 1

• #1280 COMPONENT_INFORMATION discussion (and #1176)- moving it forward

  • Helping clarify what processes exist to get features in.
  • Next step is to unblock PR (which dev team think looks good). Ollie to fix mavlink dependency and ping Don.
  • Hamish will follow up to get ETA for review if needed.

• Microservices proposal.

  • HamishW - Characterised JamesP position as a) more than enough protocol bits for us to continue with those for the time being b) current proposal offers nothing really above protocol bits c) still have to establish mechanism for verifying support of different features; proposal not worth discussing until that problem solved.
  • Hamish asked for ideas about how we might solve end to end "what does service support".
    • Assumption is that unless stated explicitly, everything described by system is assumed to be supported.
    • We need a discovery mechanism to determine what optional parts not supported.
    • We require that such a mechanism exist. Ideally we should state and approach that can be used for any service (e.g. ideally it should be part of the microservices definition).
  • Julian pointed out that for gimbal service we have capability mechanism. This provides functionality at level of feature, not message.
    • Hamish;
      • mission commands a bit different. These can be defined outside of common and there is 1:1 mapping to mav_cmds.
      • Method should be readily extensible to alternative flight stacks.
    • How about special message that can be sent to flight stack. Response is supported or not supported, and possibly to detail of parameters. Ideally could exercise actual code paths.
    • OllieW - Why not use component information XML files?
      • Use scripts to extract information about what is supported not supported. GCS has to find out anyway at least once, but this way that documentation part of the process.
      • needs to be filtered by vehicle type. Could be definition per-vehicle or all vehicles and system has to query type.
      • Should work at least for features that depend on commands.
    • No specific action came out of this. More thinking required.

• RomanLigocki

  • Update on progress (e.g. has investigated ability of px4 to deliver sufficiently good random number, plans to put certificate on SD card in first instance)
  • Wants to know if can use incompatibility bits for highlighting encryption and new signing.
  • Encrypted messages have to be supported as broadcast as there is no way to open them if in-the-middle system does not have certificate (e.g. routing broken). Suggestion was to use compatibility bits and have externalised target component/system id.
  • Potential scalability issue with session keys
  • Hamish pointed out that this all sounds good for prototype, but at point there is something more concrete to evaluate would be the point that much more rigour would be applied to the implementation. i.e. worse case the work might not be accepted and compatibility bits not allocated.

• MAVLinkFTP: Require support of compressed (text) files #1275

  • idea is that systems should be able to store XML definition files (e.g. for camera, components etc) as zip files, and that any consumer (e.g. GCS) must be able to handle zipped XML definition files seamlessly based on the file extension.
  • Generally accepted is "good idea" but only if someone commits to the work, and that work is likely to be accepted by GCS projects (i.e. specifically, that it doesn't put unreasonable dependencies on QGC, currently the only implementer).
  • OllieW has done basic investigation.
  • Julian to look at the libraries already dependencies of QGC to see if one might be fit for purpose.

Discussions not covered.

• #1264 More support for ICE monitoring

  • Asked poster to take PR. As a point of interest, what is trigger to accept vs update dialect message?

• #929 No way to transmit airspeed reference

  • Propose to close - see comment.

• #1234 Add messages for power regulation and temperature status reporting

  • FYI, Edwin no longer working on this. Do we close, or wait to see if gets picked up?

• Common Flight Modes Microservices

  • Action on Lorenz to do first evolution of spec/requirements.

• JulianOes discuss "MAVLink connection semantics

• #1216 SET_POSITION_HOME: Add frame for local coordinates

AI:

See above!

Attendees

• HamishW, JulianOes, Jonas, RomanLigocki, OllieW