PX4 Dev Call: Feb 18, 2026 (Team sync, and Community Q&A)

farhang · February 17, 2026, 5:28pm

PX4 Sync / Q&A - 2026-02-18T16:00:00Z

Agenda

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

Announcements

Future Events

Flight Testing Update

github.com/PX4/PX4-Autopilot

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

opened 05:05PM - 14 Jan 26 UTC

mrpollo

## :exclamation: About 💡 For the upcoming v1.17 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.17 Release Notes](https://docs.px4.io/main/en/releases/1.17.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.17 pre-release 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 (01/01/26) 💪 **Release Testing** | Date | Status | Submitter | Release | Platform | Flight Controller | Flights / Logs | Notes | Link | | --------- | ------ | ------------ | -------------- | ---------- | ----------------- | -------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | | | | | | | |

Testing Issue Reports

Drone climbed unintentionally up to the ceiling

Release Discussion

v1.17.0-beta1

Given how the testing has been positive so far, we are going to promote the beta1 to rc1 before the next dev call.

Community Q&A / PRs for Review

Q&A/Discussion:

PRs:

Issues:

rroche · February 17, 2026, 7:41pm

PRs for Review / Updates (Ramon):

Introduce AGENTS.md for better context guidance, pointing to the right locations in our docs and updating our docs for up to date and accurate conventions. Looking for feedback.

S3 Stable Firmware Fix - Fixed the issue where QGC users got beta firmware when selecting “stable”. Tags no longer overwrite stable firmware in S3. Backported and merged to 1.17.

PX4 SITL .deb Package - New px4_sitl_sih board target with .deb packaging, composite build action, and hardened CI permissions. Looking for feedback.

#26495 - packaging: add PX4 SITL .deb package

Docs - README modernized, release process documented, Ubuntu/macOS dev env guides rewritten, docs CI orchestrator merged.

Other merged fixes:

CI Orchestrator - Consolidates all CI workflows into a 4-tier architecture with ccache and S3 caching across all jobs. Currently working on optimizing total run time from 60 min to under 20 min. VTOL/tailsitter SITL tests temporarily disabled while fixing test
reliability.

Firmware Manifest - Unified manifest bundled into .px4 files for release discovery. Adds label_pretty and firmware_category fields to board configs.

#25414 - tools: create firmware manifest

farhang · February 17, 2026, 11:03pm

github.com/PX4/PX4-Autopilot

module_base: remove CRTP template pattern to reduce flash bloat

main ← pr-module_base_remove_crtp

opened 03:08AM - 13 Feb 26 UTC

dakejahl

+1730 -1485

# Problem `ModuleBase<T>` uses CRTP (Curiously Recurring Template Pattern) to… give each module its own static storage (`_object`, `_task_id`) and to dispatch to per-module static functions (`task_spawn`, `custom_command`, `print_usage`). The cost is that the compiler instantiates a full copy of every `ModuleBase` static method (`main`, `start_command`, `stop_command`, `status_command`, `exit_and_cleanup`, `run_trampoline`, `wait_until_running`) for each of the ~97 modules — identical machine code repeated 97 times. # Solution Replace the `ModuleBase<T>` class template with a plain class `ModuleBase` and a `Descriptor` struct that holds the per-module function pointers and storage: ```cpp struct Descriptor { int (*task_spawn)(int argc, char *argv[]); int (*custom_command)(int argc, char *argv[]); int (*print_usage)(const char *reason); px4::atomic<ModuleBase *> object{nullptr}; int task_id{-1}; }; ``` All shared logic moves to a single `module_base.cpp` (~230 lines) linked once into `px4_platform`. Each module declares `static Descriptor desc{task_spawn, custom_command, print_usage}` and passes it to the shared static methods. A typed `get_instance<T>(desc)` accessor centralizes the `ModuleBase*` → `T*` downcast to one auditable line, replacing the old `get_instance()` that CRTP provided for free. ## Per-module migration (mechanical) ```diff - class Foo : public ModuleBase<Foo> + class Foo : public ModuleBase { + static Descriptor desc; ... }; - Foo::main(argc, argv) + ModuleBase::main(Foo::desc, argc, argv) - _object.store(obj) → desc.object.store(obj) - _task_id = id → desc.task_id = id - exit_and_cleanup() → exit_and_cleanup(desc) - get_instance() → get_instance<Foo>(desc) ``` Thread-based modules add a thin 3-line `run_trampoline` that wraps `instantiate()` in a lambda. Work-queue modules need no trampoline. # Results - **25.6 KB `.text` saved** on `ark_fmu-v6x_default` (1,959,320 → 1,933,680 bytes) - ~279 bytes per module - Clean build verified on `ark_fmu-v6x_default` and `px4_sitl_default` - Net **-488 lines** (2013 insertions, 1525 deletions) across 229 files # Commit structure 1. `module_base: claude rewrite to remove CRTP bloat` — the core solution applied to 5 example modules 2. `module_base: apply to all drivers/modules` — mechanical application to remaining ~92 modules 3. Commits 3–12: build fixes, formatting, remove old `ModuleBase<T>`, `get_instance<T>()` accessor, revert global clang-tidy suppression # Alternatives considered - **Keep CRTP, rely on LTO** — LTO does not fully eliminate template bloat on the embedded ARM toolchains used by PX4 - **Virtual function interface** — adds a vtable pointer per instance and runtime dispatch overhead; the descriptor pattern avoids per-instance overhead while sharing code

methodmissing · February 18, 2026, 4:09pm

Pixhawk 6X-RT standard alignment

Context

In the Pixhawk 6X-RT standard we noticed a recent commit that formally merged for sensor set 3
We have a Europe manufactured 6X-RT Flight Controller for which we’re wrapping up testing - due to stock unavailability of some BOM components we landed on sensor set 3 before that PR was merged. BUT have a change form the v3 sensor set for the Secure Element version (SE51 → SE52) (see page 14 of the PDF 6X-RT standard)

Questions

What are our options given the Secure Element change does not appear to risk altering flight dynamics. FMU Sensor U10 (SE) changed. We are using the Secure Element driver with SE051 and SE052 compatibility, different Applet versions, similar base API for our use cases). Sensor set 3.1? Or is this explicitly not allowed?

The trademark shall only be used for compliant products and in combination with a
signed adopter agreement.
Implementations of the standard must be compliant with the full specification.

Is Pixhawk Standard supported Board still an option for us given the Secure Element change? We’d rather start with Pixhawk Standard Board than Manufacturer Supported given the delta is small, if possible.
We can provide samples for testing regardless. Have been in communication with Gerald from NXP already.

Topic		Replies	Views
Hardware/Pixhawk Dev Call: Sept 10, 2019 Pixhawk	5	660	September 10, 2019
PX4 Dev Call: September 23, 2020 PX4 Autopilot	0	560	September 16, 2020
PX4 Dev Call: October 2, 2019 PX4 Autopilot	0	696	October 2, 2019
PX4 Dev Call: September 02, 2020 PX4 Autopilot	0	536	August 26, 2020
PX4 Dev Call: October 28, 2020 PX4 Autopilot	0	823	October 21, 2020