[REP Index] [REP Source]
REP: | 138 |
---|---|
Title: | LaserScan Common Topics, Parameters, and Diagnostic Keys |
Author: | Chad Rockey <chadrockey at willowgarage.com> |
Status: | Active |
Type: | Informational |
Content-Type: | text/x-rst |
Created: | 07-Feb-2013 |
Post-History: | 25-Feb-2013 |
Contents
This REP defines common topic names, parameter names, and diagnostic key names for LaserScanners.
The following topics are expected to be common to many devices. Note that some of these topics are published by support libraries.
scan
Traditional single return output. (sensor_msgs/LaserScan)
This is the most compatible topic and represents output from a laser scanner that is not providing multiple returns per beam. This topic is not present for multi-echo laserscanners in multi-echo modes.
echoes
Output of a laser scanner capable of multiple returns per beam. (sensor_msgs/MultiEchoLaserScan)
This is the topic that is designed to give the most information to users of LaserScans. sensor_msgs/MultiEchoLaserScan is not required to be used by clients. This topic is not present for single echo laserscanners or multi-echo laserscanners in single echo mode.
To provide compatibility with libraries that do not support sensor_msgs/MultiEchoLaserScan, the following optional topics are defined. They are typically published by a support library, nodelet, or node. The driver can directly publish onto these topics if the modes are supported in hardware as a primary method of data acquisition.
first
Output of the first return from a multi echo laser scanner. (sensor_msgs/LaserScan)
This topic represents the first return (distance closest to the laser scanner). It is typically published by a support library that converts sensor_msgs/MultiEchoLaserScans into sensor_msgs/LaserScans.
last
Output of the last return from a multi echo laser scanner. (sensor_msgs/LaserScan)
This topic represents the last return (distance furthest from the laser scanner). It is typically published by a support library that converts sensor_msgs/MultiEchoLaserScans into sensor_msgs/LaserScans.
most_intense
Output of the most intense return from a multi echo laser scanner. (sensor_msgs/LaserScan)
This topic represents the most intense return (brightest value). It is typically published by a support library that converts sensor_msgs/MultiEchoLaserScans into sensor_msgs/LaserScans.
Devices should access as many of these parameters as are relevant. For example, older devices connect via serial while newer often connect over ethernet. In this case, newer devices would use ip_address/ip_port, while older devices would use serial_port/serial_baud. If a parameter is not supported by hardware, it is not necessary to read/write to that parameter.
Devices should publish as many of the following keys that are easy to assume or read from hardware. These key/value pairs are common among devices of this type. This list is not considered to be exhaustive and drivers are encouraged to add key/value pairs specific to the hardware.
ROS is built on common messages as interfaces to data. These messages allow software written without the other's knowledge to work together the first time and produce valid output. In much the same way as these common messages provide consistent software interfaces, this REP provides a consistent user interface to drivers.
The common topics provide easy to connect nodes via launch files between drivers and processing software. Common parameters provide a way to easily reuse configurations between different devices when applicable. Finally, common topics, parameters, and diagnostic keys provide a consistent user experience between drivers.
The common names also provide a consistent and documented source of names and diagnostics - freeing the author to make better defined software that's more easily validated.
It is up to the maintainer of a driver to determine if the driver should be updated to follow this REP. If a maintainer chooses to update the driver, the current usage should at minimum follow a tick tock pattern where the old usage is deprecated and warns the user, followed by removal of the old usage. The maintainer may choose to support both standard and custom usage, as well as extend this usage or implement this usage partially depending on the specifics of the driver.
+References +========== + +.. [1] ros-users discussion + (https://code.ros.org/lurker/message/20130225.194132.55d7a174.en.html) + +.. [2] Github discussion + (https://github.com/ros-infrastructure/rep/pull/25) +
This document has been placed in the public domain.