Skip to content

20190403 Dev Meeting

Jump to bottom Edit New page
Hamish Willee edited this page Apr 4, 2019 · 6 revisions

Agenda

General:

Notes

Call 1

  • Events Interface

    • Overview from Lorenz. Suggest to discuss any concerns next week.
    • Question as to whether STATUSTEXT and STATUSTEXT_LONG are still useful. Answer is "probably", and no real cost to keeping them for those who want them.
    • Some concerns about "yet another XML file definition" and keeping things "common". Answer seemed to be that we would not have common definitions of events:
      • XML definition would largely be auto-generated from printf-style code and hence would be firmware and build specific.
      • For translations we'd provide a hash from string (alternative would be to provide and maintain a permanent UUID for each string in code, and allow retranslation).

  • Status update -

    • @WickedShell File format discussion - Did not happen
    • Added fields for RTL and LAND time estimates #995 - progressed. Needs minor push through this week.
    • Upload mission - discuss with GCS vendors what they see as best way to handle lost Drone originating messages - Had discussion. Basically Mission Planner and QGC do same thing - timeout on late follow up messages. AI to update docs.
    • JulianO: Report back on possible System ID allocation approaches and GCS discovery mechanisms/publishing heartbeat when not connected. - Not done. Julian to see if Auterion have any expertise on this
    • MichaelDb: PR to update STATUSTEXT_LONG with fields to allow longer messages. - Not done

  • Local and body frames

    • Frame alignment with ROS nice, but not always practical as ground/air based frames not always have same concerns. Automatic translation would be nice - so no need for nodes to think about frame used by another node or the vehicle.
    • Existing frames include a bunch that are unnecessary - we should try to remove them to simplify the "story" for users and clarify architecture. ie some were introduced for "future proofing" without a clear need. Others are duplicates of frames that incorporate origin in the name (a poor architectural approach).
    • Proposed remove some frames from MAV_FRAME
      • Remove 12 (MAV_FRAME_BODY_FRD) to 19 (MAV_FRAME_ESTIM_ENU)
        • These are existing frames that include the origin system of the data - e.g. mocap or vision. MAVLink expects the origin to come from the component ID, or even better for the message to include the info quality/covariance so that the decision whether to use the information is based on the information itself, not origin.
        • Replace with MAV_FRAME_RESERVED_X, where X is the enum number. Implementations should stop using these.
    • Lorenz suggested remove 3 (MAV_FRAME_GLOBAL_RELATIVE_ALT), 6 (MAV_FRAME_GLOBAL_RELATIVE_ALT_INT). Julian/Hamish argue Relative in wide use from GCS and Kits, because people think in "relative".
    • James pointed out 7, 8, 9 used by ArduPilot (MAV_FRAME_LOCAL_OFFSET_NED, MAV_FRAME_BODY_NED, MAV_FRAME_BODY_OFFSET_NED)
      • Lorenz suggest maybe deprecate 7
      • James says MAV_FRAME_BODY_OFFSET_NED is basically implemented as FRD. Need to clarify action.
      • Hamish says that naming format with use of Local, Body, Offset slightly inconsistent and confusing to users.
        • Suggestion/AI to add diagrams/maths to show how they should be used/what they represent.
    • Lorenz says 10, 11 used by ArduPilot: MAV_FRAME_GLOBAL_TERRAIN_ALT MAV_FRAME_GLOBAL_TERRAIN_ALT_INT
    • Lorenz propose to deprecate 4: MAV_FRAME_LOCAL_ENU - Hamish

  • Hardware encryption support discussion with Stefano Alberico. Covered economic feasibility and some integration next steps.

  • HamishW: Absent for next 2 meetings.

AI:

Attendees

LorenzM, HamishW, JamesP, JulianO, Stefano Alberico, StoneB (silent)

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