-
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
Control_transfer returned error, index 768 from D435i #1957
Comments
Hi @MiPlayer123 If you are receiving the control_transfer returned warning only a small number of times during launch and then they stop, or they occur one or two times a minute after launch, then this warning can be safely ignored. If this warning is generating continuously though then it can indicate a serious communication problem with the device. The first test that I recommend when trying to correct this issue is to add an initial_reset:=true command to the roslaunch instruction to reset the camera at launch: roslaunch realsense2_camera rs_camera.launch initial_reset:=true Does using this command in your roslaunch instruction make a positive difference to the performance of your launch, please? |
@MartyG-RealSense Thanks for your reply. Resetting the camera does not seem to help. I am still getting the same error. I also noticed that very few of the topics are being published properly. I cannot see a video feed in Rviz or even the Odom topic. I am not sure where the error is coming from. |
Could you paste the text of the terminal log from your roslaunch into a comment please? Thanks very much. |
Here is the log:
|
Thank you very much. The versions of the RealSense ROS wrapper and librealsense SDK are correctly matched. I note your comment that "very few of the topics are being published". A number of the topics are set to False by default in the rs_camera launch file and therefore have to be enabled in order to be published. The disabled by default topics that are supported on D435i include: infra1 infra2, gyro and accel. You can enable these topics by including the commands below in your roslaunch instruction: enable_infra1:=true For example: roslaunch realsense2_camera rs_camera.launch enable_infra1:=true enable_infra2:=true enable_gyro:=true enable_accel:=true |
Thanks, I tried that, but I noticed that I am still running into issues. I can see now that the topics are being published, but I cannot see anything when I add these topic to Rviz. Side question, is there a example launch file that has all these topics enabled and the parameters set properly?
|
Are the control_transfer returned messages being generated continuously or do they stop after the ones shown in the log above, please? Also, which topics are you adding to RViz? Could you provide an image of your RViz screen if possible? rs_aligned_depth.launch has depth, color, infra and IMU stream types all enabled as True. |
If the control_transfer returned warning appears only once or twice per minute after launch then it is safe to ignore it. Out of frame resources could suggest that the USB port is being over-burdened by the rate at which incoming data is arriving and the 'frame queue' is being jammed up, preventing new frames that are arriving from being processed. You could try a simple custom launch where only depth (no color) will be published at a 640x480 resolution and 30 FPS to test how your computer copes with incoming data. roslaunch realsense2_camera rs_camera.launch depth_width:=640 depth_height:=480 depth_fps:=30 As far as I am aware, odom is a topic that is produced by launch files designed for use with the RealSense T265 Tracking Camera. A guide that is based on Intel's D435i SLAM tutorial for the RealSense ROS wrapper does suggest a method for accessing an odom topic with a D435i using RTABMAP though. https://shinkansan.github.io/2019-UGRP-DPoom/SLAM.html In regard to RViz, do you see images if you change Fixed Frame from 'map' to camera_link |
The command seems to work fine. I still get the control_transfer returned warning, but I get no other errors. However, when I run Thanks for the resource. I looked into it, but i get a failed to meet update rate error. As for RViz, I am not sure what you mean. |
Do you still experience the motion module failure if you include the command below in your roslaunch instruction: unite_imu_method:=linear_interpolation Regarding RViz, I mean going to the Fixed Frame option of the RViz side-panel and changing its setting from the map that it is currently using so that it says camera_link, like the image below. |
Do you see an improvement if you set unite_imu_method to 'copy' instead of 'linear_interpolation' by adding the command below to the roslaunch instruction to override the launch file's default linear_interpolation setting? unite_imu_method:=copy |
No, its the same as before. I still get the error, but I see something like the previous image in RViz. Do you think that the camera's IMU might be affected hardware wise? This is a brand new camera though. |
There have been past reports of the Failed to meet update rate! message happening when using the opensource_tracking.launch launch file, so I would not strongly suspect that there is a hardware problem in the camera. The camera certainly can publish data, though at a slow rate in this particular case. In the RealSense Viewer, the Motion Module Failure error is more of an annoyance than a serious problem, as the accel and gyro streams usually activate normally the next time that they are enabled after the error has occurred. It is more complicated in RealSense ROS though, as you cannot just press a button to re-start the IMU streams after the failure message has occurred. Intel provide a Python-based tool to calibrate the IMU, though I would not expect IMU calibration to be a cause of this particular issue. Indeed, a Nano user who had the Failed to meet update rate! message in a past RealSense ROS case performed the IMU calibration but it did not resolve the problem. Their next step was going to be to reduce the IMU frequency to see if it helped, but they did not report the outcome of that test. In another case involving this error, a user reported freeze-up when Failed to meet update rate! was being generated, similar to your own significant slowdown. Is the camera moving when the message is occurring or is the camera stationary? |
Oh ok.
Do you happen to know which directory the
The camera is stationary. I am not sure if the slowdown/ freeze up is caused due to the Jetson Nano not having enough processing power or not. The CPU is up near 100% when I launch it and that could potentially cause the Failed to meet update rate! error. |
rs-imu-calibration can be found in the librealsense source code folder librealsense/tools/rs-imu-calibration. It can be launched using the command python rs-imu-calibration.py https://github.com/IntelRealSense/librealsense/tree/master/tools/rs-imu-calibration Did you build the RealSense ROS wrapper from packages using the Method 1 installation that installs the librealsense SDK and the wrapper together, please? If you did then you may not have support installed in the SDK for CUDA graphics acceleration. You can install CUDA support for your Nano by building the SDK and ROS wrapper separately, as described in the link below. |
The multiple udev rules warning typically occurs if librealsense has been installed with both the package and source-code methods on the same computer. Deleting the rule in the etc/udev version of the folder can correct the problem. The lib/udev rule should not be deleted, as doing so can break linkages to the librealsense packages. |
Hi @MiPlayer123 Do you require further assistance with this case, please? Thanks! |
Sorry, I haven't posted anything lately, I got busy. I am getting the normal Jetson Nano (4GB) and I am going to test on that (with CUDA enabled). I will update here if it works or not. Thank you for your help so far @MartyG-RealSense. It has been really helpful. |
You are very welcome @MiPlayer123 - please do update here when you have test results with Jetson Nano. Good luck! |
Hi @MiPlayer123 Do you have an update about this case that you can provide, please? Thanks! |
Hi @MartyG-RealSense I just go the new jetson and i will update here with any issues in the next couple days |
Thanks very much @MiPlayer123 :) |
Hi @MiPlayer123 Do you have an update about this case that you can provide, please? Thanks! |
Hi @MiPlayer123 Do you require further assistance with this case, please? Thanks! |
Hi @MartyG-RealSense I was busy before and was not able to test it. I was able to get it to work and I can see the data in rviz. I still get the control transfer error, but its rare and does not affect performance. I have also gotten a T265 tracking camera for reliable VSLAM. I am wondering how I can run both the tracking and depth camera ros nodes. I was not able to install with cuda as the documentation was unclear to me. I get a |
Thanks @MiPlayer123 for the update. There is little documentation available about the Failed to meet update rate! error. When ROS does generate this error though, it sometimes provides this advice: "Try decreasing the rate, limiting sensor output frequency, or limiting the number of sensors". I am not involved in support of the T265 Tracking Camera model and so would recommend creating a new issue on this forum with 'T265' in the message title if you have T265 questions. You could though try launching a T265 and D435i together with rs_d400_and_t265.launch |
Case closed due to D435i performance being declared satisfactory and advice provided to create a T265 question as a separate case. |
Hello
I am trying to use the D435i on my Jetson Nano with ROS, but I am getting this error:
(messenger-libusb.cpp:42) control_transfer returned error, index: 768, error: No data available, number: 61
when I run this commandroslaunch realsense2_camera rs_camera.launch
None of the topics are being published and I cannot see anything in Rviz. If I use the RealSense viewer, everything works fine. The camera is connected to the USB3 port on the Jetson Nano. I have looked at other similar forum posts, but now of them seemed to fix the issue. Any help would be appreciated.
Thanks
The text was updated successfully, but these errors were encountered: