Obstacle avoidance usually describes how a vehicle navigates around things in its way. Collision avoidance describes preventing a predicted or imminent impact, which may involve steering, slowing, stopping, or alerting an operator. The terms overlap: obstacle avoidance can handle moving objects, and collision avoidance can react to a stationary wall. Compare the actual sensing, prediction, and control functions rather than treating the labels as two separate technology classes.
For a supplier evaluation, establish two things first: can the system find a usable way past an obstruction, and what does it do when the current motion becomes unsafe? A vehicle may need both capabilities, with different software responsible for each.
On This Page
- Compare functions before feature names
- How navigation and intervention fit together
- What moving obstacles add
- Measure the complete response
- Specify the integration boundaries
- Match the capability to the mission
- Choose from the demonstrated behavior
Compare functions before feature names
There is no dependable rule that obstacle avoidance means only static objects while collision avoidance means only moving ones. In Nav2's navigation documentation, a controller can follow a planned path and avoid dynamic obstacles. Conversely, PX4 Collision Prevention can constrain motion toward nearby obstacles without planning a complete detour.
Use the following functional comparison when reading specifications. It is an engineering synthesis of Nav2, PX4, and the dynamic-obstacle research cited below, rather than a standardized naming scheme.
| Comparison | Obstacle avoidance as a navigation function | Collision avoidance as a conflict-response function |
|---|---|---|
| Main question | Where can the vehicle travel toward its goal? | Will the current or proposed motion create an impact risk? |
| Useful inputs | Goal, vehicle position, occupied space, motion limits; sometimes object tracks | Obstacle observations or tracks, vehicle motion, separation criteria and response limits |
| Typical output | A path, local trajectory, or steering command | A changed velocity, stop, maneuver constraint, or advisory |
| Performance concern | Progress, clearance, route feasibility and recovery from blockage | Detection-to-action delay, missed conflicts and effective response |
| Important limitation | Finding a route does not ensure that every sudden encounter is handled | Avoiding an immediate impact does not ensure arrival at the goal |
Ask whether a warning is advisory or whether software actually changes motion. Also ask whether that authority applies during manual control, autonomous navigation, or both. The distinction between autonomous and automated systems helps separate a specific protective behavior from broader decision-making authority.
How navigation and intervention fit together
A navigation stack can separate path selection from immediate motion control. Nav2's planner computes a path, while its controller produces the local control effort to execute the task. Choosing the appropriate algorithm depends on the robot's geometry, motion constraints, and surroundings. A path that looks clear on a map is useful only if the installed vehicle can follow it.
An additional intervention layer can inspect motion closer to the command output. The Nav2 Collision Monitor normally uses sensor observations directly, bypassing the navigation costmap and trajectory planners. The current guide also permits an optional derived costmap input, with a warning about reaction latency and data freshness. Check the configured input path before assuming that the intervention always sees a fresh sensor sample. Its behaviors include stopping, slowing, limiting velocity, and reducing speed according to an estimated time to collision.
This separation lets an engineer distinguish a navigation failure from a last-moment response. A blocked corridor may need replanning; a newly appearing object may require an immediate interruption. They can occur in the same mission, but their success criteria differ.
The monitor's documentation explicitly says its CPU-based implementation does not provide hard real-time safety certification. Adding a software stop function does not establish that a complete robot is a safety-rated installation. Where a project requires a certified protective function, evaluate that requirement separately from ordinary navigation performance.
PX4 provides a different example: its main-branch guide describes Collision Prevention for multicopters using acceleration-based Position mode. It constrains velocity and acceleration near detected obstacles and can make limited directional adjustments. That is narrower than a promise to find a route around every blockage. Verify the exact release and flight mode; development documentation is not evidence of a capability in an arbitrary installed aircraft.
What moving obstacles add
A gap that is clear now may be occupied when the vehicle reaches it. Dynamic avoidance therefore has to consider how the vehicle's motion relates to another object's motion over time, or use conservative rules that account for that uncertainty.
In Ferguson and colleagues' urban-driving research, the system generates candidate vehicle trajectories and checks them against predicted obstacle trajectories. Road structure helps generate plausible predictions of other vehicles' behavior. The candidates also account for the controlled vehicle's dynamics. This is a historical implementation example, not a benchmark for today's suppliers.
The important distinction is between predicting an object and executing the response. A prediction can become wrong when another actor turns or accelerates unexpectedly; repeated observations must be able to change the response. A geometrically clear maneuver can also be unusable if the robot cannot turn or brake as assumed. Ask how often predictions are refreshed and how the system reacts when their uncertainty grows.
Optimal Reciprocal Collision Avoidance, or ORCA, illustrates another approach. The original research allocates shared responsibility for pairwise avoidance and selects velocities under a mathematical model. Its original formulation ignores vehicle kinematics and dynamics; the authors explain that subsequently clamping the selected velocity to physical limits does not preserve the strict avoidance guarantee. The paper assumes planar holonomic agents with perfect knowledge of other agents' shapes, positions and velocities, and agents following the same avoidance protocol. Treat those conditions, its finite prediction horizon and the existence of feasible velocities as part of the result, rather than as properties supplied by the algorithm name. The cited manuscript demonstrates historical two-dimensional simulations; it is not evidence of a proposed physical installation’s performance.
For a robot team, verify that the implemented model and response assumptions match every participating platform. For encounters with people or unrelated vehicles, do not assume the other party will make the reciprocal adjustment. A guarantee under an algorithm's assumptions is different from a demonstrated outcome with imperfect sensing and physical actuators.
Measure the complete response
Sensor range, processing rate, and successful route completion describe different parts of performance. A fast planner cannot compensate for an object that becomes observable only after the remaining maneuver space is inadequate. Nor does a sensor's advertised maximum range establish reliable detection of the mission's smallest or least visible hazard.
PX4's documentation connects permitted motion to sensor range, response delay, and vehicle control limits. It also restricts motion in directions without sensor data by default. This makes coverage a practical operating constraint: inspect which directions remain observed as the vehicle turns, reverses, or carries its payload.
For a stationary obstacle, measure the distance traveled from the first usable observation through processing and command delivery to the completed stop. Align timestamps before comparing events recorded on different computers. Include actuator response and the actual payload. When another object is moving, add its motion to the encounter assessment; stopping the controlled vehicle does not necessarily remove the conflict.
The following are proposed comparison tests, informed by the documented navigation, intervention, and trajectory-prediction mechanisms. They are not reported test results or universal pass thresholds.
| Test case | Record | What it separates |
|---|---|---|
| Known stationary blockage | Clearance, completion, replans and time spent waiting | Finding a detour versus merely stopping |
| Object entering from the side | First usable observation, command change and minimum separation | Coverage and response delay versus straight-ahead performance |
| Sustained moving conflict | Track updates, proposed maneuvers and executed motion | Motion prediction versus physically achievable avoidance |
| Delayed or missing observations | Configured timeout, last valid sample and resulting physical behavior | A visible fault response versus silent continued motion |
| Narrow passage with full payload | Actual swept clearance and recovery behavior | A nominal robot footprint versus the operational configuration |
Use the same vehicle configuration, hazard geometry, speeds, and environmental conditions when comparing implementations. Report nuisance stops and unresolved blockages alongside minimum separation. An overly conservative system may avoid contact during a demonstration while failing to complete the assigned work.
Specify the integration boundaries
Start with the observation contract: coordinate frame, measurement time, update behavior, uncertainty, and the meaning of missing data. A distance, occupied map cell, and tracked object's predicted path are different inputs. Agreeing on a message format does not establish that a downstream algorithm interprets it correctly. The guide to sensor fusion for autonomous vehicles develops the associated timing and calibration issues.
Then define command authority. Document the path from the operator or mission planner through any controller, command filter, and actuator interface. For each operating mode, identify which component can reduce or override motion and which component observes that intervention. Specify what happens after a stop: automatic resumption, a new plan, or operator acknowledgment.
A useful integration review should also ask whether navigation and intervention share sensors, compute resources, or power. Separate software nodes do not, by themselves, establish independent protection against a shared failure. The open architecture guide explains why interfaces need behavioral agreements as well as documented connections.
Finally, make recovery part of the contract. Include startup without valid observations, stale tracks, a controller restart, and loss of the planning process. Define the permitted response for each case and demonstrate that it reaches the vehicle. A logged stop request alone does not establish a completed physical stop. Nav2 provides a concrete configuration check: its source timeout can stop motion when observations become stale, but disabling that timeout disables this blocking mechanism. Record the effective timeout for each source and test the response through the command output and actuator path.
Match the capability to the mission
For a warehouse mobile robot, route planning around persistent obstructions and a prompt response to newly observed hazards solve different problems. Evaluate both if the mission includes aisle blockage and crossing traffic. Include the loaded footprint and realistic intersections in the demonstration.
For a remotely operated inspection multicopter, a local motion constraint may be useful while the operator chooses the route. Confirm that it applies in the intended control mode and sensing directions. Autonomous rerouting needs its own evidence; do not infer it from a collision-prevention feature name.
Aircraft traffic encounters introduce a separate scope. NASA's DAIDALUS project implements well-clear detection, alerting, and maneuver guidance. Its detection logic predicts a well-clear violation interval under a nonmaneuvering-trajectory assumption. These functions address aircraft separation; a nearby-obstacle sensor alone does not establish that capability.
Keep the response physically appropriate. For a fixed-wing, marine, or underwater project, require a proposed maneuver and recovery sequence that the actual vehicle can execute, with the relevant control and environmental limits included. Treat the ground and multicopter examples here as architectural illustrations, not cross-domain compatibility claims.
Choose from the demonstrated behavior
Request a functional description that names detected hazards, operating modes, prediction assumptions, available maneuvers, and failure responses. Then require a demonstration that connects observations to the vehicle's actual motion under the intended mission conditions.
Choose navigation capability for making progress through obstructions, conflict-response capability for handling unsafe encounters, and an integrated combination when the mission requires both. The deciding evidence is the demonstrated chain from observation to executable response, including what happens when the normal plan becomes unusable.
Sources
- Nav2 project: Setting Up Navigation Plugins, Jazzy. Official Jazzy-path guide to planner/controller roles and selecting plugins for robot geometry and environment.
- Nav2 project: Collision Monitor Node, rolling. Current rolling implementation guide covering intervention models, optional costmap input, configured data timeouts and certification limits.
- PX4 project: Collision Prevention, main branch. Main/alpha development documentation for multicopter motion constraints, coverage and response delay; verify the installed release separately.
- Ferguson, Darms, Urmson and Kolski / Carnegie Mellon University: Detection, Prediction, and Avoidance of Dynamic Obstacles in Urban Environments. Original 2008 road-vehicle research on behavior prediction and dynamically feasible trajectory checks, used here as a historical architecture example.
- Van den Berg, Guy, Lin and Manocha / University of North Carolina: Reciprocal n-body Collision Avoidance. Original research published in 2011; guarantees depend on stated sensing, motion, reciprocity, horizon and feasibility assumptions.
- NASA Langley Research Center: DAIDALUS: Detect and Avoid Alerting Logic for Unmanned Systems. Official well-clear detection, alerting and maneuver-guidance project description. The page displays a March 12, 2024 footer but includes later project news; it was observed on November 6, 2026.
Last checked: November 6, 2026.
