Obstacle avoidance

Obstacle avoidance – definition

Obstacle avoidance is the process by which a mobile robot detects obstacles in its environment and modifies its motion to prevent collision while still progressing toward a goal. In mobile robotics, this term usually refers to local, real-time behavior rather than global route planning. A global planner may choose a path across a map, but obstacle avoidance is responsible for reacting to objects that are near the robot, dynamic, partially mapped, or not represented in the map at all.

In ROS and ROS 2 based UGV systems, obstacle avoidance is typically implemented inside the local navigation stack. It consumes data from proximity and perception sensors such as 2D LiDAR, 3D LiDAR, depth cameras, ultrasonic sensors, or stereo vision. It then updates a local cost representation and computes safe velocity commands. On a differential-drive platform such as Leo Rover, the output is usually a geometry_msgs/msg/Twist command on /cmd_vel. The robot controller converts this command into left and right wheel velocities. On a larger UGV such as Raph Rover, the same logic applies, but stopping distance, payload, wheel slip, and terrain variation have stronger impact on safe tuning.

Obstacle avoidance is not a single algorithm. It is a system-level function that combines perception, local mapping, robot footprint modeling, motion constraints, and a local planner or controller. In ROS 2, this function is commonly provided by Nav2, especially through the local costmap, controller server, and collision monitor components.

How obstacle avoidance works in ROS 2

In ROS 2 Humble and newer, obstacle avoidance on UGVs is most often implemented with Navigation2 (Nav2). The stack separates long-horizon planning from short-horizon control. This is important because obstacle avoidance must run at a higher frequency than global planning and must use fresh sensor data.

A typical data flow on Leo Rover or Raph Rover looks like this:

Sensor publishes range data, for example sensor_msgs/msg/LaserScan at 5-15 Hz or sensor_msgs/msg/PointCloud2 at 10-30 Hz.
The local costmap marks occupied cells and clears free space using ray tracing.
The controller evaluates candidate motions or follows a kinematically feasible path segment.
The controller publishes /cmd_vel at 10-30 Hz, sometimes higher on fast platforms.
A safety layer may override commands if collision risk exceeds a threshold.

Nav2 supports multiple local control approaches. Common options include DWB, Regulated Pure Pursuit, and MPPI control. For a differential-drive UGV used in research, DWB and Regulated Pure Pursuit are common starting points because they are well integrated with ROS 2 and have documented interfaces.

The minimum ROS interfaces usually include TF transforms compliant with REP 105, especially map, odom, and base_link, plus odometry in nav_msgs/msg/Odometry. Without consistent transforms and timestamped sensor messages, obstacle avoidance will be unstable or unsafe.

Key parameters and metrics

Obstacle avoidance quality is determined by geometry, latency, and controller tuning. The same algorithm can behave well or badly depending on these parameters. For UGVs, the robot footprint and stopping behavior are more important than generic AI model quality.

Parameter	Typical range	Why it matters
Sensor update rate	5-30 Hz	Low rates reduce reaction time and increase blind motion between updates
Controller frequency	10-30 Hz	Higher frequency improves responsiveness if compute budget allows
Local costmap resolution	0.02-0.10 m/cell	Finer grids capture narrow obstacles but increase CPU and memory cost
Inflation radius	0.10-0.50 m	Adds safety margin around obstacles based on footprint and uncertainty
Sensor range	3-40 m	Determines preview distance for safe deceleration and path correction
Braking distance	platform-dependent	Must be smaller than obstacle detection distance with margin

A simple safety condition is:

d_detect > d_brake + d_latency + d_margin

where d_detect is effective obstacle detection distance, d_brake is stopping distance, d_latency is distance traveled during sensing and control delay, and d_margin is a conservative buffer for uncertainty. This is especially relevant on Raph Rover because larger mass and payload can increase stopping distance compared to Leo Rover.

Sensors used for obstacle avoidance

No obstacle avoidance system is better than its sensing pipeline. In UGV practice, 2D LiDAR is often the reference sensor for reliable local navigation because it provides direct range measurements with known scan geometry. Depth cameras are useful indoors and in structured spaces, but can degrade in direct sunlight or low-texture scenes depending on the model and technology.

Common sensor roles are:

2D LiDAR – used for local obstacle detection and costmap updates. Typical ROS message: sensor_msgs/msg/LaserScan.
3D LiDAR – useful for vegetation, sloped terrain, and non-planar obstacles. Typical message: sensor_msgs/msg/PointCloud2.
Depth camera – detects obstacles above or below LiDAR plane. Useful on indoor Leo Rover setups.
IMU – improves motion estimation but does not detect obstacles directly.
GPS/RTK – supports global localization outdoors, not local collision prevention by itself.

For Leo Rover, compute is typically constrained by the onboard Raspberry Pi, so sensor and algorithm choice must match available CPU and memory. A 2D LiDAR plus Nav2 local costmap is usually easier to run robustly than dense 3D perception. For Raph Rover, higher payload capacity can support additional compute and multi-sensor fusion, which is useful in field robotics where obstacle geometry is less regular.

Practical implementation on Leo Rover and Raph Rover

Leo Rover supports ROS 2 and can serve as a compact research platform for local navigation experiments. Because it uses differential drive, obstacle avoidance must respect nonholonomic motion constraints. The robot cannot move sideways, so the controller must generate feasible angular and linear velocity pairs rather than arbitrary planar motion.

A practical Leo Rover setup often includes a front-mounted LiDAR, odometry, TF tree, and Nav2. This is sufficient for corridor navigation, lab mapping, and basic outdoor tests on even terrain. It is not autonomous out of the box. The user must integrate the navigation stack, tune the footprint, define velocity limits, and validate stopping behavior.

Raph Rover is more suitable when the mission requires larger payload, additional sensors, or outdoor operation with longer endurance. In that case, obstacle avoidance should account for terrain-induced pitch and roll, wheel slip, and sensor occlusion from chassis geometry or mounted equipment.

local_costmap:
  local_costmap:
    ros__parameters:
      update_frequency: 10.0
      publish_frequency: 5.0
      global_frame: odom
      robot_base_frame: base_link
      resolution: 0.05
      rolling_window: true
      width: 6
      height: 6
      footprint: "[[0.18,0.16],[0.18,-0.16],[-0.18,-0.16],[-0.18,0.16]]"
      plugins: ["obstacle_layer", "inflation_layer"]
      obstacle_layer:
        plugin: "nav2_costmap_2d::ObstacleLayer"
        observation_sources: scan
        scan:
          topic: /scan
          data_type: "LaserScan"
          marking: true
          clearing: true
      inflation_layer:
        plugin: "nav2_costmap_2d::InflationLayer"
        inflation_radius: 0.20

Limitations and trade-offs

Obstacle avoidance does not solve all navigation problems. It is local by design. It may fail when obstacles are outside sensor field of view, below sensor resolution, transparent, highly absorptive, or moving too fast relative to the sensing and control loop. It can also produce oscillation in narrow spaces if the local planner and inflation settings are poorly tuned.

On outdoor UGVs, vegetation is a common edge case. Some sensors detect grass and bushes as dense obstacles, while others partially penetrate them. This affects traversability decisions. Standard obstacle avoidance stacks in ROS 2 usually treat occupancy conservatively and do not infer terrain strength or deformability unless an additional semantic or traversability layer is added.

Normative references and standards

The following references are relevant for a precise understanding of obstacle avoidance in ROS-based mobile robotics:

REP 105 – coordinate frames for mobile platforms, including base_link, odom, and map.
REP 103 – standard units and coordinate conventions used in ROS.
ROS 2 message definitions – especially sensor_msgs/msg/LaserScan, sensor_msgs/msg/PointCloud2, nav_msgs/msg/Odometry, geometry_msgs/msg/Twist.
Nav2 documentation – controller server, costmaps, behavior trees, collision monitor, and plugin interfaces.

These documents define the interfaces that make obstacle avoidance interoperable across sensors, controllers, and UGV platforms.

Obstacle avoidance