Testing a DEPSTECH Endoscope Camera (1944P) with Octoprint (and a Raspberry Pi 4)

I recently received a DEPSTECH Endoscope Camera 1944P which I had ordered from AliExpress several weeks ago.  I want to disassemble the camera, and see if it can be better integrated as a nozzle camera for my printer.  But before I start hacking away, I thought I should get a baseline to see if and how it works.  It seems to be a mixed bag so far though, the camera seems to cut out at the slightest movement and I have had the screen blank out multiple times (edit: see updates below, this seems to be an issue with the Pi).  That sucks because the image quality is pretty good, and I could see this being a good candidate for a nozzle camera.  I'm still testing it though, and will have to try it on another device to make sure the issues are related to the Pi.

But here is a bit of how I set it up and some pics of it in action.  Pardon the upside down shots of the nozzle, I did not mount it, just had it sitting next to the nozzle and the point was just to check the resolution and image quality.

To set up the cam, you can refer to this post, which goes into more depth on multicam setup, but in a nutshell:

1.  First connect the camera to the USB port where it will be plugged in and boot the Pi.  If you already have a camera configured, check out the multicam setup info from the Octoprint docs, or my prior post linked above.

2.  I already had a file named webcam2.txt set up (which is required for multicam) and it lives here:

/boot/octopi.conf.d/webcam2.txt

3.  I ran "ls  /dev/v4l/by-id/" to first get the long name (what I would call it) for the endoscope camera, which is:

​ "/dev/v4l/by-id/usb-Generic_ICT_Camera_200901010001-video-index0":

      4.  Next I checked to see what formats are supported by the camera, I tried 1080P at 30fps and 1944P at 25fps to test with "v4l2-ctl --list-formats-ext":

Now I had the info to update the /boot/octopi.conf.d/webcam2.txt which again is for the 2nd camera (multicam) and a file I had to previously create.  I just commented out the config for my other endoscope camera (by placing a "#" before the line to ignore), and set up the new one on the next line down (circled in green in the pic below).  I first tried 1080P at 30fps:

And then I tested it using 1944P at 25fps by re-editing the same file (/boot/octopi.conf.d/webcam2.txt).  Should also note that in order for the changes to take effect first the file must be saved and after that the webcamd service needs to be restarted, or the Pi can be rebooted.  For some reason restarting the service seemed to hang on my Pi so I rebooted it, and this again could be part of my problems with stability.  I will probably try a fresh image and rebuild things when I get some free time.

The image quality is pretty decent and the autofocus seems to work.  The test image is not the best composition, but again this is a quick test and I already have some issues with stability I need to look into further.  The Pi's CPU seems to be running OK and the temp is around 41.8°C which I "think" is normal.  The image however seems to lock up (see below pic), and I have to restart the stream to get it back, which could be either the Pi or the camera.  I also noticed that when I was working on the camera to position it, the stream would drop more frequently.  It is also very likely though that the issue is related to power, so I will also need to try a more robust power supply (my Pi complains of undervoltage but the reasons why I have not fixed that in the Pi's normal location is another story).

So the endoscope does what it says and the image quality seems good.  The issues with it locking up again may be my Pi or related to power, so I need to test further.  However I did not have issues though with my current cameras (two actually), and for testing this, I was only running the new Depstech endoscope camera.  I hope I can resolve this and will update what I find.  (Edit, I suspect the Pi is the issue, see the last update below).

UPDATE 9/17/2022: I still need to test this camera on another device to see if the cut outs are due to the camera or the host it was connected to.  However last night I ordered this camera, which I think could be used as a nozzle camera, and it has some benefits over the endoscope types of cameras for mounting and cooling.  The problem however may be (edit) the focal length, but it may be that a small lens could be used to get a close view so I am also gonna order some cheap lenses to test it with.  If it works I will post some updated designs and may try to work the camera into the stealthburner (that is the ultimate goal at least), but I will first try it out on the CR10S Pro.  

UPDATE 10/7/2022: I did not test the endoscope camera on another device, but I have since experienced this same issue with another camera on the Pi, so I suspect the issue is with the Pi.  I found this post on the Octoprint Community Forum and it looks like something I should try.  I will test it again if the issue can be resolved on the Pi. 

UPDATED 10/8/2022: Well this is strange, but I have been testing the other camera I have (OV5640), which has also been locking up.  I tried changing "type=forking" to "type=simple" but that had the effect of causing webcamd to reset every few seconds.  I then found this post by Foosel (Octoprint creator) and it says that the type should be "simple", however (again) with "simple" webcamd restarts constantly.  So the behavior I am seeing appears to be opposite what was reported in the linked thread (simple causes webcamd to restart constantly and forked seems to be stable, but locks up).  I may end up re-imaging the pi with the latest version (I am running 1.8.4 currently on this pi).  In any case, the issues with the locking up on the cameras seems to be related to the Pi/Octoprint and not something wrong with the cameras.