PX4 Dev Call: May 7, 2025 (Team sync, and Community Q&A)

rroche · May 6, 2025, 10:21pm

PX4 Sync / Q&A - 2025-05-07T00:00:00Z

Agenda

Announcements
Future Events
Flight Testing Update
Release Discussion
Bug Report / Q&A

Announcements

PX4 Release Testing
PX4 v1.16.0-rc1 is out, and we need your help with testing!

QGC v5.0.0-rc1 Alert
The QGC maintainer team has announced their release plans. The long-awaited fifth version of our favorite app is getting a revamp, including tons of architecture improvements, some UI/UX upgrades, and finally upgrading to Qt 6.0. Once more information is available, we will be distributing with everyone.

Next Dronecode Meetup

Nothing scheduled yet. If anyone is interested to host a Meetup please reach us out. Always happy to have it organized.

Question: Any interest in a Dronecode Community meetup during xponential?

Future Events

ICUAS May 14-17, Charlotte, USA
AUVSI Xponential May 19-22, Houston, Texas, USA
ROSCon 2025 Singapore: ROSCon 2025

Flight Testing Update

About the Test Team
The team at Ascend Engineering (Chicago). are running flight testing for the community.

How to reach out to the team

GitHub: Tag user @PX4/testflights
Discord: #flight-testing
Weekly on the PX4 Dev Call

How to Request Testing (GitHub)

Write down the steps to test your issue/pull request
- Make sure to note the risk involved in flying
- Write down things to look out for / anticipate - eg: “we are looking for no yaw jumps”
Add issue/pull request to the Flight Testing project board
Make sure to specify any hardware/software requirements as much as possible

Resources:

Comments / Discussion:

Release Testing

Date	Status	Release	Platform	FC	Notes	Link
5/3/25		Quadcopter	VMU-RT1176	rc1	Notes regarding firmware: In the firmware update menu I chose “beta”, QGC states firmware is 1.16.0beta not “RC”. General Reports: During Battery Failsafe testing, “issues” arise when setting failsafe levels and logic in handling voltage sag to activate critical failsafe. In a low battery situation, the time before battery warning, battery critical and emergency landing can be triggered if batteries have higher than normal voltage sag.	logs / video

Release Discussion / Updates

v1.16 Release Discussion

Release Candidate v1.16.0-rc1

The first release candidate for the upcoming release is finally available trough github and QGC.

We need help with flight testing, especially for early adopters and users with free time who can provide logs from flights with their drones.

Issue Reporting, and Flight Log sharing

If you find an issue/bug with the pre-release, please open a GitHub issue and include a flight review link of any relevant flight logs.
- Make sure you add the issue to the Release Project Board
- We review the project board at every weekly meeting.
Follow the instructions on this GitHub Issue to learn how to install and configure the latest pre-release version on your drone.
The same guide (link) has instructions on how to grab the log data and upload it to the flight review.

Release Blockers Discussion

ESC Calibration Issues (PX4-Autopilot #24635): There’s an inconsistency between analog and digital power modules; the interface between older and newer drivers implemented has a delta. You will receive a “unplug battery” error when trying the ESC calibration.

TODO: @MaEtUgR will update Don’s proposed changeset to cover other use cases. @AWilkins_Ascend will help with ESC testing.

Don’s proposed fix: Fix reporting of connected battery by DonLakeFlyer · Pull Request #24800 · PX4/PX4-Autopilot · GitHub

Unstable height estimates (PX4-Autopilot #24058): It seems the issue might be related to terrain. The inconsistency is between the checks for which sources the estimate is relying on. Maybe the checks or thresholds could be changed. The problem is two folded both on control and estimation side:
1- The control side also is that height estimated from distance sensor is not that tight.
2- Terrain estimate is not following the distance data.

adis16507 improvements (PX4-Autopilot # 24691: PR ready to go into main, looking to merge so we can backport.

Community Q&A / PRs for Review

SITL Test Updates: @JulianOes is looking into PX4’s SITL tests. Feedback from the call:

Let’s focus on making them reproducible locally with no extra gimmicks. This should help people debug locally.
If possible, make them simulator agnostic. Future proof!

rroche · May 6, 2025, 11:35pm

I have the following PRs and relevant discussions ready for the call

github.com/PX4/PX4-Autopilot

ci: introduce px4-dev container with multi arch support

main ← mrpollo/build_with_dev_container

opened 01:13AM - 22 Nov 24 UTC

mrpollo

+226 -106

Use the px4-dev container to build and publish all targets * builds x86, and …arm64 px4-dev images * conditional to changes in either **ubuntu.sh** or **requirements.txt** * updates **ubuntu.sh** for installing under both architectures * fixes a stringop-overflow issue with gcc > 12 * uses the px4-dev container to build the build matrix of all boards

github.com/PX4/PX4-Autopilot

docs: metadata scripts and ci

main ← mrpollo/docs_metadata

opened 08:45PM - 02 May 25 UTC

mrpollo

+575 -0

Fixes #24791 - [x] uORB Graphs Script - [x] uORB Graphs CI - [x] Failsafe …Simulator Script - [x] Failsafe Simulator CI - [x] uORB Messages Script - [x] uORB Messages CI - [x] Parameter Metadata Script - [x] Parameter Metadata CI - [x] Airframe Metadata Script - [x] Airframe Metadata CI - [x] Modules Metadata Script - [x] Modules Metadata CI ## uORB Graphs Our docs need this metadata to generate a pretty graph that shows you the connections between uORB messages and modules. **Example**: https://docs.px4.io/main/en/middleware/uorb_graph.html **Generator script** ``` metadata_uorb_graph.sh — generate, compare, and sync uORB graph JSONs Usage: ./scripts/metadata_uorb_graph.sh [--test-only] [--debug] Options: --test-only Run generation and comparison only; exit 1 if diffs found, without copying files --debug Echo debug info for missing or differing files Examples: # CI mode: fail if docs need updates ./scripts/metadata_uorb_graph.sh --test-only # Developer mode: regenerate and sync JSONs ./scripts/metadata_uorb_graph.sh ``` ## Failsafe Simulator Our docs needs this metadata to generate the web simulator, this allows you to simulate failsafes! **Example**: https://docs.px4.io/main/en/config/safety_simulation.html ``` metadata_failsafe_web.sh — build and sync failsafe webapp metadata files Usage: Tools/ci/metadata_failsafe_web.sh [--test-only] [--debug] Options: --test-only Run build and comparison; exit 1 if diffs found, without copying files --debug Show full build output and debug info for file comparisons and EMSDK install ``` ## uORB Message Reference Our docs need this metadata to generate reference docs for all uORB messages in PX4. **Example**: https://docs.px4.io/main/en/msg_docs/ **Generator script** ``` metadata_msg_docs.sh — generate and sync uORB message reference docs Usage: Tools/ci/metadata_msg_docs.sh [--test-only] [--debug] Options: --test-only Run generation and comparison only; exit 1 if diffs found, without copying files --debug Show full make output and debug info for file comparisons Examples: # CI mode: fail if docs need updates Tools/ci/metadata_msg_docs.sh --test-only # Developer mode: regenerate and sync docs Tools/ci/metadata_msg_docs.sh ``` ## Parameter Metadata Our docs need this metadata to generate a comprehensive parameter reference. **Example**: https://docs.px4.io/main/en/advanced_config/parameter_reference.html **Generator script** ``` metadata_parameters.sh — generate and sync PX4 parameter reference documentation Usage: Tools/ci/metadata_parameters.sh [--test-only] [--debug] Options: --test-only Run make target and comparison; exit 1 if diffs found, without copying file --debug Show full make output and debug info for comparison ``` ## Aiframe Metadata Our docs need this metadata to list and describe all supported airframes. **Example**: https://docs.px4.io/main/en/airframes/airframe_reference.html **Generator script** ``` metadata_airframe.sh — generate and sync PX4 airframe reference documentation Usage: Tools/ci/metadata_airframe.sh [--test-only] [--debug] Options: --test-only Run make target and comparison; exit 1 if diffs found, without copying file --debug Show full make output and debug info for comparison ``` ## Module Metadata Our docs need this metadata to provide up-to-date reference for all PX4 modules. **Example**: https://docs.px4.io/main/en/modules/modules_main **Generator script** ``` metadata_modules.sh — generate and sync PX4 module reference documentation Usage: Tools/ci/metadata_modules.sh [--test-only] [--debug] Options: --test-only Run make target and comparison; exit 1 if diffs found, without copying files --debug Show full make output and debug info for file comparisons ```

github.com/PX4/PX4-Autopilot

Firmware builds manifest

opened 01:04AM - 06 May 25 UTC

mrpollo

feature-request

I propose an upgraded workflow for delivering firmware releases that everyone co…uld leverage to download any given PX4 release reliably. **Our current approach is as follows:** * The PX4 team automates the build of releases and uploads artifacts (*.px4 files) to an S3 bucket in one of three folders. 1. When creating a new release, build all board targets and variants 2. Grab all artifacts, including metadata, and upload to an S3 bucket 3. The S3 bucket has three main directories * **master**: daily builds from the main branch. "master" is the previous name of the main branch. * **beta**: any non-stable release tag, for example: v1.16.0-rc1, v1.16.0-beta1, v1.16.0-alpha1 * **stable**: only fully tagged releases, for example: v1.16.0, v1.15.4, v1.15.0 * QGC has a hardcoded link to the S3 bucket and knows where to pull data for stable, beta, and daily releases/builds. * Whenever a user chooses to install a PX4 release, QGC can only offer the latest release for each category. Stable releases, beta releases, or daily ones. (Not taking into account flashing by file) While this approach is simple, it brings a few caveats that should be addressed. * No flexibility, we are only offering a single build per board, even though we build the whole variant matrix for a target, those binaries largely go unused. * If we ever decide to split the default builds into per-vehicle types, the current approach won't scale. * We are already facing this with the rover builds; users must download binaries themselves. * Can only install the latest stable, beta, or daily version. If a user wants to pick a previous version of the firmware (for whatever reason), they need to build it themselves and flash it. * No archive of previous release artifacts available. **Keeping track of artifacts** We need to provide a mechanism for the consumers of PX4 build artifacts (binaries) that pairs metadata, like release version, checksum verification for file downloads, and any other relevant information, such as the vehicle type designation. Work in this area started [in 2016 by Don](https://github.com/mavlink/qgroundcontrol/issues/2797), who was trying to overhaul the firmware upgrade process within QGC. While Ardupilot introduced a manifest, the PX4 project never moved in this direction. Now that we have moved from Jenkins to GitHub actions for release artifacts, it’s likely a good opportunity to move in this direction, by building on top of the infrastructure we set in place. **My proposal is as follows:** * Create a manifest that captures all the relevant build variants and their metadata, and host somewhere publicly accessible * Consumers of the manifest (such as QGC) would then parse this manifest and be able to get a list of builds available * This manifest should be search-friendly, no need to parse for hundreds of variants, when all you need is the latest stable firmware for Pixhawk 6X for a copter. * The manifest will contain URL information for where to download the binaries, their metadata, and also what the hash signatures (sha256sum) of any linked files is for validation. * **Optional**: it’s likely a good idea to build a mechanism for displaying relevant information back to the user for a given build, for example “This is an experimental board”, “Upgrade QGC to latest”, in an effort to provide instructions or important information. Given this is a huge undertaking requiring coordination of multiple stakeholders, I propose breaking up the work in stages. **Stage 1** - Investigate what the proper schema should be for a manifest - Collect all the relevant metadata - Propose a file format and hierarchy for the data - Work with possible consumers and stakeholders - QGC / MAVSDK - Discuss possible impact with hardware manufacturers - Seek buyin and feedback from PX4 maintainers - Update our tooling to support the generation of the manifest (outside of CI) - Validate the output of our tooling - Decide where and when these manifest(s) should be created and hosted - Most likely, append to the upgraded artifact release workflow in GitHub Actions **Stage 2** - Embed the manifest generation into our CI infrastructure - Work with QGC and MAVSDK developers to implement our manifest-based firmware distribution. - Write proper tests to guarantee schema compliance. - User Testing by developers and the flight test team. **Stage 3** - Ship the upgraded firmware distribution to a stable release of QGC / MAVSDK - User Testing by developers and the flight test team. **Relevant Resources** * #10676 & #19848 by @junwoo091400 * https://github.com/mavlink/qgroundcontrol/issues/2797 * [Ardupilot manifest](https://firmware.ap.ardupilot.org/manifest.json.gz) supported by QGC

Louismax · May 7, 2025, 7:01am

Hi

I have this PR for the shared repository PX4-GPSDrivers between QGroundControl and PX4 Autopilot.
These changes concern the Septentrio Gps driver and enable information from the base station to be displayed when it is connected to QGC.

github.com/PX4/PX4-GPSDrivers

Improve base station configuration

main ← Louis-max-H:pr-base-station-px4

opened 08:15AM - 18 Apr 25 UTC

Louis-max-H

+64 -21

This PR contains improvement regarding : - Add base station information using P…VTGeodetic messages. - Re-order sbf message definition in a more cleaver way. - Return special ret code when receiving message for base station infos to avoid timeout for the receiver. These changes are part of another PR on QGC to add a base station configuration menu.

Topic		Replies	Views
PX4 Sync / Q&A: Aug 7, 2024 PX4 Autopilot	0	58	August 6, 2024
PX4 Sync / Q&A: Mar 05, 2025 PX4 Autopilot	4	105	March 5, 2025
PX4 Sync / Q&A: July 3, 2024 PX4 Autopilot	0	117	July 3, 2024
PX4 Sync / Q&A: Nov 6, 2024 PX4 Autopilot	1	103	November 6, 2024
PX4 Dev Call: November 04, 2020 PX4 Autopilot	1	983	November 4, 2020

PX4 Sync / Q&A - 2025-05-07T00:00:00Z

Agenda

Announcements

Next Dronecode Meetup

Future Events

Flight Testing Update

Release Discussion / Updates

Community Q&A / PRs for Review

Related topics