How Does a Drone Detect and Avoid Obstacles?

• Observing drone
• Obstacle on the straight path
• Target after route assessment

What you will learn

• Distinguish detection, distance estimation and action selection.
• Trace how sensor data constrains a motion setpoint.
• Evaluate missing view, stale data and the difference between avoidance and a geofence.

Before you start

You do not need to program a drone; a setpoint is a target value that a controller is asked to track.

What information does a sensor provide?

A camera can detect an image region that resembles an object; a rangefinder or lidar estimates distance in a direction. Detecting “an object” does not necessarily say how far away it is, while a range reading only describes the region the sensor can see. The system needs to associate each observation with a direction, timestamp and field of view so it knows both what is observed and where coverage is missing.

PX4 Collision Prevention can receive sensor data from an attached rangefinder, MAVLink or a companion computer. The documentation describes combining observations into directional sectors around the vehicle and considering when each was last observed. A sector with no data must be distinguished from one measured as clear: “nothing seen” does not mean “absence confirmed.”

How does distance lead to stopping or avoidance?

First, the controller predicts whether the current velocity setpoint would bring the drone too close to an obstacle. If so, it can restrict the requested velocity to preserve stopping distance. PX4 describes velocity restriction in relation to distance data, setpoint tracking and delay; maximum speed may be limited when sensor range is short.

Stopping and avoiding are different decisions. Stopping reduces velocity along the current path; avoidance needs an alternative direction with evidence of free space, then needs to assess that new path. PX4 can make a small adjustment to the setpoint direction when a neighbouring sector looks better within a configured angular margin; that is not a general path planner. A more complex task needs a planner to validate a route, acceleration limits and target state.

A companion computer can process detection and send obstacle data or setpoints through an offboard interface, but it must agree with the flight stack on coordinate frames, units, sensor direction and timestamps. If components disagree about which axis is “forward,” a correct range can be attached to the wrong direction. The interface transports data; it does not guarantee detection quality or a safe decision.

A simulation flow that stops, then considers a detour

Proposed illustrative design; not a test result. A virtual sensor node publishes range with its viewing direction and observation time; an avoidance node receives the desired velocity setpoint; a coordinator checks the planned path against observed sectors; a simulator adapter sends the constrained velocity to the virtual flight stack. In this design, velocity must be restricted early enough to preserve braking distance. If the model already lacks enough room to stop, the test must report that infeasible condition; issuing a stop request does not establish that a collision will be avoided. Only if a neighbouring sector has valid observations may the design choose a direction-offset setpoint, then reassess it at the next frame.

Simulation success means the vehicle does not enter a modelled collision region, speed falls before the stopping limit, and the data state is logged with each decision. Test separately for an object outside the field of view, stale sensor data, a lost sensor or an implausible jump in range. The failure branch should reject invalid observations and avoid issuing a detour based on unobserved space. These are software simulation criteria, not certification for a flight.

How is a geofence different from obstacle avoidance?

A geofence is a virtual spatial boundary; it checks whether a vehicle is inside an allowed region rather than looking for individual objects ahead. PX4 states that a geofence failsafe action only triggers after the vehicle breaches the boundary. A geofence is therefore a region-monitoring layer, not predictive braking. Obstacle avoidance checks local data before movement; the two layers answer different questions and do not replace one another.

What can make the system fail?

Thin, transparent or out-of-view objects may not be detected. Stale data no longer describes the object's current position. Delay includes sensing, processing, transmission and vehicle response; ignoring it can make braking arrive too late. Narrow sensor coverage requires limits on speed or direction. PX4 documentation also describes range-data loss restricting horizontal motion and, after a configured wait, switching to HOLD in the relevant setup.

Common misunderstandings

A geofence prevents the drone from hitting every object. It monitors a region boundary and may act only after a breach. No warning means the path is clear. A sensor may not cover that direction, or the data may have expired.

Frequently asked questions

When should a system stop instead of detour?

When no alternative direction has reliable observations or braking ability is uncertain, stopping is more conservative than guessing a route.

Why is stale sensor data dangerous?

The object or drone may have moved since the observation, so the old distance can understate current risk.

Can a companion computer control the flight stack by itself?

Offboard interfaces allow external control information, but formats, supported modes and responses depend on the flight stack.

Can a geofence replace obstacle sensors?

No. A geofence monitors a region; obstacle sensors describe the nearby environment.

Summary

Obstacle avoidance needs observations with direction and time, a check of the intended path, stopping-distance reasoning and a constrained setpoint. A detour is justified only when the alternative is observed; missing or stale data must be treated as uncertainty. A geofence separately monitors a region boundary.