OSS + ELC EU 2026

Running PX4 on thousands of devices surfaces errors that don't appear in lab testing or flight tests. The kind that only show up at a customer site, that you cannot reproduce locally, that disappear when you add or remove code in a completely unrelated module.

This talk presents real incidents from running PX4 at commercial scale: problem descriptions, how debugging was done, and how the errors were fixed.

For each incident we share the heuristics we use to quickly identify which part of the system to investigate, and the tools we use to diagnose Heisenbugs.

We conclude with the hardware CI setup we built, including hardware tracing capabilities and describe how this can help to catch certain kinds of failures described in this talk. In addition we describe how this can be shared with upstream.

Training an RL policy with PX4 as a real-time controller is often considered impractical due to SITL limitations, communication overhead, and strict safety constraints. In this presentation, I will share how I addressed these challenges during my master’s thesis to successfully train a navigation and obstacle avoidance policy using Isaac Sim and Isaac Lab.
The talk focuses on the practical steps required to make PX4 compatible with unsupported simulators, including key preparations to enable stable SITL operation. I will discuss how to keep the PX4 SITL instance stable and continuously running throughout training.
Additionally, I will cover methods for accessing PX4 state and control interfaces via MAVLink and ROS 2, and highlight how PX4’s built-in safety layers can unintentionally block RL training. Finally, I will present strategies to work around these constraints while preserving system stability and realism.

Recently, drones have evolved from passive observers into active workers, enabling them to carry out physical work in the sky. This lightning talk shares recent advances in Aerial Manipulators (AM), where flying robots physically interact with their surroundings to perform tasks such as inspecting and maintaining offshore wind turbines.
We showcase how PX4 is accelerating the move from lab research to real-world deployment with the journey of a field test of our open AM framework, Sarax (github/sarax), physically interacting with a wind turbine by the North Sea (youtu.be/Er0f0A97aG8). Alongside it, we highlight two research threads (with references to our open-source HW/SW and PRs). First, a PX4/Pixhawk compliant open standard-interface for active, high-power payloads (e.g. manipulator with a steel brush for surface maintenance) to enable modular AM. Second, developing PX4-powered omnidirectional and actively tilting-rotor aerial robots that enable dexterous physical tasks in windy environments.
We close with next steps and open issues for PX4-powered aerial manipulators and an open invitation for the community to join forces and shape this future together.

Safely flying a drone close to high voltage power lines is a challenge. Making contact with a power line to install hardware on it is even more challenging. The line generates strong electromagnetic interference and there is no room for error in positioning.
In this talk we will go through the challenges we faced with positioning, magnetic interference and changing payload weight. We will show how tailoring the PX4 parameters can address these challenges and compare this to our experience using a DJI M600 where all problems have to be accounted for by our own specialized software. Finally we will present an open problem with RTK degradation resulting in sudden position jumps which we have currently handled in our own software.

An update on MAVLink project and standardization: how we're aligning stakeholders around common definitions, why standardization takes as long as it does, and what PX4 is doing right now to be a better MAVLink citizen.

PX4 v1.18 introduces a serialpassthrough driver that lets any MAVLink client read from and write to flight controller serial ports. This talk walks through the design: how SERIAL_CONTROL messages are mapped to hardware UART ports and, on STM32F7/H7 boards, to ESC signal pins via a software bit-bang UART; How reply routing, buffer management, and channel exclusivity are handled. We also cover the MAVLink↔UART bridge pattern that makes the feature usable from standard host-side tools, and the PASSTHRU_EN mechanism for safely handing off ESC signal pins at boot. Whether you need to debug a serial peripheral over a telemetry link, configure an ESC remotely, or build custom tooling on top of SERIAL_CONTROL, this talk gives you the full picture.

As a maintainer of MAVSDK I would like give an update on the current state of the project, specifically about changes and improvements coming with MAVSDK v4, such as:

- New lightweight Python wrappers
- New MavlinkDirect plugins
- And lots of improvements under the hood

Most PX4 simulation relies on an external simulator talking to the autopilot over a network bridge. SIH, the Simulator In Hardware, does the opposite: it is a single PX4 module that integrates the full rigid-body equations of motion right next to the flight stack. The same code runs as a SITL process on your laptop and, just as well, directly on the flight controller, feeding synthetic sensor data into the estimation pipeline while the board flies a virtual vehicle.

This talk opens up SIH and shows how little there is between you and a flying model: how actuator outputs become forces and torques, are integrated through the equations of motion, and are reconstructed into noisy IMU, baro, GNSS, and airspeed signals that the rest of PX4 cannot tell from real hardware. We cover the vehicle types supported, the aerodynamic model that makes adding an airframe a matter of physics rather than plumbing, and how to launch, run, and extend SIH.

What if losing a motor didn't mean losing the drone? This talk gives an end-to-end overview of how PX4 handles motor failure on multicopters: how it recognizes a failing motor, and the failsafe and control-allocation responses that decide what happens next.
We'll then look at where motor-failure handling is heading: a new filter-based detection method that learns each motor's expected behavior to catch faults earlier, the tooling to calibrate it from real flight data, and a recovery that can keep a vehicle flying, and bring it home, after losing a motor.

Autonomous VTOL aircraft require reliable, precision landing capabilities to enable real world applications from package delivery to infrastructure inspection. This session presents a complete open-source precision landing system built on ROS 2 and PX4, covering the full development lifecycle from high fidelity simulations to flight tested deployment.

We'll walk through how we developed, validated, and refined a multi-sensor perception and control stack that achieves centimeter-level landing accuracy using only commodity sensors and open-source tools. The system uses AprilTag fiducials for dock detection, fuses visible and infrared camera streams with a Kalman filter for robust pose estimation, and executes a phased descent state machine with real-time PID control.

The presentation covers:
Simulation first development: Building a Gazebo SITL environment with realistic sensor models
ROS 2 + PX4 integration: Bridging autopilot and perception via micro-XRCE-DDS,
Production deployment: Lessons learned scaling from lab prototype to field-tested hardware. Practical guidance on composing a production system from ROS packages, PX4 firmware, and community-contributed modules.

I want to share our bumpy road on Swarm Drone Challenge 2026 (ILA Berlin) with a team of two people and what two stubborn guys can achieve during weekends - 4th place. We built a swarm of 5 drones, each running PX4 for flight, coordinated by a ROS2 ground station and onboard with two ESP32-ser. microcontrollers. ESP32-P4 was dedicated to onboard ArUco vision and ToF obstacle sensing (no Linux SBC) and an ESP32-S3 handling MAVLink and micro-ROS comms over WiFi.

I will cover architecture — PX4 + MAVLink + a ROS2 commander that assigns swarm roles and streams waypoints — and the onboard vision pipeline on bare microcontrollers. Comparison of Version 1.0 (single-MCU) vs Version 2.0 (dual-MCU) and why we shipped a deterministic Manhattan-grid navigation fallback when ArUco-EKF localization could not be deployed in time.

Our solution was open-sourced - https://github.com/machmind-dev/drone-swarm-challenge-2026