I've been mulling over ditching the endoscope for a more mainstream camera module.

The S/N ratio sucks, the quality sucks, and I have no control over exposure on the one I have.  The exposure is a big deal as when I switch from bottom to top vision, the brightness changes which causes a delay until it adjusts... every time.  It also has started to intermittently fail, like the imaging portion is losing bits.  This is probably due to the sheer number of times I've had to mess with it as the USB cable also had an issue at the attachment point.

So I've been researching replacement cameras.  The statistics for the other USB endoscope cameras have been really hard to pull together and determining if any of them supported control over exposure has been... impossible.  I think I'm going to go with a more mainstream camera.

I've settled on either the Raspberry Pi mini camera version 1.3, or the ELP super mini 720P 45 degree version.  Both would fit my current design with some modifications..

The ELP has a little larger footprint at 26mm square, and the camera is centered on it, which would cause an issue with my current layout as the mirror arm linkage passes through that space.  However it would plug right in where my endoscope was going into the current plans of using the BBG as my platform.

The other plan using the Pi mini camera is a radical departure from 'the plan'.

Obviously this requires me to move my vision processing to a Raspberry Pi.  However, the Pi would actually be faster at vision, and the entire image pipeline is much faster as well since it doesn't have to traverse the USB bus.  But the Pi can't do step generation with hardware real-time accuracy like the BBG can using the PRU on Machinekit so I lose the ability to have a single board solution.  I'm also partial to kinematics other than cartesian for which there wasn't really a good inexpensive solution, until recently.

Through the use of klipper and a couple cheap arduinos I get the best of both worlds, mostly.  The arduinos (yes, you can use more than one synchronized) handle the hard real-time stuff and are just passed a queue of things to do, whereas the motion planning and actual interpretation of gcode happens in python on the Pi.  That is a step up from the old way of trying to squeeze the motion onto an 8 bit AVR with varying levels of compromise required.

The downsides of switching to klipper:

• No S-curve motion planning, just trapezoidal.
• I would need to write the kinematics module I need from scratch, but at least I could do it in Python.
• There is an inherent delay from when you issue a command to when it executes due to the queuing which needs to happen on the arduinos.
• It's brand new and still experimental, whereas Machinekit has been rock solid and I've used it for... years.
• Hardware changes, as my current solution uses a custom cape plugged into a BBG.

The upside:

• I could use a standard, cheap, RAMPS board and get basically the performance of a Smoothie board.
• Faster vision with a better, widely tested, and well documented camera checking all the boxes.
• More cores on the Pi, for less contention for when vision starts to suck down the processor.
• Possibly hardware accelerated OpenCV performance via the GPU?

I'm mulling it over.  

If you made it this far, feel free to weigh in.