Hi Chad,
In the IRI's hokuyo laser driver [1] we are using the first method,
multiecho data is not in every value received, they vary from 1 to 3
echoes, so the "/laser/echoN" in our case is the echoes "N" + the
first value in the case that there's no "echo N".
I have the feeling that most users plug and play and won't care much
about echoes, so I prefer a single topic with an optional policy
(keep the max, the min,..):
Advantages:
- Efficient (good for ros)
- No needs synchronization (good for ros & user)
- Single topic (good for user)
- No need to change the message type (good for ros & user)
Disadvantages:
- User can't work with separated echo data without modifying the
code (bad for few users)
- Policies have to be decided beforehand and implemented in the
driver (work for the coder)
For me its not clear how this multiecho should be used, we don't use
it. Know how people work with this multiecho data would be great to
define the policies.
Out of topic, is the ROS hokuyo_node going to work with ethernet
lasers?
[1]
http://www.ros.org/wiki/iri_hokuyo_laser
Cheers,
Martí
On 07/19/12 03:45, Chad Rockey wrote:
Hi everyone,
As part of the Groovy planning process, I've posted a review
for multi-echo laser rangefinders:
This review focuses on the ROS API for scanners that return
multiple ranges (and intensities) for a single beam. Example
lasers with this feature are the SICK LMS151 and LMS511, as well
as the Hokuyo UTM-30LX-EW.
Please take a look and contribute your thoughts.
Thanks,
- Chad
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users
--
Martí Morta Garriga. Support Engineer.
Institut de Robòtica i Informàtica Industrial (UPC-CSIC)