Yeah, you can just have your own thread to do the polling, though I’ll note that in your original example, there’s no
ros::spin*() calls made, so that’s not good . If you wanted to spin (recommended) and not interfere with the original while loop, you’d probably use an async spinner, which just spins in a thread, so in both cases (ROS 1 and ROS 2) you either need to time share with the spin thread or create a separate one.
I will say that the use of a future in the Velodyne case may be overkill, so don’t let that scare you. You could instead continue to check
rclcpp::ok() or use a (atomic) bool to signal shutdown. The future is fancier and maybe they’re using it for other reasons, but it isn’t necessary.
The other option, other than creating your own thread, is to have a callback that does the polling, sharing the executor’s thread (or threads depending on the type executor). One way to do that now is to have a timer which fires regularly.
But we’ve also talked about it in the past that it would be nice to have an “idle” callback which gets fired when there’s nothing else going on, but right now that doesn’t exist. Other event systems have this, e.g. wxWidgets has the IdleEvent (https://docs.wxwidgets.org/trunk/classwx_idle_event.html) and Qt recommends using a timer with a period of
Given how most drivers work, where you want to either poll very regularly, in order to reduce latency of acquisition, a dedicated thread for polling the sensor and publishing data seems like the best option.