Open Source Summit + Embedded Linux Conference North America 2026

Automotive Grade Linux (AGL) is advancing Software Defined Vehicle (SoDeV) as a foundation for open, scalable, and collaborative automotive innovation. As vehicles become increasingly software-centric, accelerating collaboration between AGL SoDeV initiatives and the broader open-source automotive community is critical to shaping the future of mobility.
This session highlights how AGL SoDeV acts as a collaboration hub that connects industry-driven development with open-source community contributions. Building on a previously presented demo, we introduce updated workflows and tooling that reduce collaboration friction, improve governance transparency, and enable faster feedback loops between SoDeV activities and OSS communities.
Through an updated live demonstration, we show how governance automation and clear contribution flows can function as enablers rather than barriers. The talk focuses on practical lessons learned from evolving AGL SoDeV collaboration models, explaining what has changed, why it matters, and how these improvements help communities and organizations innovate together more effectively.

Embedded software complexity has doubled every four years for decades. The way most teams build and deploy it is still stuck in the 2010s. Version control exists, but it's still not unusual for code to be shipped from a sharpie-labeled SD card or prod code to live on one machine. Deployment still means walking over to a test bench and hoping nobody else is using it. "It works on my machine" is often an entire strategy.

This talk brings modern DevOps to embedded systems. We'll cover version control workflows that actually work for firmware, build environments that don't depend on that one engineer's laptop, CI/CD pipelines that integrate with real hardware, and deployment strategies that reduce the risk of bricking devices in the field. We'll also touch on what to steal from web DevOps and what doesn't translate when your deployment target isn't a cloud server.

We'll demo the whole flow: commit, build, deploy to hardware. You'll leave with practical patterns you can bring back to your own embedded projects. Some embedded experience is useful, but if you've ever been frustrated by how your team ships firmware, you'll get something out of this.

The NAO robotics platform has been around for some time, originally developed by Aldebaran and SoftBank, and now by Maxtronics. Its OpenNAO operating system is based on the Gentoo embedded Linux OS, and uses the NAOqi API for autonomous robot control. We also used the OpenCV computer vision library as part of our open source software stack to program our NAO humanoid robot.

In this talk, I will present our work to engineer an autonomous behavior system that fuses real-time vision detection with motion planning and closed-loop control. We implemented a perception-to-action pipeline using NAOqi, OpenCV, and camera and motion calibration to detect targets, estimate relative pose, and drive head movement, walking, and task actions through a finite-state controller. We designed the system for robust target search, alignment, and approach under real hardware constraints. I will present a summary of our work, our results from participation in a robot golf tournament, and some thoughts on using open source to develop next-generation robotics platforms.

Ten thousand LCD panels passed Incoming Quality Control. Firmware injection began. Production stopped.
During the development of our next-generation Automated Fare Collection (AFC) machines, we qualified multiple LCD vendors, designed a custom MIPI DSI touchscreen panel, developed display and peripheral drivers, and prepared for mass production. Everything worked—until firmware flashing began. Devices that previously functioned flawlessly suddenly booted to dead displays. The same firmware image now failed across the line.
The root cause wasn’t firmware. It wasn’t hardware failure. It was a silent vendor-side change: the LCD panel driver IC had been swapped for a different silicon revision—without changing the panel model.
The Linux DRM panel framework assumes static hardware described in the Device Tree. Manufacturing does not. MIPI DSI panel drivers are based on LCD model types not Display IC model types.
This talk presents a real-world production failure and the redesign that followed: replacing static panel definitions with runtime detection of display controller ICs via MIPI DCS, dynamic initialization sequencing, and a more resilient driver architecture.