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

Tue Oct 5 04:15:46 UTC 2010

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101005/51ffe8c1/attachment-0003.html>