20200916 Dev Meeting

Agenda

General:

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

Notes

Agenda

• BATTERY_STATUS add faults, remove SMART_BATTERY_STATUS #1456

  • There are additional faults:
    • Voltage inconsistencies on bus - so can't start supplying power.
    • Cell imbalance fault - Claudio to provide words.
  • A smart battery can have modes like "storage mode". While this should never be used intentionally in flight, we can see a case where it might switch in flight and cause crash - an end user would want to know this.
  • AI HamishW. We will change the enum from "Fault" to status/state, allowing non-fault states. This allows us to add storage mode, and potentially other states that might be needed for notification.
  • NOTE Approach proved hard to do in a satisfying way. Have just added mode for this and am discussing.

• MAV_CMD_NAV_FENCE_RETURN_POINT - how is it supposed to work?

  • MichaelO - predates rally points. Doesn't make much sense now but should not be removed because is used by ArduPilot Chinese users who will never update.
  • Lorenz points out that deprecating it without removing at least provides clear direction of the desired alternative.
  • DONE: AI HamishW Do deprecation.

• Geofence Actions - should these be standardised so GCS can query/set them without having to know flight stack (currently would have to know the params used)

  • James P - already is standard set FENCE_ACTION but this is directly assigned to an ArduPilot param so no way to generically set it.
  • Proposal is to create a command that can be uploaded in a fence definition, and that allows a GF action per fence. If not defined then fallback to system value.
  • STARTED Command to allow geofence action to be set per-fence

• Add some "missing" fields to AUTOPILOT_VERSION, CAMERA_INFORMATION #1469 - does this make sense?

  • This isn't the way we would do it now, and the change makes sense from a consistency point of view.
  • However until there is an actual problem that this will solve we don't think there is need to make the change/it is worth the churn.
  • AI Hamish, reject with thanks.

• MAVlink Governance Policy (discussion doc)

  • Generally looks good
  • Lorenz main concern is that we need to broaden stakeholder to better involve industry partners, as proxy for end users. Example is gimbal vendors like Gremsy.
  • Proposal to devote all next meeting to covering detail of this.

Not discussed:

• File-based protocols for params, missions, etc - Next steps Lorenz?
  • Note from Michael DuB - before choosing bson, or whatever need to evaluate efficiency of alternatives. Bson probably not as efficient as .bz compression for example.

Attendees: HamishW, JamesP, JulianO, LorenzM, ClaudioM, Michael Oborne, Philip Rowse, JonasV.