A thinly veiled excuse to spend more time with my father, and a chance to feed the cats.
Objective
The cat sitter must be able to feed our cats dry food whilst we are away for up to a week without requiring any attendance.
Goals
The following are key deliverables
- The food must be kept in an airtight container prior to being served.
- The food must be divided evenly between two bowls.
- Feedings should take place twice a day, at half past six.
- Feeder must be feline tamperproof.
- It must be cheaper and more extensible than simply purchasing a commercial solution.
The following are preferred but not mandatory deliverables:
- It should be possible to remotely determine whether a feed has happened.
- The feeder should support âon demandâ feeds.
- Portion size should be controllable.
- Ideally, purchase costs are less than ÂŁ70 (as commercial units seem to start at double this).
Approach
I broke the cat sitter down into three main components:
Manipulating things in the real world:
In order to dispense food reliably, I initially considered an archimedes screw and a rotating drum. I could not find a way to make the archimedes screw airtight (neither could I see a way to source one economically, or make one with sufficient accuracy). The rotating drum idea held some merit. An aperture would allow food to fall from the drum into a chute when slot and hopper are aligned. By rotating the drum, servings are dispensed and the food is agitated to avoid clogging. Initial experiments made from coffee tins showed that it was hard to control portion size accurately, and I began to look for alternate solutions.
I settled upon a manually operated cereal / pasta dispenser, available from Ebay for around ÂŁ12, as this would give me affordable and proven mechanisms for measuring, dispensing and storing food in a tamperproof container. I opted for the double, as it meant I gained a sacrificial unit to learn on.
On delivery, the design proved quite simple. A rubber butterfly valve rotates and serves 1 ounce of dry food per 60 degrees. Tests with dry cereal (less pungent, but otherwise a good stand in for cat food) revealed that I would need a lot of torque to drive the handle if the food became stuck, or that I would need to find a way to agitate the food in the hopper, and back off the motor if significant load or reduced RPMs were detected.
Rather than try to design a mechanism to measure the load / spin rate of the shaft to detect jams, I looked to see if a brute force solution was available. The obstacle of high torque at low RPM was easily overcome once I realised the phrase I should be searching for was âgear motorâ. There are multiple models available on eBay and Amazon, and I settled for a 12V 5RPM 31kg.cm gear motor for another ÂŁ12.50.
For the prototype stage, I coupled the 6mm shaft of the gear motor to the 8mm shaft of the dispenser with with the creatively crushed body of an old metal pen. I ran another cereal test with the motor aligned by hand and powered by a 12V car battery. It rapidly demonstrated sufficient torques to solve any jams, in much the same way that a sledgehammer can solve most problems with walnuts.
Connectivity and control
I suspected an Arduino would be the ideal platform to control my motor, as I already had some experience with the hardware. The initial purchase list was based on the following, which I hoped would let me access NTP servers to schedule the servings, drive the motor, and post the result to the web.
Proposed parts list:
Total ÂŁ54.50
I soon realised that with almost half of my ÂŁ60 budget already gone on real world interfaces, I would have to find a cheaper way to control it all if I was going to keep to budget. I considered simply using a standard household timer socket to switch on the Arduino twice a day, and have a simple sketch drive the motor for 2 seconds, then stop. The saving didnât really justify losing the ability to send and receive feed activity from the web, and I looked for a cheaper way to secure the WiFi feature.
As with âgear motorâ the key phrase here was 8266. Now knowing what I was searching for, I found myriad affordable 8266 modules which seemed to promise what I wanted. Unfortunately they also seemed to throw up many dependencies, such as 3.3V power requirements, FTDI cables, python libraries, arcane IDEs, and I began to think I would most likely end up bricking whatever I ordered.
Fortunately, my google fu eventually located the Adafruit Feather HUZZAH with ESP8266 WiFi (https://shop.pimoroni.com/products/adafruit-feather-huzzah-with-esp8266-wifi), which seemed to be the equivalent of a small form factor Arduino, with the ESP8266 functionality built in. Costing about the same as the plain Arduino board, programmable using the Arduino IDE and using a standard USB A / USB micro B cable (to fit most eReaders, smartphones, cameras, etc) for power and data this was an easy win.
With the change in form factor and voltage (the Feather runs 3.3V logic rather than the Unoâs 5) the motor shield was also out, so I looked for components that might do this on the breadboard. I soon came across MOSFETs, which proved to be far more affordable and flexible solution. My parts list now looked like this:
Total ÂŁ18
This left me with about ÂŁ20 for any remaining parts, which I quickly used up by buying a proper CNC shaft connector, a 37mm DC geared motor mounting bracket, a dual power supply capable of servicing the 12V motor and the feather (which will happily run on 5V from the USB connector) and a bag of bits to help me connect up the MOSFET.
Logic
I built the sketch up in stages, starting with a simple timer that turned the onboard LED on for 2 seconds, every 12 hours. Using the LED as a stand-in for the motor circuit meant I could prototype on the move, and I spent a couple of days with the feather hanging from my USB port whilst I got on with other things.
The resulting conversations brought me to adafruit.io and IFTTT.com, and once I realised I could interface them to each other I soon had a smart phone controllable button capable of requesting a feed, and confirming the result via email.
The full code will be supplied at the end of the build, however the following learnings are shared here:
- Break it down into functions, so that each bit of code is responsible for its own task. This will make testing and maintenance lot easier in the long run.
- Use structs to organise variables into a coherent collection. I fell into the lazy habit of declaring global variables and updating them from multiple points in the script. Its fine for prototyping, but isnât really a good way to go about things.
- Regardless of the sample sketches youâll see for the HUZZAH, donât ping the MQTT feed repeatedly, as the resulting traffic will talk straight over your subscribed messages. This one tricked me for a while, as I copy/pasted sample code from adafruit, and was despondent when I found subscriptions were unreliable.
- The blue LED on the HUZZAH is turned ON by sending digitalWrite(2, LOW) and OFF with HIGH. I donât know why its reversed, but its a great way to trip yourself up if youâre using the LED to debug.
- The millis() function drifts, so checking back into the web for the time is advisable.
Donât put the MOSFET driver on pin 16. Pin 16 goes high whenever you start uploading new code. If your idea of debugging is cleaning up cat food, its fine.
- Be advised that the ârequest a header from googleâ technique can return junk, and if it does, you may well end up with a negative interval for the next time check. Debugging spotted the discrepancy, and I put failsafes around the expected boundaries.
Assembly
With no money left for parts, I had to build the CatSitter into objects I already owned. An IKEA step stool (BEKVĂM, originally ÂŁ13, but doing good service in my kitchen for years now) provided a handy scaffold for the assembly, and I was able to hold the dispenser in place using pine strip wood framing.
Feline protection was secured using the discarded perspex from a recently broken IKEA picture frame (MOSSEBO) and the backing board was employed as a floor pan.
Fitting was largely a case of making paper templates and then tracing them onto the sheet material, or cutting everything slightly large with a handsaw, then fine tuning with a dremel.
Although all of the electronics performed perfectly, the first design failed to dispense food correctly, as the ramp angle was too shallow. Having the chute dispense to the rear meant I could secure a steeper angle, which was far easier than the other two possibilities (extend the legs / move to a planet with a greater gravitational force).
Whilst the circuit is reassuringly simple, I did find a few potential gotchas in construction, all around the MOSFET.
-
If you donât want to kill the MOSFET, you need to hide it behind a diode to prevent motor blowback. It turns out that electricity isnât quite as orderly as code, and that when you stop powering anything with a coil (relay, solenoid, motor, etc) youâll open the chance to find a considerable reverse voltage spiking back up the wire. Its been and gone within a few microseconds, but it if reaches your MOSFET so has that. The diode you want to use will be fast enough to react to the flood, and beefy enough to stop it. The right diodes are in the order of pennies rather than pounds, and I opted for a Schottky 100V 5A 2Pin DO201AD. At ÂŁ4 for ten, these are probably overkill, and when they arrived I realised they were too heavy duty to fit into the breadboard. Still, a little soldering and Iâm sorted, and I can easily use the rest in other projects.
-
The MOSFET might heat up. I tried to understand the figures, but all I came away with is the impression that MOSFETs like being closed, and like being open, but the time they spend ramping between closed and open is extremely stressful to them. They express this worry as heat, and if you donât provide a big enough kick to open them assertively (gate voltage, I believe its called) they will spiral into an overheated pit of self doubt. As âthe threshold voltage has a negative temperature coefficientâ the hotter it gets, the more assertively you have to kick. Thermal runaway sounds like a worry to my ears, so I went out to find a heat sink that would be likely to cope with the worst scenario I could imagine. Again, this is very probably overkill. My motor pulls 50mA on a MOSFET thatâs rated for 30A, uses 12 of the rated 60 volts, and is generally on for less than 4 seconds every 12 hours, yet Iâve ended up with a heatsink thatâs about 5cm across.
-
Minor rant: The heatsinks are sold to fit the various bodies (my MOSFETs are a TO220 package) and seem to allow âthrough holeâ and "clip mountâ. But it turns out the âthrough holeâ is regards the link to the PCB, and not anything to do with the component Iâm trying to cool, which has a bloody great hole through it for the heatsink mount. Apparently, things affixing to that hole are called called âscrewâ mount, despite being fastened by a bolt(!) Iâd disregarded clip mounts up until then, as they sounded like a quick and dirty temporary fix against the solid assured contact of a bolt. However, not having the inclination to drill my own hole in what turned out to be a clip only mount, I just sucked up the postage delay and back ordered the clip to match. The good news was that the delivery lag gave me plenty of time to find information suggesting that clips were the preferred method of mounting anyway, giving a more even contact point and better thermal conductivity than a bolt. The bad news was that I also realised Iâd need some sort of electrically insulating heat conducting compound to add between the metal back of the MOSFET and the heatsink. I found some Bergquist BG401580 SIL-pads in a ten pack that were cheap, cheerful and clean.
You can save yourself a lot of delay (and postage fees) by buying the clip, pad and heatsink at the same time. More so, if you understand the calculations required and source a single package like this (https://shop.pimoroni.com/products/to-220-clip-on-heatsink) which is likely as not more than up to it.
On the mechanical side, the main issue was in working out how a seller might describe what I later learned was called a âshaft connectorâ. Alignment worries around the motor and shaft were alleviated by the flex it affords, and I had plenty of âeyeâ time whist assembling to make sure everything was as close as possible before screwing it in place. In retrospect, Iâd have maintained alignment better if Iâd first glued the struts into position, using screws to fix it after it had already been positioned, but a combination of luck and wedges made from offcuts brought it all into alignment eventually.
Some photos of the interim build undergoing testing.
Holding the hopper in place via dremel cut recesses in the framing.
checking ramp angles and splitter.
waiting for the glue on the final splitter to dry
The final ramp and splitter in situ.
waiting for the cats.
boxed in, with the breadboards and a scavenged USB cable.
Some videos:
Steeper ramp, better code.
Real world test.
1 Like
