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 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 >> >> 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 >> 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 >>> 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 >>> > >>> > >>> _______________________________________________ >>> ros-users mailing list >>> ros-users@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >> >> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >