system
August 31, 2026, 10:01am
1
2026-09-02T15:00:00Z This week: 99 PRs merged | 116 awaiting review | 0 new bugs
PX4 Developer Summit at Open Source Summit Europe, Prague, Czechia, 7–9 October 2026. Speakers announced; full schedule and PX4 track filter here:
Updates:
opened 05:45PM - 26 May 26 UTC
status:needs-testing
scope:release
## :exclamation: About
💡 For the upcoming v1.18 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.17 is right for you.
- [v1.18 Release Notes(Link TBD)](https://docs.px4.io/main/en/releases/1.18.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.18 pre-release firmware
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 "Beta 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.18 alpha 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.
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 (Date TBA)
**Release Testing**
main ← pr-nuttx-12-12-0
opened 02:00PM - 05 Jan 26 UTC
Continuation of #26198 but now the NuttX repo's are on the PX4 repositories.
So… me reasons why to upgrade NuttX
- Last upgrade was more then 3 years ago Aug 10, 2022
- I3C Support has been added
- RPmsg support for heterogenous MCU's
- GDBStub support (for debugging over Serial/Ethernet)
- C/C++ atomic support has been improved
- Network stack got improved
- Optional run-time stackchecking on IRQ/Context switch (useful for debugging)
- CMake support (not the focus on this PR, but allows us to cleanup the build system).
- Better RISC-V/Xtensa support.
# PX4 Test Plan
| **Category** | **Boot & Flash** | **SD Card** | **CAN/UAVCAN** | **Radio** | **Modes** | **Parameters** | **Ethernet** | **XRCE-DDS** | **USB/QGC** | **Hardfault Logging** | **CPU Load** | **Publication Rates** | **Mavlink** |
|-------------------|------------------------------------|-----------------------------------------|-----------------------------------------|---------------------------|-----------------------------------------|-----------------------------------------|----------------------------------------------|-----------------------------------------------|--------------------------------------------|--------------------------------------|----------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|
| **Description** | Flash PX4 firmware and verify boot | Run `sd_bench` and measure write speed | Check UAVCAN node and CAN1 status | Bind and verify RC input | Arm in Stabilized mode, verify leveling | Change parameters and reset to defaults | Verify Ethernet connectivity | Receive visual odometry messages via XRCE-DDS | Verify USB connection and QGC link | Trigger and verify hardfault logging | Run `top` when the system is armed | Run `uorb top` when the system is armed | Run `mavlink status` |
| **Expectation** | PX4 boots without errors | Check Avg ≥ 400 KB/s, max write ≤ 50 ms | No HW/IO errors, RX/TX frames increment | RC channels update in QGC | Craft attempts to level (bench OK) | Changes persist, reset works | PX4 responds to pings, MAVLink over Ethernet | VO messages visible in PX4 logs | QGC connects and parameters sync correctly | Hardfault log saved and retrievable | CPU load is similar | Publication rates | TX/RX rate and latency for all MAVLink instances |
| **CUAV V6X** | Okay | Okay | Okay | Okay | Okay | Okay | Okay | Okay | | | | | |
| **Pixhawk 6X** | | | | | | | | | | | | | |
| **Pixhawk 6X-RT** | | | | | | | | | | | | | |
main ← mrpollo/macos-pin-gz-tap
opened 07:09PM - 19 Aug 26 UTC
## Summary
Adds a `--ci` flag to `macos.sh` that pins the `osrf/simulation` tap… to a revision where the Gazebo formulae still ship bottles, so CI installs binaries instead of compiling Gazebo from source.
## Problem
When homebrew-core bumps a shared dependency the gz bottles are ABI-broken, and OSRF's bot strips every `bottle do` block within minutes of the upstream merge. The rebuild is a separate, unautomated step that lands days later: across 2026 the gap ran 0.5 to 11 days, median 2.5, leaving gz unbottled roughly 18% of the time.
In that window seven gz formulae build from source and the `setup` step goes from ~8min to 20-30min. It never fails, so it shows up as latency rather than a signal.
## Solution
The removal only edits the formula. The bottle tarballs are never deleted from OSRF's S3, so pinning to the last fully bottled revision keeps the install binary while upstream catches up. The pin lives in `Tools/setup/gz-tap-pin.txt`, and a follow-up will add a bot that advances it whenever OSRF publishes a newer bottled state.
Gated behind `--ci` rather than applied unconditionally. Automation wants a reproducible, fast install; development machines want the current formulae, can absorb a source build, and should not have their tap left on a detached HEAD as a side effect of running the setup script. `compile_macos.yml` passes the flag; nothing else changes for anyone running `macos.sh` by hand.
Only the gz tap is pinned. `opencv@4`, `protobuf`, `gstreamer` and the rest still track homebrew-core, so per-PR runs keep catching upstream formula breakage, which is the reason `--sim-tools` is in CI. `HOMEBREW_NO_AUTO_UPDATE=1` is set after a successful pin because `brew update` walks local taps and would otherwise reset it; a failed pin warns and continues on tap HEAD.
## Result
Measured against a concurrent unpinned run on another branch, with the upstream outage active in both:
| | setup step | gz formulae built from source |
|---|---|---|
| unpinned (run 32277742159) | 22.1m / 19.4m | 8 |
| pinned (this PR) | 11.2m / 10.2m | 1 |
The remaining source build is `gz-harmonic` itself, a metadata-only meta-formula that is never bottled and takes ~15s.
main ← mrpollo/docs-macos-dev-env-refresh
opened 08:13PM - 19 Aug 26 UTC
## Summary
The macOS dev environment page (`dev_env_mac.md`) has not been edite… d since 2026-04-20, while `Tools/setup/macos.sh` changed five times after that (#27148, #27509, #27750, #27891, #28198). This brings the page back in line with the script, stops it from enumerating script internals so it does not drift again, and fixes four linked pages that contradict it. Docs only.
## Problem
Verified against the script, the Homebrew taps, and the last 15 macOS CI runs:
- The page says `--sim-tools` installs the `px4-sim` formula and tells users to add simulation later with `brew tap PX4/px4 && brew install px4-sim`. `px4-sim` has been a `deprecate!` no-op in PX4/homebrew-px4 since 2026-04-20 and installs nothing. On Homebrew 6.0+ it does not even load, because the page never mentions the tap trust the script now performs (`Refusing to load formula ... from untrusted tap`).
- The page lists specific taps and packages from the script. That list is exactly what went stale: it misses the `osrf/simulation` and `discoteq/discoteq` taps, the `opencv@4` pin, and the automatic XQuartz and JDK install under `--sim-tools`, and it still shows XQuartz as a manual step. `--sim-tools` also prompts for `sudo`, which the page does not warn about.
- `simulation/index.md` still lists Gazebo on Apple Silicon as "Unstable (known issues)" and steers macOS users to SIH; that row predates the 2026-04-20 fix (#27148), which verified `make px4_sitl gz_x500` on macOS 26 / Harmonic 8.11. CI has compiled `gz_bridge` against brew `gz-harmonic` on both `macos-latest` and `macos-15` since #28276, and no macOS Gazebo issue has been filed since April.
- `dev_env.md` supported-targets table claims Gazebo Classic SITL on macOS. Nothing in `macos.sh` installs it, and Gazebo Classic is past EOL.
- `sim_jmavsim/index.md` says Java must be installed manually on macOS; `macos.sh --sim-tools` has installed and linked a JDK since #26672.
- `building_px4.md` recommends `ulimit -S -n 300` while the mac page says 2048, and tells users to "run" `Tools/mac_set_ulimit.sh`, which as an executed script cannot change the caller's shell limit.
## Solution
- `dev_env_mac.md` no longer lists packages, taps, or versions. It says in one sentence what the script installs, points at `macos.sh` as the source of truth, and documents only user-facing behaviour: `--sim-tools` brings Gazebo, XQuartz and a JDK and needs `sudo`; taps are trusted for Homebrew 6; re-running `macos.sh --sim-tools` is how you add simulation later. The Python prerequisite is dropped since the script installs Python and creates the venv itself. Notes that CI covers Apple Silicon only.
- Flip the `simulation/index.md` macOS row to "Works (via Homebrew)" and drop "or macOS" from the SIH recommendation.
- Remove the Gazebo Classic macOS tick in `dev_env.md`.
- Point the jMAVSim page at `macos.sh --sim-tools`, keeping the manual Java steps as the fallback.
- Align `building_px4.md` on 2048 and `source Tools/mac_set_ulimit.sh`.
Not verified and left as-is: whether XQuartz is actually required by Gazebo Harmonic's GUI (the gz tree depends on `libx11` from homebrew-core, not on the cask; nobody has tested without it), and the Intel claim (no CI coverage). One code follow-up surfaced but is out of scope here: the "Gazebo dependencies not found" fallback target in `gz_bridge/CMakeLists.txt` is dead code since #25829, so `make px4_sitl gz_x500` without gz libs yields ninja "unknown target" instead of the intended message (#28298).
No builds run for this PR; the changes are Markdown only and the compile workflows ignore `docs/**`.
Issues:
Decisions:
PX4 Dev Summit (Devs dinner arrangement)
Flight test updates
Nuttx Upgrade PR
99 PRs merged this week →
116 PRs awaiting review →
7 new issues →
