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 >