For reference, Player offers a ranger interface:
 https://playerstage.svn.sourceforge.net/svnroot/playerstage/code/player/trunk/libplayerinterface/interfaces/062_ranger.def
There are several message types defined there, because a Player
interface specifies a group of data, command, and/or configuration
messages (ROS doesn't have an analogous 'interface' concept).

Probably the most relevant message from that interface is
player_ranger_data_rangestamped_t.  It contains the range data, and
optionally geometry and configuration information.  Some of that
information would be handled in ROS by tf.

I recommend creating an API review in the sensor_msgs package
(http://www.ros.org/wiki/sensor_msgs/Reviews) to propose and discuss
the addition of a Ranger type.  The proposal should be clear about
what kind of range sensors are handled, e.g.: do the transducers have
the same origin? do they lie in the same plane?  It would also be a
good idea to provide converter nodes to go between existing "range"
messages and the new Ranger type; that way you avoid the expectation
that existing nodes, such as laser drivers, would quickly be updated
to support the Ranger type

	brian.

On Sat, Oct 2, 2010 at 3:48 AM, Eric Perko <wisesage5001@gmail.com> wrote:
> I'd like to ping the list to see if there are others that would benefit from
> a generic "Ranger" message being added to the sensor_msgs package and be
> interested in participating in a review process to get one added. An example
> use for this message type would be ultrasonic sensors or IR sensors.
> Current ROS messages similar to this (at least the ones I can find):
>
> nxt_msgs/Range (http://www.ros.org/doc/api/nxt_msgs/html/msg/Range.html)
> p2os has a SonarArray message that just contains a vector of ranges without
> min/max info or FOV angle info
>
> Information that I believe is sufficient for a range message (Note this is
> equivalent to the nxt_msgs/Range definition):
>
> Standard Header
> min/max range
> beam angle
> range reading
>
> Unless anyone needs more information in order to utilize a Sonar/IR ranger,
> I propose migrating the Range message from nxt_msgs to sensor_msgs. It would
> likely make sense to also migrate the RVIZ visualization marker for the
> ranger as well if the Range message was migrated.
> We are currently working on exposing the Ranger model in Stage to ROS and
> the message that is most appropriate is nxt_msgs/Range. I think we'd all
> agree that it doesn't make much sense for Stage to depend on nxt_msgs, so we
> need a message in the base ROS stacks to use.
> Open questions I have:
>
> Should we combine Sonars and IR sensors into one sensor_msgs/Ranger message
> or are they distinct enough to warrant completely separate messages? Is
> there enough of a difference to add some sort of type field enumerating the
> radiation used by the sensor (IR light, sound waves, etc)? I can see a use
> for knowing whether or not to expect the sensor to return from, say, glass,
> but that could also be taken care of out-of-band by knowing other info about
> the sensor.
> What to call the "beam angle"? nxt_msgs/Range calls it spread_angle, Stage
> calls it fov, and Sonar spec sheets often call it beam_angle. Is there any
> reason to prefer one over the other?
>
> Thoughts?
> - Eric
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>