The ArduPilot Developers Conference 2025 Day 3 focuses on advanced autonomy, development tools, and real-world applications within the ArduPilot ecosystem. Key presentations include Leonard Hall's deep dive into cooperative lift algorithms for multi-aircraft payload management, showcasing synchronized flight and load balancing. Ben Picard and Tamas Naz explore the intricate challenges and software solutions behind large-scale drone light shows, emphasizing safety, efficiency, and future Mavlink enhancements. Sid Prohit introduces a new VS Code extension designed to streamline ArduPilot development, offering environment validation, simplified builds, and integrated hardware debugging. Andy Piper presents innovative "Acro Fencing" and AI-driven acrobatics for small, fast drones, using Lua scripting for dynamic boundary reactions and flight maneuvers, culminating in both simulated and real-world demonstrations. Steven Dade showcases an ArduRover with ROS 2 integration for autonomous mapping in GPS-denied environments. Finally, Tom Pittinger from Krauss Hamdani Aerospace highlights ArduPilot's role in achieving record-breaking endurance and advanced capabilities for enterprise-grade fixed-wing aircraft, while also addressing critical challenges in open-source project collaboration and commercial adoption. The conference concludes with acknowledgements to its numerous contributors and organizers.
Exploring ArduPilot's Future: Autonomy, Development, and Real-World Impact
0:00:15 Conference Opening & Admin: Welcome to the final day of the ArduPilot Developers Conference 2025. Updates include a good morning weather outlook with rain expected at 4 PM, shuffled demo schedules, and no new NOTAMS affecting flight. Strict adherence to timings is emphasized due to bus departures.
0:02:59 UK Emergency Alert Test: An emergency alert text system test is scheduled for 3 PM, expected to trigger all mobile phones. The conference plans to extend any ongoing talk by five minutes if interrupted, reminding attendees it's only a test.
0:05:43 Leonard Hall - Cooperative Lift Algorithms & ArduPilot Advancements:
0:07:11 Core Progress: Leonard provides an overview of recent ArduPilot Pull Requests (PRs), including 3D offset support for position control (enabling kinematic paths relative to moving locations), EKF lane switching, real-time S-curves for improved "Follow" mode quality, and enhanced Autotune safety.
0:10:08 System-Wide Improvements: Parameter write protection via Lua scripts is being implemented for safety. A significant shift to SI units (radians for attitude, meters for position) is underway for ArduCopter 4.7, along with the removal of INAB, simplifying mathematics and saving space.
0:12:20 Cooperative Lift Introduction: Cooperative lift involves close formation flight of multiple aircraft to mirror each other in space, effectively turning them into a single physical structure to impart force on a shared load.
0:13:23 Optimization Goals: Aims to optimize power consumption across the swarm, ensuring all aircraft have similar remaining flight duration at mission's end, and preventing mid-air collisions during setup.
0:14:21 Mode Comparison: Discusses limitations of "Loiter" (high jerk rates) and "Auto" (no synchronization) for cooperative lift, highlighting "Mode Follow" and "Mode Guided" as more promising.
0:15:38 Enhanced Follow Mode: Leonard details improvements to "Follow" mode, moving from a P-term (rubber-band effect) to position, velocity, and acceleration matching using real-time S-curves (400 Hz smooth kinematic path) and a new "Follow Target" message based on the lead aircraft's target kinematics, reducing noise summation.
0:19:00 Cooperative Lift Demo (Video): Two Kalistos drones successfully lift a 10-20kg, then a 54kg payload, demonstrating tight synchronization and precise navigation despite the swinging load. The 54kg payload exceeded the Kalisto's formal maximum takeoff weight.
0:25:03 Auto Mode for Swarms: Proposes an "Auto" mode solution where all aircraft follow identical missions with different offsets, synchronizing time references to accommodate the slowest aircraft. This drastically reduces data rate requirements compared to "Follow" mode.
0:28:57 Dynamic Load Balancing: Discusses using dynamic offsets based on acceleration and battery remaining to balance load and equalize battery usage across the swarm.
0:31:30 Crane Mode for Manual Control: Introduces "Crane Mode," a velocity-controlled manual mode designed for precise, kinematically constrained movement of swarms, ensuring smooth operation under load.
0:34:10 Practical Considerations: Discusses physical connections (fixed vs. pulley systems) and data links (RFD900s, Wi-Fi dongles).
0:35:20 Q&A Highlights: Discussions include using offsets for underslung load compensation (Randy demonstrated this in Japan), potential issues with GPS errors in swarms (could lead to collisions), and the redundancy benefits of "Auto" mode over "Follow" mode for failsafe events.
0:51:05 Ryan Freriedman's Path Planner Demo Attempts: Multiple attempts to demonstrate a path planner for a quadcopter around a tree faced connectivity issues (RF link range) and an unexpected pre-configured "keep-in" fence around the home location, causing the drone to RTL (Return To Launch) safely.
2:00:50 Ben Picard & Tamas Naz - Challenges of a Drone Light Show:
2:01:29 Light Dynamics Overview: A UK-based manufacturer of drone light show hardware (Pixel drone, Pixel Pyro), emphasizing in-house PCB development and assembly. They are CA (UK) and FAA (US) authorized.
2:03:01 Custom Motherboard: Developed an STM32 H743-based motherboard integrating F9P GNSS, ESP Wi-Fi (for private networks), SIK radio, and LED/Pyrotechnic outputs, streamlining manufacturing for Pixel and Pixel Pyro drones.
2:04:42 Remote On/Off & Flight Termination: Implemented a unique remote on/off feature (sleep mode consuming 1% battery/hr) and an independent flight termination system (GPIO on Wi-Fi module pulls power from main board) for enhanced safety during large-scale operations.
2:07:32 Product Line: Details the Pixel (400g, RTK, 0.5m ground spacing, 15 min showtime) and the Pixel Pyro (400g payload, 4 pyrotechnic launches, up to 25 min flight). Both use a common 2S Li-ion smart battery with rugged multi-port charging cases.
2:10:57 Operational Challenges: Discusses the extrapolated risk of operating hundreds/thousands of drones, logistics (transport, maintenance), managing parallel Wi-Fi networks, crew fatigue, and dealing with technical failures (e.g., router lock-up during a show).
2:12:40 Successful Show Example: Showcases an 800-drone show in California (Lord of the Rings theme), with 100% takeoff rate, 350m wide formations, and "smart return to home" feature that returns drones to their exact takeoff pad.
2:13:50 Future & Wishlist: Requests for more SYSD (system ID) capabilities (32-bit Mavlink IDs) to simplify network management and enhanced failsafe features (automated detuning of rogue drones).
2:21:40 Skybrush Introduction: Tamas, lead developer of Skybrush, presents the software's capabilities for drone light shows.
2:22:21 Skybrush Demo: A simulation of a 100-drone show demonstrates the workflow: opening a show file, automatically fitting the takeoff grid, calculating trajectories, approving the layout, setting up geo-fences, uploading data (up to 800 drones/minute), pre-flight checks, and synchronized launch. RTK corrections are crucial for accuracy.
2:26:30 Open-Source Architecture: Skybrush's core is open source, including an ArduPilot fork with a "drone show flight mode" and safety features, and an open-source frontend (Typescript/React). The server is "open core," with Rust-based components for high-performance (10,000+ drones) requiring a license.
2:28:11 Show Design Process: Utilizes a Blender plugin for designing bezier-curve trajectories, light programs, and transitions, with real-time safety validations (altitude, proximity, velocity/acceleration). Exports a .skyc (zip) file containing JSON data per drone.
2:30:10 Show Execution Logistics: Requires drones, twice the number of batteries, primary and secondary ground stations, RTK base station, multiple Wi-Fi access points, and a backup SIK radio. Notably, no remote controller is used.
2:31:19 On-board Operations: Drones store trajectories (less than 10 KB) as bezier curves evaluated in real-time for position/velocity set points, light programs as bytecode, and use guided mode at 10 Hz. RTK corrections are redundantly injected.
2:33:05 Safety Enhancements: Key features include real-time drift warnings, a "hard geo-fence" (motors turn off if breached, mandatory), and a "bubble fence" (lands/disarms if too far from trajectory, optional). Some operators use "Armor EKF failsafe" for high-stakes shows.
2:34:42 Mavlink Wishlist: Requests for 2-byte Mavlink system IDs (to avoid network partitioning), error messages for non-existent parameter sets, and broadcast file transfers for efficient firmware/show uploads to thousands of drones.
2:37:54 Sid Prohit - VS Code ArduPilot Developer Environment:
2:37:54 Project Goal: A new VS Code extension aims to simplify the ArduPilot development environment, making it easier for new developers to onboard.
Installation & Setup: Easy installation, one-click cloning of the ArduPilot GitHub repo.
Environment Validation (2:43:02): A checklist system validates the development environment, with "Fix Issues" buttons to automate installation of Python, debug tools (OpenOCD, JLink), and cache setup.
Build & Feature Configuration (2:45:32): Provides a UI for selecting build targets (SITL, hardware) and visually enabling/disabling ArduPilot features (e.g., Mount) to manage firmware size and optimize for debugging.
Common Actions & Customization (2:46:53): Offers quick access to common actions like build, debug, clean, upload, run SITL, and allows overriding commands for special build/run scenarios.
Hardware Debugging (2:50:07): Enables full step-debugging for hardware (JLink, OpenOCD) across all major OS (Ubuntu, macOS, Windows+WSL2), with thread and peripheral views. WSL2 handles USB passthrough.
SITL Debugging (2:51:27): Allows launching and attaching to multiple SITL (Software In The Loop) instances for multi-drone debugging.
Productivity Tools: Includes a list of connected devices for MavProxy integration and quick launch shortcuts (Command-Shift-B for build, F5 for debug).
2:54:10 Validation & Future: Development is validated with end-to-end CI tests. Future plans include a Cube node AP_Periph designer (for generating hardware definitions), Lua script debugging, and LLM (Large Language Model) integration for project control and MavProxy interaction.
2:58:33 Andy Piper - Acro Fencing AI and Acrobatics with Small Fast Drones:
2:59:51 Problem Statement: To enable safe acro flying within a defined fence, where the drone "bounces" off boundaries and returns control to the pilot, without crashing.
3:01:05 Key Requirements: Utilizes Lua scripting for guided control, enhanced fence support (minimum altitude, customizable margins), and improved attitude control for FPV pilots.
3:02:49 Fencing Enhancements: Andy details several PRs, including minimum altitude fencing (floor), fence margins (an inner warning boundary), and faster fence code updates for quick reactions.
3:04:02 Demo 1 (Simulated Fencing): Demonstrates "Loiter" mode reacting to minimum altitude and circular fences using object avoidance, slowing down and stopping at boundaries. Shows margin warnings when approaching inner fences.
3:09:01 Attitude Control APIs: Introduced new Lua scripting APIs to set target angle, rate, and throttle, providing granular control over vehicle attitude, velocity, and acceleration in guided mode.
3:10:11 Testing Methodology: Emphasizes extensive testing using auto tests and the RealFlight simulator.
3:11:10 RealFlight Improvements: Addresses RealFlight's jittery IMU timing by running a virtual IMU at a much higher rate (5000+ fps), resulting in significantly more stable flight dynamics in simulation.
3:16:36 AI Acrobatics (Google Gemini): Used Google Gemini (LLM) for rapid Lua script development, pair programming, and to create a "vehicle control library" for automated flips on a switch.
3:19:28 Demo 2 (Simulated Acrobatics): Shows the script engaging guided mode, performing 1, 2, and 3 flips (by applying high throttle for "escape velocity" then dropping it), then returning to loiter, effectively handing control back to the pilot.
3:24:53 Acro Fencing Demo (Simulated): In "Loiter" mode, the drone auto-takes off, then reacts to the minimum altitude fence by entering guided mode, reducing throttle, and returning control. When hitting the outer circular fence, it "flips" around and returns control, demonstrating the "bounce" effect. Same is attempted in "Acro" mode.
3:29:48 Real-World Testing: Initial real-world tests were "scary" but successful, with minor issues like an unchecked trim setting (causing an uncontrolled ascent) and spammy OSD messages.
3:30:41 Small Fast Drone Initiative: Plans to build and sell preconfigured small, fast drones with this capability, acknowledging the high precision and robust GPS/guided mode required.
3:31:39 Q&A Highlights: Discussions include the risk of "bouncing" outside the actual fence (a log file bug exacerbated this in early testing), the rationale for flipping (to maintain FPV pilot's situational awareness, rather than simply stopping), and the mode change mechanism (saves original mode, enters guided for maneuver, then restores original mode). Fail-safes include parking in loiter if hands off sticks or initiating RTL to loiter above home.
4:40:39 Flips on a Switch: Successfully demonstrates one, two, and three flips with a real drone. The EKF becomes "very upset" after three flips, requiring manual recovery.
4:48:01 Acro Fencing: Demonstrates acro fencing in loiter mode using a poly fence around a hill and a 40m margin fence. The drone performs an auto takeoff, hits the min alt fence, then the poly fence, flipping and returning control as in the simulation. An EKF lane switch at the end causes a shaky landing, emphasizing the need for robust GPS and EKF.
6:39:26 Steven Dade - ArduRover and ROS 2 Autonomy Demo:
6:39:26 Rover Configuration: Presents a Dagu-derived ArduRover running ArduPilot, a Raspberry Pi 4 (ROS 2 Jazzy), and a 2D LIDAR for mapping.
6:40:56 ROS Integration: ArduPilot provides IMU and odometry data to ROS, which fuses it with LIDAR scans to create a map of the environment. Connectivity uses a PPP link, ROS 2 DDS, Mavlink, and live video over Wi-Fi/ZeroTier VPN.
6:42:10 ROS GUI & Rviz: Shows a prototype ROS GUI displaying basic drone data (battery, arm/disarm, flight modes) from the micro ROS gateway, not Mavlink. An Rviz demo visualizes the LIDAR's rangefinder and Cartographer's map generation (with Nav2 for future path planning).
6:44:50 Live Mapping Demo: The rover is manually driven to map the conference room, demonstrating the gradual expansion of the map. Some map offsets over time are noted, highlighting challenges with Cartographer settings and IMU/LIDAR synchronization.
6:50:26 Onboard Processing: All mapping and video compression/transmission occurs locally on the Raspberry Pi 4, showcasing its capability to handle significant processing loads.
6:51:17 Q&A Highlights: Discusses the "fiddly" nature of tuning Cartographer on real hardware, the crucial need for tight time synchronization between ROS nodes and data feeds (LIDAR, IMU), and the importance of wheel encoders for accurate velocity estimation indoors without GPS.
6:55:55 Tom Pittinger - Krauss Hamdani Aerospace and ArduPilot Enhancements:
6:56:04 Company Success with ArduPilot: Krauss Hamdani Aerospace leverages ArduPilot for their K1000 ULE (Ultra Long Endurance) powered gliders, achieving records like 12 hours of soaring and 76 hours of continuous electric flight for Group 2 aircraft.
6:58:10 ArduPilot's Value: ArduPilot has enabled advanced capabilities such as soaring (making batteries "optional"), resilient flight after motor failures, IP-native networking for radio relay, precise landing on small runways, and in-flight reverse thrust for controlled descent. They regularly conduct Beyond Visual Line of Sight (BVLOS) operations.
7:00:49 Contributions to ArduPilot: Krauss Hamdani actively contributes back to ArduPilot, focusing on fixed-wing enhancements, networking, solar panel improvements, and safety features like ADSB. Sid Prohit's work on WSL2 and the VS Code extension is specifically praised.
7:04:54 Future Contributions: Plans to upstream numerous features, including fixed-wing improvements (e.g., "breaker" flight surface for drag), Mavlink multi-port support, parameter management tools, and AP_Periph capabilities (payload managers, pitot tube heaters). They also contribute to manufacturability with tools for serial loopback testing.
7:07:58 Challenges for Commercial ArduPilot Users:
7:08:21 Git Workflow: Rebase workflow causes hashes to disappear, making it difficult to trace flight logs back to specific code versions. Merge is preferred for maintaining a clear paper trail in expensive operations.
7:09:14 Misinformation: ArduPilot suffers from misconceptions ("8-bit Arduino," "open-source means low quality"), highlighting a need for better marketing and outreach.
7:10:04 Steep Learning Curve: The vast number of parameters (2000+) makes the learning curve steep, with many users only utilizing basic modes like Loiter and avoiding advanced features like auto-land. Efforts are needed to make it more accessible.
7:11:06 Feature Visibility: It's challenging to itemize ArduPilot's extensive capabilities, making it hard to communicate its value to potential commercial users.
7:12:05 Expert Availability: A lack of readily available ArduPilot experts for consulting creates a barrier for companies seeking paid solutions.
7:12:53 Upstreaming PR Process: The PR process is daunting for companies due to effort/cost-risk analysis, the requirement to test on master (when companies use stable releases), and the constant rapid evolution of the master branch (making rebase difficult).
7:16:39 Q&A: Configuration Management: Tim highlights the fundamental challenge of configuration management (firmware, build options, Lua scripts, parameters) for commercial users, emphasizing the need for tools to ensure consistency and traceability, especially under regulatory requirements. Tom agrees that parameter and hash management, including for Lua scripts and embedded defaults, are critical.
7:24:15 Closing Remarks: Matt and Ben express immense gratitude to all sponsors, 3DXR (including Becca for organization), Rishab, Q Branch (for live stream production), all speakers and presenters, and the wider ArduPilot dev team and community for their passionate contributions, concluding the conference.