UAV Autonomy Engineer Job Description

A UAV autonomy engineer writes the software that lets an uncrewed aircraft decide for itself where it is, what is around it and what to do next. The pilot's hands come off the sticks, and the code has to carry the flight: holding position in gusty wind, routing around a tower that is not on the map, finishing a survey line after the radio link fades, or landing safely when a sensor fails.

On a typical drone the work splits into two layers. An autopilot such as PX4 or ArduPilot runs the inner loops: attitude stabilization, motor mixing, the basic flight modes. The autonomy engineer usually works one layer up, on a companion computer that runs Linux and ROS 2 and feeds the autopilot position, velocity or attitude targets. PX4's documentation describes exactly this arrangement: in offboard mode the vehicle obeys setpoints from a source external to the flight stack, such as a companion computer, sent over MAVLink or ROS 2. It also requires a continuous 2Hz "proof of life" signal from that external controller, which is the kind of detail that shapes how an autonomy engineer designs failsafes. If the planner hangs, the aircraft has to fall back to something sane on its own.

The software itself breaks into familiar robotics pieces, each with an aviation twist:

• State estimation. Fusing IMU, GNSS, barometer, magnetometer, optical flow and camera data into a position the rest of the stack can trust, including when GNSS is jammed, spoofed or simply blocked under a bridge.
• Perception. Detecting obstacles, terrain, power lines, people and other aircraft from cameras, lidar or radar, on a computer small and light enough to fly.
• Planning and decision-making. Generating trajectories that respect airframe limits, geofences, altitude ceilings and battery reserve, and deciding when to continue, hold, return or land.
• Mission and fleet logic. Turning an operator's intent ("inspect this corridor," "search this grid") into behavior, sometimes across several aircraft at once.

Regulation is written into the code, not just the operations manual. Under the FAA's Remote ID rule, a standard Remote ID aircraft must automatically test its Remote ID functionality before takeoff and must not be able to take off if the Remote ID equipment is not functional. Engineers implement that gate, along with geofences, altitude limits and lost-link behavior that an operator's approvals depend on.

A working week mixes three settings. At the desk: writing C++ and Python, reviewing pull requests, tuning estimators. In simulation: software-in-the-loop and hardware-in-the-loop runs in tools such as Gazebo, replaying logged flights against new code. On the range: flight tests with a test pilot and a test director, followed by hours of log analysis to work out whether a bad landing came from the estimator, the planner or a vibrating camera mount.

The job sits between several teams. Autonomy engineers trade requirements with controls engineers who own the autopilot, hardware engineers who pick sensors and compute, payload teams, and the operators or soldiers who will actually fly the system. In defense work they also answer to evaluators who score the aircraft in field trials; in commercial work, to the operations and compliance staff who build the case for each FAA approval.

The usual starting point is engineering rather than aviation: a bachelor's degree in computer science, electrical engineering, aerospace engineering, mechanical engineering or robotics. For estimation, perception and planning roles, a master's or PhD in robotics, controls or computer vision is a typical path, because the work leans on probability, linear algebra, optimization and control theory every day. Those are typical paths, not rules: a strong portfolio of flight software can carry a candidate with a less direct degree.

Aviation-specific programs exist too. Embry-Riddle's B.S. in Uncrewed and Autonomous Systems blends aeronautical science, uncrewed aircraft systems, computer science, engineering and GIS, and includes flight in actual environments, including beyond visual line of sight (BVLOS) operations using Remote Split Operations techniques. A program like that builds operational knowledge, from mission planning to airspace procedures, alongside the software; perception and estimation work still calls for deep math and coding.

The technical core, as a rough guide:

• Languages and systems: modern C++ for onboard code, Python for tooling, analysis and machine learning, and comfort on embedded Linux.
• Robotics frameworks: ROS 2, MAVLink and MAVSDK, and at least one open autopilot (PX4 or ArduPilot) well enough to read its source.
• Algorithms: Kalman and factor-graph estimators, visual-inertial odometry, sampling and optimization-based planners, and the basics of multirotor and fixed-wing dynamics.
• Machine learning: training and deploying detection and tracking models on embedded GPUs, with attention to latency, power draw and failure modes.
• Test discipline: simulation, hardware-in-the-loop rigs, flight-log analysis and the habit of writing a test before a fix.

On experience, as a rough guide, entry roles suit new graduates with strong robotics projects, competition teams or research, while senior autonomy engineers typically bring 5 or more years of shipping software that runs on real vehicles. Time on any autonomous platform counts: ground robots, marine vehicles and road vehicles build estimation and planning skills that transfer, though flight adds its own constraints.

The credential most relevant here is the FAA Remote Pilot Certificate, issued by the Federal Aviation Administration under Part 107; it lets an engineer act as remote pilot in command of test aircraft flown under Part 107 and shows an understanding of the airspace rules the software must respect. Defense programs may require that a candidate be eligible for a U.S. government security clearance.

Communication is part of the job. A good autonomy engineer can explain to a test pilot why the aircraft did something odd, write a clear incident report after a crash, and argue for a software change with flight data rather than intuition.

BLS does not report UAV autonomy engineers separately, so pay and growth data come from neighboring categories. Industry matters. In May 2025 OEWS data, software developers in aerospace product and parts manufacturing earned a median of $135,490, and those in scientific research and development services earned a median of $158,390. ONET's profile for Software Developers projects growth that is much faster than average (7% or higher) for 2025 to 2035, with about 95,300 openings a year on average. ONET's Robotics Engineers profile, a neighboring occupation, lists autonomous vehicle design engineer among its reported job titles, but BLS publishes no separate wage line for it.

On the defense side, the Department of War's Drone Dominance Program is awarding $1.1 billion in prototype orders across multiple phases. Phase 3, opened September 28, 2026, puts $450 million toward roughly 60,000 drones. On February 3, 2026, the department named 25 vendors invited to compete in Phase I. On July 1, 2026, it announced the consolidation of all Unmanned and Autonomous Systems (UxS) under a newly established position reporting directly to the Deputy Secretary of War. Each of those aircraft needs navigation and fallback software that someone has to write and test.

On the civil side, the rule to watch is Part 108. The FAA and the Transportation Security Administration proposed Part 108, Normalizing Unmanned Aircraft Systems Beyond Visual Line of Sight Operations, on August 7, 2025. The proposal covers aircraft weighing not greater than 1,320 pounds, defines personnel roles such as an operations supervisor and a flight coordinator, and includes provisions for operations of multiple unmanned aircraft, low-altitude right-of-way rules and automated data service providers. The Office of Information and Regulatory Affairs received the final rule for review on July 10, 2026, and still listed it as pending review in early November 2026. Federal law (49 U.S.C. 44811) required the FAA to issue a final rule not later than 16 months after publishing the proposal, and requires the rule to include standards for remote pilots or operators that take into account varying levels of automated control and management of UAS flights.

For autonomy engineers, the proposal matters because its detect-and-avoid, conformance monitoring and multi-aircraft provisions describe problems that software has to solve. If finalized, the rule would shape what commercial autonomy software has to demonstrate to fly package delivery, agricultural or aerial surveying missions beyond visual line of sight.

Risks are real. Defense budgets can shift with each appropriation, drone startups depend on venture funding and contract wins, and a final Part 108 could differ from the proposal. Keeping skills portable across air, ground and marine autonomy, and keeping a record of fielded results, is a practical hedge against those swings.

Dear Hiring Manager,

I am applying for the UAV Autonomy Engineer position on your flight software team. For the past four years I have built estimation and planning software for small multirotor and fixed-wing aircraft, most recently as the autonomy lead on a three-person team developing an inspection drone for utility corridors.

My core work has been state estimation without reliable GPS. I wrote and tuned a visual-inertial odometry pipeline that let our aircraft hold position under transmission towers, where GNSS multipath had been causing drift and aborted flights. I also rewrote our lost-link logic on the companion computer, replacing a single timeout with a staged response that holds, climbs to a safe altitude, and then returns along the inbound path. After that change, our test pilots stopped needing to take manual control during link dropouts in our test program.

I work in C++ and Python on ROS 2, integrate with PX4 over MAVLink and the ROS 2 bridge, and run every change through software-in-the-loop simulation before it reaches the hardware-in-the-loop bench. I hold an FAA Remote Pilot Certificate and fly many of my own test sorties, which keeps me honest about how code behaves in wind and rain rather than in a simulator.

What draws me to your team is the move from single-aircraft missions to coordinated fleets. I have prototyped task allocation for two aircraft sharing a survey area and would like to take that work further on a production system with real operators.

I would welcome the chance to walk through flight logs from my recent projects and discuss how I could contribute to your autonomy roadmap.

Sincerely, Jordan Reyes