Sensors, and what each layer hides

Sensors take facts, a flight stack holds attitude, middleware connects processes, and an operations system releases sorties. Mix the layers and a demonstration screen is mistaken for a logistics network.

What is actually measured

GNSS derives position and time from ranges to satellites. A meter-level figure is typical. Urban canyons add multipath, and the signal can be jammed or spoofed. Heading while stationary does not fall out of a track you are not moving along. RTK uses the carrier phase plus corrections from a base or a network, and it is centimeter-class when the integer ambiguity is fixed. A float solution is not a fix. Lose the corrections and you are back to ordinary GNSS. A wrong base coordinate shifts the whole precise answer. An IMU reports acceleration and angular rate at high rate and drifts when you integrate it. A barometer is strong for relative height and is biased by weather and, if the port is badly placed, by rotor wash.

Cameras are passive. They need texture and light, and they are confused by sun, rain, glass, and featureless snow. They can support landing and obstacle cues. They are not, alone, an all-weather sensor. LiDAR ranges actively and yields geometry more directly. Fog, heavy rain, and dust degrade it, and it costs mass and power. A more expensive sensor does not automatically cancel a cheaper one's failure. An estimator blends these into one state. Do not read the blended display as a claim that every input is always right. Before flight you should be able to say how the estimate degrades when each input drops.

ADS-B In listens for cooperative broadcasts, mainly from crewed aircraft that are required to equip. In the United States, ADS-B Out is mandated in defined airspace. Unequipped aircraft do not appear, and neither do most small drones. It is a partial picture of crewed traffic, not a detect-and-avoid system by itself. Remote identification points the other way: the uncrewed aircraft broadcasts its own identity and location, and standard broadcast forms can include the control station. It is an accountability signal. It is not a sensor of other traffic, and it does not identify the human who receives the parcel. Do not collapse the two radios into one claim that the aircraft can see.

What each layer is allowed to hide

PX4 and ArduPilot are flight stacks on the aircraft. They read sensors, run an estimator, close attitude and position loops, mix commands to motors, and enforce failsafes such as a geofence, low battery, or loss of link. What they hide is 'achieve this attitude, velocity, or position inside the aircraft's limits.' Outside the limits they do not achieve it. MAVLink is the protocol of the conversation: telemetry, commands, mission items, heartbeats. System and component identifiers are addresses, not safety decisions. The protocol abstracts the grammar on the wire. It does not abstract the question of whether a flight should be released.

ROS 2 is middleware on a companion computer. Nodes publish and subscribe to typed messages. It abstracts inter-process robotics software, perception, and experimental planning. It is not an autopilot. A ROS node must not be the only thing keeping the rotors stable. The flight stack fails safe on its own. QGroundControl is an operator console for setup, calibration, mission editing, and live telemetry of one aircraft. Mission Planner and its relatives play a similar role beside ArduPilot. One aircraft, one session, a human in the loop. That is not an airline operations system.

A vendor SDK abstracts a closed scope. DJI-class kits command the aircraft and its payloads at the mission level the vendor exposes. The estimator and the motor mix stay inside. Auterion puts an enterprise layer around PX4, closer to fleet software and applications than to a stick. Skydio-class kits expose high-level skills on their own airframe and keep avoidance internal. None of this means the caller possesses what the vendor hid. State the boundary of the abstraction from the contract and the document. An SDK you cannot describe that way is a convenient black box, not a safety explanation.

A pilot app is not an operations system

A pilot app's horizon is one flight. Arming, a checklist, a mission for this airframe, stick or waypoint control, return. The user is a pilot or a remote operator, and the clock runs from takeoff to landing. An operations system's horizon is the network: orders, aircraft availability, pad slots, a weather no-go, airspace constraints, strategic separation, conformance monitoring, the log a regulator will ask for, and a connection to the order system. The user is a dispatcher, and the clock is the day's slots. MAVLink telemetry can flow into that system. The flow does not turn a ground station into UTM.

Identification, geofencing, flight authorization, tracking, and support for conflict detection, as U-space and UTM describe them, are services on the operations side. Drawing them on a single-aircraft screen does not implement them. When a demo works, people want to call the screen a network. The screen may show that one aircraft followed commands. It does not show the next pad slot, a refused volume of airspace, a handover that did not happen, or a wind that ate the reserve. If no other system holds those four, there is no logistics yet. Praise the flight stack. Do not appoint it as the operations system.