Some errors are not published to /rosout.

[Krzo99]

Some errors are not published to /rosout.

[MartyG-RealSense]

Hi @Krzo99 If control_transfer returned warnings are not being logged to file then this can be considered an advantage. This is because this type of message typically generates so frequently that it makes a log file difficult to read and analyze.

If you do require the messages though then you could test whether changing the logging level from the default 'Info' to the more detailed 'Debug' makes a difference. This can be done by adding the command log_level:=debug to the launch instruction.

ros2 run
ros2 run realsense2_camera realsense2_camera_node --ros-args -p log_level:=debug

ros2 launch
ros2 launch realsense2_camera rs_launch.py log_level:=debug

[Krzo99]

That makes sense, however, I still think printing to /rosout would make sense here. All other errors are being printed, like Hardware Notification:Depth stream start failure,1.71681e+12,Error,Hardware Error
In my case, It would be a great way to log and check why the rtabmap odometry was lost. It can quite easily happen if this control_transfer returned error error happens, as the whole depth module flickers when this happens at runtime.

Do you maybe know what the error numbers mean?

Setting log_level to debug doesn't have any effect in this case.

[MartyG-RealSense]

The number after Depth stream start failure is not meaningful.

In general, control_transfer returned warnings are indicative of a communication problem between the camera and the computer / computing device, such as an issue with the USB port or cable.

Odometry may be lost if the camera is moving or turning too quickly or if the scene that the camera is observing is 'sparse' with not many objects in it.

[MartyG-RealSense]

Hi @Krzo99 Do you require further assistance with this case, please? Thanks!

[Krzo99]

Hi @Krzo99 Do you require further assistance with this case, please? Thanks!

No, however, I still think it would be a good idea to have it.
I'll close the issue.