control_transfer returned error, index: 768, error: No data available, number: 61 #2425
Comments
|
Hi @PhilipAmadasun Is this a separate issue to your earlier recent Gazebo case at #2422, where you are trying to access a real D435i camera this time instead of a simulated D435 please? If you are using a live camera and the control_transfer returned error that you experienced is generating in the log continously then this can indicate that there is a serious communication problem with the device. You have already likely tried initial_reset:=true as it is referenced in your other case. Can you confirm that this have been tried with the D435i camera? Do you experience the same control_transfer returned warnings if you launch with roslaunch realsense2_camera rs_camera.launch |
|
@MartyG-RealSense Yes I get the same exact issue when I launch this, even with initial_rest:=true |
|
Do you have another USB cable that you can try with the camera if you have not done so already to confirm whether or not the apparent communication problem demonstrated by the control_transfer returned warnings is related to the cable that is currently being used with the camera? |
|
i still get the same problem |
|
Next, we should consider the possibility that if a basic rs_camera launch does not work then there may be a problem in the installation of the librealsense SDK 2.45.0 and ROS wrapper 2.3.0 that is causing the warnings. If you are using those versions, it looks as though you installed the SDK and ROS wrapper together from packages on ROS Kinetic using the wrapper's Method 1 instructions. Is that correct, please? If you did use Method 1, did you install librealsense before running the Method 1 installation? If for example you installed librealsense from packages or source code and then ran the Method 1 installation, you would have installed librealsense twice, because Method 1 installs both librealsense and the wrapper. This could cause a conflict between librealsense installations. |
|
@MartyG-RealSense I can't recall but I believe did method 1 first, I honestly can't remember. But you are saying doing Method1 will also install a wrapper? I have installed from source librealsense version 2.33 |
|
Method 1 uses packages to install both librealsense and the ROS wrapper at the same time, whereas Method 2 (a source code build) only builds the ROS wrapper. If you used Method 1 first and then installed librealsense 2.33 from source, it is probable that you have two librealsense installations on the same computer that are conflicting with each other. Installing from source and packages on the same computer can lead to a Multiple udev rules detected problem that could prevent the SDK from working correctly. If you have multiple udev rules then the simple solution is to delete the rule that is at the /etc/udev/rules.d/ folder location, as described by a RealSense team member at IntelRealSense/librealsense#6153 (comment) |
|
Hi! So I removed librealsense 2.33 from my laptop redid method 1 from scratch. I still get the same error. I looked at /etc/udev/rules.d, and I have 99-realsense-libusb.rules. Do I delete this? I'm confused. This s the error:``` PARAMETERS
NODES auto-starting new master setting /run_id to 69e3dfe0-1219-11ed-b475-d43b04207196 [ INFO] [1659413588.912487340]: Device with physical ID 2-1.2-5 was found. Intel RealSense UVC cameras (R200, F200, SR300 LR200, ZR300, D400, L500)SUBSYSTEMS=="usb", ATTRS{idVendor}=="8086", ATTRS{idProduct}=="0a80", MODE:="0666", GROUP:="plugdev", RUN+="/usr/local/bin/usb-R200-in_udev" Intel RealSense recovery devices (DFU)SUBSYSTEMS=="usb", ATTRS{idVendor}=="8086", ATTRS{idProduct}=="0ab3", MODE:="0666", GROUP:="plugdev" Intel RealSense devices (Movidius, T265)SUBSYSTEMS=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="0af3", MODE="0666", GROUP="plugdev" KERNEL=="iio*", ATTRS{idVendor}=="8086", ATTRS{idProduct}=="0ad5", MODE:="0777", GROUP:="plugdev", RUN+="/bin/sh -c 'chmod -R 0777 /sys/%p'" |
|
There is something wrong wth my "depth_image_to_laserscan" node, its not connected t oanything on my rqt_graph. There is a launch file in turtlebot_bringup called "3dsensor.launch" that activates this node. Maybe you can look at this file and help me. Here it is: |
|
If you have a rule at /lib/udev/rules.d/60-librealsense2-udev-rules.rule then you can delete the other rule at etc/udev/rules.d In regard to your second question, I do not have knowledge about use of depth_image_to_laserscan unfortunately. |
|
@MartyG-RealSense I dont have any such rules in my lib/udev, how do I make one? |
|
The SDK installation guide at the link below advises to use these two instructions to install the /etc udev rule after navigating to the root directory of the librealsense source code folder. sudo cp config/99-realsense-libusb.rules /etc/udev/rules.d/ https://dev.intelrealsense.com/docs/compiling-librealsense-for-linux-ubuntu-guide |
|
@MartyG-RealSense Isn't it supposed to be a 60-realsense-libusb..... file and not a 99-realsense-lib? |
|
@MartyG-RealSense I also don't have a config file. in my librealsense, its supposed to be in my ros/kinetic/shared directory right? |
|
If you have a source code build then the udev rule installed is /etc/udev/rules.d/99-realsense-libusb.rules If you build from packages then the udev rule is /lib/udev/rules.d/60-librealsense2-udev-rules.rules If both rules are installed on the same computer then the /etc rule is the one that is deleted, because removing the /lib rule can break linkages to packages. In your case though, you had neither of these rules installed. If a system is in a tangle, with both package and source code builds and missing / conflicting files, it can be easier just to perform a complete wipe of the computer (including Ubuntu) and re-install everything from the beginning, making sure to only choose one SDK install method this time (such as the ROS wrapper's Method 1). If it is not possible to wipe the whole computer then remove as much of librealsense as possible. *. If you built the ROS wrapper from source code, delete the entire catkin workspace folder /catkin_ws/src *. If you built librealsense from packages, remove them. dpkg -l | grep "realsense" | cut -d " " -f 3 | xargs sudo dpkg --purge *. If you have a source code installation of librealsense on your computer, go to its root directory and run the CMake instruction below to uninstall it. sudo make uninstall && make clean |
|
ROS seems to recognize the camera though, its just the depthimage to laser
scan nodelette that doesn't connect to anything, Thus why I can do SLAM.
…On Thu, Aug 4, 2022 at 11:35 PM MartyG-RealSense ***@***.***> wrote:
If you have a source code build then the udev rule installed is
/etc/udev/rules.d/99-realsense-libusb.rules
If you build from packages then the udev rule is
/lib/udev/rules.d/60-librealsense2-udev-rules.rules
If both rules are installed on the same computer then the /etc rule is the
one that is deleted, because removing the /lib rule can break linkages to
packages.
In your case though, you had neither of these rules installed.
If a system is in a tangle, with both package and source code builds and
missing / conflicting files, it can be easier just to perform a complete
wipe of the computer (including Ubuntu) and re-install everything from the
beginning, making sure to only choose one SDK install method this time
(such as the ROS wrapper's Method 1).
If it is not possible to wipe the whole computer then remove as much of
librealsense as possible.
*. If you build the ROS wrapper from source code, delete the entire catkin
workspace folder.
*. If you built librealsense from packages, remove them.
*dpkg -l | grep "realsense" | cut -d " " -f 3 | xargs sudo dpkg --purge*
*. If you have a source code installation of librealsense on your
computer, go to its root directory and run the CMake instruction below to
uninstall it.
*sudo make uninstall && make clean*
—
Reply to this email directly, view it on GitHub
<#2425 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AND3KDSQ57OF7VLQ5Z6RSITVXSYZLANCNFSM54UHSQPQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Some resources about using D435 with depthimage_to_laserscan are listed at #2440 (comment) |
|
@MartyG-RealSense The initial issue is that the scan topic is not receiving any messages. the depdthimage-to-laserscan nodelet only works when the scan topic is receiving data(as I now realize). How do I get the scan topic topic to recieve data, I think this is the main issue that needs to be solved. WHat are the possible reasons why the scan topic does not receive anything? |
|
I found a case at #1163 where move_base was not receiving depth images when using depthimage_to_laserscan, so the RealSense ROS user in that case created their own adapted 'fork' version of the ROS wrapper that published directly to the /camera/scan topic from the wrapper. https://github.com/dschnabel/realsense-ros Because of the age of that case though, the forked wrapper matches to librealsense SDK 2.33.1 instead of 2.50.0, so the edits made to the wrapper would likely have to be recreated in your own fork of 2.50.0 unless you were happy to use the old 2.33.1 SDK. |
|
@MartyG-RealSense Okay, because this is the 2.33.1 version I will try to build depthimage_to_laser scan in a workspace. Although, I have the ros-kinetic-depthimage-to-laserscan package in my opt/ros directory(which does not seem to have some of the files here,do I just remove that and build another one in the workspace? How do I make sure my the launch file that includes the depthimage-to-laserscan I build? |
|
The impression that I get from #1163 is that the RealSense ROS user incorporated the depthimage_to_laserscan code into their forked RealSense ROS wrapper so that depthimage_to_laserscan does not have to be launched separately as a standalone package. If the separate depthimage_to_laserscan package that you already have installed does not appear to be outputting anything then it may be worth first trying leaving the existing package in place and running the forked wrapper to see whether anything is output to the /scan topic. |
|
@MartyG-RealSense If I build the editted wrapper package in a workspace, how do I make sure the already installed "ros-kinetic-realsense2-camera" does not fight with this newly installed wrapper? wouldn't I have two wrappers then fighting against each other like last time? |
|
If ros-kinetic-realsense2-camera was built from packages using Method 1 then using the package uninstall command should remove all packages that include 'realsense' as part of their name. dpkg -l | grep "realsense" | cut -d " " -f 3 | xargs sudo dpkg --purge It would also remove the librealsense SDK though. So you could then install librealsense 2.33.1 from source and then build the edited wrapper. https://github.com/IntelRealSense/librealsense/releases/tag/v2.33.1 |
|
Hi @PhilipAmadasun Do you require further assistance with this case, please? Thanks! |
|
Case closed due to no further comments received. |
|
@MartyG-RealSense I found the solution. The depthimage_to_laserscan package wasn't working because the realsense camera could not share information with the nodelets the package uses for some reason. So the problem is fixed by modifying the Maybe this can help someone else, thanks! |
|
It's awesome to hear that you found a solution! Thanks so much for the update and for sharing your solution with the RealSense ROS community :) |
|
Hello, I am trying to use the turtlebot2 with the d435i camera. I am using this file as 3D sensor turtlebot_bringup/launch/includes/3dsensor/d435i.launch.xml but the maps created are not very accurate:
Could you show me the modifications you have made to gmapping with the turtlebot and the d435i? Thanks in advance. |
trying to get d435i camera to work with turtlebot2. For some reason the '/scan' does not get any data. This is what I get when I
roslaunch turtlebot_navigation gmapping_demo.launch:The text was updated successfully, but these errors were encountered: