An unmanned vehicle operates without an onboard human operator. An autonomous vehicle performs specified operating tasks without a person directing each action. The terms describe different properties, so a vehicle can be both: a remotely piloted drone is unmanned, while an underwater robot executing its own survey is unmanned and autonomous for that task.
For engineers and buyers, the useful comparison is between remote operation and autonomous operation, with the task and operating conditions stated. Software capability must be demonstrated separately from removing the onboard operator. Autonomous operation still involves people who prepare, supervise, maintain, and recover the system.
On This Page
- Two labels, different questions
- How the control architecture changes
- Compare performance under the same conditions
- Integration and failure behavior
- Which missions fit each approach
- What to request before selecting a system
Two labels, different questions
NOAA provides a concrete distinction underwater. A remotely operated vehicle, or ROV, receives commands from a ship through a cable. An autonomous underwater vehicle, or AUV, conducts a survey without continuous operator intervention and without that tether. Both are uncrewed. The difference is how the work is controlled, as explained in NOAA's AUV and ROV reference.
These terms need three separate questions: Is an operator onboard? Which actions does software perform? When must a person intervene? A vehicle's name rarely answers all three.
| Question | Unmanned vehicle | Autonomous vehicle or operating mode |
|---|---|---|
| What does the label establish? | No onboard operator | Independence from human direction for specified tasks |
| Does it rule out remote human control? | No | Routine task execution is independent, but supervision or intervention may remain |
| Does it describe every function? | No autonomy capability is implied | Capability must be identified by function and conditions |
| Does it mean no humans are involved? | No | No; mission preparation and support can still require people |
| What should a specification add? | Control location, operating modes, and link requirements | Task scope, environmental limits, and intervention or recovery responsibilities |
Source basis: NOAA's underwater examples and the NIST ALFUS framework, Volume II, version 1.0. The specification questions are practical interpretation, not a certification checklist.
NIST's December 2007 framework describes autonomy in the context of mission complexity, environmental complexity, and independence from human interaction. It remains a useful way to frame a capability claim: navigating a cleared route and handling an unfamiliar obstruction are different tasks, even when performed by the same vehicle. ALFUS is a technical framework, not a universal approval or a product certification.
Autonomous does not always mean empty
A road vehicle can carry passengers while software performs the driving task. Conversely, an empty vehicle can be driven remotely. Occupancy and driving responsibility should therefore be recorded separately.
For road vehicles, NHTSA's driving-automation explanation distinguishes Level 2 assistance, where the driver remains responsible and attentive, from Level 3 operation, where the driver must be available to take over on request. At Level 4, the system performs driving within its limited service area without requiring a passenger to drive. These are road-driving categories; they should not be assigned to a drone or marine robot as if the tasks were interchangeable.
Automatic functions can coexist with remote control
An autopilot's capabilities have specific boundaries. In the documented PX4 v1.16 multicopter Mission mode, the aircraft executes a flight plan uploaded to its flight controller. The mode requires a global three-dimensional position estimate, and the operator can change modes. That is a defined automatic capability, not evidence that the aircraft can interpret every obstacle or complete every mission unaided.
Avoid a rigid claim that anything preprogrammed is merely automatic while anything autonomous must learn or invent a new plan. Technical documentation uses the terms with different boundaries. Describe the demonstrated behavior: following waypoints, selecting a route around an obstruction, requesting assistance, or recovering after a fault.
How the control architecture changes
In remote operation, the human closes an important part of the decision loop: observe the scene, choose an action, send a command, and inspect the result. Sensors or cameras supply observations; the communications link carries information and commands. Local control software may still stabilize the vehicle or regulate speed.
When those decisions move into software, the system needs the inputs and authority to make them. A useful functional sequence is: measure vehicle state and surroundings, interpret what matters, select an allowed action, command the actuators, and check the outcome. Identify where each step runs. Calling a system autonomous does not prove that every computation happens onboard.
The PX4 v1.16 system architecture illustrates the distinction between a flight controller and an optional companion, or mission, computer. The flight stack contains estimation and control functions; an additional computer can host other processing. The ground station, telemetry connection, manual control input, sensors, and payload remain identifiable parts of the system.
For an integrator, this means an autonomy upgrade can change more than software features. Ask which computer issues movement requests, which controller can reject them, and how their states are reported to the operator. Also check the added equipment's power, mounting, cooling, and data connections. An interface drawing should make it possible to trace one requested action all the way to the vehicle and back to its status display.
Separate vehicle control from payload control. Following a survey route does not, by itself, establish that a sensor recorded usable data. Specify how the system confirms the mission result as well as how it moves.
Compare performance under the same conditions
Neither label predicts speed, endurance, accuracy, or productivity. Compare complete operating arrangements against the same job, including human work before and after the vehicle moves.
The following are proposed evaluation measures. They are not reported test results or promises that either approach will win.
| Measure | What to compare | Why it affects the decision |
|---|---|---|
| Mission completion | The same route, payload, required output, and recovery endpoint | Finishing movement is different from delivering usable work |
| Human involvement | Preparation, monitoring, interventions, and recovery time | Reduced joystick use may leave substantial support work |
| Response to change | The same unexpected blockage or task change | Reveals what software handles and what requires an operator |
| Communications dependence | Normal operation, degraded connection, and complete loss | Shows which functions actually require connectivity |
| Output quality | The same survey coverage, inspection detail, or positioning criterion | A fast mission is unhelpful if its output needs repeating |
| Operational limits | The same visibility, terrain or water conditions, and traffic assumptions | A successful demonstration outside the intended environment proves little about the intended job |
NIST's separation of mission, environment, and human independence informs this comparison. Choose actual thresholds from the mission requirement; a generic autonomy score cannot supply them.
NOAA's 2019 REMUS 600 seafloor-mapping account shows why the surrounding workflow matters. Its AUV used programmed surveys, surfaced periodically for position updates and status transmission, and required recovery, data transfer, battery charging, and subsequent data processing. Autonomous survey execution was one part of that operation. The account describes that deployment, not a benchmark for all AUVs.
For a proposed purchase, request results that include abandoned missions, recovery effort, and unusable outputs alongside successful runs. If two suppliers use different environments or definitions of success, record the mismatch before comparing their numbers. Do not infer a staffing reduction from a demonstration in which the support crew's work was unreported.
Integration and failure behavior
The most revealing question is often what happens when the expected input disappears. Remote operation depends on getting enough information to the operator and returning commands in time. Autonomous operation may reduce that dependence for some tasks while increasing reliance on valid localization, perception, and decision software.
Lost connection is not one universal event
In PX4 v1.16 failsafe configuration, manual-control loss and ground-station data-link loss are distinct conditions. Their timeouts, selected responses, and mode exceptions affect behavior. Possible responses include holding, returning, or landing, depending on the fault and configuration. Verify the installed aircraft's response from its configuration and demonstrations, even when the advertised capability is an “autonomous mission.”
Request a written sequence for the proposed system: what detects the lost connection, how long detection takes, which action follows, and what happens if the connection returns. Review that sequence together with positioning and energy failures. A return setting does not prove that sufficient navigation information and energy remain to get back.
Handover needs a usable operator view
If software requests help, specify what the person sees and what authority they receive. Can the operator distinguish a stopped vehicle from a stale display? Is the current mode clear? Does taking control cancel the mission, pause it, or leave other automated functions active?
These questions matter particularly in a mixed arrangement where software performs routine movement and a person handles exceptions. Require demonstrations of those transitions, including an unavailable operator. “Human supervision” is incomplete unless the supplier states what the human must notice, decide, and do.
Define the boundary before adding capability
Write down the supported environment and task, including excluded conditions. For a proposed ground robot, for example, distinguish a controlled indoor route from an outdoor route with changing surfaces and public access. That is a comparison scenario, not evidence that a particular robot supports either environment.
Also identify the authoritative mission file, map version, software version, and fault settings. When a supplier changes one of these, ask which demonstrated behaviors still apply. An integration is reviewable when its operating assumptions and responsible components are explicit.
Which missions fit each approach
Choose the control arrangement around the work. The following recommendations are interpretations of the documented examples, rather than rankings of vehicles.
Close inspection with frequent redirection: remote operation deserves strong consideration when a person must continually choose the next view or manipulate an object. NOAA identifies object identification and vessel-hull inspection among ROV applications. Verify that the tether, vehicle handling, operator view, and tooling suit the actual site. Software assistance can still stabilize movement without taking over the inspection decisions.
A defined survey that does not need continuous steering: an autonomous mission can be appropriate when the route, data requirement, operating boundary, and recovery plan can be specified ahead of time. NOAA's AUV survey examples illustrate this fit. Confirm navigation performance and completion behavior separately from payload-data quality.
An aircraft survey with operator intervention available: a mixed arrangement may fit better than either extreme. PX4 Mission mode illustrates uploaded execution with a way to change modes. Specify what remains the operator's responsibility and which events interrupt the plan; waypoint capability alone is not proof of broader environmental awareness.
An unfamiliar or changing site: compare the system's demonstrated handling of the actual changes against the operator's ability to observe and respond through the link. A robot that needs remote help at a blockage is a poor fit where that help cannot arrive. Conversely, direct remote control is a poor fit where the operator cannot obtain an adequate view. If neither arrangement can handle the required conditions, change the mission scope or operating environment before selecting hardware.
What to request before selecting a system
Ask for one concise operating description that answers these questions:
- Which tasks run without human direction, and under exactly what conditions?
- Which tasks still need continuous control, supervision, or approval?
- What information and commands cross each communications link?
- What happens after loss of communications, positioning, or mission-computer function?
- How does an operator take over, and what happens when nobody can respond?
- What evidence shows usable mission output and successful recovery under comparable conditions?
Use the answers to choose the simplest arrangement that satisfies the mission. Remote operation fits work that benefits from continuous human judgment through a suitable link. Autonomous execution fits defined tasks that the system can demonstrate within stated limits. Many useful vehicles combine the two, so specify each operating mode and its responsibilities instead of treating “unmanned” and “autonomous” as opposing product classes.
Sources
- NOAA: What is the difference between an AUV and a ROV? Government explanation of tethered remote operation, independent survey execution, and underwater applications.
- NIST: ALFUS Framework, Volume II, version 1.0, December 2007 Technical framework connecting autonomy with mission, environment, and human independence; not a product certification.
- NHTSA: Automated Vehicle Safety Government explanation of road-driving automation and driver or passenger responsibilities.
- PX4 v1.16: Mission Mode (Multicopter) Implementation documentation for uploaded missions, positioning requirements, and operator mode changes.
- PX4 v1.16: System Architecture Implementation documentation distinguishing flight control, supporting hardware, communications, and a companion computer.
- NOAA: Seafloor Mapping with the REMUS 600 Autonomous Underwater Vehicle, July 25, 2019 Official expedition account of survey execution, navigation updates, recovery, and data handling; also the featured photograph's source.
- PX4 v1.16: Safety (Failsafe) Configuration Implementation documentation for fault detection and configurable responses, including distinct manual-control and data-link losses.
Last checked: September 6, 2026.
