Anti-collision System

Anti-collision System – definition

An anti-collision system in mobile robotics is a set of sensors, software nodes, and control rules that reduces the risk of a robot hitting static or dynamic obstacles during motion. In the UGV context, it is not a single component. It is a safety-related function built from perception, state estimation, local environment representation, and motion limiting. On ROS 2 platforms, this usually means obstacle sensing with LiDAR, depth camera, sonar, or bumper inputs, then converting detections into a costmap, collision monitor zone, or emergency stop condition.

For differential-drive robots such as Leo Rover and larger outdoor UGVs such as Raph Rover, anti-collision logic typically operates at two levels. The first level is preventive. It modifies velocity commands before contact occurs. The second level is protective. It stops the robot when a configurable distance threshold, time-to-collision threshold, or contact event is reached. In practice, anti-collision is tightly coupled with navigation, but it is not identical to autonomous navigation. A robot may have anti-collision without full autonomy.

In ROS terminology, anti-collision functions are commonly implemented around sensor_msgs/msg/LaserScan, sensor_msgs/msg/PointCloud2, sensor_msgs/msg/Range, nav_msgs/msg/Odometry, geometry_msgs/msg/Twist, and a 2D or 3D cost representation used by Nav2 or custom control nodes. The exact behavior depends on robot footprint, braking distance, controller frequency, sensor field of view, and computation latency.

How anti-collision works in ROS 2

In ROS 2, anti-collision is usually implemented as a pipeline rather than a monolithic driver. Sensor data is published, transformed into a common frame using TF2, filtered, and then consumed by a local planner, collision monitor, or safety supervisor. Nav2 is the standard ROS 2 navigation framework and provides the main building blocks for obstacle-aware local motion. Recent Nav2 distributions also include collision monitoring components designed to stop or slow the robot based on configurable zones.

A typical ROS 2 data path on a UGV looks like this:

• LiDAR or depth camera publishes obstacle observations at 5-30 Hz or more.
• TF2 provides transforms between base_link, laser_frame, odom, and map.
• A local costmap marks occupied cells around the robot.
• A controller such as DWB or MPPI reads the costmap and generates collision-aware /cmd_vel.
• A collision monitor or safety node overrides /cmd_vel if a stop zone is violated.

For ROS 2 Humble and newer, the common navigation stack is Nav2. The local costmap is updated from observation sources and robot footprint data. Anti-collision behavior depends on correct frame semantics and message timing. REP 103 defines standard SI units and conventions used by ROS. REP 105 defines coordinate frames for mobile platforms such as base_link, odom, and map. If those are inconsistent, obstacle locations may be projected incorrectly and the anti-collision layer becomes unreliable.

local_costmap:
  local_costmap:
    ros__parameters:
      global_frame: odom
      robot_base_frame: base_link
      update_frequency: 10.0
      publish_frequency: 5.0
      rolling_window: true
      width: 4.0
      height: 4.0
      resolution: 0.05
      footprint: "[[0.18,0.14],[0.18,-0.14],[-0.18,-0.14],[-0.18,0.14]]"
      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
          obstacle_max_range: 8.0
          raytrace_max_range: 10.0
      inflation_layer:
        plugin: "nav2_costmap_2d::InflationLayer"
        inflation_radius: 0.35
        cost_scaling_factor: 3.0

Key parameters and metrics

Anti-collision quality is measurable. The most important parameters are geometric, temporal, and dynamic. These values should be derived from hardware data sheets and verified in tests.

Parameter	Typical ROS / hardware representation	Why it matters
Detection range	LiDAR max range in sensor spec, for example 8-12 m for compact 2D units	Defines earliest possible reaction to obstacles
Field of view	LaserScan.angle_min to angle_max	Limits side and rear coverage
Update rate	Topic frequency, often 5-20 Hz for LiDAR and 15-30 Hz for depth cameras	Affects latency and missed detections
Robot footprint	Nav2 footprint polygon or radius	Required for correct clearance checking
Stopping distance	Derived from current speed and deceleration	Determines stop zone size
End-to-end latency	Sensor + transport + processing + controller + actuator delay	Directly reduces safe reaction margin

A practical minimum model for stopping distance is:

d_stop = v * t_latency + v^2 / (2 * a_brake)

Where v is robot speed in m/s, t_latency is total delay in seconds, and a_brake is achievable deceleration in m/s². This is a control-oriented engineering estimate, not a certified functional safety formula. On loose terrain, wet grass, gravel, or ramps, actual stopping distance can increase significantly.

Supported hardware and sensor integration

On UGVs, anti-collision depends strongly on sensor selection. No single sensor is sufficient for all conditions. Outdoor robots often combine LiDAR with wheel odometry and IMU. Depth cameras add near-field perception but may degrade in direct sunlight or rain. GPS or RTK does not detect obstacles and is therefore supplementary rather than primary for anti-collision.

Common sensor roles are listed below:

• 2D LiDAR – primary obstacle detection in a horizontal plane. Typical ROS topic: /scan.
• 3D LiDAR or depth camera – detects overhanging or non-planar obstacles. Typical ROS topic: /points or /camera/depth/image_rect_raw.
• IMU – improves motion estimation during turns and rough terrain traversal. Typical message: sensor_msgs/msg/Imu.
• Bumper or contact switch – last-resort protective input, usually mapped to immediate stop.

For Leo Rover, a common anti-collision setup is a front-mounted 2D LiDAR integrated with ROS 2 Humble on the onboard Raspberry Pi 4, with Nav2 local costmap and conservative speed limits. Because Leo Rover is not autonomous out of the box, a full anti-collision stack requires sensor integration, TF configuration, and controller tuning. For Raph Rover, the larger chassis and payload capacity allow wider sensor baselines, higher-mounted LiDAR, additional side coverage, and more capable compute such as an NVIDIA Jetson class module. That is useful for multi-sensor fusion and dense point cloud filtering.

Use cases with Leo Rover and Raph Rover

On Leo Rover, anti-collision is often used in labs, classrooms, and light outdoor tests where the robot navigates around boxes, chairs, curbs, or vegetation. The main constraint is compute budget and sensor placement. A low-mounted sensor can miss thin or elevated obstacles. Since the platform is differential-drive, turning in place can create fast lateral footprint sweeps near walls or table legs, so footprint tuning and inflation radius are important.

On Raph Rover, anti-collision is more relevant for field robotics, where payload mass and higher kinetic energy increase braking demands. Use cases include inspection paths, agricultural rows, rough construction areas, and research deployments with custom payloads. In such cases, anti-collision should include larger stop zones, terrain-aware speed limits, and detection coverage beyond the front arc.

ros2 topic hz /scan
ros2 topic echo /cmd_vel
ros2 run tf2_tools view_frames
ros2 param get /local_costmap/local_costmap update_frequency

Limitations and trade-offs

Anti-collision systems reduce collision probability, but they do not guarantee avoidance in all conditions. Failure modes include blind spots, bad extrinsic calibration, incorrect TF trees, reflective or absorptive surfaces, vegetation clutter, motion on slopes, and compute overload. Another common issue is over-conservative tuning. If inflation radius, obstacle persistence, or stop zones are too large, the robot becomes unusable in narrow passages.

There is also a version-specific distinction between ROS 1 and ROS 2 deployments. ROS 1 systems often relied on move_base with layered costmaps and custom safety nodes. ROS 2 systems typically use Nav2 with lifecycle nodes, behavior trees, and collision monitor tools. The architectural principle is similar, but parameter names, launch systems, and node behavior differ.

Normative references and standards

The following references are relevant when defining anti-collision behavior in ROS-based UGVs:

• ROS REP 103 – Standard Units of Measure and Coordinate Conventions.
• ROS REP 105 – Coordinate Frames for Mobile Platforms.
• ROS 2 TF2 documentation on frame transforms and timestamp consistency.
• Nav2 documentation for local costmaps, controller servers, and collision monitor in ROS 2.
• Sensor manufacturer specifications, for example Slamtec LiDAR range, scan rate, and angular resolution; Intel RealSense depth range and frame rate.
• Platform documentation at docs.fictionlab.pl/leo-rover for Leo Rover integration details.

See also

• SLAM
• Nav2
• LiDAR
• TF2