20211222 Dev Meeting

Agenda

General:

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

Notes

• Meeting schedule is Jan 5 and Jan 19. James and Julian may be away for 5th (may be able to come). Hamish away for 19th.

  • We will confirm Jan 3 if next meeting going ahead.

• DISCUSS: MAV_FRAME_BODY_ to MAV_FRAME_MAV_ - better origin indicator than BODY

  • Not sure that changing body helps - users have to read the description to be sure how things work.
  • Either way MAV_FRAME_BODY_FRD is problematic.
    • Description means the "FRD tangent frame with origin centered on the vehicle". So this is like NED aligned with the front of the vehicle.
    • But FRD "really" commonly means body post aligned.
    • And we need frames for both FRD as it is now defined and FRD that is body aligned - what do we call them?
    • We can't use RPY as in the RFC because the things that use these frames don't specify angles.
  • AO Two paths ON team.
    • Find an existing standard for frames and use that naming
    • Agree convention for body aligned.
  • AO HamishW ask for thoughts on issue itself. DONE

• RFC 0016 - Mavlink Standard Modes - update to Proposal: Support for common flight modes #1750

  • HamishW:
    • Design is better if current standard mode is broadcast, either in heartbeat or in new separate message. Trying to infer from standard modes can be done, but makes things painful for implementers.
    • Heartbeat would be consistent place for that. There is some argument that heartbeat was always the wrong place for mode info, and we should move towards separate message anyway.
    • We can set the mode (standard/custom) in one message. It's just that it would have to be a new message. This does not preclude using old message to set a standard mode via a mapped custom mode.
  • James not yet had enough feedback from ArduPilot/Tridge to confirm next steps.

• Autotuning PX4 and ArduPilot do different implementations. Is this a problem? Can GCS implement "standard" behaviour?

  • MAV_CMD_DO_AUTOTUNE_ENABLE is minimally specified as a command that enables/disables tuning. Result is that different flight stacks implement differently.
    • PX4 implements this as a long running command in the current altitude controlled/stabilized mode for both MC and FW. The flight stack injects appropriate movement and then tunes. Process is more or less fixed in length and ends (by default) with test for FW and in flight application of new params, and landing for MC where values then applied.
    • ArduPilot implements as a FW mode (only). The user flies in the mode and inject steps. The tuning system steadily improves the flight characteristics. When user is happy that flight is good they exit the mode.
    • Both stacks allow a single axis RPY to be tuned, but do this via parameters.
  • AO Hamish to propose a message update to allow GCS to be more general. DONE/In discussion

Not discussed

• new message radio_status_extensions in development #1748

  • Messages won't be updated until next year.

• Component support flags should be versioned? (originates here Component Information Basics: add camera cap flag #1752 )

  • HamishW - we keep on adding support flags to things for the reason that we don't have "microservice versioning protocol".
  • We don't have to have that protocol, but we do need to clearly identify how we work with flags 'n'such.
  • Propose we continue to use flags but we always number them.
  • Briefly discussed holes in story for camera - need to work out what the old messages are used for/where and document as v1.

• AP: common: added voltage and current multipliers to BATTERY_STATUS #233 and 16-cell support #1747

  • Any progress?

• Common.xml - WIP message review #1669 - do some more cleanup

Attendees: ?HamishW, JamesP, JulianO, Matej, Lorenz, Ramon, Thomas Debrunner.