-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem with 2 D415 cameras | RS2_USB_STATUS_BUSY | Not detected after realsense-ros in other tools #1187
Comments
I upgraded the version of realsense ros that I am using and downgraded the version of librealsense. Combined with unplugging and replugging in cables (gotta try everything), it now seems to be working as expected again. I would love to see some guidance from intel on how to deploy their code safely. Running an apt update/upgrade should never break things. But with realsense, it happens all the time. On whole the platform seems super unstable. Is that a design problem, a user problem, both? |
It is recommended that the RealSense ROS wrapper is matched with a particular version of the Librealsense SDK where possible. On the 'Releases' page for the wrapper, each version lists a recommended Librealsense SDK version to use it with. https://github.com/IntelRealSense/realsense-ros/releases The log in your first message says that you were using ROS wrapper 2.2.8 with Librealsense SDK 2.33.1. According to the Releases page, the appropriate match for wrapper version 2.2.8 would be the older Librealsense SDK version 2.25.0. It is sometimes possible to 'mix and match' non-recommended combinations of wrapper and SDK, but in general the best way to make a good match between wrapper and SDK is to follow the recommended SDK for a particular wrapper version. In regard to stability, the RealSense SDK aims to run on anything and is extremely adaptable in regard to the hardware and software that it can be used with. There are sometimes hardware and / or software configurations that require a bit more work to achieve a stable RealSense setup on though. These cases are usually mostly resolved over time as the RealSense community, the RealSense team or both develop guides and code solutions to overcome problems. It is also worth bearing in mind that the ROS wrapper and Librealsense are not developed in sync, so there may be a delay between the release of a new Librealsense version and a ROS wrapper version that officially supports it (though the ROS wrapper for the previous Librealsense version may still work with the newer Librealsense release). |
@MartyG-RealSense I agree, that mismatch was likely the source of the problem. Updating a system by looking at a webpage isn't a great solution. It is pretty easy to programatically update the realsense-ros repo and do the rebuilds, etc. Is there a way to programmatically install the recommended version of librealsense? Ideally there would just be an |
The set of installation instructions in the link below may provide useful insights. https://github.com/IntelRealSense/realsense-ros/blob/development/.travis.yml The instructions in this file are summarised by a two-step description in the link below, in which Librealsense is installed first and the ROS wrapper second: https://github.com/IntelRealSense/realsense-ros#method-2-the-realsense-distribution This could create a "chicken and the egg" dilemma ... if the Librealsense SDK is installed first and the ROS wrapper second, then the ROS wrapper version that was auto-selected to be installed would have to be matched to the Librealsense version installed in the previous step in order to get a recommended compatibility match. This may be why manually checking the Releases page is the most practical solution in most cases, if not the ideal one. |
Yeah, I don't see how those scripts prevent one from getting a version of librealsense that is ahead of the ROS wrapper. Regardless my issue is fixed, so I am going to close this issue. A feature request before I go though: If improving the installation experience is out of scope, then adding a check to the ros wrapper's startup that ensures that the librealsense version being used is the ideal one should be added. That check should not break anything but should make a very loud (but silenceable through parameters) noise to let the user know. |
Could you post your feature request as a new question on its own please? Then I can label it as such and it can be left open to be tracked by the ROS wrapper developers. Thanks! |
done |
Thanks very much! I will add the label to it now. |
@MartyG-RealSense, having this problem again, but I don't think it is due to a version mismatch: Any thoughts? |
Hi @mjsobrep Here are some things to try:
|
Hi @MartyG-RealSense, thanks for the suggestions:
I'm seeing a lot of this sort of spam in ROS, This is the launch file for my realsense system I am sometimes able to open both cameras in rs-viewer, but other times not. Both cameras have been updated to the latest firmware through rs-viewer. |
Actually, it is not just restarting the computer, just re running the launch file can cause a change in which camera chooses to work. It seems like after a while, realsense-ros stops trying to connect to the camera, sets up the publishers, and just sits there quietly, not doing anything. |
Apologies for the delay in responding further, as I was carefully considering your case. Do you have more than one program running at the same time that accesses the same camera? For example, launching the RealSense ROS wrapper and then the Viewer, or launching the Viewer first and then the ROS wrapper? If the camera is already "claimed" by a program that has an active stream when you try to access the same camera with another program then the second program may fail to access the camera. |
Never at the same time. There errors persist even after a computer restart. I'm not sure if the text of the errors is the same or not whether the camera has been used previously or if coming off a restart. |
Further research found a past case that had similar errors to this case. The case was about launching D435 and T265 together which is not the same situation as your one with two D415s but is still an interesting reference. One RealSense ROS user with problems launching two cameras wrote some arg code for delaying the launch of one of the cameras. I note though that you have also had problems with sometimes recognizing the cameras in the Viewer, which is not related to the ROS launch process. |
I'm not sure how much power the camera draws during roslaunch. If streams are being started and published then one might expect it to be more than if the camera was detected in the Viewer but not currently streaming. The recommendation that I know of when calculating the camera power needs of a project is to budget for around 2W power draw per camera. That is why using a mains electricity powered hub is useful for multiple camera projects, as they can supply around 12W of power. I am away from computer now for 7 hours. Good luck! |
After a night of leaving the cameras and computer off, things seemed to be working more consistently. I do not know why that might be. I lowered the resolution on the color imagers to 1080x720. Just tried changing to 1920x1080 and it didn't work. Changing back to 1080x720 did again work, although after a lot of errors and a tough time finding the cameras. So running these sequentially
I'm not sure how to setup the timed launch system you mention above to run launch files instead of nodes, need to figure out if that can be done. Tomorrow I will investigate whether the timing delay for starting the cameras is needed or if just starting them under different terminals is what is needed. If timing is what is important then it would be good to understand from your end why that is, do you have published power draw curves for starting up and running the cameras? Is there something in software that conflicts? Tomorrow I will also try to run at full resolution to see if this staggered start works with that. out1:18/08 18:54:30,771 ERROR [140491492402944] (handle-libusb.h:95) failed to claim usb interface: 0, error: RS2_USB_STATUS_BUSY 18/08 18:54:30,794 WARNING [140491525973760] (rs.cpp:304) null pointer passed for argument "device" [ WARN] [1597791270.794228307]: Device 1/2 failed with exception: failed to set power state [ WARN] [1597791270.821031122]: Asked to publish at 'fps' (30) which is higher than the 'set_camera_fps' (15), we can't publish faster than the camera provides images. ..... 18/08 18:54:50,594 WARNING [139845309544192] (messenger-libusb.cpp:42) control_transfer returned error, index: 768, error: No data available, number: 61 18/08 18:54:50,612 WARNING [140491484010240] (messenger-libusb.cpp:42) control_transfer returned error, index: 768, error: No data available, number: 61 18/08 18:54:50,612 WARNING [140491525973760] (types.cpp:78) set_xu(ctrl=1) failed! Last Error: Resource temporarily unavailable [ERROR] [1597791290.613241399]: An exception has been thrown: set_xu(ctrl=1) failed! Last Error: Resource temporarily unavailable terminate called after throwing an instance of 'rs2::invalid_value_error' 18/08 18:54:50,613 WARNING [139845458224896] (types.cpp:78) set_xu(ctrl=1) failed! Last Error: Resource temporarily unavailable what(): set_xu(ctrl=1) failed! Last Error: Resource temporarily unavailable [ERROR] [1597791290.614003341]: An exception has been thrown: set_xu(ctrl=1) failed! Last Error: Resource temporarily unavailable terminate called after throwing an instance of 'rs2::invalid_value_error' what(): set_xu(ctrl=1) failed! Last Error: Resource temporarily unavailable [lower_realsense/realsense2_camera_manager-23] process has died [pid 2964, exit code -6, cmd /opt/ros/kinetic/lib/nodelet/nodelet manager __name:=realsense2_camera_manager __log:=/home/nuc-admin/.ros/log/ c4fa8b00-e1a5-11ea-a88a-982cbccfb098/lower_realsense-realsense2_camera_manager-23.log]. log file: /home/nuc-admin/.ros/log/c4fa8b00-e1a5-11ea-a88a-982cbccfb098/lower_realsense-realsense2_camera_manager-23*.log [upper_realsense/realsense2_camera_manager-27] process has died [pid 3001, exit code -6, cmd /opt/ros/kinetic/lib/nodelet/nodelet manager __name:=realsense2_camera_manager __log:=/home/nuc-admin/.ros/log/ c4fa8b00-e1a5-11ea-a88a-982cbccfb098/upper_realsense-realsense2_camera_manager-27.log]. log file: /home/nuc-admin/.ros/log/c4fa8b00-e1a5-11ea-a88a-982cbccfb098/upper_realsense-realsense2_camera_manager-27*.log [upper_realsense/realsense2_camera-28] process has finished cleanly log file: /home/nuc-admin/.ros/log/c4fa8b00-e1a5-11ea-a88a-982cbccfb098/upper_realsense-realsense2_camera-28*.log [lower_realsense/realsense2_camera-24] process has finished cleanly log file: /home/nuc-admin/.ros/log/c4fa8b00-e1a5-11ea-a88a-982cbccfb098/lower_realsense-realsense2_camera-24*.l out2:[ INFO] [1597791807.439703133]: setupDevice... [ INFO] [1597791807.439730552]: JSON file is not provided [ INFO] [1597791807.439745257]: ROS Node Namespace: lower_realsense [ INFO] [1597791807.439760414]: Device Name: Intel RealSense D415 [ INFO] [1597791807.439773509]: Device Serial No: 904412060717 [ INFO] [1597791807.439788916]: Device physical port: 2-3-21 [ INFO] [1597791807.439801651]: Device FW version: 05.12.06.00 [ INFO] [1597791807.439811870]: Device Product ID: 0x0AD3 [ INFO] [1597791807.439821559]: Enable PointCloud: Off [ INFO] [1597791807.439833162]: Align Depth: On [ INFO] [1597791807.439844702]: Sync Mode: On [ INFO] [1597791807.439889529]: Device Sensors: 18/08 19:03:27,439 ERROR [140328753407744] (handle-libusb.h:95) failed to claim usb interface: 0, error: RS2_USB_STATUS_BUSY 18/08 19:03:27,450 WARNING [140328900060928] (rs.cpp:360) null pointer passed for argument "list" [ERROR] [1597791807.450248494]: An exception has been thrown: failed to set power state terminate called after throwing an instance of 'rs2::error' what(): failed to set power state [lower_realsense/realsense2_camera_manager-23] process has died [pid 10824, exit code -6, cmd /opt/ros/kinetic/lib/nodelet/nodelet manager __name:=realsense2_camera_manager __log:=/home/nuc-admin/.ros/lo$ /c4fa8b00-e1a5-11ea-a88a-982cbccfb098/lower_realsense-realsense2_camera_manager-23.log]. log file: /home/nuc-admin/.ros/log/c4fa8b00-e1a5-11ea-a88a-982cbccfb098/lower_realsense-realsense2_camera_manager-23*.log [ INFO] [1597791807.691790266]: Device with serial number 904412060717 was found. out3:[ INFO] [1597792570.880249894]: Device with serial number 912322061173 was found. [ INFO] [1597792570.880279117]: Device with physical ID 2-4-4 was found. [ INFO] [1597792570.880287386]: Device with name Intel RealSense D415 was found. [ INFO] [1597792570.880719944]: Device with port number 2-4 was found. [ INFO] [1597792570.882529422]: getParameters... [ INFO] [1597792570.943920926]: setupDevice... [ INFO] [1597792570.943954667]: JSON file is not provided [ INFO] [1597792570.943969764]: ROS Node Namespace: upper_realsense [ INFO] [1597792570.943985418]: Device Name: Intel RealSense D415 [ INFO] [1597792570.943993065]: Device Serial No: 912322061173 [ INFO] [1597792570.943999906]: Device physical port: 2-4-4 [ INFO] [1597792570.944006978]: Device FW version: 05.12.06.00 [ INFO] [1597792570.944013946]: Device Product ID: 0x0AD3 [ INFO] [1597792570.944020936]: Enable PointCloud: Off [ INFO] [1597792570.944027398]: Align Depth: On [ INFO] [1597792570.944036343]: Sync Mode: On [ INFO] [1597792570.944117104]: Device Sensors: 18/08 19:16:10,944 ERROR [140436790286080] (handle-libusb.h:95) failed to claim usb interface: 0, error: RS2_USB_STATUS_BUSY 18/08 19:16:10,954 WARNING [140436944922368] (rs.cpp:360) null pointer passed for argument "list" [ERROR] [1597792570.954680004]: An exception has been thrown: failed to set power state terminate called after throwing an instance of 'rs2::error' what(): failed to set power state [upper_realsense/realsense2_camera_manager-27] process has died [pid 2850, exit code -6, cmd /opt/ros/kinetic/lib/nodelet/nodelet manager __name:=realsense2_camera_manager __log:=/home/nuc-admin/.ros/log$ c41f06c2-e1a8-11ea-91ac-982cbccfb098/upper_realsense-realsense2_camera_manager-27.log]. log file: /home/nuc-admin/.ros/log/c41f06c2-e1a8-11ea-91ac-982cbccfb098/upper_realsense-realsense2_camera_manager-27*.log [ INFO] [1597792571.130816545]: Device with serial number 912322061173 was found. [ INFO] [1597792571.130856141]: Device with physical ID 2-4-4 was found. [ INFO] [1597792571.130887521]: Device with name Intel RealSense D415 was found. [ INFO] [1597792571.131294457]: Device with port number 2-4 was found. [ERROR] [1597792571.152285131]: The requested device with serial number 904412060717 is NOT found. Will Try again. [upper_realsense/realsense2_camera-28] process has finished cleanly log file: /home/nuc-admin/.ros/log/c41f06c2-e1a8-11ea-91ac-982cbccfb098/upper_realsense-realsense2_camera-28*.log [ INFO] [1597792577.198455498]: 18/08 19:16:17,210 ERROR [140436698031872] (handle-libusb.h:95) failed to claim usb interface: 0, error: RS2_USB_STATUS_BUSY 18/08 19:16:17,231 WARNING [140436827858688] (rs.cpp:304) null pointer passed for argument "device" out4This just keeps repeating: [ INFO] [1597792727.138558932]: Device with physical ID 2-4-4 was found. [ INFO] [1597792727.138579174]: Device with name Intel RealSense D415 was found. [ INFO] [1597792727.139113313]: Device with port number 2-4 was found. [ERROR] [1597792727.160540464]: The requested device with serial number 904412060717 is NOT found. Will Try again. [ INFO] [1597792733.209254157]: 18/08 19:18:53,222 ERROR [140436698031872] (handle-libusb.h:95) failed to claim usb interface: 0, error: RS2_USB_STATUS_BUSY 18/08 19:18:53,243 WARNING [140436827858688] (rs.cpp:304) null pointer passed for argument "device" [ WARN] [1597792733.243276919]: Device 1/2 failed with exception: failed to set power state [ INFO] [1597792733.620774728]: Device with serial number 912322061173 was found. [ INFO] [1597792733.620800564]: Device with physical ID 2-4-4 was found. [ INFO] [1597792733.620808152]: Device with name Intel RealSense D415 was found. [ INFO] [1597792733.621159204]: Device with port number 2-4 was found. [ERROR] [1597792733.642218041]: The requested device with serial number 904412060717 is NOT found. Will Try again. [ERROR] [1597792737.586395839]: Kobuki : malformed sub-payload detected. [25][170][19 AA 55 4D 01 0F ] [ INFO] [1597792739.690636658]: 18/08 19:18:59,703 ERROR [140436706424576] (handle-libusb.h:95) failed to claim usb interface: 0, error: RS2_USB_STATUS_BUSY 18/08 19:18:59,724 WARNING [140436827858688] (rs.cpp:304) null pointer passed for argument "device" [ WARN] [1597792739.724495557]: Device 1/2 failed with exception: failed to set power state [ INFO] [1597792740.120868031]: Device with serial number 912322061173 was found. [ INFO] [1597792740.120903760]: Device with physical ID 2-4-4 was found. [ INFO] [1597792740.120914623]: Device with name Intel RealSense D415 was found. [ INFO] [1597792740.121461940]: Device with port number 2-4 was found. [ERROR] [1597792740.142978243]: The requested device with serial number 904412060717 is NOT found. Will Try again. [ INFO] [1597792746.192939340]: 18/08 19:19:06,206 ERROR [140436689639168] (handle-libusb.h:95) failed to claim usb interface: 0, error: RS2_USB_STATUS_BUSY 18/08 19:19:06,226 WARNING [140436827858688] (rs.cpp:304) null pointer passed for argument "device" [ WARN] [1597792746.226949295]: Device 1/2 failed with exception: failed to set power state [ INFO] [1597792746.618079961]: Device with serial number 912322061173 was found. out518/08 19:39:03,730 WARNING [139913949128448] (messenger-libusb.cpp:42) control_transfer returned error, index: 768, error: Device or resource busy, number: 16 18/08 19:39:03,790 WARNING [139913949128448] (messenger-libusb.cpp:42) control_transfer returned error, index: 768, error: Device or resource busy, number: 16 18/08 19:39:03,851 WARNING [139913982699264] (types.cpp:78) set_xu(ctrl=1) failed! Last Error: Resource temporarily unavailable 18/08 19:39:03,874 WARNING [139913982699264] (rs.cpp:304) null pointer passed for argument "device" [ WARN] [1597793943.874385919]: Device 1/2 failed with exception: set_xu(ctrl=1) failed! Last Error: Resource temporarily unavailable [upper_realsense/realsense2_camera_manager-27] process has died [pid 2995, exit code -11, cmd /opt/ros/kinetic/lib/nodelet/nodelet manager __name:=realsense2_camera_manager __log:=/home/nuc-admin/.ros/lo$ /fa9fb2de-e1ab-11ea-ac81-982cbccfb098/upper_realsense-realsense2_camera_manager-27.log]. log file: /home/nuc-admin/.ros/log/fa9fb2de-e1ab-11ea-ac81-982cbccfb098/upper_realsense-realsense2_camera_manager-27*.log [ INFO] [1597793944.362110477]: 18/08 19:39:04,374 ERROR [140144354014976] (handle-libusb.h:95) failed to claim usb interface: 0, error: RS2_USB_STATUS_BUSY 18/08 19:39:04,395 WARNING [140144395978496] (rs.cpp:304) null pointer passed for argument "device" [ WARN] [1597793944.395339391]: Device 1/2 failed with exception: failed to set power state ──────────────────────────────────────────────────────────────────────────────────┬───────────── |
Thanks very much for the very detailed testing report! With ROS, the multicam launch timing issue particularly affected a pairing of D435 and T265 cameras. If D435 launched first then T265 could not be recognized properly. #774 that linked to earlier sums this phenomenon up well. Would you say that you get the most frequent success when both cameras are plugged into the computer (instead of both in the hub or one in hub and one in computer)? There was a recent case where a RealSense user had no problems when both cameras were plugged into the full size USB ports on their computer but had problems if using the micro USB-C port on the computer. They found that the ports that worked all used an Intel USB controller with xHCI support. The USB-C port that didn't work used an Asmedia USB controller without xHCI support. IntelRealSense/librealsense#6899 (comment) The workaround that they eventually found was to create a script that rebinds the USB driver. |
You're welcome, hopefully it can help in tracking this all down. I read through that report. Since both of my cameras are D415s, I'm not sure how to interpret that. There are reports elsewhere in the issues about there being a sensitivity to starting the D415s in order of their serial number or plugging them in the order of their serial number. The hub plugs into a thunderbolt port and is powered by a battery pack (the computer, an intel nuc is also powered by the same battery pack). There are a lot of other devices plugged into the hub (described in this paper) so I an concerned about stability of a camera being plugged into it. I have not noticed an improvement by plugging into the hub. We know that the realsense pushes USB pretty hard, that is why we need nice cables and the like. I have no confidence that a commodity hub off Amazon has the same quality of connection as the high end cables we all use. I would hope that whatever is breaking out USB inside of a computer (or maybe the nuc has ports with dedicated controllers?) is higher quality than an off the shelf hub. So for those reasons, I think I am going to avoid using the hub for now. That is interesting. Wouldn't restarting the computer prevent that sort of rebinding from being needed? Once I get it all working after a reboot then perhaps I will take a look at starting after stopping. I think there is some underlying engineering work that could be done on this to characterize the sensors and how to properly start them up. For a long period of time, I have been using an older NUC with this launch file (with the custom record param off). So I have been running with just color at a moderate resolution. I recently upgraded to a newer nuc with much better compute capabilities. Now using depth with higher resolution on the color than before. |
When Intel wrote their white paper on multiple cameras for the 400 Series cameras, they tested with the AmazonBasics 4-port mains powered hub from Amazon. I bought the 7-port version of it based on that recommendation and have had no problems at all with it. I have seen a couple of reports in the past of expensive USB 3.2 industrial grade hubs having problems with RealSense, whilst a cheap USB 3.1 hub worked fine. So industrial-grade may not be a guaranteed solution if there is a conflict with another aspect of the product (such as the USB 3.2 standard). I believe that the issue of needing to insert cameras in a certain order mostly applies to Nvidia Jetson boards rather than NUCs. In regard to an earlier question about power draw: the data sheet document for the 400 Series has extreme levels of detail about power delivery. If you open the PDF and do a search operation for the word power then that will help you to browse quickly through all the references. https://dev.intelrealsense.com/docs/intel-realsense-d400-series-product-family-datasheet Regarding the rebinding: my knowledge is hazy on that aspect, but I believe that there can be sections in the USB section of the computer's BIOS boot-up settings that specify whether a port has xHCI support. BIOSes tend to vary widely between different computers though depending on what chipset the computer is using. I have a NUC myself as my main personal workstation, a NUC8i5INH with Radeon graphics. It has been excellent for me. https://www.intel.co.uk/content/www/uk/en/products/boards-kits/nuc/mini-pcs/nuc8i5inh.html |
Hmm, so do you know if the realsense cameras have more trouble with USB 3.2 ports compared to USB 3.1? The new nuc that I am using is all USB 3.2 ports. Looking through the spec sheet. I see a number of places where power sequencing is discussed, as well as steady state power consumption. No discussion of any sort of higher turn on current, maybe because it doesn't exist. It would be interesting to see some real world plots of power consumption during startup of the cameras, but I am more and more thinking that is not the problem. Do you know what the ideal settings are for the USB controllers in the BIOS (of course every bios is different, but maybe for the intel nuc bios since those are widely used and we both have them)? |
I re-reviewed the case. control_transfer returned errors are very hard to diagnose a specific cause for though. I recall a case where the errors were solved simply by updating OS and kernel. I note that your problems at the start of this case began when you updated the computer. So there may indeed by a causal relationship between OS / kernel and problems. |
hmm, that is helpful to know. The OS is Ubuntu 16 with the latest kernel. Perhaps a simple re-install of the OS would fix the problem. Could secure boot cause these sorts of problems? |
There is not a great deal of concrete evidence for or against having secure boot turned off. Having Secure boot disabled was a recommendation for the previous RealSense ROS wrapper (realsense_camera) for the earlier generation of cameras though as it made DKMS packages fail. And having it enabled may affect patching of the video driver in Linux, in which case a member of the RealSense team recommended disabling it in 2019. IntelRealSense/librealsense#3354 (comment) If it is not a policy of your company that Secure Boot has to be enabled on its machines then it should be okay to turn it off. |
Hi @mjsobrep Do you require further assistance with this case, please? Thanks! |
Hey @MartyG-RealSense I think I am good for right now. I have some stuff that I want to check out, but have the information I think I need. Thanks! |
Hi @mjsobrep Thanks very much for the update! |
I am facing a similar issue. I have a robot with three D435i cameras and sometimes I got How to avoid this to happen? Just for reference, I use Thank you |
Hi @jcgarciaca Which roslaunch method are you using to launch your multiple cameras please - rs_camera.launch or rs_multiple_devices.launch? https://github.com/IntelRealSense/realsense-ros#work-with-multiple-cameras |
Hi @MartyG-RealSense, actually I use |
Are you putting each camera on a separate terminal on the same computer, with a separate roslaunch for each camera, as Step Two of Intel's multiple camera ROS tutorial suggests? https://www.intelrealsense.com/how-to-multiple-camera-setup-with-ros/ |
Yes, you're right. But I use
|
Do you experience any improvement in performance if you add a reset instruction to the end of each of the three roslaunch instructions so that the camera undergoes a hardware reset at launch (similar to a USB unplug-replug of the camera). initial_reset:=true |
I just tested with the |
@jcgarciaca You said in your original comment "Usually, I just stop and re-launch them again and everything works well". Could you tell me the method that you use to re-launch the cameras please? |
In my application I have some |
Okay, thank you very much for the information. I will continue to investigate on Thursday. Thanks for your patience! |
If the cameras work correctly after a stop and restart, I wonder if you could incorporate a start-stop-start into your sh script. Start |
Well, with the |
Thanks very much @jcgarciaca |
Right now I don't have a better solution for the occasional RS2_USB_STATUS_BUSY error. |
RS2_USB_STATUS_BUSY is a message of the RSUSB backend which is built into the ros-librealsense2 package. And rebuild realsense2_camera from code Does the reliability seems better with that librealsense2 build? |
I just made the mistake of updating software (dumb) and am now having trouble with a setup running two D415 cameras. My launch file had been working well for sometime. Rather than just downgrading, I would like to understand the source of the problem and fix it.
The system seems to think that the cameras are busy on startup, I do not know why. If I am running in rosmon, I kill the nodes, and then restart them, then it seems to work, although CPU usage goes crazy. Simple relaunching does not solve the problem.
Weirdly, when I turn on the computer, if I launch realsense viewer, there are no problems. If I run the ros launch file above and then open realsense viewer, the cameras do not show up.
If downgrading software is the way to go. How do I downgrade librealsense, the ros stack, and the firmware all at once? Or do I only need to downgrade one? Where should I be downgrading to?
console output:
The text was updated successfully, but these errors were encountered: