Time-of-flight sensor

Time-of-flight sensor – definition

A time-of-flight sensor, usually abbreviated as ToF sensor, is an active ranging device that estimates distance by measuring the travel time of emitted light between the sensor and a scene point. In mobile robotics, this usually means near-infrared light emitted by an LED, laser diode, or VCSEL and measured after reflection by a photodetector or photodetector array. The basic relation is simple: distance equals the speed of light multiplied by round-trip time and divided by two.

In the UGV context, a ToF sensor is used to obtain depth information for obstacle detection, short-range perception, docking, terrain analysis, and local navigation. It is not a single product category. The term covers several implementations, including single-point rangefinders, multi-zone sensors, and depth cameras. In practice, engineers often distinguish compact ToF sensors from spinning LiDARs even though both can rely on time-of-flight measurement. LiDAR usually provides wider field mapping and publishes 2D or 3D scan data, while compact ToF modules are commonly used for close-range sensing with lower range and narrower field of view.

On ROS 2-based UGV platforms such as Leo Rover and Raph Rover, a ToF sensor is typically integrated as a short-range depth source. It complements wheel odometry, IMU, cameras, and sometimes LiDAR or GNSS. It should not be treated as a full autonomy stack by itself. On Leo Rover in particular, a ToF device is useful for laboratory navigation, indoor experiments, and obstacle stops. On Raph Rover, the same class of sensor can serve as a near-field safety or perception layer around a larger payload setup.

How a time-of-flight sensor works

The core principle is direct or indirect measurement of optical propagation delay. The implementation matters because it defines range, precision, susceptibility to ambient light, and output format.

The most common variants used in mobile robotics are listed below.

Direct ToF – the sensor measures photon arrival time directly. This method is used in some LiDAR architectures and specialized depth devices.
Indirect ToF – the emitted light is modulated, and the phase shift of the returned signal is used to infer distance. This is common in compact depth cameras and some ranging modules.
Single-zone or single-point ToF – one distance estimate per acquisition cycle. Typical use: front obstacle detection.
Multi-zone ToF – a small grid of distance samples, for example 8×8 zones. Typical use: simple scene segmentation and local obstacle reasoning.
ToF depth camera – a depth image, usually published similarly to other RGB-D or depth sensors.

The idealized ranging equation is:

d = (c * t) / 2

where d is distance, c is the speed of light, and t is round-trip travel time. Real devices apply internal calibration, phase unwrapping, filtering, and confidence estimation. Manufacturer datasheets should always be treated as the primary source for accuracy and operating envelope.

Key parameters and metrics

For UGV integration, the useful question is not only whether a sensor measures distance, but whether its output is stable enough for navigation and whether it fits the compute and power budget of the platform. The parameters below usually matter more than product naming.

Parameter	What it means	Typical relevance in UGVs
Range	Minimum and maximum measurable distance	Defines whether the sensor is useful only for near-field stopping or also for local mapping
Accuracy	Distance error relative to true value	Important for docking, edge detection, and obstacle margin tuning
Precision / repeatability	Measurement spread under fixed conditions	Affects filter stability and local planner behavior
Field of view	Angular coverage of emitter and receiver	Determines blind spots and mounting strategy
Frame rate	Update frequency in Hz	Must be sufficient for robot speed and stopping distance
Ambient light robustness	Resistance to sunlight and reflections	Critical outdoors, especially on bright surfaces
Interface	I2C, UART, USB, Ethernet, MIPI CSI-2	Affects driver availability and CPU load
Timestamp quality	How accurately data is time-stamped	Important for TF alignment and sensor fusion

In ROS, data from ToF devices may appear as sensor_msgs/msg/Range for single-point sensors, sensor_msgs/msg/Image for depth frames, sensor_msgs/msg/PointCloud2 for projected 3D output, or less commonly sensor_msgs/msg/LaserScan if the driver converts a sensor profile into a scan-like representation. The exact topic type depends on the driver, not on the physical principle alone.

Time-of-flight sensors in ROS 2

ROS 2 integration should follow standard frame semantics and message conventions. For coordinate frames, the relevant normative reference is REP 103 for units and conventions and REP 105 for mobile platform frame relationships such as base_link, odom, and map. A ToF sensor mounted on a UGV should have its own sensor frame in the TF tree; for camera-like devices, an optical frame is also commonly used.

A minimal ROS 2 setup often includes these elements.

A hardware driver node connected over I2C, UART, USB, or Ethernet
A static transform from base_link to the sensor frame
Optional filtering, for example median filtering or range clipping
Optional conversion to point cloud or costmap observation source

Example static transform publisher:

ros2 run tf2_ros static_transform_publisher \
0.12 0.00 0.18 0 0 0 base_link tof_link

Example costmap observation source in Nav2 for a depth-producing ToF device converted to a point cloud:

local_costmap:
  local_costmap:
    ros__parameters:
      observation_sources: tof_cloud
      tof_cloud:
        topic: /tof/points
        data_type: "PointCloud2"
        marking: true
        clearing: true
        obstacle_max_range: 2.5
        obstacle_min_range: 0.05
        max_obstacle_height: 0.5
        min_obstacle_height: 0.0

For single-point range sensors, direct integration into navigation is more limited. They are often used for emergency stop logic, docking triggers, or simple behavior-tree conditions rather than full local mapping.

Supported hardware and integration on Leo Rover and Raph Rover

On Leo Rover, ToF sensors are usually attached as auxiliary perception devices because the default platform is based on a Raspberry Pi compute unit and has limited compute headroom compared with larger GPU-equipped systems. This makes compact ranging modules attractive for experiments where a full 3D LiDAR or heavy depth pipeline is unnecessary.

Typical Leo Rover use cases include:

front-facing obstacle detection in indoor corridors
close-range docking to a charging or fiducial station
ground-clearance or edge detection experiments
teaching ROS 2 sensor integration with low power consumption

On Raph Rover, the larger payload envelope allows more combinations, such as multiple ToF modules around the chassis, a ToF depth camera paired with a LiDAR, or a fusion stack with GNSS/RTK and IMU. In that setup, ToF usually serves the near-field layer while LiDAR or stereo handles wider perception.

For both platforms, mounting geometry is critical. A low-mounted sensor can detect curbs and low obstacles but may also suffer from dust, grass, or uneven terrain. A high-mounted sensor increases horizon coverage but may miss small obstacles near the wheels.

Limitations and trade-offs

Time-of-flight sensors are useful, but they have strict operating limits. These limits often determine whether the sensor is suitable for field robotics or only for structured indoor use.

Sunlight sensitivity – many compact ToF modules degrade outdoors due to strong infrared background.
Surface dependence – dark, absorptive, glossy, or transparent materials can reduce reliability.
Multipath reflections – reflective environments can produce biased depth.
Limited range – many modules are intended for centimeters to a few meters, not for global navigation.
Narrow field of view – single-point sensors create large blind areas unless multiple units are used.

For this reason, ToF should usually be treated as one component in a perception stack, not as the only ranging source on an outdoor UGV. On Leo Rover and Raph Rover, combining ToF with wheel odometry, IMU, and another exteroceptive sensor produces more robust behavior than relying on ToF alone.

Normative references and standards

The definition and integration practice above align with standard ROS documentation and message conventions rather than a platform-specific interpretation. For ROS-based systems, the most relevant references are REP 103 for standard units and coordinate conventions, REP 105 for coordinate frames on mobile platforms, and the ROS 2 message definitions for sensor_msgs. Device-level numeric claims such as range, accuracy, and update rate should always be verified against the current manufacturer datasheet for the exact sensor model.

When comparing devices, it is also important to separate physical principle from ROS representation. A ToF sensor may publish a single range, a depth image, or a point cloud. The correct integration path depends on the published message type, timestamp behavior, and transform consistency in TF2.