20210526 Dev Meeting

Agenda

General:

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

Notes

HamishW note: The below was result of brief discussion with JulianOes. I was not present. Sorry if incorrect summary.

Discussion with MAVSDK contributor around whether MAVSDK is best approach for common mavlink implementation. Main interest in boats, subs.

• Fix up enum generation - this is a "fix" to the broken enum. Includes This ZIP contains current and fixed up generated libraries that shows old mechanism is clearly broken (compare common files when generated from common.xml and when generated from ardupilotmega.xml). It shows the new library generates consistent enums irrespective of generation order.
  • This is a precondition to development.xml working properly.
  • Can we get it reviewed. Perhaps architecture can be better, but this proves that the old way is broken, and seems to work reliably.

AO: JamesP to chase up review.

• Replace IDX with simple ifndef to remove build order dependencies #537 - attempts to remove (what looks like) unnecessary code that makes the order of building dialects matter.
  • This seems sane to me, but fails tests. Can I get some advice on this from someone technical.

AO: JamesP to chase up review.

• COMMAND_PROGRESS message proposal #1635

  • Proposed as generic solution to notifying status/progress of a command while executing (in response to #1622)

  • Discussion basically ended up as "long running commands already do this", and more clearly/efficiently

  • Problems are that:

    • ArduPilot do not use long running commands at all (though PeterBarker is interested as he sees it as a way to get around some technical issues related to arming)
    • PX4 don't use LRcommands for cases where they make sense: Takeoff, Orbit etc. These just immediately ack "accepted". I.e. if this was implemented PX4 would not be interested in this generic COMMAND_PROGRESS.
    • LRCommands have some conceptual edge cases:
      • Not clear when some commands would "end". ie. clear for takeoff, but what about orbit? I think it is probably when the specific number of orbits has completed OR for continuous orbiting, it is at the point that the orbit has started.
      • Commands are inherently synchronous. We can keep it that way, but might make sense to include a command instance ID so that multiple commands can be handled.

  • Benefit of COMMAND_PROGRESS is that it might replaces LR commands without having to change existing implementations and state machine. Downside (also of proper LRCommand) is implementation detail of notifying the end of the command - this happens somewhere that is decoupled from the state machine.

  • Action - discuss - can we get will together to discuss the LRCommands. PeterB seemed interested in being in this chat.

  • Comments from meeting

    • James see's this as possible way to converge on "long running protocol". Further discussion worthwhile.
    • Hamish see could use this as a direct replacement for long running protocol - ie use COMMAND_PROGRESS as a new ACK. If we do this, maybe move to a new command protocol.
    • More thinking to be done.

• MAVLink signature check in C library does not check signing_streams's link_id when creating new stream #1619 - can I get a technical review please?

  • JamesP possible duplicate of bug in Pymavlink - suggest cross post.

Not covered:

• Any other open issues or PRs we can close?

Attendees: ? JulianO, JamesP, Neptune UK. Apologies: HamishW