@Myzhar This camera driver needs more testing on ROS side definitely, as it is unstable for now. If you want me open a ticket on issue side, please let me know.
Hi @anath93
the error that you see is not caused by an “unstable camera driver”, but it’s caused by an unstable USB connection.
Are the screw of the USB3 connector strongly strengthened? Are you moving that camera and the USB connector on the Jetson side is moving too?
Do you meant the GMSL card below the Jetson, if so yes as this is ZedX camera.
After re-start this error goes away, so its strange if the card was supposed to be loose, then it should have repeated.
Are you using a ZED 2i or a ZED X?
Please provide all the relevant information when you report an error, the solution/reply can be different according to the model of the camera that you are using.
The error that you faced with ZED X is caused by a bad previous closing of the camera.
You can reset it without a reboot by simply running the command sudo service nvargus-daemon restart and waiting a few seconds before restarting the camera.
@Myzhar I have both the cameras with me, but I am keeping the thread specific to its issue to avoid conflict. Currently I am doing bench testing, to see the best winner for my application. But this is ZedX camera, it happens quite often, I don’t know if the node is not getting destroyed correctly ? as there are no abrupt power cutoffs which are taking place. To shut down node currently I am using Ctrl + C, and the logger prints the process was ended clean.
I just installed ZedX camera again, this camera IMU performs better than Zed2i with same spin rate of LIDAR, but I see the drop in packages like above, if this could be resolved y preference would be to stay with ZedX.
You say that the ZED 2i does not have this problem, but you face it with ZED X.
They both use the same code, so I can’t explain how this is possible.
Can you post the output of the following commands running simultaneously on two different consoles?
ros2 topic hz /zedx/zed_node/rgb/image_rect_color
and
ros2 topic hz /zedx/zed_node/rgb/camera_info
OK, this does not make sense. I’m checking the wrapper to try to replicate the problem and eventually solve the issue
I agree with you, I am going to bump this image transport to 4.0.0 as it have custom qos settings and see what happens.
1 Like
@Myzhar Looks like this could be issue, 2 publishers for camera_info from sdk_wrapper, I tried launching node separately and cumbersome with other nodes.
The problem is caused by image_transport.
When you subscribe to /zedx/zed_node/rgb/camera_info you subscribe to the camera_info topic of both /zedx/zed_node/rgb/image_rect_color and /zedx/zed_node/rgb/image_rect_gray.
For this reason, both the color and gray publishers are activated and they publish the same camera_info message causing your “async” issue.
You can solve this problem by searching for these lines
std::string img_gray_topic = "/image_rect_gray";
std::string img_raw_gray_topic_ = "/image_raw_gray";
and replacing them by
std::string img_gray_topic = "_gray/image_rect_gray";
std::string img_raw_gray_topic_ = "_gray/image_raw_gray";
The fix will be merged into the master branch as soon as possible.
@Myzhar Thank you, it worked. Once it is pushed if you can let me know, I would appreciate it, otherwise I can check in next couple days.
The fix is already available in the master branch
@Myzhar Would appreciate if you can shed some thought on this below, if I do echo on camera_info, do see its published and its ros2 message and not a custom zed message.
This is the command that correctly publishes a virtual laser scan:
ros2 run depthimage_to_laserscan depthimage_to_laserscan_node --ros-args -r depth:=/zedx/zed_node/depth/depth_registered -r depth_camera_info:=/zedx/zed_node/depth/camera_info -p output_frame:=zedx_left_camera_frame
Thank you for that, I do see echo now on /scan. Appreciate your help.
Consider changing the Fixed Frame. If no node publishes the odom_ekf frame, no data can be seen.