[ros-users] Ranger (Sonar/IR) message added to sensor_msgs?

Mon Oct 4 15:39:32 UTC 2010

Hi everyone!

We've been following this discussion up-close since we have some Roombas
equipped with sonars here at the lab. Plus the Roombas come with some neat
IR sensors, meaning a Ranger msg would come very handy to us.

And that's why we ended up creating a Ranger msg which we added to our
installations of ROS a while back (sensor_msgs). Coming from Player, we got
our inspiration for the Ranger msg from the Player Ranger interface.

We actually created 2 msgs, RangerScan.msg and RangerScanArray.msg, since
most of the times we have arrays of Sonars or IRs. We decided to put a
header on each single ranger since an array of rangers might not always be
neat and tidy with equal spacings between sensors.

RangerScan.msg
# Single scan from a single sonar
Header header

float32 field_of_view     # field of view of the sonar [rad]

float32 range_min        # minimum range value [m]
float32 range_max       # maximum range value [m]

float32 range     # range data [m] (Note: values < range_min or > range_max
should be discarded)

RangerScanArray.msg
# Single scan from an array of sonars
RangerScan[] rangers

I hope this can be of some contribution to this discussion,

Gonçalo Cabrita
ISR - University of Coimbra
Portugal

On Mon, Oct 4, 2010 at 4:12 PM, Brian Gerkey <gerkey at willowgarage.com>wrote:

> 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 at 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 at code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> >
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101004/c3e81f89/attachment-0003.html>