移動機械人如何利用 2D LiDAR 導航及偵測障礙物

A mobile robot approaching a warehouse aisle faces several different questions. Where is it on the site map? Has a pallet been left across its route? Is there enough room to turn with its current load? These questions are related, but they do not all require the same information or the same response.

A 2D LiDAR can supply part of the answer by measuring the surrounding geometry. The useful starting point is to understand what the scanner measures, how the controller uses those measurements, and what remains outside that sensing arrangement.

What a 2D LiDAR scan actually contains

A planar scanner collects distance measurements at successive angles. Together, those readings describe a cross-section of the surroundings, rather than a complete three-dimensional scene. On a horizontally mounted unit, that cross-section lies around the scanner’s installation height.

A scan also has a time dimension. A moving robot changes position while measurements are being acquired. Software therefore needs more than an unlabelled list of distances: it needs the angle convention, measurement timing, valid range limits and the scanner’s coordinate frame. These details determine whether readings can be placed correctly relative to the robot.

The ROS LaserScan message illustrates this distinction. It includes angular increments, timing information and range limits alongside the range array. That is a useful example of the information an integration must handle, not a promise that every scanner supplies that message directly.

Mapping, localization and obstacle detection are different jobs

Mapping builds a representation of the environment. In a 2D SLAM system, software can combine laser scans with motion estimates, align observations and refine a map as the robot moves. The scanner is a measurement source; the mapping algorithm performs the estimation.

Localization asks a different question: where is the robot within an existing representation? A robot may compare new scans with a saved map rather than rebuild that map on every journey. Matching the sensor data to the software’s expected format and coordinate relationships is essential in either case.

Obstacle detection concerns what is in the route now. A pallet placed in a previously clear aisle may need to appear in the robot’s current obstacle representation even though it is absent from the saved site map. Navigation software can then use that updated information when evaluating a route or movement command.

This distinction is useful during commissioning. A robot that appears correctly positioned on its map can still have an incorrectly configured obstacle-data path. Conversely, a sensor can report an obstacle without giving the vehicle enough information to localize itself. Verify these functions separately.

Decide whether the controller needs data or switching signals

Not every project needs a full stream of distance measurements. Some ordinary detection tasks need a defined signal when an object enters a configured area. A discrete-output scanner can suit that arrangement if its output type and detection behavior match the receiving controller.

Navigation and mapping applications generally need measurement data that software can interpret. An Ethernet connector alone does not establish the protocol, supported commands, data structure or availability of a suitable driver. Some devices offer both data and switching interfaces, but their exact behavior still needs confirmation.

The catalogue of DAIDISIKE 2D LiDAR scanners separates ordinary switching detectors, navigation and measuring models, and safety-scanning configurations. That makes the function a more useful starting point than simply choosing the device with the longest advertised range.

Check the complete software path, not just the connection

For a data-based navigation setup, trace the information from the scanner to the software component that consumes it. A practical review includes acquisition, decoding, timestamps, coordinate transformation and the destination topic or interface. A successful network connection verifies only one part of that path.

Navigation systems such as Nav2 use sensor observations in layered costmaps. Configuration affects how obstacles are added, how observations clear previously occupied space and how far measurements are used. Seeing points in a visualization window is therefore not the same as verifying the obstacle representation used during motion.

During a controlled evaluation, inspect both views. Place and remove representative objects, then observe the raw measurements and the controller’s resulting representation. Record the configuration used so that later software or mounting changes can be compared with the same baseline.

Mounting determines which objects can be observed

A 2D scanner cannot obtain a useful return from an object that does not intersect its scanning plane. Consider a low obstruction below that plane and an overhanging load above it. Both may occupy space that matters to the vehicle even when neither appears in the planar measurements.

The installation must also account for the robot’s own body and load. A bracket, bumper, cable or carried item can obstruct the intended view. Review the arrangement with the robot loaded as well as unloaded, and consider how the sensing geometry changes along the actual route.

Evaluate specifications under the intended conditions

Range figures need their test conditions. Compare the specified target reflectivity, minimum range and environmental limits instead of assuming that the maximum distance applies to every surface. Accuracy, repeatability, angular step and scan rate describe different properties; they should not be treated as interchangeable measures of performance.

Ask which settings are supported together on the exact ordered variant. Likewise, request the applicable manual, configuration utility and software documentation. An evaluation should establish whether the complete combination works for the intended task, rather than relying on a family name shared across several configurations.

Keep navigation separate from personnel safeguarding

Ordinary obstacle detection is not automatically a personnel-safety function. A software zone labelled “stop” does not make an ordinary measurement output a safety-rated output. Where the application requires personnel protection, suitable devices and a properly designed and validated safety function are separate requirements.

Some documented safety scanners can supply navigation measurements while independently monitoring protective fields. That dual capability belongs to the particular safety device and its specified integration; it must not be assumed for an ordinary LiDAR because the products look similar.

Prepare a short, repeatable evaluation before ordering

Turn the application into a testable brief. The following questions help the supplier and integrator discuss the same requirement:

• Which objects must be observed, at what distances and approach directions?
• Does the controller need distance data, ordinary switching signals or a separately specified safety interface?
• Where will the scanner sit relative to the chassis, load and possible obstructions?
• What protocol, software package, driver and version information is required?
• How will readings and controller behavior be checked when an object appears, moves away or a connection is lost?
• Who will record the configuration, acceptance criteria and results?

A model-by-model comparison, supported by a 2D LiDAR selection guide, can then narrow the choices before a sample is ordered.

The goal is not to find a scanner with the most impressive headline specification. It is to select a measurement source, interface and installation that the robot system can use consistently, with its limitations understood and its required functions verified.