Automation performs tasks through defined control logic. Autonomy describes how independently a system can choose and carry out actions toward an assigned goal. For unmanned vehicles, the useful distinction is which decisions the system can make, under what conditions, and when a person must intervene. An autonomous vehicle still contains automated functions, and neither label alone establishes mission capability.

Use prescribed automation when the mission can be specified in advance and handled exceptions are sufficient. Consider greater autonomy when the vehicle must choose among valid actions as conditions change. In either case, compare demonstrated behavior in the intended operating environment before comparing labels.

On This Page

What autonomous and automated actually describe

A feedback controller can adjust its output continuously while remaining an automated function. A vehicle holding a commanded position, for example, need not decide where the mission should go next. Conversely, an autonomous navigation function may select a new route while the operator retains responsibility for the destination and mission priorities.

Terminology overlaps in real documentation. The PX4 multicopter Mission mode guide describes an uploaded flight plan as a predefined autonomous mission and the mode as automatic. That wording does not establish obstacle avoidance, unrestricted replanning, or independence for every other vehicle function. Read the documented behavior and configuration behind the term.

NIST's ALFUS terminology, Volume I, Version 2.0, characterizes unmanned-system capability through mission complexity, environmental complexity, and human independence. Its October 2008 terminology framework remains useful for asking precise questions; it is not a universal certification ladder.

Describe capability by function: navigation, payload operation, task selection, and recovery may have different human involvement. A craft following a survey pattern can still need an operator to interpret the sensor output or authorize a changed task. “Unmanned” describes the absence of an onboard human operator, not the absence of people elsewhere in the system.

Architecture: from a command to a new decision

Both approaches need sensing, state estimation, control, and actuators appropriate to their task. The difference becomes visible where the system chooses what to do next.

In a prescribed mission, a sequencer advances through instructions and the controller executes the current command. PX4 Mission mode illustrates this arrangement: the flight controller executes an uploaded plan, subject to mode requirements and configured behavior. Following that plan requires a usable position estimate; uploading waypoints does not remove navigation dependencies.

A navigation stack with route-selection capability adds a process for evaluating possible paths. The Nav2 Jazzy navigation-server documentation separates planning from control. A planner produces a path toward a goal using an environmental representation. A controller uses local information to produce feasible motion commands. Recovery behaviors address failures that prevent normal progress.

That separation matters during integration. A valid path is not a motor command, and successful path tracking does not establish that the vehicle chose the right mission objective. Ask which component owns each decision and what information crosses its interface.

The table compares two illustrative arrangements, rather than assigning universal properties to every automated or autonomous system. Its basis is the PX4 mission guide and Nav2 architecture; the integration implications are engineering interpretation.

Decision or functionPrescribed mission executionNavigation with delegated path selection
DestinationSupplied in the mission planSupplied as a goal; higher-level software may assign it
Motion commandsController executes the active instructionController follows a path computed by a planner
Environmental changeHandled through configured responses or a revised instructionMay trigger another path calculation within permitted space
Failure handlingDefined hold, return, abort, or operator response, as implementedRecovery logic may retry or change behavior before reporting failure
Main integration questionAre instructions, position inputs, and mode transitions correct?Are environmental inputs, planning constraints, and recovery authority correct?

Autonomy is also not synonymous with learning during operation. Nav2's behavior-tree walkthrough shows explicitly configured logic coordinating path calculation, following, and recovery. A behavior tree selects actions according to conditions and returned results. Replanning in that arrangement does not, by itself, mean the software has learned a new policy.

Performance: measure the mission and the exceptions

Greater decision authority does not establish greater speed, accuracy, reliability, or safety. Compare systems on the same task, vehicle configuration, operating conditions, and success criteria. Include the work people perform before departure and during recovery.

NIST's September 2024 report, Feature Description for Assessing Autonomous Vehicle Performance, connects operating conditions, specified behaviors, and test scenarios. Its subject is automated road vehicles. Applying that feature-based approach to other unmanned systems is an engineering recommendation, not a claim that the report certifies aircraft or underwater vehicles.

For a route-following mission, request results for completion rate, completion time, tracking error, operator interventions, and recovery time. Define each measure before the trial. A safe abort is different from mission completion, and an intervention count should distinguish a routine authorization from an emergency takeover.

Then vary the conditions that matter: route blockage, changed lighting, degraded positioning, or loss of the supervisory connection, where relevant to the platform. Retain normal runs as well as difficult cases. NIST cautions that predefined scenarios and worst-case testing each leave gaps; a demonstration cannot establish behavior in every possible situation.

A useful comparison records what happened after the disturbance. Did the vehicle stop as intended, find another permitted route, repeatedly attempt an ineffective recovery, or require a person to resume? That outcome is more informative than a single autonomy score. No numerical advantage can be assigned to either category without matched evidence.

Keep task timing separate from control timing. For an illustrative ground-robot evaluation, record when an obstruction enters the sensor view, when the navigation software recognizes it, when a revised command is issued, and when motion changes. These timestamps help distinguish slow sensing, slow planning, and slow physical response. A short path-calculation time alone would leave the other intervals unmeasured. Repeat the observation with the intended onboard workload running, because a demonstration with only navigation enabled does not exercise the complete installation.

Human workload also needs a defined boundary. Count mission preparation, active supervision, intervention, and recovery separately. A robot that completes more trips without intervention could still demand substantial map maintenance or difficult recovery work. Ask for the duration and reason behind operator actions, rather than treating every intervention as interchangeable. Those records let the buyer compare the actual operating arrangement without assuming that fewer steering inputs mean fewer staff hours.

Integration determines the limits of independence

The navigation system must receive data in forms it can use. Nav2's state-estimation documentation distinguishes a global map reference, a continuous local odometry reference, the robot body, and sensor coordinate frames. Localization relates the map to odometry; odometry relates motion to the body. The stack uses time-aware transformations to connect those references.

The practical consequence is that sensor installation, coordinate conventions, and timing belong in the integration specification. A planner cannot compensate for every misleading input simply because it is labeled autonomous. Verify how a position jump, missing transformation, or stale observation reaches the rest of the system.

Also document where decision-making runs. Nav2 describes both centrally dispatched robots and robots carrying more of the task logic onboard. For a proposed installation, trace the dependency explicitly: if the onboard controller keeps moving but the next task requires a remote dispatcher, losing that connection still limits mission continuity.

Specify the handover interface with equal care. The operator should be able to identify the active mode, requested goal, reason for a pause, and available next action. Define whether a resumed mission continues an interrupted instruction or starts a new one. These are integration requirements to agree and demonstrate, not capabilities implied by the word autonomy.

Recovery deserves its own limits. Nav2's example behavior tree can clear costmaps, spin, wait, or back up, with configured retry handling. A costmap represents the navigation cost or obstruction associated with locations; clearing it is a software recovery action, not removal of a physical obstacle. Those options require application-specific review. A maneuver useful for a ground robot in open space may be unsuitable beside a drop or on a different vehicle type. NIST's ALFUS terminology likewise distinguishes an emergency stop from the designed emergency procedures an aircraft needs in flight.

Compare the integration effort behind each proposal as well. Ask who maintains maps and configurations, which computing resources are required, and which software changes require renewed trials. Include operator training and exception handling in that comparison. Without installation-specific evidence, neither approach has a defensible universal cost advantage.

Consider an illustrative handover during a blocked-route event. The robot has paused, a dispatcher still holds the original delivery task, and an operator moves the robot manually to a clear location. Before automatic operation resumes, establish which component cancels the old motion request, which position is used to plan again, and whether the original destination remains valid. Require the interface to show the resulting state. Otherwise, a successful manual recovery leaves the next software action unspecified.

Treat loss of communication and loss of localization as different faults in that exercise. A vehicle may be allowed to finish an onboard instruction without a dispatcher while being unable to continue safely without a usable position estimate. The desired response must follow the actual dependency and mission restrictions. A single generic “continue autonomously” setting is too imprecise to serve as the requirement.

Match the decision authority to the mission

The following choices are illustrative engineering recommendations drawn from the architecture and performance distinctions above. They describe candidate arrangements to evaluate, not verified outcomes for a particular product.

  • Repeatable survey with a known route: start by evaluating prescribed mission execution. Add decision capability only where the mission needs it, such as permitted route changes or onboard selection of another measurement location. Confirm what happens when the original plan becomes unusable.
  • Ground transport with changing obstructions: evaluate local path selection and recovery if stopping for every blockage would defeat the task. Demonstrate that the robot stays within allowed areas when a shorter alternative becomes visible.
  • Remote exploration with delayed supervision: evaluate onboard navigation decisions that can proceed between instructions. Separate that authority from decisions about the broader science or inspection objective.
  • Work requiring human interpretation or authorization: retain explicit human decisions while automating repeatable motion or data collection. Greater independence is useful only for decisions the mission actually permits the system to make.

NASA's record of Perseverance's first AutoNav drive makes the third case concrete. The team planned a drive toward a hazardous rock; the rover identified the hazard and changed its course around it. That is a documented onboard navigation decision within a human-planned activity. The accompanying paired camera image shows the terrain input, not a general performance guarantee for autonomy.

Specify the behavior before selecting the system

Ask a supplier to complete one statement for each critical function: “Given this task and these operating conditions, the system may make these decisions; when it reaches these limits, it takes this action and requests this human response.” Require a demonstration of both the routine case and the boundary case.

For example, an illustrative ground-transport requirement might permit rerouting inside an approved area, require a controlled stop when no permissible route remains, and require operator authorization before resuming after a localization fault. The test should show each transition, including the information the operator receives.

Choose the arrangement that completes the permitted mission with understandable limits and manageable human work. “Autonomous” and “automated” are useful starting terms. The decisive comparison is the actual division of decisions among the vehicle, supporting software, and people.

Sources

Last checked: September 7, 2026.