improve workflow to avoid added latency
bmegli opened this issue · 5 comments
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)
ROS publish thread (ROS thread)
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
- https://github.com/stereolabs/zed-ros2-wrapper/blob/ac3eb476455160508e62648230efe7fbf0dfc048/zed_components/src/zed_camera/src/zed_camera_component.cpp#L5053
- https://github.com/stereolabs/zed-ros2-wrapper/blob/ac3eb476455160508e62648230efe7fbf0dfc048/zed_components/src/zed_camera/src/zed_camera_component.cpp#L5649
In that case, thank you for a quick answer.
For anybody in need to remove added latency in ROS1 fix is in:
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.