The ArduPilot Developers Conference 2025 showcased significant advancements and diverse applications of the ArduPilot platform, featuring a range of technical presentations and live demonstrations. Key themes included the development of sophisticated drone hardware and software, leveraging companion computer ecosystems like Blue OS for enhanced autonomy, and operationalizing drone fleets for complex missions such as last-mile delivery and swarm coordination. Speakers detailed innovations in building an ArduPilot-based aerial photography drone with high-altitude optical flow, managing over 15,000 flight hours in commercial drone delivery, orchestrating 100-drone swarms for self-organized missions, and exploring advanced control topics like BVLOS telemetry and TECS controller tuning. The conference also highlighted efforts in aerospace engineering education using ArduPilot, the introduction of a methodic configurator to streamline user setup, and new tools for plane system identification. Recurring challenges discussed included managing regulatory compliance, human error, hardware integration, and the need for improved documentation and community support. The event underscored the open-source community's collaborative spirit and continuous drive for innovation and robust drone solutions.
Summarizing the ArduPilot Developers Conference 2025: Key Presentations and Insights
0:00:13 Conference Welcome & Logistics: The ArduPilot Developers Conference 2025, hosted by 3DXR, opens with sponsor acknowledgements and administrative announcements regarding the conference area, improving weather outlook, NOTAMs, a busy schedule, and details for the conference dinner in Richmond. A key initiative is offering new hardware to developers using outdated equipment, with James as the contact. Bus transport to Darlington train station is arranged for Sunday departures.
0:19:04 Small Aerial Photography Drones with AP (Randy Mai Presentation): Randy Mai discusses the creation of an ArduPilot-based aerial photography drone aiming for Mavic-like capabilities (4K video, real-time telemetry, 30+ min flight, smart battery, object avoidance, cloud integration, user-friendly, affordable).
0:21:12 Hardware: Features a Cube Orange Plus, Herefor GPS, Cube Node (for Ethernet), Raspberry Pi Compute Module 4/5, AM32 ESCs, QuecTel LTE modem, XFroot Z1 mini 3-axis camera gimbal, Hereflow optical flow, and two Benwaki Lidars (TF20L downward, TF Nova forward). It uses T-Motors 400KV (6S) with MAD 12in props and Foxtech semi-solid state batteries, all integrated into a 3D printed frame with a custom carrier board.
0:25:50 Flight & Custom Carrier Board: Initial test flights were successful with a stock ArduPilot tune. The custom carrier board significantly improves rigidity, reduces vibration, simplifies wiring, and manages heat distribution.
0:30:17 Software & Blue OS Integration: The software stack emphasizes over-the-air (OTA) updates for all components, with ArduPilot 4.7 at its core. Blue OS runs on the companion computer, providing a versatile platform for Docker-based extensions.
0:31:57 Why Blue OS: Blue OS offers an existing ecosystem with a dedicated development team, business model, user community, and robust support for ArduPilot, enabling capabilities not feasible on the flight controller itself. Its Docker-based extensions simplify integration of Python programs with custom UI settings.
0:35:08 Blue OS Applications: Key applications include LTE telemetry (via ZeroTier), high-altitude optical flow (using the main camera gimbal, effective up to 100m+ by eliminating rotational noise and leveraging RPi's CPU power), precision landing with April tags, and automatic cloud upload for images/videos.
0:36:34 Future Plans: Randy aims for robust live video, cloud-based log uploads, visual follow-me, and Nvidia/Jetson support for enhanced image processing. He invites community input and collaboration on drone manufacturing, hardware development (smaller gimbals, Ethernet autopilots), and Blue OS contributions.
0:53:09 Blue OS Update (William Gavveni Presentation): William Gavveni details the evolution and features of Blue OS, designed as an embedded ecosystem on Linux using Docker containers for modularity and reliable updates.
0:55:01 Architecture & Goals: Blue OS addresses limitations of older companion software, aiming for modularity, reliable updates, and a dynamic web UI. It uses a Core container for services and a Bootstrap container for system recovery. Performance-critical services like the Mavlink server are written in Rust.
0:58:48 Key Developments: Recent updates include H.265 video support, expanded camera/gimbal configuration, and Mavlink camera manager improvements. Safety features now warn users about armed vehicles or dangerous actions. The UI offers enhanced compass/diagnostics views, visual AHRS orientation helpers, and 3D vehicle models.
1:02:07 Networking & Mavlink Routing: Blue OS provides detailed network connectivity status, configurable interface priorities, an API for IP routes, and a backup DHCP server. Ethernet-based flight controller support has been integrated. The Rust-based Mavlink server offers efficient routing and diagnostics.
1:04:09 Extensions & Roadmap: The Docker-based extension system allows external applications to integrate widgets and actions into the Cockpit UI. Future plans include Zeno integration for synchronized logging and efficient front-end communication, MCAP file support for comprehensive system replay, enhanced ROS integration, and Foxglove visualization. Improved resource management, notification systems, and a more user-friendly service management UI are also planned. William encourages users to try Blue OS and provide feedback.
1:21:11 Instructing Users on ArduPilot (Lee Chafield Presentation): Lee Chafield, known as "Painless 360," offers six key tips for providing free community support to ArduPilot users.
1:24:49 Six Top Tips: He advises setting clear boundaries and expectations for support interactions, avoiding overly quick responses to manage user expectations, and addressing lazy or rude questions with requests for more detail. Crucially, he advocates a zero-tolerance policy for trolls (deleting and banning comments) to maintain a positive community. Lee emphasizes helping users understand troubleshooting principles rather than just fixing symptoms, and titling content with user-centric search terms. Finally, he suggests considering potential cognitive issues in users and avoiding support when in a bad mood, highlighting the importance of patience and respect.
2:00:58 Turbine Helicopter Demo (Fuchio Vicari): Fuchio Vicari demonstrates a turbine helicopter, showcasing his contributions to ArduPilot's AP Heli Motors library for turbine engine support. The demo includes a takeoff, hover check, auto mode, and acro flight, with ArduPilot managing head speed governing and a turbine cool-down phase.
2:20:07 MANA Drone Delivery: Challenges and Journey (Charlie Burge & Dan Moss Presentation): Dan Moss and Charlie Burge from MANA detail their journey in last-mile drone delivery, highlighting operational challenges and solutions.
2:20:07 MANA Operations: MANA operates in Texas, Dublin, and Helsinki, delivering up to 4kg packages in 3 minutes, 7 days a week, in challenging Irish weather. Deliveries are made via winch from 14 meters.
2:24:09 Development Approach: MANA's "Crawl, Walk, Run" strategy involved rapid prototyping and environmental testing, scaling to automated operations with robust checks for commissioning, quality control, and pre-arm procedures. Simplicity and safety are paramount in their high-volume operations (thousands of flights daily).
2:28:19 Scale & Reliability: Their Dublin operation demonstrates significant daily flight volumes. MANA operates under European SAIL 3 regulations and has accumulated over 15,000 flight hours across diverse conditions. They use Continuous Probability Monitoring (CPM) to track reliability, with "top-level" failures (simultaneous component failures) impacting confidence.
2:35:57 Learnings from Failures: Analysis revealed that human error (e.g., accidental RC switch activations) was a more common failure mode than sensor issues. This led to phasing out complex RC transmitters in favor of simplified 4-button interfaces for operators. Automation is extensively used for pre-flight checks, 4D flight routing, and adaptive weather responses to minimize human interaction.
2:45:52 Key Achievement: MANA drones have cumulatively flown a distance equivalent to over three trips to the Moon, largely powered by ArduPilot. Noise pollution is addressed through propeller design and intelligent routing strategies.
3:00:57 BVLOS Telemetry Options (Stephen Dade Presentation): Stephen Dade outlines options for Beyond Visual Line of Sight (BVLOS) flights, emphasizing the need for robust GCS and data links.
3:01:42 Mavlink Bandwidth: ArduPilot telemetry typically requires 3-3.5KB/s (reducible to ~1KB/s), with data spikes during parameter transfers. Granular control over Mavlink messages helps manage bandwidth. The Mavlink High Latency Protocol (52 bytes every 5 seconds) suits very low-bandwidth systems like LoRa or short-burst satellite.
3:09:23 Radio Options: Cellular (4G/5G/LTE) offers good range with lower frequencies; ArduPilot 4.6+ supports direct UART modem connection. Satellite communication (Starlink Mini, Iridium Certus, SBD systems) is expensive and bulky but provides global coverage. Meshed radios and relay aircraft are alternatives.
3:15:14 Multiple Links & Cybersecurity: Managing multiple links requires de-duplication of Mavlink packets and preventing bridging loops. Other considerations include real-time video bandwidth (Mb/s), companion computer access, GCS redundancy, and GCS failsafe configuration. Cybersecurity is crucial: use encryption, unique passkeys, VPNs/IPsec/Mavlink signing, and UDP over TCP for lossy links. A triple-redundant system (RFD900, satellite, 4G) provides a robust BVLOS solution.
3:22:38 Multi-UAV Missions with ArduCopter and Skybrush (Gabbor Vasarili Presentation): Gabbor Vasarili from Koma Robotics and the University of Budapest presents their work on intelligent drone swarms and multi-UAV missions, built on ArduPilot and Skybrush.
3:22:50 Koma Robotics: A 10-year-old spin-off focused on intelligent drone swarms. They use an open-core business model, relying on ArduPilot, with income from Skybrush software licenses.
3:25:07 Drone Swarms: Since 2016, they've scaled to over 100 autonomous, self-organized drones, demonstrating "flocking behavior" (ad-hoc Wi-Fi communication) and "traffic situations" (collision avoidance for individual routes in dense environments). Simulations extend to 5,000 drones.
3:27:30 Tech Stack: Utilizes Pixhawk-family autopilots, Odroid companion computers, Wi-Fi, secondary radios, and RTK GPS. The software stack includes ArduCopter+Mavlink, closed-source "Flock Control" algorithms, and the open-core Skybrush ground station. A full Software-in-the-Loop (SITL) simulation framework is crucial for testing large swarms.
3:31:33 Skybrush Ecosystem: Skybrush Live (fully open-source front-end) is optimized for multi-UAV mission operation and monitoring. The ecosystem also includes open-source firmware and standardized protocols.
3:32:58 Use Cases: Skybrush is used for drone shows (including an early UK show at Buckingham Palace with a 3.5-minute permit), precision agriculture (terrain-following crop spraying), and R&D for multi-drone/UGV distributed surveillance. A demo shows Skybrush Live for mission planning, execution, monitoring, and real-time control, adaptable for various applications.
3:36:33 Log Analyzer: A new Q&A style log analyzer (poplan.sky.io) is in beta, offering quantitative answers for drone tuning and error checking.
4:39:53 Fleet Management and Automated Operation (Yogesh Khadar Presentation): Yogesh Khadar, CEO of Outri, introduces the "OS" software platform, a cloud-native solution for simplifying complex drone operations.
4:40:57 The Problem: Manual drone operations are complex and prone to errors across planning, flight execution, data capture, storage, and analysis.
4:41:52 Outri OS Solution: OS centralizes all operational stages into a single app, reducing errors and increasing efficiency and compliance. Its architecture features a Kubernetes-based backend and a "Sky Client" on drone companion computers, integrating with Mavlink (ArduPilot/PX4) and DJI SDKs.
4:43:34 Open Source & Multimodal: Outri has contributed to open-source projects like ME SDK with ArduPilot support. OS is multimodal, controlling various vehicles (drones, rovers, boats, DJI docks) and sensors, including motion sensors that can trigger automated flights.
4:45:09 Fleet Management: The platform provides a fleet overview, exportable compliance data, individual device monitoring (flight history, parameter tracking), cloud-synced logs, and Sky Client UI for companion computer configuration (cameras, modems, offline maps).
4:48:11 Automated Operation: OS streamlines automated operations through geo-zone management (custom and aviation data), plan management (complex waypoint missions with actions), and mission creation (scheduled, recurrent flights with pre-flight checklists for unattended workflows). The control station allows real-time monitoring and control, including object detection and DJI Dock integration. Data is synced post-flight for photogrammetry and 3D model generation.
4:52:18 Roadmap: Public beta includes mapping, automated photogrammetry, and object tracking. Future features comprise AS-based flight simulation, direct firmware upgrades, offline maps, and mission sharing.
4:58:59 Exploration of TECS Parameters (George Sopuoulos Presentation): George Sopuoulos presents an exploration of ArduPlane's TECS (Total Energy Control System) controller parameters, using extensive SITLE simulations.
5:00:49 Methodology: He detailed a methodology involving repeatable missions, custom Python scripts for parameter sampling (260-300 runs), and analysis using pyMavlink tools and TinyDB to extract and plot metrics like oscillations, overshoot, rise time, and climb rate error. Repeatability was good for stable flights.
TECS_TIME_CONST: Dictates TECS responsiveness; low values cause oscillations and overshoot, while higher values (above a minimum for stability) have limited further impact.
TECS_HDM_TIME_CONST: Controls altitude demand rate; increasing it improves stability (less overshoot) but increases rise time.
TECS_INTEG_GAIN: Essential for correcting airspeed and altitude errors; zero value leads to poor control, but excessive values can cause pitch oscillations.
TECS_PITCH_DAMP: Acts like a proportional gain for pitch, enhancing dynamics.
Troubleshooting: Differentiating pitch vs. throttle issues is challenging due to coupling; energy balance rate logs can help.
Climb Performance: TECS typically limits climbs to ~90% throttle in normal flight to avoid exceeding pitch or throttle limits, a behavior that may be revisited.
Miscellaneous:TECS_HEIGHT_OMEGA is usually inactive with EKF, but TECS_SPEED_OMEGA is crucial and should not be zero.
5:33:54 Future Work: Includes improving script repeatability with confidence intervals, testing on more diverse vehicle models, and exploring TECS autotuning methods, such as automating parameter limit maneuvers and system identification.
5:43:04 Design Build Fly β ArduPilot in Aerospace Education (Bob Entistle & Cameron Boyd Presentation): Bob Entistle and Cameron Boyd from Southampton UAV describe their "Design, Build, Fly" project-based teaching method, integrating ArduPilot into aerospace engineering education.
5:43:16 Southampton UAV: Showcased advanced aircraft like the "Spotter" fixed wing (35kg, 4m wingspan, BVLOS operations), "Valerie" (volcano monitoring), and "Fire Drones" (heavy-lift multirotor).
5:47:23 Student Projects: Second-year students undertake a fixed-wing project to design wings for speed range and Arduino-controlled gimbals, tested in semi-automated flights with a custom live data dashboard. Fourth-year Group Design Projects (GDPs) involve designing and building UAVs (e.g., blown flap aircraft, precise aid delivery tail-sitters, competitive "FASTER" drones, winch-lowered droids, person-portable UAVs) over eight months, emphasizing practical application of theory.
6:03:30 ArduPilot Resources: Southampton UAV provides Boeing-sponsored ArduPilot starter kits, online guidance documents, a live data dashboard (using WebSockets to Mission Planner), and in-person advice.
6:07:15 Challenges: They discuss challenges like radio interference in multi-team environments, students being overwhelmed by documentation, ensuring safety with complex systems (e.g., students disabling arming checks, unexpected parameter permutations), and identifying skills missing from graduates for industry needs. They invite industry collaboration on design briefs and research opportunities.
7:11:18 ArduPilot Methodic Configurator (Amalkar Lucas Presentation): Amalkar Lucas introduces his "ArduPilot Methodic Configurator" (AMC), aiming to simplify and standardize the ArduPilot configuration process.
7:12:01 Problem & Solution: AMC addresses the complexity of ArduPilot's flexibility and overwhelming documentation (1600+ wiki pages), which leads to incorrect configurations. It offers a wizard-like, semi-automated interface that guides users through configuration steps in a specific, mandatory sequence.
7:14:49 Key Features: AMC provides all relevant information (parameter defaults, limits, firmware-specific documentation, wiki links, component specs, connections) in a single view. It enables users to document why they change parameters, automates Lua script installation, and performs parameter backups at the start of every session.
7:20:26 Workflow: The wizard checks for updates, connects to the FC, facilitates project creation/opening, and guides through parameter configuration, from initial optional steps (e.g., FC in freezer) to mandatory basic setup, minimalistic tuning for flight readiness, optional advanced tuning, and everyday use settings. Experimental steps are divided into setup, flight, and data feedback stages.
7:26:11 Reliability & Compliance: AMC has been used successfully on vehicles from 600g to 350kg, with 1,644 regression tests and few known bugs. Its Python-based engine is data-driven, reading all configuration logic from JSON files and linked Markdown documentation. This allows easy customization and addition of support for new vehicles or firmwares without Python coding.
7:32:01 Roadmap: Near-future plans include simplifying ESC configuration (frame type selection, voltage warnings, automated motor testing), status messages, and automated log file downloads. Long-term goals aim for Betaflight-level user-friendliness and expanded vehicle support.
7:35:25 Documentation & AI Chatbot: AMC offers extensive documentation and an ArduPilot-trained AI chatbot (accessible on the AMC website) that has indexed the entire ArduPilot wiki, CubePilot, CUAV, Holybro documentation, and YouTube video subtitles, aiming to reduce human error and increase configuration speed, consistency, and traceability.
7:47:16 Plane System ID (Bill Guyire Presentation): Bill Guyire details the implementation of System ID for ArduPlane and QuadPlane, a tool to characterize aircraft dynamics for better tuning.
7:48:31 Implementation: Unlike Copter/Heli (flight mode), System ID in Plane/QuadPlane is an AUX function (RC_FUNCTION 184) running on top of flight modes (QStabilize, QHover, QLoiter for VTOL; FlyByWire_A, Loiter, Guided/Auto for fixed-wing). It's currently for pitch and roll only in fixed-wing mode.
7:50:40 Status & Parameters: QuadPlane VTOL System ID is merged into 4.7 (master) and 4.6. Fixed-wing implementation is nearing completion. Key parameters control oscillation amplitude (SID_MAGNITUDE, 5 degrees recommended), frequency range (SID_START_FREQ/SID_STOP_FREQ), record length (SID_T_REC), and linear amplitude ramping (SID_FADE_IN/SID_FADE_OUT).
7:56:36 Usage: Users must compile custom firmware (not in standard builds). SID_AXIS is set to define the test, and SCHED_LOOP_RATE should be 100Hz for optimal logging (LOG_BITMASK). In-flight, after takeoff, maintain constant height and speed (crucial for fixed-wing). Activate System ID via an AUX switch. For planes, LOITER mode with a large radius helps maintain control during pitch sweeps. A stable initial tune is critical to prevent instabilities.
8:01:42 Analytic Tune & Good Tune Definition: System ID data is used in Analytic Tune to generate Bode plots, showing gain and phase versus frequency. A good tune aims for 0dB gain (output equals input) as high as possible, no overshoots, and 0-degree phase for broad frequency ranges.
8:04:27 Theory & Demo: Analytic Tune determines bare airframe dynamics and analytically wraps control loops based on linear system theory. Non-linearities can affect results. A demo of the Analytic Tune tool shows how to compare predicted vs. calculated responses and adjust gains to achieve desired Bode plot characteristics.
6:38:39 Small Aerial Photography Drone Demo (Randy Mai): Randy Mai attempts a live outdoor demo of his small aerial photography drone, aiming to showcase high-altitude optical flow and precision landing.
6:46:09 Mission Plan: The drone was programmed to take off to 20m, fly forward 40m, hover, then switch to optical flow, turn off GPS, climb to 100m, hover, return at 40m, and attempt precision landing on April tags.
Demo Outcome: The demonstration encountered significant connection and GPS issues (low satellite count, potential cold block) with the main drone. While the drone did eventually arm in Auto and performed the high-altitude optical flow flight (climbing to 100m with GPS turned off, and showing drift when GPS re-engaged), it failed to perform precision landing (did not detect the April tag target). A second attempt with a smaller drone also faced connection and GPS issues, resulting in a manual flight in Stabilize mode, thus not showcasing the intended Blue OS features.