• First successful test of wiring and software

    Bradley Austin Davis • 02/23/2022 at 00:22 • 0 comments

    I've had my first successful test of the feeder Web interface.  After powering on the below contraption, I'm able to both capture still images from the camera and issue a web request that triggers the rotation of the motor by a set number of scoops.

    Most of the web code is cribbed together from the ESP32 CameraWebServer example and the UPnP SimpleServerESP32 example, but the motor control and switch sensor code for actually operating the feeder are completely from scratch.

    I've completely disconnected the battery compartment and added a buck converter to step down from 12v to 5v, since I have both a ridiculous number of 12v power adapters and quite a few buck converters laying around.  Now I just have to re-assemble this into a functional piece of hardware.  

  • Rethinking the IoT setup

    Bradley Austin Davis • 02/18/2022 at 20:21 • 0 comments

    Having done the debugging of the ESP32-CAM board and decided to use image processing in this, I realized that I don't want to be constantly sending images off to AWS.  It would be much more cost effective for me to have the cameras register themselves with a service running on my local network (likely on my FreeNAS fileserver) that could do image processing, change detection, etc, and could manage all of the feeders itself, while acting as a single IoT device from the perspective of AWS.

    This will make it much to have the devices all programmed with the exact same image, and differentiate themselves to the hub server via MAC address.  I can then have hub able to do things like watch for changes in the camera stream, automatically capture images based on certain criteria, etc.

    The only tricky bit is my connectivity.  My ISP router provides my NAT, giving my local network a 192.168.0.0/24 address space.  However, the router's positioning and WiFi support aren't good enough for my house, so I use a set of Google WiFi routers to cover the whole house.  However, they're not running in peering mode, but rather using an HPNA backbone.  In this mode, as far as I can tell, there's no way to avoid the Google WiFi creating a second NAT layer.  So it creates its own network of 192.168.86.0/24.  The practical upshot is that while my WiFi devices can connect to each other and to the LAN devices, the reverse isn't true... the LAN devices can't connect to the WiFi devices.  

    This means if the pet feeders are on the WiFi and connecting to the NAS box on the LAN for functionality, they'll have to get requests via either a continuous connection they initiate or some kind of polling mechanism.  

    But, I'm sure there's probably lots of example code out there for me to find.  Now I just need to go get it.  

  • Adding camera functionality

    Bradley Austin Davis • 02/18/2022 at 19:37 • 0 comments

    I'd previously thought that to support any kind of camera functionality I'd need at least a Raspberry Pi level board, but I recently discovered the ESP32-CAM boards which support connecting a camera.  However, they're less developer friendly than the ESP32 development boards I've been using and don't include a built-in USB connection for programming.  So although I received a couple from Amazon yesterday, I couldn't use them until I got an FTDI programmer to bridge that gap.  Fortunately that arrived this morning and I've spent the better part of the time since it showed up trying to load up a test program (mostly following these instructions) on it that would stream the camera image over a web-stream.

    I encountered three major issues while trying to get this done.  The first was a debugging problem.  In order to program the board you need to short GPIO 0 to GND.  The guide suggested that you should power down the board before removing that connection.  However, it looks like the Arduino IDE Serial Monitor doesn't really like the COM port being listened to to vanish and re-appear.  I finally figured out I could get it to start listening again by switching the baud to another value and back again (I'm using 115,200 baud normally).  So in order to test out any change to the program the steps were

    • Disconnect the USB port
    • Short GPIO 0 to GND
    • Reconnect he USB port
    • Tell the Arduino IDE to upload
    • Disconnect the USB port
    • Remove the short
    • Reconnect the USB port
    • Toggle the speed on the serial monitor
    • Hit the reset button on the board

    Which is a far cry from the developer board experience of "Press upload".  Regardless once I figured out the process I was able to get debug output, which led me to my second problem.

    The linked guide above says

    I have found the 3.3-volt set up to be more reliable, which is why I am recommending it.

    However, once I started getting debug output, I saw that when I powered the board in this way, I got a looping "Brownout detector was triggered" message from the board.  Reading up on the FT232RL board I found some sources that suggested that you could draw up to 500 mA in 5v mode, but only 50 mA in 3.3v mode.  So I switched the voltage mode on the programmer and swapped to the 5v input pin on the ESP32-CAM board (as well as wiring the ground to the GND pin right next to the 5v pin) and suddenly the board was booting and trying to connect to Wifi.

     Here's where I ran into my third problem: the antenna connection

    If you look at this image you'll see the built-in antenna running on the bottom of the board, and a pigtail connector on the left side.  Finally there's a small boomerang area where a 0 Ohm resistor is put into one of two positions to enable either the internal antenna or the pigtail connector.  I have 3 boards and two of them have the internal connector enabled, while the third has the pigtail enabled.  In the case of the pigtail connector being enabled, if there's no actual external antenna connected, then while the board can "hear" my main WiFi access point, it can't transmit loud enough to maintain a connection.  I figured this out when I saw the connection state cycling between WL_DISCONNECTED and WL_CONNECTION_LOST, and examined the pigtail connector resistor.  I just count myself lucky that the guide I was using talked about how to work with an external antenna or I would never have thought to check this. 

    Once I switched to one of the other boards that was wired to use the built-in antenna, it connected to my network just fine and I was able to see the web server and stream the camera image in a browser.  This proof of concept gives me enough to ensure I can use these chips in the feeders and extend the functionality to include monitoring the bowls to ensure they're getting food and not jammed.  On the one hand I could also see who's eating what, but now that I think about it, it would probably be easier...

    Read more »

  • The failure cause

    Bradley Austin Davis • 02/18/2022 at 01:42 • 0 comments

    I forgot to mention in the previous log.  When disassembling them the fault was apparent almost immediately.10 years in storage had caused the drive bands to lose elasticity and become brittle.  They snapped on each of the 3 feeders the very first time they tried to dispense food. 

  • The story so far...

    Bradley Austin Davis • 02/17/2022 at 21:12 • 0 comments

    As soon as I opened up the device I saw that this would be a relatively simple problem to solve.  The core functionality of the device is a motor that is connected via a drive band to some gears that turn the feeder mechanism and also open and close a simple switch, which provides logical feedback into how many scoops have been delivered.  

    I only really had to worry about 4 wires... the two leads coming from the DC motor and the two leads coming from the sensor switch.  I spent a bit of time soldering new wires to the leads with pin ends so I could plug them into a prototyping breadboard and mess around with them.

    I encountered some issues because I'm an electronics novice.  It took me a while to figure out that I was getting noise on the sensor GPIO input on the board because I needed a pull-down resistor to keep the pin from floating when the switch wasn't closed.  I also didn't really understand that you can't drive DC motors directly from logic pins and managed to partially fry the first ESP32 I was using.

    The motor issue was frustrating because although I had quite a few stepper motor driver boards and a few servo driver boards, I didn't have anything for a single simple 2-wire DC motor.  I had to order those and they didn't arrive until today.  However, until now I've been settling for having the "enableMotor" function in my code turn on the built-in LED on the board and manually pressing the switch to simulate turns of the gear.  So I spent the time since starting and today working on getting the board to work with the AWS IoT services.  

    The ultimate goal is to be able to say "Alexa, feed <PetName> 2 scoops" or "Alexa, feed <PetName> 3 scoops every day at 8 am" and have the correct one of the 3 devices spin the motor to deliver the correct amount of food at the correct time.

    This morning for the first time I was able to actually wire everything together.  The motor is being driven by the 3 C batteries in the base on the right side.

    I haven't yet wired it up to Alexa, but the device has it's own identity on my AWS account and after boot I can both send and receive messages from the AWS MQTT console.  Sending a message with a scoop count caused the device to turn the desired number of times.

    Unfortunately my current approach requires that I create an explicit device in the AWS for each of the feeders and build a custom binary for each of them so that they would have individual certs and private keys.  Ideally I'd rather just have a single binary and have AWS automatically differentiate them based on something like the MAC address of the WiFi chip in them.  So I'm researching the AWS IoT functionality to see if that's possible and how to do it.

    Additionally I've ordered some other ESP32 boards that come with cameras to see if I could set up remote monitoring functionality.  But getting closer to a working prototype.