Note that this is for communications with the SICK S300 Standard, not the S300 Professional. If you have an S300 Professional, see the cob_sick_s300 ROS package.

As much as I am a software guy, you’re simply not going to avoid hardware for long in the world of robotics.  Sure, simulators are great, but it’s impossible to fully replace the nuances (and excitement and frustration) of developing robots with actual hardware.  Furthermore, the “noise” generated by live robotics is hard to adequately mimic in the simulated environment; e.g., missed laser scans, bumpy surfaces, sensors that aren’t perfectly aligned with where you think they are, dealing with hardware drivers, etc.

Unfortunately, the hardware side of robotics is far from cheap if your research is self-funded (read – I am still accepting research donations).  One of the most essential, and expensive, elements of modern robotics is a solid range-finding sensor(s).  While having been around for some time, laser range-finders are finally compact enough and relatively affordable enough to augment any roboticist’s tool bench.  The challenge is finding one that is the right balance of size, price, power consumption and capability for your project’s needs.

The Hokuyo URG-04LX-UG01 Laser is a great choice for basic range-finding needs; it’s very compact (e.g., can fit in the head of an Aldebaran Nao), weighs little, has a great price point (around $1,200…Nao head not included) and provides precise 2D range details out to 5.6 m.  Providing 3D point cloud information, the Mesa Imaging SR4000 provides an insane amount of range information within a narrower range of sensing (43° or 69°) out to 10 m, ideal for highly precise applications, such as interpreting facial expressions (if you’re not using a camera for some reason) or tracking slight body motions…all for a cool $9,000.  On the other end of the cost spectrum, the XBox 360 Kinect also provides point cloud information out to 5 m while only costing a fraction of the cost at $150 (assuming you can find it during the Christmas rush); the Kinect also has newly available drivers for ROS.  (I can’t imagine a better starting point than Kinect.)

For my own needs, I was looking for something that could provide a greater range than the URG-04LX-UG01 without precluding the ability to collect point cloud information at an extended range as well.  Without spending your entire research budget, this can be achieved by obtaining a 30m laser range-finder and mounting it on a tilt system, such as a SPT400 Tilt System.  The pairing won’t be as real-time as an SR4000 (you’ll need to remain stationary while tilting the laser for a most accurate point cloud), but it makes the 30 m point-cloud generator far more affordable.  (If you don’t need 30 m capabilities…stop here and go for the Kinect!)

As for the range finder, a 30 m laser range finder can cost around $4,000 – $5,500 brand spanking new; great choices being Hokuyo UTM-30LX and the SICK LMS100.  But if you keep your eye on eBay, you can pick up a comparable laser range finder for far less; I was fortunate enough to find a new SICK S300 Standard priced more like a URG-04LX-UG01, providing the 30 m range data I was looking for.  Unfortunately, the S300 Standard does not provide programmatic access through its “system plug” (the base port) like it’s bigger (and more expensive) brother, the SICK S300 Professional.  With that said, the S300 Standard does provide communications via an RS-232 diagnostics port on the front of the scanner.  It’s limited to 38400 baud, but it’s enough to provide 2.75 scans per second, encompassing 270° of range information at 1/2° increments.  Unfortunately, the S300 Standard documentations is almost useless for taking this approach; accordingly, this post (after the above segue) provides an overview of programmatic communications with the SICK S300 Standard via the diagnostics port.

The SICK S300 Standard diagnostic port provides 38400 baud reporting of laser scan data over RS-232 serial communications.  There are three general steps to requesting laser scans via this approach:

1. A “token” must be programmatically requested and allocated by the S300 in order for scan data to be requested.  Requesting a token informs the S300 which communication port will be used for data exchange.
2. After successfully requesting a token to be allocated, requests (max 2.75 Hz) may be sent for laser scan information.
3. The token may be released when no more scans are needed.  If not released, the token will be automatically released during a power reset.  (There isn’t much need to release the token if you’re only communicating via the diagnostics port.)

We’ll now detail how each phase of communications is accomplished, beginning with setting up the system for initial testing.

Initial System Setup

Instead of diving right in to writing a C++ application for managing the communications, it’s best to confirm and demonstrate successful communications with the S300 via raw serial communications using a serial utility.  But before we get even that far, the hardware itself needs to be setup.  To communicate with the S300 Standard, the following equipment is required (model numbers are further detailed here):

• SICK S300 Standard S30B-2011BA (obviously)
• Standard 11-wire System Plug SX0B-B1105G.  The system plug provides separate wire access for powering the device and for accessing the safety output wires.  Accordingly, if you’re simply looking to use the S300 Standard for laser range scans, and do not require the safety features, the system plug is optional; alternatively, power source wires may be soldered directly to the base of the S300.  (But the system plug sure looks nice, gives the S300 a flat surface for mounting the S300 on a mobile robot base, and decreases the chance of damaging the S300 with a solder gun.)
• S300 Programming Cable 6021195.  This cable plugs into the front of the S300, via the diagnostic port, and has an RS-232 connector at the other end for communications from a computer.
• 24 VDC, 2.1 Amp Power Supply (PS) 50W-24V.  This power supply facilitates running the S300 from an AC outlet.  Alternatively, you can use a 24 VDC battery (and surely will on a mobile robot)…but the AC connection is very handy during development.  This power supply can typically be found on eBay for far less than retail.

The hardware setup is then quite simple, as follows:

1. Wire the power supply by taking a three wire cord, such as an old monitor cord and splice the wires at the monitor end; e.g., ending up with brown (positive), blue (neutral), and green-yellow (ground) wires.  The wires will be inserted into the bottom-front of the power supply with brown going to “L,” blue going to “N” and green-yellow going to the remaining ground connector.
2. From the S300, only three wires are used coming from the system plug for powering the laser scanner; all other wires are unused and may be wrapped (separately) in electrical tape.  Line FE (ground – green) should be inserted into the same power supply connector that the green-yellow ground wire was inserted into.  Line 1 (+24V DC – brown) should be inserted into the top-front connector of the power supply labeled “+.”  Finally, line 2 (0V DC – blue) should be inserted into the connector, two over from line 1, labeled “-.”

After providing power to the S300 Standard, and before serial communications are possible, the S300 Standard must be initialized via the Configuration & Diagnostics Software (CDS); until that is done, it’ll show the number “6″ on its display when powered up.  Since the S300 Standard is a safety scanner, the laser scanning will stop (and it would send a signal to the vehicle it’s mounted on) if an object enters the protective field range, with its default settings.  So within the CDS, set the scanner for automatic interlock restart to disable this disabling trigger action.  (Certainly not recommended if you actually need the safety features…the S300 operating instructions gives all the details on this.)  Once properly configured, the S300 Standard should show “1″ on its display with a green checkbox displayed.

Now that the scanner is powered and configured, it’s time to test basic communications.  If using Windows, a tool such as Advanced Serial Port Monitor may be used to send serial requests to the S300 and to read from it, accordingly.  In a Linux environment, such as Ubuntu Lucid Lynx, there are two tools that I prefer for testing serial communications: jpnevulator to write commands and slsnif to listen for responses.  Using these utilities, take the following steps to setup:

1. Hook up the S300 Standard diagnostic cable to a port, such as /dev/ttyUSB0.  If you’re unsure of which port you are plugging in to, run the following command in a terminal, before plugging it into the port; it’ll let you know which port has been connected to:
   tail -f /var/log/messages
2. Open a terminal for monitoring responses from the S300:
   slsnif -s 38400 -n -x -u /dev/ttyUSB0
3. Open a second terminal for manually sending serial commands to the S300:
   jpnevulator --ascii --tty /dev/ttyUSB0 --write

We’re now ready to request a token and laser scans…

Token Request

As mentioned, before being able to request laser scan data, a token must be requested to inform the S300 which communication port we’ll be requesting scan data on.  In this case, communications are over the diagnostic port.  To request a token, send the following hex command via the jpnevulator terminal by simply copying/pasting the following command:

00 00 41 44 19 00 00 05 FF 07 19 00 00 05 FF 07 07 0F 9F D0

If this command was successfully sent, the slsnif terminal should return 4 null byte-pairs as 00 00 00 00.  If this response was not received, verify the port of communication (e.g., /dev/ttyUSB0 vs. /dev/ttyUSB1) and try again.

Scan Request

After successfully requesting a token, laser scans may now be requested.  Send the following to request a laser scan:

00 00 45 44 0C 00 02 22 FF 07

This request should return a 1096 byte-pair response.  The response is interpreted as follows:

In practice, the first 12 byte-pairs may be ignored assuming the fourth byte-pair (position 3) is null (00).

Each element of the scan data is made up of two byte-pairs (four bytes) and must be broken down to the bit level to parse the information. The first byte-pair may be ignored as it concerns itself with the S300′s safety features. The second byte-pair contains information stored across 16 bits. Bits 0-12 express the range distance in cm. The only other useful bit (pun intended) is bit 13 which indicated if glare (dazzling) was detected; an indication that the range measurement may be subjectively ignored, or confidence variance increased for that datum.

The TGM CRC is a cyclic-redundancy-check (or checksum) to test the integrity of the scan report. Googling for that fancy phrase will provide algorithms for its implementation.

The care-o-bot‘s S300 ROS package provides terrific example code for parsing range data and computing the CRC. (This package won’t work out-of-the-box as the care-o-bot’s S300 driver is intended for the S300 Professional which has quite different header information…but it doesn’t take much effort to modify it for the S300 Standard. I’ll make an announcement once I publish the ROS package that I’ve developed which works with the S300 Standard.)

Token Release

If you’re dotting your i’s and crossing your t’s, you should request a token release when complete.  Do so by sending the following command:

00 00 41 44 19 00 00 05 FF 07 19 00 00 05 FF 07 00 00 E7 B8

This isn’t required if you’ll only ever be communicating via the diagnostics port, but it surprisingly makes you feel clean and tidy if you do it, nonetheless.

The next step is to write a program which sends the described commands to the S300 Standard and parses responses, accordingly. If you don’t want to go for what the care-o-bot code includes, simple, reusable, serial port communications code for sending and receiving data in C++, may be found within the ROS package serial_port; an example package which uses it is the ax12-arm.

With this, the 30 meter ranging capabilities of the S300 Standard are available for programmatic use.

Enjoy!
Billy McCafferty