ROS output and input hooks required about ssl-vision HOT 4 CLOSED

@MichaelEischer and @joydeep-b any preference or opinion for this issue/request?

from ssl-vision.

A ROS standalone shim should be easy to add as a standalone client.
I am not too keen on adding ROS support directly to the ssl-vision main app for the following reasons:

1. It will add to the dependencies for the main app for an optional feature. Adding it as an agnostic feature would require some hacking.
2. Latency and frame rate performance of ssl-vision is crucial, and teams rely on it. Adding ROS support might adversely affect performance.

I like the idea of a headless version of ssl-vision, with a GUI frontend as an optional add-on runtime, rather than a requirement. This would require significant refactoring of the code, however.

from ssl-vision.

@joydeep-b Thanks for the feedback. While having a stand-alone ROS node is the eventual intention, what do you think about ROS output as (a) something conditionally turned on via a CMake or command line option and (b) a plugin in the stack such that it does not influence latency, much as the current UDP broadcast scheme is threaded and does not inhibit the capture side? I think this middle ground may be useful for groups that already have work in ROS and would like to leverage its features in addition to the ssl-vision base stack.

I agree that headless will be a challenge.

from ssl-vision.

During my master thesis, I wrote a small converter that reads ssl-vision data and publish the data to ROS topics: https://github.com/g3force/ros_ssl_robot
I agree with Joydeep, that we should not add any ROS dependencies directly to ssl-vision.
If you have a dedicated ROS converter that could be useful for other teams, we could just add it as separat repository and reference it in the docs.

from ssl-vision.