Skip to content

20220216 Dev Meeting

Jump to bottom Edit New page
Hamish Willee edited this page Feb 17, 2022 · 17 revisions

Agenda

General:

Notes:

  • Common flight modes update: https://github.com/mavlink/rfcs/pull/17

    • JamesP. Good enough to prototype.
    • DONE AO Hamish: Get it into development.xml

  • Any interest in fixed up MAVFTP?

    • This is a close copy of the approach used for FTP elsewhere - it has the same opcodes, semantics, and is well documented (except for burst mode).
    • The original ftp definition also includes all the opcodes etc in payload.
    • Moving opcodes out of payload into fields (or any other change) might help tooling, but will move this away from being true to the broader protocol definition.
    • General agreement not to do for now.
    • DONE AO HamishW Add link to existing FTP protocol info so that it is more obvious that the original implementation is what we have followed.
    • AO HamishW chase up getting documentation for burst mode. BeatK says he can help. - IN PROG - https://github.com/mavlink/mavlink-devguide/issues/98

  • COMPONENT_INFORMATION: dynamic updates #1790 adds support for component information dynamic updates

    • General discussion about the particular use case - SMART_BATTERY_INFO might be a better solution.
    • AO BeatKung to determine if this is needed/appropriate here. Current leaning is that SMART_BATTERY_INFO might be better (has been converted to draft)
    • IFF it is a better approach, this can be merged.

  • Add radius to DO_REPOSITION #1787

    • Starting to get stale with no responses to questions.
    • AO HamishW Close with prompt that it can be reopened if information is provided.

  • MAV_WINCH_STATUS_CLUTCH_ENGAGED: clarify definition #1781

    • James to follow up with Randy if this is OK.

  • Flight termination - https://github.com/mavlink/mavlink/pull/1774

  • All agreed flight termination is irreversible and immediate termination of flight, which may trigger safety measures (commonly disabling motors and deployment of parachute on MC, and setting flight surfaces to initiate a landing pattern on FW). On vehicles without configured safety measures it may trigger a crash landing.

  • PX4 implementation of MAV_CMD_DO_FLIGHTTERMINATION reverses termination if value < 0. As above, this is inconsistent with our understanding of termination.

  • DONE AO: HamishW to update docs as above.

  • AO: Julian to remove this behaviour on PX4. Issue created in https://github.com/PX4/PX4-Autopilot/issues/19198

  • Parameter protocol tidy - better bits (also)

    • Parameter protocol has two possible encoding param values into (float) fields: C-style cast and Bytewise encoding. ArduPilot uses the first, PX4 uses the second. They are incompatible, and there is no documented way to tell which is being used. Proposal is to use protocol bits MAV_PROTOCOL_CAPABILITY_PARAM_UNION and MAV_PROTOCOL_CAPABILITY_PARAM_FLOAT to differentiate these. These can then also be used for discovery of the protocol. This reflects the history of implementation and makes both protocols valid. Also gives ArduPilot a path towards using Bytewise encoding, if desired. It is desirable to change the protocol bit names, and should have no side effects. These should then be set appropriately.
    • All agreed this is a good idea. There may be better ways that protocol bits, but we should not wait on those.
    • Done AO HamishW - create PR to rename the bits to MAV_PROTOCOL_CAPABILITY_PARAM_ENCODE_BYTEWISE, MAV_PROTOCOL_CAPABILITY_PARAM_ENCODE_C_CAST
    • AO HamishW - Create issues in PX4/ArduPilot to get them to set bits (once above merged)
    • Drafted AO HamishW - create PR to document change. Do not merge until above PR agreed.

  • COMPONENT_INFORMATION Protocol - How do we get this accepted as part of the standard

    • Perception is that this is still in "flux". There are PRs still being delivered against it.
    • What we're trying to do is get the core infrastructure and "approach" approved. There may be churn on specific types of data.
    • To be standard, we need more than just one implementation. Need to start looking at implementing this, at least for parameter metadata, in ArduPilot.
    • Actions
      • PR to remove WIP from core infrastructure. Should clearly identify what is core and what is not.
      • Go through open PRs and clarify status.

Attendees: JulianO, Hamish, BeatKung, Lorenz

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