I recently ran into an issue where the depth camera topic was publishing all 0s, so I ran stretch_camera_streams_check.py and got this output:
For use with S T R E T C H (R) from Hello Robot Inc.
---------------------------------------------------------------------
cv2.__version__ = 4.11.0
sys.version = 3.10.12 (main, Mar 3 2026, 11:56:32) [GCC 11.4.0]
Unable to find Realsense D405...
D435i Stream Settings:
D435I_COLOR_SIZE=[640, 480]
D435I_DEPTH_SIZE=[640, 480]
FPS=30
Unable to Find device: /dev/hello-nav-head-camera
And the RGB camera looked fine, but the depth camera window was black with some indistinct greys at the edges.
I thought this might be similar to this issue, with the exception that streams check does not seem to work for me, so I’ve included some outputs from suggested commands there:
Could you please post the output from cat /etc/udev/rules.d/87-hello-nav-head-camera.rules?
Also, regarding the depth camera window that is all 0’s for you, do you mean the depth camera on the wrist camera (D405), or the head camera (D435i)? Thank you for clarifying!
Thanks again, a couple quick clarifications that will help:
First, could you please share the robot serial number?
Also, could you confirm which cameras you have on your robot?
D435i (head RealSense)
D405 (wrist / gripper camera)
Navigation head camera (separate USB camera)
Just to clarify, the navigation head camera is different from the D435i, so I want to make sure we’re talking about the same devices.
Also, regarding the D435i depth image:
Seeing a mostly dark (black) image with some faint grey is actually expected in many cases, depending on the scene, so that alone isn’t necessarily an issue.
Finally, when you mentioned the depth topic publishing all 0s, could you let me know which specific topic you’re referring to? If possible, could you also share the output/logs you’re seeing for that topic?
The serial number is 1028. We don’t have a separate USB camera or a camera on the wrist, and we have been working with the D435i in the head.
I ran ros2 launch stretch_core stretch_driver.launch.py and ros2 launch stretch_core d435i_low_resolution.launch.py. The output from ros2 topic echo /camera/depth/image_rect_raw is attached here: image_rect_raw echo.txt (18.3 KB)
I ran the same test on my side and recorded the full output from /camera/depth/image_rect_raw . I can confirm that the topic normally contains a mix of zeros and non-zero values.
The zeros correspond to pixels where the camera does not return a valid depth (this is expected behavior), while the non-zero values are valid depth measurements.
So seeing zeros in the topic is normal, what matters is whether you also see non-zero values in the stream.
On my side, the data looks similar to what you shared, with valid depth values mixed in with zeros, which suggests the depth stream is behaving as expected.
If you want to verify this more clearly, you can run:
This will create a full_topic.txt file in your current directory. You can open this file to inspect the full topic data and confirm that non-zero values are present.
You can also visualize the streams in RViz:
In a new terminal, run:
rviz2
Add an Image display and select:
/camera/depth/image_rect_raw (depth image)
/camera/color/image_raw (RGB)
Optionally, add a PointCloud2 display and select:
/camera/depth/color/points (pointcloud)
This is often the easiest way to confirm that the depth and RGB streams look correct and that you are getting valid data.
Let me know what you observe on your side and we can take it from there if needed.