Posts Tagged ‘HardwareIntegration’
Posted on 23:59, November 22nd, 2010 by Billy McCafferty
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.
Serial Communications with SICK S300 Standard
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:
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):
The hardware setup is then quite simple, as follows:
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:
We’re now ready to request a token and laser scans…
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
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 (
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.)
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.
© 2011-2014 Codai, Inc. All Rights Reserved