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 PDT (subscribe to calendar)
- Uberconference: www.uberconference.com/lf-dronecode
- Phone: +1 415-891-1494
- The agenda is announced in advance on the PX4 Discuss
- To nominate Issues and PRs for the call you can use the devcall label to flag them for discussion.
Test flights are important for quality assurance. The Dronecode test team can help review (test flight) your pull requests and provide feedback and logs.
How to request test flights
- Assign the test team @PX4/testflights as a reviewer to the pull request or issue
- Add a complete and thorough description of your changes
- Wait for feedback from the test team
- The test team will add your PR/issue to their queue
- Multi-Copter: up to 48 hours (typically within 24 hours)
- VTOL, Fixed Wing: up to 4 days (typically 2 days)
Have a problem?
Help diagnosing problems
If you are unsure what the problem is and you need help diagnosing
- Upload logs to Flight Log Review
- Open a discussion on PX4 Discuss with a flight report and links to logs.
- If you find an issue or bug with PX4 open a Github Issue
Issue & Bug reporting
- Upload logs to Flight Log Review
- Open a Github Issue with a flight report with as much detail as possible and links to logs.
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.
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/check_code_style_all.sh. 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.
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 <firstname.lastname@example.org>
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.