Realsense dmesg spam #2380
Comments
|
Hi @BryanStuurman These messages originate from the kernel. There was a request in 2021 to be able to mute kernel messages to ease debugging but it was declined by Intel for reasons provided at IntelRealSense/librealsense#8215 (comment) You could try building the librealsense SDK from source code with the RSUSB backend installation method, which bypasses the kernel, to see whether this reduces the volume of kernel-related messages. An RSUSB source code build is not dependent on Linux versions or kernel versions and does not require patching. |
|
Interesting. I'm less interested in muting the messages and more so interested in why they occur in the first place. This suggests me to some enumeration issue in the realsense itself, can you comment as to the root cause of this? |
|
Some kernel versions may conflict with librealsense, especially kernels that are unsupported by the SDK. The newest supported kernels are 5.4 if building from Debian packages, and 5.8 or 5.11 if building from source code. Unsupported kernels, such as 5.13, can work with the SDK but there may be unpredictable consequences in regards to stability. An RSUSB build of librealsense can help to avoid kernel conflicts as it bypasses the kernel. |
|
Okay. I am running kernel We are having connection issues with one robot in the field, probably related to the USB cable (the camera is on the end effector). Would the RSUSB build be more reliable with a spotty USB connection? |
|
An unreliable USB connection will negatively affect any type of librealsense build, so it is better to try to address the cause of the USB issue. Movement of the camera's USB cable during robot motion may be slightly dislodging the cable connector in the USB port and causing disconnection. There are a pair of small holes either side of the camera's micro-USB port for a screw lock USB cable to be used for firmly affixing the cable into the port so that motion does not dislodge it. Information about this can be found at IntelRealSense/librealsense#3118 (comment) |
|
Indeed we are using the screw lock cables, I am hoping to find a software solution that adds some robustness while the client waits for replacement cables/parts. |
|
You are very welcome. It is possible that the USB cable on the affected robot may have internal damage if it gets flexed a lot during motion, or it could simply be a bad cable. The quality of USB-C cables can vary when using your own choice of cable instead of the official one supplied with the camera that is validated by Intel for use with RealSense. If your robot uses 6 FPS speed then I would also recommend increasing to 15 FPS, as errors such as stream time-outs may occur at 6 FPS (due to frames not arriving quickly enough) that disappear at 15 FPS. |
|
We spend a fair bit of money on these cables, but I will be investigating the failure thoroughly when the hardware comes back. We run 30FPS - would 15 FPS be preferable to 30? |
|
Reducing from 30 FPS to 15 would be advisable if there is evidence that the computer board on the robot is struggling to process the data stably at 30. The higher the FPS, the higher the volume of data being transmitted from the camera to the USB port of the computer board, increasing the risk that the computer cannot keep up with processing the incoming frames. Using a system monitoring tool on Ubuntu such as htop would show whether the CPU usage percentage is near 100 percent, which would indicate that the CPU is over-burdened and so negatively affecting overall performance. |
|
CPU load is not a problem, this is an i5 6/12 core/thread chip, the realsense2_camera_manager process uses about 30% peak of a single execution port. What is the failure mode when USB errors delay a frame transfer beyond when the next frame is due? Does the node crash or does it try again ASAP, or wait until the next scheduled frame time? |
|
If new frames are not received then the SDK will listen for frames for 5 seconds before declaring a time-out. If frames arrive within 5 seconds then the pipeline should resume streaming automatically from the point where it left off. If a script uses try_wait_for_frames() instead of wait_for_frames() then the program should not exit with an exception error when time-out occurs and instead continue running. |
|
Sounds like pretty reasonable behaviour. Also implies that the realsense is configured to autonomously generate frames, instead of being requested for them by the SDK - true? |
|
A camera will not be generating frames until it is requested by a program to do so and once started it will continue streaming frames until stopped by the program, whether due to an intended stop or an exit due to an error such as RuntimeError: Frame didn't arrived within 5000 (5000 being equivalent to 5 seconds), |
|
Hi @BryanStuurman Do you require further assistance with this case, please? Thanks! |
|
@MartyG-RealSense we had the client replace the cable for us and our connectivity issue is now solved. I'd like to do some forensics to see how many packets were lost - but you can close this issue. Please let me know if you'd like to me reopen it when I make my findings. |
|
Hi @BryanStuurman I'm pleased to hear that you had success after a cable change. It is fine to keep this case open until you are ready to report your findings. Thanks again! |
|
I just need log to spam money |
|
Case closed due to solution achieved and no further comments received. |
I have a 415 on my desk and four 435's deployed in the field that are generating a large amount of traffic on dmesg when they're first started up:
The 415 (for which the logs are pictured above) is running the most current firmware. Others are running a sprinkling of firmware versions dating back to early 2021; they all do this.
The systems all run:
ROS 1 noetic
Ubuntu 20.04
RealSense ROS v2.3.2
Built with LibRealSense v2.50.0
Running with LibRealSense v2.50.0
Why does this occur, and can it be limited in the future? This makes debugging issues on remote machines that much harder.
The text was updated successfully, but these errors were encountered: