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

rroche · May 13, 2025, 3:46am

PX4 Sync / Q&A - 2025-05-14T15:00:00Z

List of all Dronecode events

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
TODO: @mrpollo needs to reach out to @DonLakeFlyer for an update

Side note: In case you want to add features to this release, you better bring them up within this week.

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

ROS Aerial Robotics WG May 22, Online
- Presentation: A Neural Network Mode for PX4 on Embedded Flight Controllers by Mihir Kulkarni, NTNU
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 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.

Release Testing

Testing Tracker

github.com/PX4/PX4-Autopilot

[v1.16 Release Candidate] - Flight Testing & Flight Issues (log archive)

opened 04:08PM - 08 Jan 25 UTC

mrpollo

bug-report

## :exclamation: About 💡 For the upcoming v1.16 release, we are asking the Commu…nity for flight tests. This issue will be used for keeping track of all the tests from the Community. If you're unsure about upgrading, please read the preliminary release notes on the PX4 docs. Pay close attention to the Upgrade Guide before deciding if v1.16 is right for you. - [v1.16 Release Notes](https://docs.px4.io/main/en/releases/1.16.html) ## ❓ Why we need flight testing 🌏 Thousands of people around the world depend on the stable release of PX4. 🖐️ Before every major release, as much testing as possible is needed to ensure that our release actually works! 😯 Simply said, **more testing = better release** 🤗 We would like to encourage every community member to join us in improving PX4! ## 🤷 How you can help with flight testing 😱 Even if you have never contributed a flight testing report, fear not! Please follow the steps below for the details of how you can contribute to flight testing. 1. **Select** a category from the "flight testing matrix" below 1. **Flash** the firmware (documented below) 1. **Test** 1. **Upload** the log (documented below) 1. **Report** the test in this issue thread! ## Test Procedures https://docs.px4.io/main/en/test_and_ci/test_flights.html ### How to flash v1.16 beta firmware ![beta_flashing](https://user-images.githubusercontent.com/23277211/230138126-c7b02c00-f07b-4a4f-b6b7-866d69db6520.png) 1. Open QGC 3. Click the Q icon on upper right > Vehicle Setup > Firmware (Step 1 in picture) 4. Connect your flight controller to the computer 5. When the Firmware setup window pops up, click "Advanced settings" checkbox 6. Select "Beat Testing (beta)" from the drop down (Step 2 in picture) 7. Click "Ok" This should automatically flash & reboot your flight controller with the latest v1.16 beta release! ### How to share your log First, retreive the log from the flight controller in QGC Q icon > Analyze Tools > Log Download, and find the log you want to download. ![log_uploading](https://user-images.githubusercontent.com/23277211/230143915-4dad89ec-ab6d-43f3-9e5f-7a4624faa56e.png) Then: 1. Go to https://logs.px4.io/ 2. Click on "Flight Report" tab (this allows public viewing of the log in the [browse page](https://logs.px4.io/browse)) 3. Add the ULog file 5. Fill in the description, feedback, and video URL (if available) 6. Click "Upload" 7. Copy and paste the link of the log, and share it to this thread When posting on this thread, please mention what kind of test it was (especially if it is one of the testing matrix options) & general info behind it! ## Questions? Feel free to ask any questions regarding flight testing in the #dev-team channel in the [discord server](https://discord.gg/dronecode)! ## Results (05/12/25) 💪 **Release Testing** | Date | Status | Submitter | Release | Platform | Flight Controller | Flights / Logs | Notes | Link | | --------- | ------ | ------------ | -------------- | ---------- | ---------------------------------------------------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | 1/16/2025 | ❌ | afwilkin | v1.16.0-alpha1 | Quadcopter | Pixhawk 4 | 2 | | [Link](https://github.com/PX4/PX4-Autopilot/issues/24188#issuecomment-2596594336) | | 1/23/2025 | ✅ | afwilkin | v1.16.0-alpha1 | Quadcopter | Pixhawk 4 | 2 | | [Link](https://github.com/PX4/PX4-Autopilot/issues/24188#issuecomment-2611482935) | | 1/29/2025 | ✅ | afwilkin | v1.16.0-alpha1 | Quadcopter | Pixhawk 4 | 6 | | [Link](https://github.com/PX4/PX4-Autopilot/issues/24188#issuecomment-2622581014) | | 1/29/2025 | ✅ | afwilkin | v1.16.0-alpha1 | Quadcopter | Pixhawk 4 | 2 | | [Link](https://github.com/PX4/PX4-Autopilot/issues/24188#issuecomment-2622581014) | | 2/10/2025 | ✅ | afwilkin | v1.16.0-alpha1 | Quadcopter | Pixhawk 4 | 5 | | [Link](https://github.com/PX4/PX4-Autopilot/issues/24188#issuecomment-2649177017) | | 3/5/2025 | ✅ | DroneWuKong | v1.16.0-rc1 | Quadcopter | [VMU-RT1176](https://docs.px4.io/main/en/flight_controller/nxp_mr_vmu_rt1176.html#nxp-mr-vmu-rt1176-flight-controller) | 11 | | [Link](https://github.com/PX4/PX4-Autopilot/issues/24188#issuecomment-2851994468) | | 9/5/2025 | ✅ | afwilkin | v1.16.0-rc1 | Quadcopter | Pixhawk 6C | 2 | | [Link](https://github.com/PX4/PX4-Autopilot/issues/24188#issuecomment-2867864092) | | 9/13/2025 | ✅ | TeddyZaremba | v1.16.0-rc1 | Quadcopter | VOXL 2 | 8 | [Precision landing issue](https://github.com/PX4/PX4-Autopilot/issues/24850) | [Link](https://github.com/PX4/PX4-Autopilot/issues/24188#issuecomment-2880662926) |

Testing Matrix

Date	Submitter	Release	Platform	Flight Controller	Flights / Logs	Notes	Link
1/16/2025	afwilkin	v1.16.0-alpha1	Quadcopter	Pixhawk 4	2		Link
1/23/2025	afwilkin	v1.16.0-alpha1	Quadcopter	Pixhawk 4	2		Link
1/29/2025	afwilkin	v1.16.0-alpha1	Quadcopter	Pixhawk 4	6		Link
1/29/2025	afwilkin	v1.16.0-alpha1	Quadcopter	Pixhawk 4	2		Link
2/10/2025	afwilkin	v1.16.0-alpha1	Quadcopter	Pixhawk 4	5		Link
3/5/2025	DroneWuKong	v1.16.0-rc1	Quadcopter	VMU-RT1176	11		Link
9/5/2025	afwilkin	v1.16.0-rc1	Quadcopter	Pixhawk 6C	2		Link
9/13/2025	TeddyZaremba	v1.16.0-rc1	Quadcopter	VOXL 2	8	Precision landing issue	Link

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): NEEDS DISCUSSION ON CALL → May have a solution till end of the call. Needs high level change.

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): NEEDS DISCUSSION ON CALL

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

Community Q&A / PRs for Review

Precision landing issue: The issue is it shut up during precision landing. @Teddy will post an issue for it.

Q1: @slgrobotics Is there a plan/intend/thought to support for such “generic” RPi configurations?
A: @rroche It will be appreciated if the work wants to be put in and we can maybe introduce different tiers of support.

Discussed PRs:

ci: use dev-container for nuttx targets by alexcekay · Pull Request #24832 · PX4/PX4-Autopilot · GitHub. As this is merged then @Sindre could rebase the PR and hopefully it fixes the issues.
https://github.com/PX4/PX4-Autopilot/pull/24022 mentioned while discussing number 1.
MARSH dialect for crewed flight simulators by Maarrk · Pull Request #2272 · mavlink/mavlink · GitHub

Discussed Issues:

Firmware builds manifest · Issue #24806 · PX4/PX4-Autopilot · GitHub → Comes from an old topic discussion on QGC forum to have manifests settled well and simplified. Besides, there are possible chances to have vehicle specific targets for the upcoming future release.

SITL Test Updates: by @JulianOes (May 13th, 2025)

Been working on it today, pushing some things tomorrow to use latest MAVSDK. Some mutex deadlocks can happen within mavsdk that I need to fundamentally solve, independently of the tests.

github.com/mavlink/MAVSDK

Fixing thread sanitizer issues

main ← pr-tsan

opened 09:06AM - 16 Apr 25 UTC

julianoes

+517 -266

I played around with thread sanitizer and tried to fix at least some of the issu…es it came up with. I also cherry-picked the two commits from #2526 but eventually decided against it, and instead switched to `std::recursive_mutex` and `std::list`. See some of the last commits for that. The good news is that I think I finally squashed the system_test failures that we kept having on macOS.

github.com/mavlink/MAVSDK

Add incoming and outgoing message queue, fixing threading/locking issues

main ← pr-threading

opened 01:28AM - 14 May 25 UTC

julianoes

+355 -169

This is a bigger refactor where we no longer do work from the receiver threads b…ut instead copy messages into a queue and work on them subsequently. This is an attempt to prevent deadlocks where locks are acquired in different orders. Additional, there are various small fixes to make all system and unit tests pass in address sanitizer and thread sanitizer. I need to review this with fresh eyes again tomorrow. Follow up to #2542

Sindre · May 14, 2025, 11:00am

I would love some help/discussion with what I can do to make this pass CI and make it mergeable. And if anyone can tell me if the CI GCC is indeed upgraded to 13.2.

github.com/PX4/PX4-Autopilot

Neural Control Mode

main ← SindreMHegre:neural_control_with_tflm

opened 12:23PM - 19 Feb 25 UTC

SindreMHegre

+3024 -27

### Solved Problem Using neural networks for various tasks on UAVs in research …is becoming more and more commonplace. My aim is to provide a module that can be used to replace the MC controller with NN to lower the barrier for using RL and NN on UAVs in general, and give researchers and hobbyist a place to start for NN use. ### Solution - Add TensorFlow Lite Micro as an inference lib into PX4 - Make custom board configs with neural controllers - Make a module for NN control ### Changelog Entry For release notes: ``` Feature: Neural control mode for PX4, with possibility to use your own neural networks. New parameters: MC_NN_EN, MIN_RPM, MAX_RPM, THRUST_COEFF Documentation: read docs.px4.io/advanced/neural_networks, tflm and nn_module_utilities ``` ### Alternatives We could also look into using Eigen or executorch ### Test coverage - Built and tested SITL with the x500 https://review.px4.io/plot_app?log=52502d02-009e-4d1f-baac-a49dd51cfdef (check neural_control topic) - Built and tested HITL with pixracerpro and jMAVSim Hitl, note that the sim itself seemed a bit unstable and the network is not optimized for this model. https://review.px4.io/plot_app?log=43d2ba6c-3d05-4d7f-a31b-490a57b3e647 - Tested live on ARL LMF model: https://review.px4.io/plot_app?log=d101189d-672e-42a3-9d39-828c675dde57 https://www.youtube.com/watch?v=lY1OKz_UOqM&t=1s https://arxiv.org/abs/2505.00432 ### Context Other feature requests: - Put in different controller parameters with possibilities to replace different parts: Full e2e, only control, only allocation, Allocation and control as two separate networks. - Script to give thrust and delay parameters from a flight log

rroche · May 14, 2025, 2:38pm

For discussion

github.com/PX4/PX4-Autopilot

ina228/ina238: correctly set ADC range, and a few fixes

main ← pr-ina-adcrange-fix

opened 12:47AM - 14 May 25 UTC

julianoes

+51 -5

It turns out that we set the ADC range incorrectly leading to the measured curre…nt being capped at a certain level as the ADC on the sensor saturates. Instead, we need to set the range according to the formula given in the interface datasheet. ![image](https://github.com/user-attachments/assets/38971f9d-f936-48f9-a71d-d60db7fe40e9) https://www.ti.com/lit/ds/symlink/ina228.pdf https://www.ti.com/lit/ds/symlink/ina238.pdf

github.com/PX4/PX4-Autopilot

ci: use dev-container for nuttx targets

main ← pr-build-with-dev-container

opened 11:38AM - 12 May 25 UTC

alexcekay

+8 -5

## Change This PR changes all CI workflows that previously used a NuttX contain…er to use the new dev container. Build all targets was tested here: https://github.com/PX4/PX4-Autopilot/actions/runs/14972290755/job/42055844601?pr=24832 **FLASH savings on v5x and v6x are ~44K** ## Open topics ### Tagging strategy As there is no `latest` or `stable` of the dev container yet, I used the most updated dev container. This would thus require updates when new dev containers are created in the future. **Is there a container tagging strategy yet?** Just adding `latest` automatically on each dev container build workflow run is not a complete solution as this would also trigger when creating a RC for an old PX4 release. I see the following options: - Have some magic in the workflow that sets `latest` to the highest SemVersion - Manually set a `latest` or `stable` tag for the dev container @mrpollo: Can you manually create a new updated dev container that we can reference in this PR? Or do you guys prefer another strategy. ### Checks not working **Fail 1:** https://github.com/PX4/PX4-Autopilot/actions/runs/14971242279/job/42052457639?pr=24832 This seems to be fixable by adding a safe directory. Does not depend on GCC as it also fails when using the old GCC, thus related to the newer git contained in the dev container. **Fix is contained in this PR**. **Fail 2:** https://github.com/PX4/PX4-Autopilot/actions/runs/14971242273/job/42052457618?pr=24832 This seems harder to fix, had a look, but don't see the reason yet. Seems to be a problem with the new version of `gcov`, so no visible functional problem. **This needs to be fixed in a separate PR as it will require a deeper investigation. Thus I did not use the dev container in the checks.yml.** ### Flash Analysis not working https://github.com/PX4/PX4-Autopilot/actions/runs/14971242276/job/42052457576?pr=24832 Known problem with some GCC versions, see here: https://github.com/google/bloaty/issues/362 Easiest fix is not displaying `compileunits` but `symbols` instead. The output will then look like this, which is as helpful as the previous one in my opinion: ``` FILE SIZE VM SIZE -------------- -------------- +0.0% +296 +0.0% +296 .text +0.8% +1.29Ki +0.8% +1.29Ki g_cromfs_image [NEW] +152 [NEW] +152 land_detector::RoverLandDetector::RoverLandDetector() [NEW] +122 [NEW] +122 land_detector::RoverLandDetector::_update_topics() [NEW] +120 [NEW] +120 commands.26190 +8.2% +60 +8.2% +60 AirspeedValidator::check_first_principle() ``` **Fix is contained in this PR**.

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

Topic		Replies	Views
PX4 Dev Call: April 15, 2020 PX4 Autopilot	1	491	April 15, 2020
PX4 Dev Call: May 7, 2025 (Team sync, and Community Q&A) PX4 Autopilot	2	80	May 7, 2025
PX4 Maintainers Call: April 04, 2023 PX4 Autopilot	3	588	April 12, 2023
PX4 Sync / Q&A: Mar 05, 2025 PX4 Autopilot	4	102	March 5, 2025
PX4 Dev Call: March 23, 2022 PX4 Autopilot	0	618	March 16, 2022

PX4 Sync / Q&A - 2025-05-14T15:00:00Z

Agenda

Announcements

Next Dronecode Meetup

Future Events

Flight Testing Update

Release Discussion / Updates

Community Q&A / PRs for Review

Related topics