Force Torque connection method is not great

[ibaranov-cp]

Hello,

The behaviour for connection to the force torque is fairly bad practice.
https://github.com/ros-industrial/robotiq/blob/jade-devel/robotiq_force_torque_sensor/src/rq_sensor_com.cpp#L155

This causes any other USB devices to get killed off, as this driver steals focus, crashing other software (including, for example, our Husky)

2 options:

1. Make a parameter on launch for the proper address
2. Point to a fixed /dev device (ex: FT) and then create a udev rule that points that name to the real RS485 adapter (Ex: Bus 003 Device 008: ID 0403:6015 -> FT)

[ibaranov-cp]

For reference, here's a slightly more reasonable approach, with a launch file, fixed model for FT_300 model, etc:

https://github.com/ibaranov-cp/husky_UR_accessories/tree/master/robotiq_force_torque_sensor

[shaun-edwards]

Thanks for reporting. I can't say I've seen a perfect way of handling USB devices. The "kinect" cameras allow you to specify the bus# (helpful if only one device is plugged into a bus) or the bus+device# (less helpful because the device# increments every time something is plugged in). Other devices allow you to specify a "unique number" (i.e. serial number) and then the USB devices are searched for the appropriate info. Do you think any of these approaches are better? Would it be possible with the Robotiq?

[ibaranov-cp]

Hey, see my reply above, it has a udev rule baked in that will recognized every time, and already fixed launch files for you.

[shaun-edwards]

Does your fix above work if multiple sensors are plugged in?

[ibaranov-cp]

Sure, each ftdi RS485 adaptor has its own unique ID, Infact we use them exactly this way.

…

On Sep 25, 2017 6:35 PM, "Shaun Edwards" ***@***.***> wrote: Does your fix above work if multiple sensors are plugged in? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#107 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFJrZgO9wkW0TVhgg5rt0m2waukXZQuZks5smCqkgaJpZM4PfwWD> .

[SammyRamone]

Hello,
I can verify that this problem exists. In #109 I solved this by providing a launch parameter (your option 1).
It was very easy to implement but it could happen that the names of two devices switch (e.g. ttyUSB0 and ttyUSB1) since Linux just numbers them in the order in which they are discovered (I guess). I was using rfcomm (which adds a device based on a given Bluetooth adress) and therefore I didn't encounter this switching problem.
Your solution using udev seems to prevent the switching problem. I had a look at your linked code and I think your solution is better but a bit more complicated for the user since s/he has to know the ID. Maybe you could still keep the looping through devices if no ID is specified to get the best of both worlds. I think in many cases the user has only one device and wants to start the node without having any knowledge about the device s/he connected.