PX4 Dev Call: January 06, 2021

📞 Coordination Calls PX4 Autopilot Coordination
1

January 06, 2021

Agenda

  • Status update by component/project
  • Roadmap, and Release discussion
  • Community Q&A
  • In-Depth discussions

Join Meeting

Component update

Roadmap discussion

In previous years we presented a roadmap that showed the trends but we did not achieve every single item on these plans in time. We need a way to present the roadmap and plans in a way that’s more clear in terms of what’s committed and what are trends that are still uncertain.

High-level roadmap:


Low-level issues should be linked to the high-level roadmap issue.

Roadmap items

  • Control allocation
    We should have a call with the involved developers to bring an iteration into master and start to have returns. There were successful flights before but there’s a huge effort right now to configure it for the specific vehicle. We should bring it in for optional test use and at the start use it in a dumb limited way to get testing and a feeling of what is missing.

  • ROS2

    What’s mainly missing are examples and documentation to present how the setup works. We should start with a very minimal example like sending the computer’s time to PX4 and add it to the draft documentation.

  • Tuning UI UX
    @bkueng did progress on the tuning page. We need to have few sliders that are well described for a start.

  • Online IMU signal FFT filters
    The pipeline still needs to be adjusted to fit in the draft FFT work that @dagar already did.

  • Device tree for robots
    @bperseghetti started to look into sdf text representation of such a tree in https://github.com/rudislabs/hcdformat/blob/main/template.hcdf
    We need to experiment in storing these files on board, sending them over, being able to edit in the UI. A good point to start would be the output system/mixers. This might result in a hierarchical parameter system with more data types. We could start with a text representation and optimize it backward compatible once we understand what’s important with the real-world configuration. If done right this can include the low-level device specification.

  • Mode/navigator

    https://github.com/PX4/PX4-Autopilot/projects/34
    https://docs.google.com/document/d/1N59JHFqL_E9X4b-U0CzxW_eydqXUHZMxAH_FTD30ilk/

    Goal to have a separate, sequential implementation for each mode and each vehicle type. No class hierarchy like in FlightTasks and no vehicle type distinction cases in the implementation like in Navigator.

    First step to use for other vehicle types.

    https://github.com/PX4/PX4-Autopilot/pull/14665

    https://github.com/PX4/PX4-Autopilot/pull/16484

    Closely related to state machine (commander). The goal is a hierarchical state machine such that build time it can be modularly decided what needs to be in what what the requirements for each mode are.

  • Automatic tuning for multicopter and fixed-wing

    @bresch had a draft for velocity control tuning but is currently looking into rate and attitude control tuning. A multicopter rate and attitude control tuning is close to an integratable state.

High priority issues

  • We need to make sure support levels for boards are clear also when someone is just picking up the code and builds it or downloads a binary.
  • Enable airmode by default

We need to make sure airmode is diabled during initial bringup because of very high risk of instability in the really first flight and have a simple detection

Errata and Feedback

Let me know below if we failed to capture anything the right way, and if there are any updates (not present here), or you have feedback you would like to share with the dev-team.