Skip to content

20211013 Dev Meeting

Jump to bottom Edit New page
Hamish Willee edited this page Oct 13, 2021 · 8 revisions

Agenda

General:

Notes

  • Enum IDX bug fixed but not reviewed

    • James notes that this is part of bigger problem that will be looked at all together.
    • Hamish requests James ask Peter to look at the PR anyway, because it is trivial and will unblock certain builds.
    • AO James to ask for review from Peter.

  • External dialects - don't build

    • James wants to know root cause - what is the problem that is causing this so we can assess scope of problem and whether it can be fixed in another way. Also to verify it is not a build config issue.
    • AO David Jablonski to find more info.
      • DONE - context here and in comment above.
      • In summary this is a real issue from building pymavlink library that is affecting other scripts like ROS (it isn't misuse). The PR proposed fixes setup.py and attempts to explicitly rather than implicitly support building a dialect.
    • Discussion may be raised again next meeting.

  • specify invalid value for MAV_CMD_NAV_VTOL_LAND.param7 (ground altitude) #1716

    • OK to add NaN value. Remove the "ground truth" comment because it might imply that the value should be ignored for systems with a distance sensor (generally distance sensor is for final landing "tuning" - this will still be useful in that case).
    • DONE AO Hamish to merge

  • How validate "companion" messages like Cellular Status that don't quite fit into the "must be in 2 flight stacks" governance.

    • Some things are harder to validate. For example the cellular status is in a companion and a ground station. The companion code may well not be open source but the functionality is needed to be common for a GCS for multiple systems.
    • The concern/goals here is that things must only go into common if actually common. There must be verification of some kind of implementation and use in multiple stacks.
    • Governance doc should guide us here.
    • Upshot, keep this in mind next time we have something similar to integrate to make sure the governance rules can be applied properly.

  • Mission feasibility checking + atomic mission uploads (discussion comes from here).

    • It is not currently possible to guarantee successful upload and validation of a "whole plan" (mission + geofence + rally points) because each part of the plan is uploaded and accepted separately. Therefore any part can only be validated against the other parts that are currently on the vehicle, and if any part fails, the whole plan may be inconsistent.
      • Particularly serious if a mission that contains a landing pattern is invalidated.
    • The approaches used across flight stacks to notify GCS of unfeasible missions (e.g. pre takeoff) are not standardized. It would be useful for a GCS to have a common notification mechanism so that they could implement common behaviour (i.e. marking mission as not executable using the events interface).
    • Whole-mission validation on upload is a potentially expensive operation for flight stacks that keep the mission in memory, as all parts of the plan need to be kept in memory until validated rather than just the part being uploaded
      • How significant this is depends on the size of the plan vs just the size of part of the plan.
      • There are also processor costs to this validation.
    • Some flight stacks support partial mission uploads, which may have other validation requirements
    • Some systems commonly fly with an "invalid" mission so it must be possible to force the mission to fly despite certain types of failures in the validity (but possibly not others). For example, when a mission is dynamically updated, and only a partial mission executes at a time.
    • Broad consensus:
      • Support for atomic upload of whole plan is needed
      • Common way to report and run feasibility check on plan is desirable.
      • Even if a feasibility check is failed, it should still be possible to force a mission to run.
    • We won't resolve this now. Let's defer.

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

Attendees: David Jablonski, JamesP, Seb, HamishW, JulianO

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