PX4 Maintainers Call: May 30, 2023

📞 Coordination Calls PX4 Autopilot Coordination
1

:calendar: May 30, 2023

The maintainers meeting is a meeting for the developer team to coordinate on pressing issues and to plan the development of the PX4 Autopilot project, the community is welcome to join and listen, but won’t be able to speak unless specific access is granted ahead of time.

:selfie: Meeting Link

:notebook_with_decorative_cover: Agenda

  • v1.14 new beta

:memo: Meeting Notes

v1.14 new beta release

  • Currently having sensor issues on mRo control zero
  • PWM details @MaEtUgR raised
  • Geofence causing flyaway issue. Any opinions? > Logic is completely wrong even when far from the border (Alex), so it has been unstable for a while
    • Can we disable (predictor) this since 1.14 is already branched out?
    • We can then state that we will not support this feature
    • Also geofence constantly messing with dataman is not ideal.
    • Should we maybe kill the whole feature?
    • We need to verify if Geofence really works !?
    • If we can set down a minimal scope of what we actually want to achieve for the next release, that would be more helpful. <<<

Beta blockers:

  • Optical flow check
  • Geofence predictor disable

Action Item:

  • Disable geofence predictor (PR) & update Docs to state that predictor is disabled & Verify Geofence actually working > Initial effor here: Discord

PR created: [1.14 Backport] Geofence: Disable pre-emptive geofence predictor by default by junwoo091400 · Pull Request #21657 · PX4/PX4-Autopilot · GitHub

Note: Geofence predictor was introduced in v1.12: Release 1.12 | PX4 User Guide

v1.14 extra backports

Vince from Holybro wants to get this PR in: lights: Add LP5562 RGBLED driver by julianoes · Pull Request #21649 · PX4/PX4-Autopilot · GitHub

Beta binaries not showing up

Discord thread: Discord

E.g. the cubeorangeplus px4 binary doesn’t seem to exist in S3 bucket: http://px4-travis.s3.amazonaws.com/Firmware/beta/cubepilot_cubeorangeplus_default.px4

  • Initial Jenkins setup uploading binary to S3 could be broken (credentials)
  • Action Item: Converting the github actions (deploy_all.yml) to also upload binary could be nice
  • Branches: main/beta/stable
  • Problem found: the target lists for the Jenkins build server was maintained manually! ARKv6X is also probably missing.

:fire: v1.15 / next release improvement discussion

  • Scopes: We should have some scopes (to achieve) / stop points (to limit feature creep) for the next release.

  • Time window: Even if the schedule is arbitrary, if we set the window, it would be helpful.

  • Resources: Also, we should keep track of who has the resources to support certain things.

  • Stale PRs: We should also do review of the PRs that has been sitting stale, and figure out if we can get a new release out of those stale PRs.

  • Support level: Already now it would be nice to discuss which features are well/kinda/badly supported, for the next release.

  • The support level should be obvious to figure out for developer/users (e.g. by having that in the root folder).

  • Tier splitting: E.g. from KConfig we could even specify the tier level (e.g. for EKF2).

  • We could already list out which features are truly well supported (should be) / etc.

  • We could document this support level within codespace itself (related comment on atomic documentation: https://github.com/PX4/PX4-user_guide/pull/2331#issuecomment-1470957337). This can also save duplicate work when branching out / changing docs for the release.

  • Discussion with Hamish would be necessary for how to structure this whole idea. What would this look like in high level docs overview? (E.g. note on every feature docs to have it specified?)

Followup created on discord: Discord