Topic hub

Aerial and field robots

Robots that work in the air, on water, on farms and in orbit. Multirotor dynamics and cascaded control, the PX4 and ArduPilot autopilots and MAVLink, and what changes when a robot leaves the factory floor.

Updated 14 Nov 2026 · multirotor, quadrotor, differential flatness, minimum snap, PX4, ArduPilot, MAVLink, uXRCE-DDS, marine robotics, agricultural robots, space robotics, inspection

Overview

Field robots work outside controlled buildings: in the air, at sea, on farms, along pipelines and in orbit. They share a set of problems that factory robots rarely meet. Positioning relies on GNSS, which fails indoors, underwater and near tall structures. Weather, waves and dust change the dynamics. Communication links are slow or drop out, so the robot must act sensibly on its own. Many of these robots fall under aviation or maritime rules. This hub covers multirotor drones in most depth, because their open autopilot stacks are where most engineers start, and then the wider field.

Key ideas

Multirotor dynamics and control

Each rotor produces a thrust along the body z axis roughly proportional to the square of its speed, and a reaction torque about the same axis. A quadrotor has four inputs, the rotor speeds, and six degrees of freedom. It is underactuated: to move sideways it must first tilt, so position control has to work through attitude. Mahony, Kumar and Corke (2012) give a clear tutorial on the model, estimation and control. Mellinger and Kumar (2011) showed that the quadrotor is differentially flat in four outputs, the position and the yaw angle. Any smooth enough trajectory in those outputs can be tracked, which is why minimum-snap polynomial trajectories are widely used to plan aggressive flight. Lee, Leok and McClamroch (2010) wrote the controller directly on SE(3) instead of in Euler angles, proved almost global stability, and showed in simulation a recovery from an upside-down start.

In practice autopilots use a cascade of loops. PX4 describes its multicopter controller as a standard cascaded architecture that mixes P and PID controllers, with state estimates from its EKF2 estimator.

PositionPVelocityPIDAttitudeP, quaternionRatePIDAllocationmixerMotorsESCsvelocitysetpointthrust andattitudebody ratesetpointtorquesand thrustmotoroutputsEKF2 estimatorposition, velocity, attitude, ratessensors: IMU, GNSS, baro
The cascaded multicopter control loops described in the PX4 documentation. Each loop passes a setpoint to the loop inside it, and control allocation turns the total thrust and body torques into individual motor commands. The EKF2 estimator feeds every loop.

The two open-source autopilots most engineers meet are PX4 and ArduPilot. PX4, a Dronecode Foundation project, runs on multirotors, fixed-wing aircraft, VTOL, helicopters and rovers, and is BSD-3-Clause licensed. ArduPilot supports multicopters, helicopters, fixed-wing aircraft, boats, submarines and rovers, and is GPL-3.0 licensed. The licence matters for a product: distributing modified GPL firmware brings source obligations that BSD does not. Both talk to ground stations and companion computers over MAVLink, a compact message protocol. For ROS 2, PX4 uses a uXRCE-DDS bridge so that its internal uORB messages appear as ROS 2 topics on the companion computer. Both stacks run in software-in-the-loop (SITL) simulation, so a flight controller can be tested before any propeller spins.

What changes in the field

At sea the vehicle is pushed by waves, wind and current, and most surface vessels are underactuated, with a propeller and a rudder for three planar degrees of freedom. Fossen’s handbook covers the vessel models and the controllers built on them. Underwater there is no GNSS and radio barely penetrates, so navigation leans on inertial sensors, Doppler velocity logs and acoustic positioning. On farms the challenge is perception in clutter and changing light, with crops that look different every week. In space, robots work in microgravity with very limited repair options. NASA’s three Astrobee free-flying robots have operated inside the International Space Station since 2019, according to NASA, and their flight software is open source and built on ROS. For inspection robots on pipes, tanks, power lines and wind turbines, the data they bring back is the product. Sensor quality and repeatable viewpoints matter as much as how the robot moves.

Where to start

Read Frames and rotations first, because attitude control is rotation maths. PID control covers the loops in the cascade above, and the PID tuning reference helps with the rate loop. Sensors and noise explains what an IMU really measures. The state estimation hub covers the extended Kalman filter inside EKF2. The drones platform page lists hardware and ecosystems.

Tools and platforms

Tool What for Licence
PX4 Autopilot for multirotors, fixed-wing, VTOL and rovers BSD-3-Clause
ArduPilot Autopilot for copters, planes, boats, submarines and rovers GPL-3.0
MAVLink Message protocol between vehicle, ground station and companion computer Generator LGPL-3.0, generated code MIT
QGroundControl Ground control station for PX4 and ArduPilot Apache-2.0 or GPL-3.0, your choice
MAVSDK MAVLink client library for companion computers BSD-3-Clause
Mission Planner ArduPilot ground station GPL-3.0
Astrobee software Flight software and simulator for NASA’s ISS free-flyers Apache-2.0

Common mistakes

  • Tuning outer loops before the rate loop is stable. Tune from the inside out.
  • Mounting the flight controller without vibration isolation, then blaming the estimator for noisy attitude.
  • Trusting GNSS near buildings, bridges and under trees. Watch the reported accuracy and plan for its loss.
  • Assuming that a field robot will always have a link. Define what it does when the link drops, and test it.
  • Shipping modified GPL autopilot firmware without planning for its licence terms.
  • Ignoring local aviation and maritime rules until the first field trial.

Going deeper

Latest news on this topic

Recent papers

  • RGB-D SLAM on the Edge: Benchmarking and Profiling RTAB-Map and ORB-SLAM3 on the Raspberry Pi 5

    H. Patil, J. Joshi, R. Saluja et al. · arXiv cs.RO · digest

    The authors ran RTAB-Map and ORB-SLAM3 on a Raspberry Pi 5 on six TUM RGB-D sequences, each at three resolutions, and recorded per-frame time, memory use, CPU load, temperature, trajectory error and how much of each sequence stayed tracked, and profiling each system down to function level. With RTAB-Map set to process and retain every frame, its full pipeline took 150 to 462 ms per frame against 26 to 62 ms for ORB-SLAM3, and most of RTAB-Map's time went into optimising a pose graph that grows without limit under its default memory settings. At quarter resolution both systems lost tracking on most sequences, and runs that lost tracking reported lower error on the poses they kept, so error must always be read alongside coverage. This is a dataset benchmark on the board rather than a flight test, and repeating an identical run changed trajectory error by as much as 27%, which leaves the accuracy comparison inconclusive even though timing repeated within 1% to 5%.