Multi camera set up without hw sync, infinite loop on some cameras #8694
Comments
Hunk86
changed the title
|
Hi @Hunk86 Have you seen Intel's guide for setting up multiple cameras in ROS on the same computer and obtaining point clouds from them, please? https://github.com/IntelRealSense/realsense-ros/wiki/Showcase-of-using-2-cameras |
|
@MartyG-RealSense The example above is an easy example for two cameras. I've problem with four cameras with the librealsense software driver layer |
|
Adding further cameras to the same computer can indeed place additional demands on the computer and USB. A seminar about multiple cameras held by Intel in 2018 suggested a computer with an Intel Core i7 processor for a system with 4 cameras attached. So long as each camera is roslaunched on its own individual ROS terminal as indicated by Intel's guide then as far as I know there should not be an activation conflict between the multiple cameras. If the control_transfer returned error is continuously generating then this indicates that there is a serious communication problem with the device (which would be consistent with the Failed to set power state errors). If you are launching each camera in its own terminal, a good place to begin the investigation of your case would be to add the command below to the end of all of your roslaunch statements to reset the camera at launch: initial_reset:=true |
|
Hi @Hunk86 Do you require further assistance with this case, please? Thanks! |
|
sorry for the late response We tried the inital_reset:=true but I've exactly the same problems. Also every launch file is running in its own terminal. Do you have more ideas what we can test or how we can provide you more information for debugging ? |
|
An alternative to launching specific devices using serial number is to use usb_port_id instead of serial_number in the roslaunch instruction. This method looks for the camera on a USB port of the computer with a specific ID. For example, adding this command to the roslaunch instruction to look for the camera on a USB port with the ID '4-1': usb_port_id:=4-1 |
|
Hi @Hunk86 Do you require further assistance with this case, please? Thanks! |
|
Case closed due to no further comments received. |
|
Hi, please re-open this issue, I also work with the setup described above and have switched to usb_port_id for identifcation, but we still get Nodes do not always catch this, when launching into the multi-camera setup we always find one or two of the nodes shutting down with an exception due to the same error. Sometimes, we even have to reboot or re-power the computer, or re-connect the cameras via the kernel driver to make the failed cameras detectable again. |
|
Hi @norman1479 Given the similarity between your situation and that of @Hunk86 who created the case, I will re-open the case for further discussion. @Hunk86 Please feel free to contribute if you wish to. Thanks! |
|
Hello @MartyG-RealSense thank you for reopen the Issue I still have the same problems, right now I've the case that one camera can't be connected, but the other ones are working fine after unplug and plug again, it was possible and I got only this kind of errors |
|
Hi @Hunk86 Is the problem always with the same camera wit a specific serial number? Or is it that if you have a set of cameras attached, one of the cameras in the set will always have a Failed to set power state - but not always the exact same camera. |
|
Hello @MartyG-RealSense it is random and not always the same. We have cases we we get all cameras up and sometimes only one We are also using dev_id right now and not serial number Do you have any idea ? |
|
There was a past case in which a right MIPI error occurred because of frames not arriving reliably. This would be consistent with the accompanying control_transfer returned warning in your log, which can indicate that there is a serious communication problem with the device if the message is generating continuously instead of appearing a small number of times at launch. As the issue is with a randomly selected camera rather than the same camera each time, it suggests that the problem is not with the camera hardware or its firmware. The discussion in the link below may be useful, which has a similar RealSense ROS scenario of some cameras failing at start-up sometimes but not every time. It discusses a range of possible solutions, such as putting a sleep period between the start of each camera. IntelRealSense/realsense-ros#1187 A table was produced of different approaches tested and whether all cameras could be detected using that method. IntelRealSense/realsense-ros#1187 (comment) At the end of that case, Doronhi the RealSense ROS wrapper developer provides advice about occurrences of RS2_USB_STATUS_BUSY |
|
Additional errors we frequently encountered in this scenario are RS2_USB_STATUS_NOT_FOUND and RS2_USB_STATUS_NO_DEVICE. In this case, one or more cameras (or the corresponding usb port / driver) remain in an undetactable state we can only recover by repowering the computer or issue a USBDEVFS_RESET using ioctl on that port - even after re-plugging the camera or after an unbind/bind of the device via /sys/bus/usb... and also when using initial_reset:=true. That's what our kern.log repeats in that situation for the camera port related: We will also try the suggestions mentioned above and try a build with v4l next. |
|
Thanks very much @norman1479 for the update on your particular situation - good luck with your tests and I look forward to your update afterwards. |
|
When I check the documentation option(FORCE_LIBUVC "Explicitly turn-on libuvc backend - deprecated, use FORCE_RSUSB_BACKEND instead" OFF) The LIBUVC is deprecated ? But I will try to turn this on and disable the backend |
|
The RSUSB backend system was introduced in SDK 2.30.0. Before that, libuvc-backend was typically used to perform an installation of librealsense over an internet connection without the need for kernel patching. https://github.com/IntelRealSense/librealsense/blob/master/doc/libuvc_installation.md The libuvc-backend method, though deprecated, is still valid as far as I know, though rarely used now. |
|
Hi @Hunk86 Do you have an update about this case that you can provide, please? Thanks! |
|
Yes at the moment we try with the new backend but we still have the same problems with multiple cameras I can provide you some logs next week |
|
Thanks very much @Hunk86 - I look forward to your update in the coming week. Good luck! |
|
Hi @Hunk86 Do you have an update about this case that you can provide, please? Thanks! |
|
Case closed due to no further comments received. |
Setup
Application
I start the realse node four times with :
roslaunch realsense2_camera rs_camera.launch ...and the important args ( serial ... )
The main problem is that the cameras do not boot consistently when I start them at the same time. After various restarts of the individual non-functioning nodes, I get the point clouds from all cameras.
I've added different issues descriptions in the bottom. If I can provide you more information please ask for it :)
The first issue with the infinite loop is the most blocking at the moment
Thank you for your help!
Issue Description
But when I stop it and run it again and program runs without any problems.
My guess here is that the camera drivers are interfering with simultaneous startup.
When the node is running, I get this libusb feedback at the beginning.
Here I also get this feedback similar to the node
One more question about the udev rule comment. It says that auto power off is done for usb2. Does this also apply to USB3?
The text was updated successfully, but these errors were encountered: