-
Notifications
You must be signed in to change notification settings - Fork 4.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
Error Calibrating IMU and failed to receive IMU frames when stream Depth Color IMU at the same time #6370
Comments
I considered the calibration EEPROM writing problem carefully. As a first step to try, I would recommend performing a "gold reset" on the camera to return it to factory defaults. If there is a corruption in the calibration table that is stored inside the camera then the gold reset can correct it. https://forums.intel.com/s/question/0D70P000006EFHESA4 There have been a couple of previous cases related to difficulty with using Python to stream color, depth and IMU together. I hope that the links below will provide useful insights. The second link relates specifically to streaming color, depth and IMU at the same time on Nano. |
Thank you for your reply! Sure, for the problems with Python stream color depth and IMU together, already tried those solutions and their codes. But it didn't work as well. But let leave that aside while trying to fix the calibration error. Maybe after that it will work fine! Refering to
can you help me with this problem before I perform the gold reset? |
Someone else had problems installing librscalibrationapi but were able to install librscalibrationtool. librscalibrationtool is actually the one that you want. The 'Calibration API' is a more advanced tool for users who want to create their own custom calibration tool. If you installed librscalibrationtool first and then tried installing the optional librscalibrationapi second, then that second optional step can be skipped as you do not need the custom calibration tool creation functions. |
@MartyG-RealSense yes, same error with librescalibrationtool. It cannot find the package. But that's okay I used Windows and it worked. I got result:
And then I performed again
|
Okay, thanks for trying the gold reset. At least we have eliminated the calibration table as a potential cause of your problem. Your opening mention of having sufficient power supply suggests that you are using a mains electricity powered USB 3 hub connected to a wall power socket? |
Thanks! I don't use any USB 3 Hub, I connect it directly to the Jetson Nano USB Port, but my Jetson Nano is powered with 5V Barrel Jack with maximum current 3.5A. I never have (yet) any issue with my Jetson Nano failed to power any USB device through it's USB port. I also could perform stream depth+color with Python code continuously. (Which it means it could work, and I don't think EEPROM writing or IMU calibration needs more power than depth+color stream, am I wrong?) |
It's more an issue of whether the power supplied to the USB port is stable, rather than the overall amount of power supplied to the board. An enterprise computer with a big power supply can still experience USB port problems. What a mains powered USB hub does is provide stable power to the USB port, because the hub is supplied from the mains electricity. Whereas if the camera is plugged directly into the computer's USB port, it is still a "passive" connection that relies on the computer's power supply (whilst a mains powered USB hub is an "active" connection). This guide to the Nano power supply suggests having both a barrel jack and a powered hub: https://desertbot.io/blog/jetson-nano-power-supply-barrel-vs-micro-usb Having said that, you are able to run all three streams on the first run of the program, so the hardware is capable of performing it without the help of a powered hub. I have also heard of cases like this, where the application fails on a subsequent run, seemingly because something was not closed properly after the first run. Are you using syncer instead of pipeline in your program, please? There was a reported problem earlier this week with syncer not being shut down properly after the stop and then close of a sensor. |
@MartyG-RealSense So the idea about using Jetson Nano and RealSense was to make a portable wearable device and battery powered. I'm afraid it is not possible for me to use powered hub while designing a simple portable battery powered wearable device. Sure, I also aware of that pipeline, so I said earlier in the first post that I stop all my pipelines correctly. I didn't use syncer since I used and still modified many sample codes provided. I even try to stop the pipelines twice (in case my Also when I open |
It is not unusual for a process to work fine in the RealSense Viewer (which uses C++ language) but be more problematic to reproduce in the Python language due to differences between the languages. Could you test please whether the problem with IMU occurs if you reset the camera (but not the Nano) by unplugging the camera after the first successful run and then plugging it back in before starting the program for the second time? |
This in my code:
First, after restart: worked, then exit properly.
I noticed that with these simple tasks, I got very poor FPS even though my setting was 60FPS for the depth+color. Yes, this is not the legal way to check the FPS, just as an indicator
Third, unplug the RealSense for a minute, and plug it back, and run the program again:
I realized it managed to get the first IMU frames, but with no depth+color (the
Now it didn't manage to get the first IMU frames. Very strange huh! |
Frame didn't arrive within 5000 is a useful indicator. It suggests that the pipeline might be getting jammed up with frames because they are not being released properly, causing timeouts due to the pipeline not being able to respond to a poll for new frames in a timely manner. |
@MartyG-RealSense sure, thank you for your explanation. I didn't understand about how the pipeline work, for example if I have pipeline for gyros and accel with different FPS, at what FPS would I get the timeline frame? |
The discussion in the link below is a good reference for the timing differences between the depth and IMU streams |
Okay, so I've tried callback function to deal with it. If I may conclude, the problem of this error when stream depth + rgb + imu is the more-than-one pipelines. I don't know why, but if I open one pipeline only, and stream through three of them with callback function, I can get all the IMU (Accelerometer and Gyroscope with different FPS), Depth only (corupted). If I use 2 pipelines, then one of the pipeline would not working correctly, or receive the frame very rare (like 1 every 5-15 seconds). @MartyG-RealSense if I may ask, do you know any reference about Python Callback function only give 1 I will provide the script latter.
the output:
|
This subject is somewhat outside of my current level of programming knowledge. I did though find a reference for using callback with depth and RGB in Python. |
WOW! Right on target. Thank you very much! Yes it works and it helps me a lot! I also tried to search other issues but didn't find that one, should be more thorough. Okay I think this three stream problem is solved. Maybe this is just imperfect feature, since And last but not least about the IMU calibration. Currently, this uncalibrated IMU don't affect me, but I'm thrilled to find the reason why. Again, thanks! |
I'm very glad that the link was able to help you! Yes, feel free to post a new issue containing your feature request and I will label it as Enhancement. My understanding of the reason for calibrating the IMU is that otherwise, you can get non-zero values in the accelerometer and gyro even when the camera is stationary, when the values should be reading zero. |
Case closed due to no further comments received. Thanks again! |
@juliussin do you have updated code you could share? Did you end up using/testing with two pipelines? Can you share at what frame rates you actually receive gyroscope & accelerometer data (were you able to get them at 200 fps & 63 fps using the callback)? |
Hi, I'm getting This is my code:
Tried debugging with |
Hi @a7u7a I looked at your code carefully. Your script does not seem to have a definition for what the contents of fs should be. So you could instead use the default frame in its place. I would also change test_callback to callback, and edit the pipeline start instruction appropriately to reflet this change. Also, I believe that you cannot call pipeline.stop() before pipeline.start() if the pipeline has not already been started. So I moved pipeline.stop() below the start statement. import pyrealsense2 as rs |
Hi MartyG, Sorry for the late reply. Your comment was very helpful, many thanks! |
Hi @MartyG-RealSense , i tried this sample script, but it seems the callback function doesn't seem to be invoked in my case. i'm using D455 device. i kept some print statements in the call back function which doesn't get printed confirming that call back function is not getting invoked |
Issue cleared! adding delay of few milliseconds, before accessing call back data did the trick |
Hi @07hokage It is great to hear that you succeeded - thanks very much for the update! |
Issue Description
I'm having some troubles with my realsense. First, I got this error when I open
realsense-viewer
After looking for the solution, I tried to calibrate my realsense with the
rs-imu-calibration.py
provided in SDK. But after calibration, it failed to write the results to the eeprom:I'm wondering what's wrong with my device?
Also I'm having a lot of problems with Python Wrapper. I can't stream Color + Depth + IMU at the same time. Similar to #5628 and #6031 . I run their kindly provided code, and it didn't succeed to read the IMU frames. But strangely, sometimes after I restart my Jetson Nano, the code worked! But on the second time running, IMU frames timeout! I've stop the pipeline properly, so I think that's not the problem. I think that's a bug. I've been restarting my device frequently to find out the problem.
I'm using only 1 realsense, and I'm using USB cable provided in the product box. I also powered my Jetson Nano properly with sufficient power supply, if you would guess those. :)
The text was updated successfully, but these errors were encountered: