Using two SICK lidars creates problems about sick_tim HOT 6 CLOSED

If you launch two nodes, both will try to connect to the first USB device (device_number = 0), which will fail for the second one because the LIBUSB interface has already been acquired by the first one. You can avoid this by setting the device_number parameter:

So start the sick_tim310 node with the parameter device_number = 0 and the sick_551 node with device_number = 1, or the other way around (you'll have to try).

It would be cool to have a better way to assign the proper nodes, e.g. by device serial number. I'm happy to accept pull requests! :)

from sick_tim.

Hi mintar, thanks for the help!
Can't believe it was that simple. How is the device number generated?
Again, many thanks!

from sick_tim.

Glad to help! The device number n simply means "the nth device in the list returned by libusb" (AFAIK, ordered first by USB bus, then USB device). It remains stable (also during reboots) as long as you always plug in the devices into the same USB ports and don't switch them around.

from sick_tim.

Just to document this here: Libusb does not guarantee consistent device ordering

See libusb/libusb#311:

If I call libusb_get_device_list with the same context, will I always get the devices in the same order? This works under linux, but is it guaranteed to work on all platforms? (assuming there's no hardware changes between calls).

No, there is no guarantee of ordering. I'll close this since it doesn't appear to be a bug report. Let me know otherwise.

from sick_tim.

Thanks for the information! However, the text you quoted says "This works under Linux". I'd interpret this as saying that consistent ordering isn't guaranteed across platforms, but the Linux implementation just happens to return a consistent ordering. Since probably 99% of the people running our driver use Linux, that could be good enough?

I agree that it's a brittle way of addressing the devices, and it would be better to use something like the device serial number (something that many cameras support), but I don't know if that's supported by the SICK scanners. Note that this problem only happens if you're using the USB interface. On Ethernet, the scanners are properly addressed via their IP address.

from sick_tim.

Could be. The device_number parameter is not that stable, because this can change by reorganizing all all USB cables. A selection from the serial number would be better.

But since ROS is going EOL and we now have the official drivers from SICK, I guess this package will go EOL as well. Unfortunately, sick_scan2 has no interest in supporting USB SICKAG/sick_scan2#22. That's the only reason we currently use this driver with the ros_bridge.

from sick_tim.