Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enabling connection via Bluetooth #109

Closed

Conversation

SammyRamone
Copy link

Hello,
we developed a serial connection to the Robotiq Gripper and FT sensor via Bluetooth. For more information see this Github:
https://github.com/TAMS-Group/tams_robotiq_bluetooth
We changed a few things in the code to make it run on the BT connection. The code is running for several weeks now on our setup and we didn't encounter any bugs.
If you have any questions or want further changes, I will be glad to help.
Best regards,
Marc Bestmann

Marc Bestmann added 4 commits June 15, 2017 15:29
…loss to make it usable with bluetooth connection
…rgument, thus preventing interference with other active serial connections, for example a gripper. Also added rfcomm devices to the list of possible connections for the sensor.
@shaun-edwards
Copy link
Contributor

@SammyRamone, thanks for the contribution. Anything that gets rid of wiring outside the robot arm is a good idea in my book. I'm curious what you think of the discussion in #107. It appears your device_id is solving the same problem, although I don't fully understand what you are doing.

@SammyRamone
Copy link
Author

SammyRamone commented Sep 28, 2017

Hi,
yes you are right. It solves the same problem as in #107
So basically you just pass the device as an argument when starting the node, for example /dev/ttyUSB0 or in the case of using rfcomm /dev/rfcomm0
Now the code does not loop through all devices and therefore does not interfere with already existing connections.
I also commented on #107 have a look there too
I can really recommend using this Bluetooth connection to get rid of the cables. There will also be a paper published about it on this years IEEE Robio.

@shaun-edwards
Copy link
Contributor

Ideally, the device argument is semi-static. This would ensure that the launch files do not have to be changed or called with different arguments between runs. Do you know if the device ID is static. If you unplug and then plug in the same device or it loses connection for whatever reason, does it come up with the same ID?

If you fix is to be accepted, the old behavior (however bad) would need to remain in place so that existing users aren't affected. Is this the case?

@SammyRamone
Copy link
Author

I'm not sure if the device ID is static, but I think it's not. However, if you unplug and plug a device it will be probably the same ID since nothing else changed. But if you plug in another device before repluging the first device, it may have another ID.

My code should not change the previous behaviour. If you do not provide a device ID the old search for devices will be used. So I think no one will notice. Furthermore, I am not sure how many people actually used the ModbusRTU before because there was no node for this. I added one in this pull request.

@SammyRamone
Copy link
Author

Closing old PRs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants