RoboticView

PX4 Offboard Control & ROS 2 Drone Development

Your airframe, your data Not a generic training rig.

Engineered for Your Team. Calibrated to Your Codebase.

Customized to Your Team

Unlike generic public courses, our corporate training can be tailored to your company’s technology stack, workflows, skill gaps, and business objectives.

Enterprise Inquiry

Interested in this service?

Leave your email and our team will be in touch.

Share it

Autonomous Drone Programming - on your airframe, with your flight data

By the end of day three, every participant has written a Python mission script, run it in simulation, run it against your own aircraft with props off, and read the log it produced.

Most drone and robotics teams reach the same wall at the same point. The aircraft flies. Someone has a script that arms it and flies a mission. It works on one laptop, it is understood by one person, and nobody can say with confidence what happens if that script stops mid-flight. When something goes wrong in the air, the investigation is a conversation rather than an analysis, because nobody on the team can read the flight log at the level the log actually supports.


That wall is expensive in three specific ways. Autonomy work stays bottlenecked on one or two individuals. Integration bugs surface at the field site instead of in a test suite. And incidents cost days of guesswork that a scripted log analysis would have resolved in an hour.


This intensive removes that wall in three days, using your hardware and your data rather than a generic training rig. Participants do not watch a demonstration. They build the software, they break it deliberately on your bench, and they leave with a tested, packaged version of it in your repository.


Key Business Outcomes & ROI

Autonomy stops being one person's job. More than one engineer can safely write, review and modify flight software — which removes the single point of failure that most autonomy teams are quietly carrying.


Failure behavior becomes known rather than assumed. Failure modes are tested on a bench with props off, on a schedule, rather than discovered in the air. The predicted-versus-actual table stays with your team as a reusable test artifact.


Incident investigation becomes evidence-based. Your team can query a hundred flights for a pattern instead of opening one log in a viewer, which turns a multi-day guessing exercise into an hour of analysis.


Prototype code becomes maintainable software. Configuration externalized, mission logic testable without a vehicle, dependencies pinned, tests running in continuous integration.


You get an honest external read. A one-page written review of your stack — what you have, what is missing, what to fix first, and what to avoid for now.


Core Training Objectives

The program is built on one premise: engineers acquire this capability by doing it on real hardware under supervision, not by watching it done. Every session ends in something the participant built and can demonstrate.


Teams learn to command an aircraft from Python correctly — driven by live telemetry rather than fixed sleeps, which is the difference between a script that works once and one that works every time. They learn the authority boundary in offboard control, and what the vehicle actually does when a setpoint stream slows or stops. They induce five real failure modes on their own aircraft and write down what happened. They refactor two days of working, unmaintainable code into a tested package running in CI — taught deliberately late, after participants can feel the problem themselves. They cross into ROS 2 and uXRCE-DDS, including the DDS discovery failure that onboard radios and corporate networks reliably produce, demonstrated as a failure first and then fixed. And they spend the highest-value three hours of the workshop reading their own flight data as evidence.

Skills You Will Walk Away With

  1. 1

    Commanding an aircraft from Python, correctly

    • Connecting to a vehicle with MAVSDK-Python and working with its asynchronous model
    • Arming, taking off, navigating waypoints and landing - driven by live telemetry rather than fixed sleeps
    • Reading MAVLink: message anatomy, stream rates, request patterns, heartbeats, and how to read a pre-arm rejection instead of guessing at it
    • Knowing what each flight mode actually asserts about who holds control of the aircraft
  2. 2

    Offboard control and the authority boundary

    • Entry and exit conditions for OFFBOARD PX4, and exactly who holds authority at each moment
    • Setpoint streaming rates, and what the vehicle does when the stream slows or stops
    • Choosing between position, velocity and attitude setpoints for the job at hand
    • Measuring control-loop latency rather than estimating it
  3. 3

    Failsafe behavior, tested on your own aircraft

    • A five-rung failure ladder: clean script exit, killed process, disconnected serial cable, companion computer power loss, and the case most teams have never tested — a companion computer that is alive but wedged, presenting a healthy link, a live process and frozen setpoints
    • A written table of predicted versus actual behavior that stays with your team as a test artifact
  4. 4

    Turning prototype scripts into maintainable software

    • Externalizing configuration - no more hardcoded coordinates
    • Separating mission logic from transport so the logic can be tested without a vehicle
    • Writing tests that run headlessly against simulation
    • Packaging with pinned dependencies so a colleague clones the repository, runs one command, and the tests pass on their machine
    • Running it in CI - the moment the discipline becomes real rather than aspirational
  5. 5

    ROS 2 alongside PX4, including the parts that break in the field

    • Nodes, topics and services, compared honestly against the MAVLink model participants now understand
    • Bringing PX4 topics into ROS 2 over uXRCE-DDS and writing subscribers against real vehicle state
    • Why default DDS discovery depends on UDP multicast, and why onboard radios and corporate networks routinely will not carry it — demonstrated as a failure first, then fixed with a Discovery Server
    • Large-data transport for video and point clouds, and socket buffer sizing whose defaults assume a desktop LAN
  6. 6

    Reading flight data as evidence

    • ULog structure, logging rates, and what you are silently missing
    • Programmatic access with pyulog - the capability that makes your team true professionals
    • Interactive investigation in PlotJuggler, with saved layouts your team reuses
    • EKF innovations, estimator resets, vibration, mode transitions and the timing
    • Scripting a metric across your entire log archive to find patterns

Questions? Check here