I saw wigglegrams a long time ago. I had planned on building a lens for my dslr but pivoted when I remembered I have a handful of ESP32-CAM modules.
The initial plan of action was:
- Have one esp32-cam module be the controller
- Have one-n additional esp32-cam modules be triggered by the controller
- Each module would, when triggered, take an image and save it to the sd card
- Images would then be brought onto a computer for editing and later scripted to produce the results
The first challenge I faced when developing the prototype was having one controller (the 'dom') signal the other controllers (the 'subs') to all take pictures simultaneously.
My first attempt was to use the Wire. After writing up some code and preparing two modules I set out to test it. I hastily wired everything up with prototype wires and powered it on. The dom proceeded to take two images and then the camera became non-responsive. Looking at the camera config I saw that the framebuffer was set to two. Setting it to 5 allowed me to take 5 images before failing. I thought that this must be a bug in the library as the sample code had the module going to sleep after taking an image.
I set out to produce a minimal example before going to submit a bug when it just started working. Clearly I had something in my code that was interfering with the camera. After going from function to function I finally discovered that the onewire interface was on a pin used by the camera module itself. Fail on me for not reading.
Second, Third, Fourth? Failure
After my frustrations with not reading I set out to re-implement the communications with a different pin. Problem was that the Wire library doesn't support bitbang mode. I found a library that would solve all my problems but then ran into camera failures again. Doh, a bunch of other pins are also used.
Eventually I actually read (and comprehended!) the docs and used a couple of pins that were not tied to the camera. Got the dom taking images, got communications to a single sub working and taking images, now just need to save them. Fail. The other pins I chose were tied to the SD card. After a moment away from the project I figured out that I had been adding extra complexity the whole time. There is already an open channel to communicate and I had been using it the whole time ... for debugging.
I once again rewrote the communications to use the onboard serial ports. Since it is unidirectional the dom's TX pin is connected to all of the sub's RX pins. The sub will read from the Serial until it gets a \r or \n character. At that point the message is "processed". If the message doesn't start with a þ then it is ignored. This will allow me to keep debugging while only attached to a sub module.
The code evolved and a few new features were added and finally I was ready to test "something". Using a proto board I connected all the power pins and all of the communication pins. I added in a UBEC from my RC parts box to provide power from a lipo and things started to come to life ... just not everything.
I quickly found out that my old tired proto board was not up for the job of keeping the pins in constant contact and any sort of movement would cause one or more of the modules to loose power or loose connection. Wanting to just get a proof of concept I played twister with my fingers holding pins at various angles to get everything to fire once and finally ... success but a disappointing one.
In the next post I will go over the issues with this setup and how I resolved them.