Contact information for the core dev team and community can be found here. Developers are also most welcome to attend the weekly dev call and other developer events.


Weekly Dev Call

The PX4 dev team syncs up on platform technical details and in-depth analysis. There is also space in the agenda to discuss pull requests, major impacting issues and Q&A.

Who should attend:

  • Core project maintainers
  • Component maintainers
  • Test team lead
  • Dronecode members
  • Community members

The dev call is open to all interested developers (not just the core dev team). This is a great opportunity to meet the team and contribute to the ongoing development of the platform.


  • TIME: Wednesday 5PM CET, 11AM EST, 8AM PST (subscribe to calendar)
  • Join the call:
  • Meeting ID: 625 711 763
  • Dial(for higher quality, dial a number based on your current location):

    • Switzerland: +41 (0) 31 528 0988
    • US: +1 646 876 9923 or +1 669 900 6833 or +1 408 740 3766
    • Germany: +49 (0) 30 3080 6188
    • Mexico: +52 554 161 4288
    • Australia: +61 (0) 2 8015 2088
    • United Kingdom: +44 (0) 20 3695 0088
    • South Korea: +82 (0) 2 6022 2322
    • Spain: +34 91 198 0188
    • International numbers available
  • Agenda is published before the call on PX4 Discuss - weekly-dev-call

  • To nominate Issues and PRs for the call you can use the devcall label to flag them for discussion.

Tests Flights

The Dronecode test team can help review (test flight) your pull requests and provide feedback and logs.

See Test Flights for information about available test vehicles/autopilots, how to request flights, and response times.

Have a problem?

Help diagnosing problems

If you are unsure what the problem is and you need help diagnosing

Issue & Bug reporting

General support

Calendar & Events

The Dronecode Calendar shows important events for platform developers and users. Select the links below to display the calendar in your timezone (and to add it to your own calendar):

Note: calendar defaults to CET.


Code of Conduct

We pledge to adhere to the PX4 code of conduct. This code aims to foster an open and welcoming environment.

Source Code Management

The PX4 project uses a three-branch Git branching model:

  • master is by default unstable and sees rapid development.
  • beta has been thoroughly tested. It's intended for flight testers.
  • stable points to the last release.

We try to retain a linear history through rebases and avoid the Github flow. However, due to the global team and fast moving development we might resort to merges at times.

To contribute new functionality, sign up for Github, then fork the repository, create a new branch, add your changes, and finally send a pull request. Changes will be merged when they pass our continuous integration tests.

All code contributions have to be under the permissive BSD 3-clause license and all code must not impose any further constraints on the use.

Code Style Formatting

PX4 uses astyle for code formatting. Valid versions are

Once installed, formatting can be checked with ./Tools/astyle/ The output should be Format checks passed on a clean master. If that worked, make format can be used in the future to check and format all files automatically.

In-Source Documentation

PX4 developers are encouraged to create appropriate in-source documentation.

Source-code documentation standards are not enforced, and the code is currently inconsistently documented. We'd like to do better!

Currently we have two types of source-based documentation:

  • PRINT_MODULE_* methods are used for both module run time usage instructions and for the Modules & Commands Reference in this guide.
  • We encourage other in-source documentation where it adds value/is not redundant.

    Developers should name C++ entities (classes, functions, variables etc.) such that their purpose can be inferred - reducing the need for explicit documentation.

    • Do not add documentation that can trivially be assumed from C++ entity names.
    • Commonly you may want to add information about corner cases and error handling.
    • Doxgyen tags should be used if documentation is needed: @class, @file, @param, @return, @brief, @var, @see, @note. A good example of usage is src/modules/events/send_event.h.

Commits and Commit Messages

Please use descriptive, multi-paragraph commit messages for all non-trivial changes. Structure them well so they make sense in the one-line summary but also provide full detail.

Component: Explain the change in one sentence. Fixes #1234

Prepend the software component to the start of the summary
line, either by the module name or a description of it.
(e.g. "mc_att_ctrl" or "multicopter attitude controller").

If the issue number is appended as <Fixes #1234>, Github
will automatically close the issue when the commit is
merged to the master branch.

The body of the message can contain several paragraphs.
Describe in detail what you changed. Link issues and flight
logs either related to this fix or to the testing results
of this commit.

Describe the change and why you changed it, avoid to
paraphrase the code change (Good: "Adds an additional
safety check for vehicles with low quality GPS reception".
Bad: "Add gps_reception_check() function").

Reported-by: Name <>

Use git commit -s to sign off on all of your commits. This will add signed-off-by: with your name and email as the last line.

This commit guide is based on best practices for the Linux Kernel and other projects maintained by Linus Torvalds.

results matching ""

    No results matching ""