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

Tue Oct 5 04:24:20 UTC 2010

My $0.02, if such a message was added to the sensor_msgs pkg, the p2os
stack would switch to it for its next release. One thing, though, is
that rviz support for such a message should be added and that in
addition to range (min,max) and distance (actual value) angle spread
should be included. The sonar ranges on the pioneer have something
like a 15 deg spread, while ir are a single beam of light with a
rather narrow spread.

-Dave

On Mon, Oct 4, 2010 at 9:15 PM, Eric Perko <wisesage5001 at gmail.com> wrote:
> Everyone,
> Thanks for the input and validating that I'm not the only person that would
> like to see a message like this in ROS :).
> I have put together an API review page
> here http://www.ros.org/wiki/sensor_msgs/Reviews/2010-10-04_Ranger_Proposal_API_Review .
> This will cover the addition of a Ranger message to the sensor_msgs package.
> If you have an interest in seeing a standardized Ranger message that can
> support sonars and IR sensors included in ROS, I encourage you to
> participate in this review. Please look over the proposed message and put
> any comments in the "Question / concerns / comments" section in preparation
> for the review meeting. I've scheduled review meeting via IRC chat for
> Monday, Oct 11 at 4:15PM Eastern Time (1:15PM Pacific Time). This will be
> held on #meeting.ros.org on freenode.net. If you do not have an IRC client,
> http://webchat.freenode.net/ looks to be a decent web-based IRC client for
> freenode.net.
> - Eric
> 2010/10/4 Gonçalo Cabrita <goncabrita at gmail.com>
>>
>> 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
>>
>>
>> _______________________________________________
>> 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
>
>