Closed imwhocodes closed 5 months ago
I saw on the forum that the call to the various call to dai::Device and dai::Pipeline are not thread-safe
So I tried (very crudely) to mitigate it by getting sharing a lock between all Camera nodelet and by acquiring it for ANY function or callback present in Camera.cpp
As seen here: https://github.com/luxonis/depthai-ros/compare/noetic...imwhocodes:depthai-ros:noetix-multicam-nodelet-fix
But either I'm doing something wrong or this don't help either The nodelet-manager is still crashing after a couple of second of having both camera connected, with some new error sometimes
@Serafadam Please check this asap. Thank you. M.
@imwhocodes Thanks for the report, it seems that the issue probably originates from IMU interpolation, you can switch try checking if changing sync method to COPY helps in meantime.
<rosparam param="imu_i_sync_method">COPY</rosparam>
@imwhocodes Thanks for the report, it seems that the issue probably originates from IMU interpolation, you can switch try checking if changing sync method to COPY helps in meantime.
<rosparam param="imu_i_sync_method">COPY</rosparam>
Thanks, this worked out!
Describe the bug If you try to load 2 cameras node on the same nodelet after some seconds ROS do crash
I saw multiple causes in the log, some of them are:
All error seem caused by some concurrency problem on managing allocation / deallocations
Minimal Reproducible Example My setup is based on this:
The minimum launch file to reproduce is:
Expected behavior You should be able to attach/load multiple camera-nodelet to the same nodelet-manager
Additional context With nodelet (if attached to the same manager) you don't pay extra cpu price when moving data from a node to the next of a given pipeline This have a big impact when working with point-cloud (given they enormous message size) where from one node to the next you simply move a smart-pointer around without serialising and deserialising the data at each step In my setup I'm acquiring multiple point cloud from multiple oak-d-pro-w, merging them and applying multiple steps of processing, being unable to exploit the memory sharing of the nodelet architecture is a big performance hit
Example Log
Thanks, Luca