improve workflow to avoid added latency

Preliminary Checks

This issue is not a duplicate. Before opening a new issue, please search existing issues.
This issue is not a question, bug report, or anything other than a feature request directly related to this project.

Proposal

Publish depth/rgb data after grabbing instead of:

grab polling thread
ROS publishing thread

With:

30 hz grab thread
30 hz ROS publish thread

This is adding worst case single frame latency (publish just before new data) and half frame latency on average.

33 ms or 33/2 ms respectively

Use-Case

Any low-latency ROS application needing depth/RGB data

Anything else?

grab thread (std::thread)

zed-ros-wrapper/zed_nodelets/src/zed_nodelet/src/zed_wrapper_nodelet.cpp

Line 3158 in 50dda07

void ZEDWrapperNodelet::device_poll_thread_func()

ROS publish thread (ROS thread)

zed-ros-wrapper/zed_nodelets/src/zed_nodelet/src/zed_wrapper_nodelet.cpp

Line 569 in 50dda07

    
           mVideoDepthTimer = mNhNs.createTimer(ros::Duration(1.0 / mVideoDepthFreq), &ZEDWrapperNodelet::callback_pubVideoDepth, this);

Run separately

It may be possible to keep current code structure and trigger ROS publishing after successful grab
(as opposed to timer based publishing)

The original ROS wrapper was made in that way.
We added a separate publishing thread when other users (too much to not listen to their request) asked to publish data at a lower frequency than the grab frequency.

I can understand your requirement, you can apply your modification if you need it.
I'm sorry, but we are not planning major changes to the ROS wrapper since ROS is close to EOL and most of the ROS users are moving to ROS 2.

Thank you @Myzhar

Oh, ok, I now see this was improved in ROS2

In that case, thank you for a quick answer.

For anybody in need to remove added latency in ROS1 fix is in:

Extend-Robotics@ea399c8

To keep compatibility with existing behavior:

if pub_frame_rate > 0 - works as usual
if pub_frame_rate == 0 - (not valid value before)
- timer based publishing is disabled
- grabber thread notifies about data availability through ROS empty message
- data is published on notification

All above was used to keep existing threading model and behavior compatibility.

@Myzhar

We avoid maintaining third-party forks if possible.

If the fix looks like something mergeable we are happy to open pull request (and adapt as requested).

If not let me know, I will close the issue.