Have had issues with the new low-light camera disconnecting during the middle of dives recently. In the past when this has happened I’ve been able to solve by restarting the companion computer, but this time when i tried to reboot the pi became unresponsive through the web gui (but was still working in QGround control), and i had to ssh into it in order to restart. Once restarted. the CPU status read “Arm frequency capped has occurred”.
The pi runs several programs independently, so the webserver can crash while the telemetry stream or camera stream continues. A log of the webserver that crashed can be found at /home/pi/.webui.log.
Have you made any modifications to the filesystem or programs on the Pi?
Do you still see frequency capped after you reboot again?
How are you powering the pi; what does your wiring look like?
Have had a dig through the log you described and couldn’t find any red flags there - but maybe I was looking for the wrong thing. I’ve uploaded it here, last crash was on 2018-01-17 webui.txt (610.0 KB)
Haven’t changed any part of the raspberry pi software apart from adding another broadcast stream for mavlink - though have been doing this for ~6 months on both our Blue ROVs with no problems.
All of the internal wiring is exactly the same as on the assembly instructions from the Blue Rov website (am using the standard 5V 3A BEC provided with the electronics kit, so i don’t think it’s a voltage issue?). Since i’m pretty sure its not a low-voltage thing, the only thing i can think of why the frequency may have been capped is a heat thing?
Also worth noting that this problem with the Low Light Nav Cam hasn’t been happening on our other ROV
It looks like the camera may be disconnecting/coming unplugged. This can be seen in the log: CAMERA ERROR [VIDIOC_G_CTRL] 19 No such device
It also looks like the camera is still connecting at boot, is this correct, do you see the image at all any more? Can you try this:
If the camera is connected, then when you enter ls /dev/video*, you should have two results, /dev/video0 and /dev/video1. If the camera is disconnected, you should see no output.
Can you try this when you get in the state where the camera has stopped? It looks like the web server is not handling this gracefully, and the web server also crashes when it can’t find the camera. This could all be caused by a loose cable, so you could perhaps force it to happen by poking/wiggling the cable near the connectors. If re-seating the cable connections fixes it, great. If not, we can send you a replacement.
I managed to recreate the error again twice, go through the steps you outlined, with both times having the same result. Interestingly, the wiggling of the camera only resulted in a disconnect after the camera had been running for about 10mins. Once it started to disconnect due to wiggling it, any little bump would result in a disconnect. Taking a temprature reading of the camera, it was running at 62°C - see screen shot.
Results: ls /dev/video* would result in /dev/video0 and /dev/video2, as opposed to /dev/video0 and /dev/video1
All of this can be found in screenshots here and in the log webui.txt (576.5 KB)
Ok, if you continue to have trouble with the camera, send an email to support@bluerobotics.com for a replacement. I’m not sure about the frequency cap, I haven’t seen that one yet at my climate controlled desk, so heat is a good theory.