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):

   1. Standard Header
   2. min/max range
   3. beam angle
   4. 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