Despite multiple attempts, I have been unable to access or detect the cameras.
When connecting Reachy to an external monitor and launching a camera application such as Cheese, no webcam is detected. Also when running the following commands I have no infomation on the cameras as seen in the attached photos. `lsusb```, ls /dev/video*, ```lsmod | grep videoand ```journalctl -b | grep -i video``.
Given that the system appears to be functioning correctly otherwise, I suspect that the issue may be due to a faulty connection with the onboard camera or a hardware failure in the camera module.
Could anyone kindly advise on how to fix the issue such as any recommended steps to verify internal camera connections safely? And any additional diagnostic tools or logs we can check to further isolate the problem?
Any help in resolving this would be greatly appreciated. I am happy to provide system logs or run any additional commands you suggest.
Could you specify what you mean by not being able to access the cameras in the first place? Is the sdk-server running and if yes are you able to connect to Reachy with its SDK using reachy = ReachySDK() but cannot get a frame with the SDK?
From what I can see there is a typo when you typed ls /de/video* (a v is missing). Can you confirm that you don’t have any output when you type /dev/video* aswell?
There should be 8 outputs to this command, usually from /dev/video0 to /dev/video7 (4 outputs are created per camera)
Also can you try if the commands ls /dev/left_camera and ls /dev/right_camera give you anything?
The cameras seem to be in the lsusb command, its the ones with MCS C2.
I am able to run the SDK serever, eg. I am able to move its arms about using the python SDK from a seperate computer. I can not get access to the cameras throught the SDK and when I plug Reachy into a monitor and use the Cheese (Camera application) it doesn’t show anything.
Sorry about the typo. When i run ls /dev/camera0 to 7 i get a no such file/directory response. The same thing happens when i run ls /dev/left_camera and ls /dev/right_camera
Also, you could try to stop the sdk server service with
```bash
systemctl --user stop reachy_sdk_server.service
```
and use a script available to try to get the video feed from one of the camera:
python3 ~/reachy_ws/src/reachy_2023/camera_controllers/examples/view_cam.py left opencv
You can get more info directly in the documentation, in this section.
To be honest, I don’t think this last command won’t work right now because you can’t see the /dev/video* outputs but I am giving you this info just in case or at least it might be useful for later.
Ok, so the message tev: ddsi_udp_conn_write to udp … failed with retcode -1 usually means that there was a network error during usage. ROS’ DDS does not like network events such as changing wifi, losing wifi or ethernet connection.
When this happens, it is needed to restart the service, either in cli with systemctl --user restart reachy_sdk_server.service or by using the dashboard which should be running on the robot.
What is your network setup for the robot? Is it connected with ethernet, wifi, both? Is it on an academic network? Some users had issue with robot connected to faculty network due to firewalls or other safety added to the network.
The set up in those photos were on an acedemic wifi so i could access this forum and copy commands over. Usually it is connected to a wifi pineapple MARK VII router. When connected to to the pinapple router i haven’t had any issues with connectivity with moving arms/base, etc. The cameras arent accessible thru the network or when i am directly on the robot via a monitor/HDMI set up
