Ultrasonic sensor

Ultrasonic sensor – definition

An ultrasonic sensor is a range sensor that estimates distance by transmitting an acoustic pulse, usually above 20 kHz, and measuring the time-of-flight of the reflected wave. In mobile robotics, it is used for short-range obstacle detection, near-field safety, docking, cliff or edge checking in selected geometries, and basic environment awareness where low cost and simple integration matter more than angular resolution. The core measurement model is straightforward: distance equals the speed of sound multiplied by the round-trip travel time, divided by two.

For a monostatic sensor, the basic formula is:

d = (c * t) / 2

In this equation, d is distance in meters, c is the speed of sound in air, and t is the measured echo time. At 20 degrees Celsius, c is approximately 343 m/s, but it varies mainly with temperature and, to a lesser extent, with humidity and air composition. This makes ultrasonic ranging sensitive to environmental conditions. In UGV platforms, this sensor is generally treated as a complementary proximity source, not as the primary perception modality for mapping or high-confidence navigation.

On Leo Rover and Raph Rover, an ultrasonic sensor is typically relevant when the robot needs short-range frontal or side proximity sensing in indoor corridors, lab setups, or low-speed outdoor experiments. It does not replace LiDAR for navigation, and it does not provide the geometric detail required by modern SLAM pipelines in ROS 2. Its practical role is usually local obstacle awareness in the last few centimeters up to a few meters, depending on the transducer design and target surface.

How an ultrasonic sensor works in mobile UGVs

The sensor emits a burst of sound, often around 40 kHz in common robotics modules, then waits for an echo reflected by an obstacle. The measured delay is converted to distance. This method is simple, but the beam is usually wide, reflections are strongly affected by target angle and material, and multi-path effects are common near walls, chassis parts, and uneven terrain.

For ground robots, the main operational characteristics are the following:

Short useful range – often from about 0.02 m to 4 m for common modules, depending on manufacturer specification.
Wide field of view – often roughly 15 to 60 degrees, which reduces spatial precision.
Low update rate compared with LiDAR – often around 5 to 50 Hz.
Strong dependence on acoustic reflectivity and incidence angle.
Susceptibility to crosstalk when multiple ultrasonic sensors fire at the same time.

These properties matter on differential-drive platforms such as Leo Rover. A wide beam may detect a wall before the LiDAR or depth camera does in a blind spot close to the bumper, but it may also produce ambiguous readings near corners or vegetation. On Raph Rover, where payload capacity allows denser sensor suites, ultrasonic modules may serve as auxiliary near-field sensors around the chassis perimeter, but they are still secondary to LiDAR, stereo, or depth sensors in autonomy stacks.

ROS 2 integration and message types

In ROS and ROS 2, ultrasonic distance data is usually exposed either as a single range measurement or as a simplified synthetic scan. The normative reference for close-range distance sensors is sensor_msgs/Range. This message supports radiation types including ultrasound and infrared and carries both the measured value and the sensor operating bounds.

The most relevant fields in sensor_msgs/msg/Range are:

header.frame_id – sensor coordinate frame.
radiation_type – ULTRASOUND for ultrasonic sensors.
field_of_view – angular width in radians.
min_range and max_range – valid measurement interval in meters.
range – measured distance in meters.

In ROS 2 Humble and newer, a typical setup publishes one topic per sensor, then uses TF2 for spatial placement on the robot model. If the robot runs Nav2, the ultrasonic stream can be inserted into the local costmap through a custom integration path, for example by converting range readings into obstacle observations conservatively. This is useful for close objects that may be poorly represented by sparse LiDAR returns at bumper height.

ultrasonic_front:
  ros__parameters:
    frame_id: ultrasonic_front_link
    topic_name: /ultrasonic/front/range
    radiation_type: ULTRASOUND
    field_of_view: 0.52
    min_range: 0.02
    max_range: 4.00
    publish_rate: 10.0

ros2 topic echo /ultrasonic/front/range
ros2 topic hz /ultrasonic/front/range
ros2 run tf2_ros tf2_echo base_link ultrasonic_front_link

When integrating on Leo Rover, the compute unit is typically a Raspberry Pi, so a lightweight driver over GPIO, I2C, UART, or USB is preferred. On Raph Rover, more complex multi-sensor filtering is practical if the onboard computer includes a higher-performance x86 or Jetson-class system.

Key parameters and metrics

Ultrasonic sensors are simple, but their usefulness depends on a small set of parameters that should always be checked against the manufacturer datasheet. For robotics integration, the measurement model and timing behavior are more important than raw presence of the sensor.

Parameter	Typical meaning	Why it matters on UGVs
Operating frequency	Usually around 40 kHz	Affects transducer design and beam characteristics
Min and max range	Example: 0.02 m to 4 m	Defines usable near-field safety envelope
Beam angle	Field of view in degrees or radians	Determines lateral ambiguity and corner behavior
Update rate	Often 5 to 50 Hz	Limits stopping distance at higher robot speed
Resolution and accuracy	Often centimeter-level accuracy, with some sensors offering finer resolution under ideal conditions	Important for docking and approach tasks
Temperature compensation	Hardware or software correction	Improves consistency in outdoor operation

For low-speed navigation, a useful engineering check is whether the update rate and braking distance are compatible. If Leo Rover moves at modest speed in a corridor, a 10 Hz front ultrasonic sensor can support emergency slowdown logic. If Raph Rover carries a higher payload and moves faster, the same sensor may be insufficient as a primary stop trigger due to latency and uncertainty.

Use cases with Leo Rover and Raph Rover

On Fictionlab platforms, ultrasonic sensing is best understood as a support sensor. It adds local redundancy, not full scene understanding. This distinction is important for students and researchers who expect it to behave like a compact LiDAR.

Practical examples include:

Front bumper proximity detection on Leo Rover during teleoperation or slow autonomous approach.
Docking distance estimation to a charging point or fixture in controlled indoor conditions.
Side clearance checks on Raph Rover when carrying wide payloads.
Detection of low, acoustically reflective obstacles that may be weakly visible to another sensor mounted higher on the chassis.

In ROS 2 deployments, these sensors are often fused at the behavior or planning level with wheel odometry, IMU, and a 2D LiDAR-based local planner. On Leo Rover, this can be added without changing the differential-drive base model. On Raph Rover, a ring of ultrasonic sensors may be useful for perimeter awareness, but synchronization must be managed to avoid mutual interference.

Limitations and trade-offs

Ultrasonic sensors have clear limits in research-grade autonomy. Soft materials, angled surfaces, mesh structures, and vegetation can generate weak or misleading echoes. Rain, wind, dust, and thermal gradients can degrade performance. The wide beam makes exact obstacle contour extraction impossible. This is why ultrasonic sensing is rarely the main source for SLAM or traversability mapping on modern UGVs.

Important trade-offs are:

Low cost and easy integration versus poor angular resolution.
Good close-range awareness versus weak performance in cluttered outdoor scenes.
Simple ROS 2 publishing versus limited direct use in map building.

For Leo Rover and Raph Rover, the engineering conclusion is simple: use ultrasonic sensors for local proximity tasks, fallback safety logic, or teaching fundamentals of time-of-flight sensing. Use LiDAR, depth cameras, and calibrated visual-inertial pipelines for mapping and autonomy.

Normative references and standards

The ROS interface reference is the sensor_msgs/Range definition maintained within the ROS ecosystem. Frame naming and coordinate conventions should follow standard ROS TF practices and the relevant REP documents used by the robot stack, especially REP 103 for standard units and coordinate conventions. Numerical limits such as minimum range, maximum range, field of view, and update frequency must come from the specific sensor manufacturer datasheet, because they differ significantly across modules.

For implementation work, verify these sources first:

ROS 2 message documentation for sensor_msgs/msg/Range.
REP 103 – Standard Units of Measure and Coordinate Conventions.
Platform documentation at docs.fictionlab.pl for mounting, compute, and ROS 2 integration context.
The exact ultrasonic sensor electrical and timing specification from the manufacturer.

Ultrasonic sensor