Thank you all for the great feedback, many great ideas have been floated. My first sense it that we need to clarify the distinction between the PFC2.0+ and the PFC-MVP. While they are pursuing a similar end objective, designing a few hundred dollar device oriented toward consumer and a few thousand dollar device oriented toward research have different constraints.
I don’t want to dig in too much to the PFC-MVP right now but it makes sense for cost constrained device to use a lower-cost processing unit. Something like the Particle Photon could work quite well. I have used it in past projects and it is a really nice device to develop on. Flashing over the air is magical and having a backend solution within minutes of development time is a huge win for a lot of cases. I do see concerns with image acquisition however there are solutions previously mentioned. Counter to that, the ESP32 could achieve a lot of the same features with a bit more development work. But the selection of the processor for the MVP should move to a different thread.
As far as the PFC2.0+, having a processor that runs linux is a huge win. Being able to connect to usb devices, run multiple event loops, and have an operating system raises the ceiling of the device quite a bit. I can easily imagine a future where we connect a low cost usb spectrometer to the bot that feeds a lot of data to the system that would overwhelm a microcontroller. For this reason, a processor that runs linux for the PFC2.0+ is a requirement.
The next major concern is for the timing critical processes. @wsnook makes a great point that “it’s questionable to rely on linux kernel modules to do a good job of high speed GPIO. Offloading the timing-critical stuff to dedicated processors can be more reliable as long as the firmware is written carefully” While most of the processes in our system right now are not timing critical, reliably actuating the doser pumps need to acurate to a few milleseconds (real-ish time). I would be curious to see what timing accuracies we could get from a raspi alone.
However, looking forward, as we pursue the research line of the device, it is likely more timing sensitive modules will be added. This leads to searching for a system with both linux and real time processing abilities. This can be solved either with a single board computer (like a raspi) plus a microcontroller (like arduino or photon) or by a single board computer with a programmable real time unit (like beaglebone). Using one board instead of two seems simpler to me. Also using the beaglebone removes the file system corruption concerns.
Other factors that are also important consider are the communities surrounding the device. Raspi has the largest however Beaglebone also has a thriving one. Another point for the beaglebone is that the board files are open source so moving to a single integrated board (instead of board + shield) is possible.
For these reasons, the beaglebone black wireless seems like an optimal solution for the reasearch line of the PFC.