OSS + ELC EU 2026

Since Micro XRCE-DDS replaced Fast-RTPS in PX4 version 1.14 the support for direct communication between ROS 2 and PX4 never stopped improving.
With PX4 stable version 1.17 recently released and version 1.18 close to enter its beta testing phase this presentation aims to cover the latest changes, imporvents and limitations of the Micro XRCE-DDS and Zenoh-pico interfaces.
The presentation will also compare the two communication methods to give the audience all the information necessary to choose the best approach given their requirements and application contraints.

Global regulatory shifts—driven by strict NDAA requirements and EASA U-Space mandates—require drone manufacturers to implement verifiable supply chain security. Software-only implementations of FAA Remote ID remain vulnerable to key spoofing and firmware tampering. This session delivers a practical breakdown of how to enforce a hardware root of trust by embedding physical Secure Elements (like the OPTIGA Trust M) into open flight controllers running PX4 and NuttX.
We will bypass high-level concepts to dive straight into the embedded architecture:
Configuring the SPI/I2C bus interface between the flight MCU (PSoC C3M) and the security peripheral.
Modifying the NuttX driver layer to offload ECDSA signing keys for broadcast messages without blocking safety-critical flight loop threads.
Structuring secure boot sequences to protect downstream firmware from local physical exploits.
We will share timing benchmarks showing how to manage cryptographic latency within standard PX4 task frequencies to build compliant systems without sacrificing real-time flight performance.

When it comes to controlling PX4 from a companion computer, developers are often spoiled for choice - leading to confusion about which architecture best suits their specific mission requirements. Historically, Offboard Mode has been the go-to default, but the evolution of the PX4 ecosystem has introduced powerful alternatives like External Flight Modes and the native ROS 2 Control Interface.
This session provides a technical breakdown of how PX4 handles companion computer inputs under both paradigms. We will explore how External Flight Modes register directly with PX4's internal mode manager, allowing custom autonomy apps to behave like native flight modes with built-in safety boundaries. Attendees will learn the differences between these methods, the performance benefits of moving to the ROS 2 bridge, and a practical migration path to transition legacy offboard code into robust, external ROS 2 applications.

EKF2 is the heart of PX4's navigation, and over the past few years it has quietly received a series of improvements that make it more accurate, more robust, and easier to work with. In this talk I'll walk through the most significant ones. We'll start with a short recap of the filter's architecture, then cover the move to a proper error-state formulation, along with its symbolic derivation and code generation using SymForce. We'll then see how this makes it easy to add a new state or measurement, as we did for the terrain state. From there we'll turn to round-earth navigation, paired with a position-dependent gravity model, which replaces the flat-earth assumptions to support long-range and high-latitude flight. We'll also look at how the Joseph-stabilized covariance update not only makes the filter more numerically stable, but also lets us perform partial updates, which we rely on heavily in the magnetometer and optical-flow fusion. Finally, we'll look ahead at the next changes coming to EKF2 and some of the ideas we're exploring.

This talk will introduce a new MCU architecture that PX4 only recently supported: the Xtensa ESP32. Using it as a walk-through, we'll demonstrate the software components needed to add your own custom board, contribute to or expand existing MCU architecture support, and highlight how PX4's compile process is designed to be agnostic to the underlying MCU architecture.

Some highlights will be:
How PX4 interacts with NuttX at a low level, and why that relationship is central to bringing up new hardware

The role of the High Resolution Timer (HRT) in PX4's timekeeping, and what it takes to implement it for a new architecture

The difference between Menuconfig and boardconfig, and when to use each when defining your board's peripherals and pin allocation

How PX4's build system sets up the compilation environment for NuttX, and how to configure it for your specific board

How PX4 is designed to be MCU-agnostic, and what that means in practice when working at the boundary between PX4 and NuttX

While PX4 is open source, the underlying hardware often remains tied to proprietary vendor black boxes. This creates a gap for PX4 developers and sovereignty-sensitive applications that need an inspectable full stack all the way down to silicon.

This session presents CORE-ET, a fully open-source RISC-V platform that can scale from a 16-hardware-thread Erbium configuration to systems with more than 2000 cores. We will show a simulation demo of Erbium running PX4 alongside onboard AI: PX4/control runs on two hardware threads, while the remaining 14 run workloads such as vision, depth, VIO, or object detection.

We will discuss the porting structure, real-time capabilities, and measurements needed to show flight control running alongside local inference. The result is a path toward drones where both software and hardware are open and inspectable.

Airspeed sits at the center of fixed-wing flight. It determines how much lift the wings generate, how effective the control surfaces are, and ultimately how the aircraft can be controlled. As a result, it influences nearly every aspect of flight, from stability and maneuvering to energy management. Yet the airspeed value used throughout PX4 is far from a simple sensor reading. Behind a seemingly simple number lies a surprisingly large stack of sensor physics, conversions, calibration procedures, validation logic, control scaling, and TECS handling.

This talk traces the airspeed pipeline end-to-end: from pitot-tube measurements, through IAS → CAS → TAS conversion, in-flight calibration, and validation, to the controllers that ultimately use it. We'll also examine real-world failure modes from the PX4 community and show how to diagnose them from flight logs.

The Total Energy Control System (TECS) coordinates throttle and pitch to manage a fixed-wing vehicle's airspeed and altitude as a single energy problem — but for many users it remains a black box of tuning parameters. This talk opens it up.
We start from first principles, deriving how TECS balances kinetic and potential energy and why throttle and pitch are the natural levers to control them. We then cover the controller's concept, its architecture in PX4, a structured approach to tuning, and the shortcomings every operator eventually hits. Finally, we distill seven years of hands-on TECS tuning into the heuristics and hard-won insights that don't appear in the documentation.
Whether you're tuning your first fixed-wing or maintaining a fleet, you'll leave with a clearer mental model of what TECS is really doing.

Is it a multicopter? Is it a fixed-wing? Not quite: It is a quantum superposition of both, and only upon flipping the transition switch we can observe the VTOL state with certainty.

VTOL vehicles bridge the design space between either pure vehicle type and enable long, efficient flights combined with accurate and soft landings. However, they challenge our software engineering and architecture skills, and properly supporting all VTOL vehicles in PX4 is quite the balancing act.

In this talk, we will go over the architecture and implementation decisions that connect those two vehicle types within a running system. We will visit some VTOL specific features and see where they slot in, and finally we will conclude with possible paths for further improving VTOL support in PX4.

Modern drone operations have moved from one pilot, one aircraft to multi-agent autonomous fleets. Dozens and even hundreds of vehicles now fly missions while only a handful of operators supervise from the ground. More drones, fewer ground stations, and the station is where all the value is, the operator, the mission data, a full-blown OS, and even access to other drones.

For years, drone security researchers have focused on attacking the vehicle. I flip the target and show how a single infected drone becomes a beachhead, reaching up the command chain to own the very station meant to control it, and the fleet.

This research audited six popular independent ground-control and middleware projects across the MAVLink ecosystem, Mission Planner, QGroundControl, MAVSDK, MAVProxy, MAVROS, and DroneKit and found the same broken trust boundary in all of them. The result is 14 findings rooted in one systemic flaw, including two novel full remote code execution chains against the operator's own machine.

PX4 and MAVSDK have made controlling individual drones remarkably accessible. Building systems around fleets, however, introduces a different class of challenges.

While developing a distributed multi-UAV architecture, we repeatedly discovered that many problems that initially appeared to be robotics problems were, in fact, distributed-systems problems. Task execution, telemetry aggregation, observability, fault tolerance, and fleet coordination quickly became more important than vehicle control itself.

This talk presents the architectural lessons that emerged from this work. It covers the separation of control and orchestration, the shift from commands to tasks, event-driven architectures, spatial state, and observability.

A recurring theme is that fleet management can be viewed as a space-time scheduling problem involving heterogeneous resources. From this perspective, many challenges beyond individual vehicles are problems of state, scheduling, and coordination.

The session connects PX4 and MAVSDK with ideas from distributed systems and scheduling theory, highlighting reusable patterns for scalable autonomous systems.

This isn't just about Airtel but for every organisation as MAVLink has supported per-message signing since MAVLink 2, yet almost no real-world PX4 fleet enables it, because key distribution, rotation & revocation across dozens of airborne vehicles has no production-ready tooling, so most swarms still accept any correctly formatted command from whatever radio reaches them. A single spoofed ground station or one drone with cloned key can inject commands rest of swarm has no way to reject. Talk introduces swarm-native trust layer that issues short-lived, mission-scoped MAVLink signing keys from a lightweight onboard authority, lets every drone verify signatures independently without round-tripping to a ground station & adds a peer-consensus exclusion protocol so that if one drone starts broadcasting commands inconsistent with its own attested mission profile, the rest of swarm votes to ignore it mid-flight without operator intervention. We demonstrate this on PX4 SITL & real hardware over a Zenoh-based inter-drone link, show a live command-injection attack being rejected by consensus & discuss key rotation strategy under degraded or fully lost ground-station connectivity mid-mission.