Closed adeguet1 closed 4 years ago
In General i don't see the value of adding the string client program as there is already a stringc lient example program
Regarding the reason to add yet another StringMessage
client, I should probably add a bit of background information. I'm working on a library that automatically wraps our components (dVRK: https://github.com/jhu-dvrk/sawIntuitiveResearchKit/wiki, Phantom Omni: https://github.com/jhu-saw/sawSensablePhantom/tree/feature-crtk, UR robot, misc. force sensors, tracking devices, haptic devices, etc). The current code for this IGTL bridge library can be found at: https://github.com/jhu-saw/sawOpenIGTLink/tree/feature-crtk.
To test this code, I find it very convenient to send different strings (and using different device names) using a command line tool. For example, with a Phantom Omni I can do something like:
StringClientSend localhost 18944 arm/state_command enable
StringClientSend localhost 18944 arm/state_command home
Using ROS, this is similar to:
rostopic pub /arm/state_command ....
I can also send a force for haptic feedback using the Sensor example I added (sending 6 values for a 3D wrench):
SensorClientSend localhost 18944 arm/servo_cf 1 1 0 0 0 0
I realize that these two programs are more "tools" or "utilities" than examples. I would totally understand if you conclude that these don't belong to the OpenIGTLink code base.
Hi, Thanks for explaining the background. I really appreciate your interests in the library and the contribution you made to the library. I think these are good examples of using the library. However, i do think the existing examples explained very well about the usage of the library. I appreciate your understanding of the decision of not merging the pull request.
Best, longquan
…ngMessage or igtlSensorMessage) from command line with arguments for ip, port, device name and payload (feature similar to rostopic pub)