Open Source Summit + Embedded Linux Conference North America 2026

Ten years ago, Zephyr set out to solve a problem that many embedded teams quietly struggled with: how to build dependable real-time systems without being locked into a single vendor, toolchain, or proprietary stack. Before beginning the project, open source developers were surveyed to identify the key problems they wanted to see a new open source RTOS to solve, such as security and safety certifications.

What followed over the next decade was more than steady adoption. Zephyr introduced a new model built around portability, adoption of security best practices, modern tooling, and a shared ecosystem of drivers and middleware. Contributors collaborate in the open to improve performance, connectivity, and reliability, enabling it to now be found embedded in products which need to last many years, if not decades.

As we head into our next 10 years, the Zephyr project reached out again to survey RTOS users and understand better what they value, and what the project should focus on improving in the years ahead. This talk will go through the results that LF Research team has identified from the survey and interviews, giving a peak at the focus points going forward.

Embedded Automotive RTOS (Real-Time Operating Systems) must meet stringent requirements for safety, reliability, and security, primarily governed by the ISO 26262 standard, which details ASIL (Automotive Safety Integrity Level) requirements.

This talk covers the Zephyr RTOS complies with key functional needs, including minimal latency, high determinism, efficient memory management, and robust multitasking capabilities to handle critical tasks. Currently, the project is actively moving toward greater alignment with the needs of the automotive industry, with specific plans outlined.

When our production power‑management IC (PMIC) firmware moved to Zephyr, it opened the door for us to streamline our development and validation workflow. Our production firmware used a proprietary RTOS, which required maintaining a separate codebase for pre-silicon validation. By standardizing on Zephyr, an RTOS supported across hundreds of MCUs, we were able to use single application codebase across the entire development flow.

In this talk, I’ll describe how we built a Zephyr‑based pre-silicon PMIC testing platform, enabling the same application to run on both the production as well as pre‑silicon hardware running on a completely different SoC (Raspberry Pi Pico) and a custom evaluation kit. I will briefly outline the software architecture: the application running on Zephyr with board configuration defined through device tree and Kconfig. I will also cover the hardware architecture that connects the Pico to the PMIC evaluation kit, and the Twister‑based Hardware-in-loop tests we incorporated for validation.

I’ll close by highlighting how Zephyr’s broad hardware support and tooling helped simplify our workflow and reduce duplicate effort across multiple platforms.

Zephyr’s build-time configuration excels at efficiency, but challenges mass production. When a single product design needs to support dozens of hardware variations, e.g. swapping out sensors or chargers due to supply chain constraints, the standard build flow often leads to managing a unique binary for every combination. This creates a validation nightmare.

This talk presents an architectural framework used in the ChromeOS Embedded Controller that brings runtime adaptability to Zephyr, achieving Linux-like flexibility without the memory overhead of a live DTB parser.

We cover two specific patterns:
1. Dynamic Driver Selection: We treat the Devicetree as a pool of supported components. By reading a configuration bitfield from manufacturing data (EEPROM or protected flash) at boot, the firmware dynamically initializes only the correct drivers for that specific unit.

2. Safe Hardware Discovery: Zephyr compiles away hardware descriptions, leaving the host OS blind to connected peripherals. We introduce a pipeline that exports Devicetree definitions into a "Component Manifest". This enables safe OS-level verification, avoiding the risks of "blind probing" on I2C buses.

Fuzzing, a type of dynamic analysis, is a testing method to find security flaws in software during execution. It involves providing randomized inputs to the application and observing for crashes.

Embedded applications present unique fuzzing challenges. Unlike general-purpose software, they run continuously in real-time without terminating, making it hard to use traditional fuzzing approaches. They receive inputs through specialized peripherals or direct memory/register accesses that require accurate modeling. Fuzzers must generate inputs satisfying highly constrained validation checks while maintaining application state, and crash detection is complicated by the lack of clear program termination.

Existing solutions use hardware, emulation, or rehosted systems with modeled peripherals, employing full source code level, binary-only or API-level fuzzing. Zephyr's current libFuzzer integration targets unit-level API fuzzing but misses system-wide bugs. We aim to integrate AFL++, a popular fuzzing engine, to create a generalized fuzzing strategy across Zephyr's supported platforms. Though still in development, we're exploring the optimal approach to achieve this integration.

FreeRTOS has long been the go-to RTOS for embedded developers. But as projects grow in complexity, demanding better modularity, richer middleware, and long-term maintainability, teams are turning to Zephyr. The migration, however, can feel daunting. Different APIs, build systems, configuration models, and abstractions create a steep learning curve.

This session delivers a practical, step-by-step guide for transitioning from FreeRTOS to Zephyr with confidence. We'll map the similarities and differences between the two RTOSes, demonstrate migration strategies for tasks, queues, and synchronization primitives, and show how to translate existing FreeRTOS designs into Zephyr's ecosystem — covering proven tips to avoid common pitfalls, validate your port, and leverage Zephyr's strengths from device trees to vendor-neutral drivers.

Key Takeaways:
- Core architectural differences between FreeRTOS and Zephyr
- Migrating primitives (tasks, queues, semaphores, timers) to Zephyr equivalents
- Adapting build systems, configuration, and drivers
- Best practices for validating and testing migrated code
- Leveraging Zephyr's ecosystem for scalability and long-term support

Many flight‑control and autonomy programs still begin with hardware prototyping, only to discover late in development that controller tuning, transition behavior, and system coupling are difficult to resolve without a reliable model. This session presents a practical simulation‑to‑flight workflow based on recent university flight‑test research, demonstrating why starting with simulation is critical for reducing risk and accelerating development while helping teams avoid costly UAV crashes and hardware damage. Using a subscale eVTOL case study, we show how aerodynamic modeling, propulsion modeling, and six‑degree‑of‑freedom dynamics are integrated into a digital twin that directly informs control‑law design, hardware deployment, and flight testing. The workflow culminates in direct PX4 implementation and a comparison of simulation predictions against real flight‑test data across hover, transition, and forward flight, highlighting close agreement between model and reality. The talk emphasizes how a simulation‑first approach enables faster iteration, safer testing, and more predictable flight performance for the broader aerospace and UAS community.

A team of aerial and ground robots operating in a coordinated way is the key to large-scale operations in kilometer-scale environments. Nonetheless, significant challenges, such as orchestration, intermittent communications, and command-and-control of the team, need to be solved.
This talk will explore an application where a team of ground robots performs a search mission, with an UAV acting as an eye in the sky and a data mule between the different ground robots. We will focus on the challenges for this task and how PX4 can be used in a heterogeneous team of aerial and ground robots. We will show examples of the system in large-scale urban and rural environments. Finally, we will mention how large foundational models can enable more complex tasks for a robot team.

This session introduces the open-source Unified Autonomy Stack (https://github.com/ntnu-arl/unified_autonomy_stack), a containerized, system-level solution enabling robust autonomy across diverse aerial and ground robot morphologies. The architecture centers on three modules -multi-modal perception, multi-stage planning, and multi-layered safety mechanisms- that together deliver end-to-end mission autonomy. Resulting behaviors include safe navigation into unknown regions, exploration of complex environments, and efficient inspection planning. The stack has been validated on multiple multirotor platforms and legged robots operating in GNSS-denied and perceptually degraded environments, demonstrating resilient performance in demanding conditions. To facilitate ease of adoption and extension, we additionally release a reference hardware design that integrates a full multi-modal sensing suite, time-synchronization electronics, and high-performance compute capable of running the entire ROS-based stack while leaving headroom for further development. Strategically, we aim to expand the Unified Autonomy Stack to cover most robot configurations across air, land, and sea.

PX4-based drones are powerful, but interacting with them typically requires specialized ground control software and trained operators. This talk presents a new interaction model: controlling and querying a PX4 drone using natural language from a standard mobile phone.

The system combines a Model Context Protocol (MCP)–style interface (inspired by ROS 2 MCP implementations) to expose PX4 capabilities as structured, machine-readable commands, with OpenAI’s real-time ChatGPT API to interpret user intent. A phone call or voice interaction—handled via Twilio—becomes the primary user interface, allowing operators to issue commands such as “take off to 10 meters,” “orbit that location,” or “what’s your battery state?” and receive immediate spoken feedback.

The talk will cover:

* How PX4 commands, telemetry, and state are exposed through an MCP-like abstraction
* Real-time bidirectional communication between phone, AI model, and drone using Twilio and RealTime API
* Safety considerations, command validation, and constraints when using AI-mediated control
* Practical use cases, fly missions, object detection all using hands free control
* Lessons learned, what worked and didn't work

PX4's EKF2 replay module allows developers to tune estimator performance by re-running the EKF on prerecorded logs. This is useful for EKF2 development or for testing the impact of different parameters on performance. KEF robotics has patched the replay module so that replay progress can be controlled by an external program, enabling deterministic *integration* testing. We are using this patched replay module to test the integration of PX4 with an external vision navigation system.

We will cover:
- Using the replay module to assess performance of different EKF2 parameters.
- Development and testing considerations for a visual navigation system that integrates with PX4.
- Modifying the replay module so that it can be deterministically 'stepped' in sync with an external program
- Results from integration testing with the modified replay module

The audience will get a better understanding of the replay system, technical details on modifying the replay system for integration testing, and the benefits of integration testing with regard to visual navigation development with PX4. We will also share the patch we made to the replay system.

By the end of this workshop, every attendee will land a simulated drone precisely on an ArUco marker using computer vision, with PX4 running the drone and ROS 2 handling the control logic. PX4 powers over a million drones worldwide, and in this session you'll run the exact same production firmware on your laptop. Precision landing on a visual marker is a real-world capability used in package delivery, autonomous charging, and marine recovery, and you'll build it from scratch.

We'll start by booting PX4 in Gazebo simulation and exploring the architecture of a production flight stack, including uORB, the pub-sub middleware that connects every module in PX4. From there, we'll connect PX4 to ROS 2 via the uXRCE-DDS bridge, build a custom flight mode using the px4-ros2-interface-lib, detect ArUco markers with OpenCV, and estimate pose from a simulated camera, and finally wire perception into the flight mode to execute an autonomous precision landing.

This workshop is for embedded developers looking for a robotics application of their existing skills, ROS 2 developers wanting to move beyond MAVLink offboard control, and anyone interested in seeing how perception, control, and middleware come together in a real flight stack. No drone experience required.
Hosted by Dronecode maintainers Ramón Roche and Nuno Marques, with guest contributors from the PX4 ecosystem.

Workshop Requirements (please read before attending):
Bring a laptop. Any OS works, but in order of expected smoothness: Linux is your best bet, followed by Windows, then macOS. Workshop materials and setup instructions live at https://github.com/Dronecode/ossna-26-workshop. Pre-install the Docker containers before arriving, since conference Wi-Fi might be unreliable and pulling multi-gigabyte images on-site will eat into your workshop time. macOS users should note that the container image doesn't run Gazebo well; use the official PX4 setup script at https://github.com/PX4/PX4-Autopilot/blob/main/Tools/setup/macos.sh with the --sim-tools flag to install Gazebo natively (details in the workshop repo). Join the Dronecode Discord at https://chat.dronecode.org for workshop updates, setup help, and community support before, during, and after the event, and keep an eye on the repo and Discord in the days leading up for any last-minute changes.

By the end of this workshop, every attendee will land a simulated drone precisely on an ArUco marker using computer vision, with PX4 running the drone and ROS 2 handling the control logic. PX4 powers over a million drones worldwide, and in this session you'll run the exact same production firmware on your laptop. Precision landing on a visual marker is a real-world capability used in package delivery, autonomous charging, and marine recovery, and you'll build it from scratch.

We'll start by booting PX4 in Gazebo simulation and exploring the architecture of a production flight stack, including uORB, the pub-sub middleware that connects every module in PX4. From there, we'll connect PX4 to ROS 2 via the uXRCE-DDS bridge, build a custom flight mode using the px4-ros2-interface-lib, detect ArUco markers with OpenCV, and estimate pose from a simulated camera, and finally wire perception into the flight mode to execute an autonomous precision landing.

This workshop is for embedded developers looking for a robotics application of their existing skills, ROS 2 developers wanting to move beyond MAVLink offboard control, and anyone interested in seeing how perception, control, and middleware come together in a real flight stack. No drone experience required.
Hosted by Dronecode maintainers Ramón Roche and Nuno Marques, with guest contributors from the PX4 ecosystem.

Workshop Requirements (please read before attending): 
Bring a laptop. Any OS works, but in order of expected smoothness: Linux is your best bet, followed by Windows, then macOS. Workshop materials and setup instructions live at https://github.com/Dronecode/ossna-26-workshop. Pre-install the Docker containers before arriving, since conference Wi-Fi might be unreliable and pulling multi-gigabyte images on-site will eat into your workshop time. macOS users should note that the container image doesn't run Gazebo well; use the official PX4 setup script at https://github.com/PX4/PX4-Autopilot/blob/main/Tools/setup/macos.sh with the --sim-tools flag to install Gazebo natively (details in the workshop repo). Join the Dronecode Discord at https://chat.dronecode.org for workshop updates, setup help, and community support before, during, and after the event, and keep an eye on the repo and Discord in the days leading up for any last-minute changes.