PX4 Autopilot Release v1.17: What You Need To Know

PX4 Autopilot has released stable version v1.17.0, a release that tightens PX4’s grip on the modern robotics stack: cleaner ROS 2 control surfaces for planes and rovers, a Zenoh middleware that finally behaves like a real ROS 2 citizen, a new multicopter flight mode, safer fixed-wing takeoffs, on-device neural network control, and a wave of new high-end inertial and GNSS hardware support.

The headline changes: Altitude Cruise mode for multicopters, a Fixed-Wing Takeoff that survives navigation loss, first-class fixed-wing and rover setpoints in the PX4 ROS 2 Control Interface, a Zenoh middleware that shakes hands with rmw_zenoh, an experimental neural-network control path running TensorFlow Lite Micro on-device, and three new INS driver families (MicroStrain, sbgECom, EULER-NAV). Let’s dig in.

Link to the full release notes.

Altitude Cruise Mode for Multicopters

For long-distance, single-heading flights, v1.17 introduces a new Altitude Cruise Mode for multicopters. The pilot commands tilt with the roll and pitch sticks, yaw rate with the yaw stick, and climb rate with the throttle. When the sticks are released the vehicle holds the current tilt and heading rather than returning to level, so it keeps cruising at a steady velocity instead of decelerating to a stop the way Altitude mode does. Once the tilt is balanced against wind resistance the vehicle settles into a constant-velocity cruise, which is much closer to how you’d actually want to ferry a multicopter across distance.

Note that the manual-control-loss failsafe can optionally be disabled for this mode via COM_RCL_EXCEPT. If you do that, configure the data-link-loss failsafe via NAV_DLL_ACT so you don’t trade one problem for a fly-away.

Link to Altitude Cruise Mode documentation.

Fixed-Wing Takeoff Continues Climb Through Position Loss

Fixed-Wing and Rover ROS 2 Setpoints

The PX4 ROS 2 Control Interface gets proper support for planes and rovers. Before v1.17, the only way to fly a fixed-wing from a ROS 2 node was offboard mode with TrajectorySetpoint, a message designed for multicopters that asks for position and velocity in a fixed frame, but planes don’t fly that way. 

The new FwLateralLongitudinalSetpointType matches how a plane actually moves. A ROS 2 node can command lateral behavior (course, airspeed direction, or lateral acceleration) and longitudinal behavior (altitude or climb rate, plus airspeed) as separate inputs, and PX4 keeps the two axes decoupled while enforcing vehicle limits. VTOLs benefit too: external modes can now command transitions through the same interface instead of going through MAVLink.

Plus, rovers get the same treatment now too. The v1.16 rework gave Ackermann, differential, and mecanum builds dedicated controllers, but v1.17 exposes them to ROS 2 through RoverSetpointTypes covering position, speed, attitude, rate, throttle, and steering. Each type is a pre-validated combination, so a planning node can say “drive to this point at this speed” without worrying that a field will be silently dropped on a differential chassis but honored on an Ackermann one. The deprecated legacy rover module is gone, keeping the interface coherent. The Rovers Apps & API docs cover the full picture.

Check out the log from the demo video

Link to PX4 ROS 2 Control Interface docs

Zenoh Matures Toward rmw_zenoh Compatibility

PX4 added an in-tree Zenoh module in v1.16, but it couldn’t quite shake hands with rmw_zenoh: serialization formats differed, the ROS 2 graph couldn’t see PX4, and getting a vehicle into ros2 topic list took workarounds. v1.17 closes the gap. CDRv1 serialization matches ROS 2, the transport lease is 60 seconds to match ROS 2 defaults, experimental liveliness makes the graph populate, and Rmw attachment code is split into rmw_attachment.h. A PX4 vehicle on Zenoh now appears in a ROS 2 stack running rmw_zenoh like any other node.

Also, configuration got a usability pass: Zenoh config is auto-generated from dds_topics.yaml, there’s a Domain ID parameter, and the CLI gained instance selection, pub/sub deletion, and better status output. Zenoh ships in the default firmware on FMU-v6xRT (make px4_fmu-v6xrt_default) and as an opt-in zenoh variant on FMU-v6x and SITL (make px4_fmu-v6x_zenoh, make px4_sitl_zenoh). It’s also compiled in by default on nxp/mr-canhubk3, nxp/mr-tropic, and nxp/tropic-community.

The older uXRCE-DDS bridge isn’t going away. It picks up asimple index-based namespace parameter (UXRCE_DDS_NS_IDX) for cleaner multi-vehicle setups, plus new DDS topics for ADS-B TransponderReport, landing gear commands, wind, gimbal device attitude, and the fixed-wing high-level setpoint and configuration interfaces.

Link to Zenoh on PX4 docs.

Neural Networks on the Flight Controller (Experimental)

PX4 v1.17 adds an initial MC Neural Network Control test path that runs a learned controller directly on the flight controller. The infrastructure integrates TensorFlow Lite Micro (TFLM) on-device, so a network trained externally (for example with reinforcement learning in Aerial Gym) can be loaded as a tflite model and substituted for the multicopter controller. It is exposed as a new flight mode, so you can switch back to the classical, well-tuned stack at any time.

This is a research and bench-testing path, not a replacement for the production controller. The intent is to give the community a real way to experiment with learned policies on actual hardware, with all of PX4’s safety nets still in place. If you’re doing research on non-traditional drone morphologies or learning-based control, this is now a much shorter path from simulator to flight.

Link to MC Neural Network Control docs.

New INS, GNSS, and Sensor Drivers

PX4 v1.17 broadens the pool of supported high-grade inertial and navigation hardware, which matters most for operators flying in conditions where consumer-grade IMUs and GNSS aren’t enough: GNSS-degraded environments, long-endurance fixed-wing, or platforms that need certified-grade attitude estimation. Three new INS families come into the ecosystem this release, alongside expanded GNSS resilience reporting and several smaller sensor additions.

New INS driver families

• MicroStrain Inertial Sensors get a new driver with expanded aiding support, opening MicroStrain’s INS product line to PX4 vehicles.
• The new sbgECom INS driver brings SBG Systems hardware into the ecosystem.
• A new EULER-NAV Baro-Inertial AHRS driver adds another path to robust attitude and altitude estimation.

GNSS and ranging

• Septentrio receivers now expose resilience reporting (jamming, spoofing, authentication state) to PX4, so EKF2 and operators can see when the constellation environment is under attack.
• ARK X20 and ARK F9P GPS receivers and the new ARK DIST distance sensor round out the receiver and ranging additions.

Other additions

• QMC5883P compass driver.
• ICM42688P IMU support on the Mamba F405 MK2 V2.
• LightWare SF30/d binary protocol.
• A synthetic-airspeed option in AirspeedSelector for dead-reckoning scenarios.

EKF2 also gains the new SENS_BAR_AUTOCAL parameter, which auto-calibrates barometer offsets against GNSS height when GNSS is the height reference. It’s enabled by default and is the right behavior for typical outdoor flight. If you operate indoors or in heavily GNSS-degraded environments where you’d rather keep baro offsets locked, disable it.

Simulation: Gazebo Flexibility and SIH Expansion

Gazebo integration is now version-agnostic at the CMake level. The hard pin to Harmonic has been removed from the build glue, which means building against newer Gazebo releases like Jetty (v15) is now possible without forking the build. Harmonic remains the supported, CI-tested version (so it’s still the safe default), but advanced users who want to track upstream Gazebo can now do that locally.
Simulation-in-Hardware (SIH) gained two new vehicle types: Hexacopter X and Ackermann rovers. The rover simulation was also updated to match the reworked rover architecture from v1.16, the Gazebo bridge picked up a custom-spawn-pose parameter (PX4_GZ_MODEL_POSE), and HITL/SIH battery status is now driven by the configured battery parameters instead of a fixed model.

Security Hardening and CVE Fixes

v1.17 closes out a coordinated wave of security advisories disclosed through GitHub’s private reporting program. Eight runtime fixes landed in this cycle, covering MAVLink FTP path traversal and session validation, the MAVLink shell, the MAVLink log handler, the CRSF and BST receivers, the tattu_can driver, and the Zenoh middleware. Two were rated High severity; the rest are Moderate. All have been addressed in v1.17, and the responsible disclosure flow worked exactly as we’d want it to.

If you operate PX4 vehicles over non-USB MAVLink links, this is also a good time to enable MAVLink 2.0 message signing and review the Security Hardening guide. Special thanks to the security researchers who reported these privately rather than dropping them on a Friday.

Link to PX4 Security Advisories.

Expanded Hardware Support

v1.17 continues to broaden the PX4 hardware ecosystem in collaboration with partners.

New flight controllers

• Radiolink PIX6 — new Pixhawk-compatible board.
• CUAV X25-Evo — new flight controller from CUAV.
• Accton Godwit GA1 — Accton enters the PX4 ecosystem.
• Kakute H7 dual-IMU — new build target for the dual-IMU variant.
• NarinFC-H7 — new flight controller build target.
• ESP32 generic-target — experimental, sponsored by AutonoSky.
• NXP MR-Tropic — new target with imxrt driver improvements, alongside continued investment in the MR-CANHUBK344 NXP B3RB rover platform.

New build targets for existing hardware

• cuav/fmu-v6x for the CUAV Pixhawk V6X.
• auterion/fmu-v6x for the Auterion FMU-v6x.

Improvements to existing boards

• FMU-v6xRT — V6XRT001 and V6XRT002 sensor sets, LIS2MDL and BMM350 magnetometer support, DTCM added to heap.
• FMU-v6s — PCA9685 PWM expander driver, INA226/228/238 power-monitor support.
• ARK FPV — rover board variant and payload-deliverer module.
• 3DR Control Zero H7 OEM Rev G — MTD driver fix resolving a USB enumeration issue.

PWM peripheral support also got a real upgrade. The new PWM_*_CENTER parameters replace the old PWM_*_TRIM model and add asymmetric deflection, which is a nicer fit for servos with non-symmetric throw. Trim values aren’t auto-migrated, so re-set the center for each previously trimmed servo channel after upgrading.

Together these updates reflect the continued investment of the partner ecosystem in keeping the Pixhawk standard and the broader PX4 hardware base alive and well.

Flight Testing

PX4 v1.17 went through an extensive flight testing campaign led by the Ascend Engineering team, the official test flights provider for Dronecode, with support from the wider community. From the first 1.17-alpha builds through to the rc series, we collected and analyzed over 100 flight logs across multicopter and fixed-wing platforms.

This level of real-world validation helps us catch regressions early, fine-tune performance, and ensure a stable release for everyone. Our thanks go out to every pilot, engineer, and tester who contributed their time and hardware to make v1.17 better. You can browse the full set of test logs and discussions here: PX4 v1.17 Release Candidate Flight Testing.

And Much More

This release also includes dozens of smaller improvements and bug fixes that don’t make headline status but still add up: MAVFTP path-traversal hardening, the extended MISSION_CURRENT MAVLink message, the QGC bootloader update via SYS_BL_UPDATE re-enabled after several releases of being broken, motor failure detection using more robust timeout checks, the failsafe state machine letting a pilot take back control from a degraded state, Offboard no longer falling into Position without RC available, NuttX submodule updates including a dcache fix, ITCM checker added to CI, and a long list of build-system and infrastructure cleanups.

You can explore the full list of changes in the PX4 v1.17 Release Notes.

Community Contributions

The v1.17 cycle was, as always, the work of the broader PX4 community. From the first 1.17-alpha builds in October through to the stable release, contributors landed feature work, hardware bring-ups, bug fixes, documentation, and flight testing across every vehicle type PX4 supports. Thank you to everyone who wrote code, fixed bugs, brought up new boards, ran flight

Getting the Release

Read the full release notes on the PX4 documentation portal and download the v1.17.0 firmware from our GitHub releases page. To build from source or flash via QGroundControl, follow the same steps as before.

We welcome your feedback and issue reports on GitHub. Enjoy the new release and happy flying.