Autonomy Integration Intensive PX4 ROS2 MAVLink
PX4 ROS2 MAVLink MAVSDK - Agentic Drone
-
Participants can interact with the instructor,
ask questions, seek clarification,
and receive immediate feedback. -
You can receive a full refund before
the second session. After attending
the second session, you will not be eligible
for a refund. -
Access to the session that was originally
conducted in real time. -
You can retake the same course you attended.
-
We will provide you with the notes for the course.
-
We will provide you with the homework
assignments for additional practice. -
You can always reach out to the instructor
between sessions or after the course on Slack.
Full price
Bundle and save
4-times payment
calculated by Klarna
Buy now, pay later
calculated by Affirm
Upcoming Enrollment
November 2nd - November 6th
5 sessions 6 hours each
Online, US Eastern Time
By the end of day five, you have built, tested and demonstrated a packaged autonomy capability that runs on your own stack — and you can read the logs that prove it works.
Drone autonomy roles are advertised at $120,000 to $290,000 and go unfilled for months. The expertise sits with a few thousand engineers worldwide, and the conventional channels are not producing more of them. That is a genuine opportunity if you already write good Python and understand Linux, and the barrier is narrower than it looks — it is a specific, teachable body of knowledge, not a decade of aerospace.
The problem is that the usual way in does not close the gap. You can follow tutorials until you have a script that arms a simulated aircraft and flies a mission. It runs on your laptop. And then you stop, because everything past that point — offboard authority, failure recovery, DDS on a network that blocks multicast, log forensics, packaging your work so a team could maintain it — is where the tutorials end and the actual job begins.
This week is that gap, compressed into five days and taught in the order it makes sense: understand the system, command it safely, make the code survive a team, read the evidence, then build something of your own and demonstrate it.
You will write something ugly on day one. That is deliberate. On day four you refactor it, and you will understand why it mattered because you can feel the problem in your own code rather than being told about it.
What You Walk Away With
The ability to command an aircraft correctly, not just once.Missions driven by live telemetry rather than fixed sleeps, with clean entry into and exit from offboard mode, and explicit state machines that recover from a rejected command instead of hanging.
Knowledge of what actually happens when things break.Six failure modes induced on real hardware, predicted out loud first and then observed — including the case most teams have never tested, where the companion computer is alive but wedged, presenting a healthy link, a live process and frozen setpoints.
ROS 2 that works on a real network.Not the tutorial version. You reproduce a DDS discovery failure, then fix it with a Discovery Server you configure yourself, on a network that blocks multicast the way onboard radios and corporate networks routinely do.
Engineering practice that makes you hirable rather than merely capable.Configuration externalized, mission logic testable without a vehicle, dependencies pinned, tests running headlessly against simulation in a CI pipeline you build in the room and watch go green.
Flight data literacy.The skill that separates you from everyone who only ever opens a log in a web viewer: programmatic access with pyulog, the signals that matter, and scripting one metric across an entire archive to find a pattern across a hundred flights rather than reading one at a time.
Evidence you can put in front of an interviewer.A capstone that runs end to end, a recording of it running, and log analysis confirming the behaviour you claim. That is a materially stronger thing to bring to a hiring conversation than a certificate.
Core Objectives
The week is built on one premise: this capability is acquired by building things and breaking them under supervision, not by watching someone else do it. Every session ends in something you made and can demonstrate.
You start with the architecture on a whiteboard — what the flight controller is responsible for, what it must never be responsible for, and why the companion computer exists at all. Nearly every later confusion traces back to that boundary, so it gets proper time rather than a hurried diagram. From there you fly a mission in simulation from Python you wrote, move to offboard control and the authority question, and then to mission state machines and recovery, which is the single biggest gap in most working flight code.
Midweek you cross into ROS 2 and the uXRCE-DDS bridge, including a full afternoon on the network behavior that breaks in the field and never in the tutorial. Thursday is practice and evidence: packaging, testing, CI, and log forensics. Friday is yours — you build, test, package and demonstrate a capability of your own choosing, with the instructor circulating and asking questions rather than supplying answers.
Skills You Will Walk Away With
-
1
Core System Diagnostics & Flight Management
- GUI-to-Terminal Synergy: You will master mapping visual indicators in QGroundControl (QGC) directly to the underlying terminal commands (pxh>) and parameters in PX4.
- Low-Level Vehicle Status Diagnosis: You will be able to look at a drone that refuses to arm and pinpoint the exact blocker (e.g., sensor calibration issues, EKF health, or missing safety links) using commander check and status
- Firmware Configuration & Param Mastery: You will understand the PX4
-
2
System Safety & Deterministic Failure Handling
- Failsafe System Architecture: Hold, Return, Land, Terminate for critical failures
- Sensor-in-the-Loop Failure Injection: test how your software reacts to real-world emergencies
- EKF2 Interrogation: How PX4 builds its mathematical understanding of where it is in 3D space
-
3
Hardware Translation & Vehicle Dynamics
- Control Allocation & Geometry Mapping: How PX4 translates abstract concepts (like "yaw left") into specific electrical signals sent to individual motors. You will acquire the skill to modify physical aircraft geometries in code (SDF files) and align them with the PX4 control matrix (CA_ROTORn_*)
-
4
Modern Robotics Integration
- Micro-XRCE-DDS Middleware Engineering: Master the communication bridge between Linux/ROS 2 and the real-time operating system NuttX
- Prevent silent data loss: Learn QoS
- Offboard Control Loop Programming: Write ROS 2/Python nodes
- Coordinate Frame Transformation: Master mapping spatial coordinates back and forth between PX4’s NED and ROS 2
-
5
Data Literacy & Alternative API Frameworks
- Aeronautical Data Forensic Analysis: ULog/Flight Review/PlotJuggler
- Architectural Trade-Off Analysis: uXRCE-DDS/ROS 2 architecture and MAVSDK architecture
Schedule & Enrollment
| Date | Time |
| Nov 02 | 10:00 a.m. - 05:00 p.m. |
| Nov 03 | 10:00 a.m. - 05:00 p.m. |
| Nov 04 | 10:00 a.m. - 05:00 p.m. |
| Nov 05 | 10:00 a.m. - 05:00 p.m. |
| Nov 06 | 10:00 a.m. - 05:00 p.m. |
Instructors
Art Yudin
Questions? Check here
No. Everything you build runs in simulation on your own machine, and the failure-ladder and bench sessions are run live on the instructor's Pixhawk and companion computer, with props removed. If you do own hardware, you are welcome to bring your configuration into the capstone — but nothing about the week requires it.
Because the material compounds, and the gaps between weekly sessions are where momentum dies. The escalation from "wrote a script" on Monday to "built, tested and demonstrated a capability" on Friday only works if the code you wrote on day one is still fresh in your hands on day four when you refactor it.
The default track is PX4, and the architecture, authority model, failure ladder and engineering practice transfer to ArduPilot directly. Where the toolchain differs — GUIDED rather than OFFBOARD, AP_DDS rather than an external bridge, MAVExplorer and UAV LogViewer rather than pyulog and PlotJuggler — the differences are taught explicitly rather than skipped, so you are not lost the first time you meet the other stack.
Live, five consecutive days. Sessions are recorded and the archive is yours permanently, but the recordings are a reference for afterwards rather than an alternative to attending — most of the value is in being unblocked by an instructor while you are actually stuck.
It will not get you one by itself, and treat anyone who promises otherwise carefully. What it changes is what you can demonstrate. Most candidates for these roles arrive with a tutorial mission script; you arrive with packaged code in CI, a documented failure ladder, a network fix you can explain from first principles, and a capstone with log evidence. That is a substantially different conversation, and it is the part of the gap a course can honestly close.
No. Everything you build runs in simulation on your own machine, and the failure-ladder and bench sessions are run live on the instructor's Pixhawk and companion computer, with props removed. If you do own hardware, you are welcome to bring your configuration into the capstone — but nothing about the week requires it.
Because the material compounds, and the gaps between weekly sessions are where momentum dies. The escalation from "wrote a script" on Monday to "built, tested and demonstrated a capability" on Friday only works if the code you wrote on day one is still fresh in your hands on day four when you refactor it.
The default track is PX4, and the architecture, authority model, failure ladder and engineering practice transfer to ArduPilot directly. Where the toolchain differs — GUIDED rather than OFFBOARD, AP_DDS rather than an external bridge, MAVExplorer and UAV LogViewer rather than pyulog and PlotJuggler — the differences are taught explicitly rather than skipped, so you are not lost the first time you meet the other stack.
Live, five consecutive days. Sessions are recorded and the archive is yours permanently, but the recordings are a reference for afterwards rather than an alternative to attending — most of the value is in being unblocked by an instructor while you are actually stuck.
It will not get you one by itself, and treat anyone who promises otherwise carefully. What it changes is what you can demonstrate. Most candidates for these roles arrive with a tutorial mission script; you arrive with packaged code in CI, a documented failure ladder, a network fix you can explain from first principles, and a capstone with log evidence. That is a substantially different conversation, and it is the part of the gap a course can honestly close.
The default track is PX4, and the architecture, authority model, failure ladder and engineering practice transfer to ArduPilot directly. Where the toolchain differs — GUIDED rather than OFFBOARD, AP_DDS rather than an external bridge, MAVExplorer and UAV LogViewer rather than pyulog and PlotJuggler — the differences are taught explicitly rather than skipped, so you are not lost the first time you meet the other stack.
Live, five consecutive days. Sessions are recorded and the archive is yours permanently, but the recordings are a reference for afterwards rather than an alternative to attending — most of the value is in being unblocked by an instructor while you are actually stuck.
It will not get you one by itself, and treat anyone who promises otherwise carefully. What it changes is what you can demonstrate. Most candidates for these roles arrive with a tutorial mission script; you arrive with packaged code in CI, a documented failure ladder, a network fix you can explain from first principles, and a capstone with log evidence. That is a substantially different conversation, and it is the part of the gap a course can honestly close.
It will not get you one by itself, and treat anyone who promises otherwise carefully. What it changes is what you can demonstrate. Most candidates for these roles arrive with a tutorial mission script; you arrive with packaged code in CI, a documented failure ladder, a network fix you can explain from first principles, and a capstone with log evidence. That is a substantially different conversation, and it is the part of the gap a course can honestly close.