Contents

Introduction

Scanning laser range finders provide a relatively new and exciting high-resolution robotics sensor.  Common in high-end robotics for many years, these sensors are becoming more common on relatively inexpensive robotics applications due to the rich, high resolution, and high frequency data they generate. 

When a sensor generates tons of data quickly like that of a laser range finder, it demands higher performance onboard computing power for the robot to take full advantage of the sensor's unique capabilities.  This means you will typically find laser range finders on robots like our Garcia with onboard processing in the hundreds of Mhz with plenty of memory.  This is not the territory of OOPics, Basic Stamps, or your favorite 8-16 bit controller flavor.  Typically a higher powered, 32-bit processor running a full OS like Linux is employed.  In some ways the Laser range finder is halfway between the minimal compute requirements of a sonar range finder and a real-time vision system. 

Laser range finders give data with pencil beam viewing at high data rates with roughly millimeter resolution.  Power consumption varies but tends to be somewhat more than smaller and less sophisticated sensors like IR rangers, sonars, etc.  The lasers tend to be pretty self contained in professional and sturdy enclosures for external mounting on mobile robots and other applications. 

Theory of Operation

Scanning laser range finders can be thought of as little sonars using light instead of sound to create 2-D maps of the proximity to nearby objects...  much like the sonars used on a submarine to detect nearby objects. 

Because lasers use light instead of sound, they can measure both very fast and with an extremely narrow FOV (field of view) for the measurement. 

The term scanning means the ranger takes a reading and then moves some fraction of the full angular resolution and then takes another reading...  continually repeating this in a full circle.  Due to typical physcical and mechanical constraints there is often a small portion of the radial path that is "blind" to the sensor. 

The data coming back from a laser typically maps directly to a polar plot with the scanner at the origin and each reading taking place around the circle from 0 to 360 degrees with a blind spot somewhere in the circle. 

Lasers are often specified in resolution, frequency, and angular resolution.  Resolution refers to how accurate the distance measurement is in a given direction and is typically around 1-3mm.  Frequency refers to how often the full 360 degree arc is swept by the scanning sensor and is typically 10Hz or even more.  Angular resolution refers to how many samples are taken with each full 360 degree scan of the sensor.  This value is often over 500 steps of resolution meaning sub-degree wedges of the full circle are measured with each sample. 

Rangers typically also have a minimum and maximum range where they can measure.  Minimums are often a few centimeters and range can be over a meter up to tens of meters and more. 

Laser Hardware

Lasers are made by several manufactures with some of the most common in mobile robotics being SICK and Hokuyo.  These vary in range, performance, power consumption, and cost. 

The Hokuyo URG-04LX is a very capable sensor example.

These sensors typically take a power input of roughly 5V (anywhere from 2.5 Watts to 17.5 Watts).  The sensor is then interfaced with a serial connection (and USB in some newer sensors).  This interface allows some changes and primitive filtering of the data but essentially is a stream of data coming in at a relatively high serial transfer rate (38.4k baud or more) to the host computer's serial port. 

Inside the enclosure for the scanner is a scanning head (think of a flying or spinning disk) where the sensor is mounted on the head.  The actual laser is a low-power laser that emits a narrow beam of laser light that then reflects off the nearest object and is detected by the ranger. 

Since the speed of light would require Ghz or better timing for the ranges used by the rangers, there are tricks employed with pulsed laser light to view phase change of the pulses which greatly reduces the absolute timing requirements of the internal sensor/laser interfacing circuitry. 

This raw data then commutes through some sort of embedded processor that package up the data for the serial interface and communication with the host computer. 

Laser Software

Scanning laser range finders are either available as a component with minimal software or they are integrated into more complex systems where there may or may not be any specific laser software support. 

Since the interface is straightforward serial communication, most vendors of the components assume that you are competent with the language and host hardware of your choice and you can readily write software for the interface...  based on your preferences and system architecture. 

Often, there is a simple sensor viewing application that lets you view the data from the laser quickly and easily from a standard desktop or notebook machine.  For instance, the Hokuyo offered by Acroname is supported in the download section with versions of the viewer for MacOS X, Linux, and Windows host computer platforms. 

MacOS X version of the laser viewing application

Interface Example

For this example, we used a Hokuyo URG-04LX laser and a laptop running Windows XP.  This would work equally well on a MacOS X computer or a machine running Linux, depending on your preference. 

First, the connector on the laser was soldered up to an included DB-9 shell to give a common ground, TX, and RX lines between the computer and the sensor.  There is no flow control employed either in software or hardware.  The laser comes with a cable that has blunt cut wire that is color coded on one end and the other side is a small white connector and dust cover that plugs into the laser. 

Close up showing the color coding and position of the wires.

The cable also provides power to the laser so it forms something of a "Y" with the DB nine branching out to the laser on one arm of the "Y" and the power supply providing 5V on the other arm.  We used a 5V 2.5A wall wart we had laying around for the power supply which is overkill...  but works well. 

Next, we downloaded the software for the laser from the Acroname Download Center for our particular platform.  This software is a simple archive that can be placed anywhere on a system's disk when it is downloaded (we used C:/acroname/test).  In this download is a simple instruction file and a directory named "aBinary" where the application and configuration file resides.  The configuration file defaults worked fine for us but would need to be changed if not using the default serial port (COM1 in our case). 

We then plugged in the laser (to the computer and the wall) and ran the application.  Right away, the display started dancing with the live sensor data.  Moving things in front of the laser and re-positioning it with respect to walls, ceilings, etc.  gives an impression of the data that is returned by the laser. 

Simulation Example

The simulation example uses the Symonym simulation environment and a model of a Garcia in a odd shaped room with a laser mounted on it.  There is no wiring for this example but it does require a download of the Symonym Free Player at www.symonym.com for the platform of your choice.  You also need to download the LaserDemo.stick file from the Acroname Download Center that is placed into the aSymonym sub-directory of the Symonym Free Player download. 

With these in place, you can run the Symonym executable (located in the aBinary directory) to get a model of the Garcia equiped with a laser up in the simulation environment.  We tested this quick and then closed the window to go and get the Laser viewing application. 

The Laser Viewer is also available in the Acroname Download Center and we installed this in a different location from the Symonym player.  We then needed to change the laser.config file in the Laser Viewer download (the file is in the aBinary directory) to reflect the connection to the simulated laser, rather than the default physical one.  This ended up being three lines as follows, based on our maching running the simulator's IP address:

This directs the viewer to connect to the simulation for sensor data, rather than a physical laser.  Also, the baudrate is changed to the default of 19200 (for the Laser application) to avoid setting and resetting the port on the connection. 

Once this configuration is in place (with your TCP/IP address in place of the 192.168.1.175 above), we were able to start up the simulation and then run the viewer to see the simulated laser data. 

Windows XP version of the Symonym Free Player with a laser model

Using the Data

There are some things to quickly notice about the data.  This viewer shows that there are noisy bits in the data that tend to diminish when viewing a solid wall with a consistent surface. 

The Laser viewer application just shows every sample for the entire radial path of the laser.  There are options with this laser to "window" down to a smaller angular portion of the scanner's data as well as averaging multiple points to dampen noise and reduce data. 

Most laser data is consumed by algorithms that deal in propabilities over time and position.  Each data point from the laser is managed in a database with time information.  In this way, clouds of recent data can be considered obstructions in the laser's field of view but over time, these data points diminish as things may move (think people, doorways that close/open, etc.)

This topic is much broader than that of the basic functioning of the laser and really deserves it's own article or set of articles to fully discuss this broad topic.  Let us know if you would like to learn more and with enough requests, we can put together more information on this.