Internet-Enabled Cat Feeder... Powered by Cisco!

Page last modified Monday, 15-Feb-2010 21:28:21 GMT

Internet-Enabled Cat Feeder

Our two cats, Frankie and Elmo, are no strangers to technology; they've even got their own keyless-entry system in the form of a microchip-enabled catflap. So, when it came to solving the problem of how to feed them whilst we're away for short periods (e.g. overnight or weekends away) without having to bother the neighbours (not that they mind) I was sure there'd be something out there to do the job.

Surprisingly; there wasn't. Or at least there was nothing that satisfied what I considered to be important, if not essential, requirements. These included i) being suitable for two cats i.e. not forcing them to use the same bowl (or having the potential expense of buying two of the same product), ii) delivering food at the right time and quantity (this includes stopping them from helping themselves!), iii) being suitable for two meals a day for perhaps 2/3 days at a time, and iv) providing some form of feedback loop (ideally remotely-accessible video) as the last thing I wanted to come back to is two starving cats because something has failed - we want to know immediately if something's gone wrong so we can at least then get one of the neighbours to call round!

Nearly all the products on the market seemed to receive mixed reviews - most didn't seem particularly cat-proof (this video shows the persistance of one cat succeeding in helping himself by advancing the timer on an analogue-clock based feeder!), and others were limited in how much food (and time) they could cater for. The closest product to seemingly tick all the boxes was something like the Smarthome Remote Pet Feeder which, at $298 (I could only find it in the US), was also a tad pricey!

So, I set about designing and building my own. I wanted to keep costs down without sacrificing performance or flexibility, ideally by using whatever I had already had to hand. Of course it had to work well, perfectly in fact, and be ultra-reliable too - at the end of the day it was important to me to not lose sight of the fact that we're talking about animal welfare here so it was far more than just a 'geeky' hacking project.

There was no real requirement for controlling the provision of water as both our cats rarely, if ever, drink from their bowl preferring instead to sort themselves out from the watering cans in the garden, puddles etc. We do leave a bowl out for good measure and have noticed that occasionally they will drink from it if it is left to stand for a couple of days. This seems to be fairly common - perhaps due to the chlorine (and evaporation thereof) in the tap water. Similarly, there was no concern for litter trays either - our cats are of the, how should I put it, "al fresco" persuasion - I do hope the neighbours aren't reading this as they probably don't need reminding that cats don't tend to use their own back garden either! ;-)

Moving swiftly on; here's a video of how it all turned out...

Visit this video's page on YouTube

The mechanics of the design are best covered by breaking it down into its constituent parts, i.e. food delivery, network interfacing/connectivity, and control software...

Food Delivery

This bit was arguably the hardest, or at least the most difficult to turn theory in practice! I went through loads of ideas which seemed good on paper but really were asking for trouble in the real world. The biggest problem was the mechanical handling of the (thankfully dry!) food as Sod's Law mandates that any form of metered-delivery will provide plenty of opportunities for food to get caught and jam. Rather than completely reinvent the wheel I settled on making use of a simple cereal dispenser - this was designed to reliably deliver dry foods at the turn of a wheel and made allowances for food getting caught by incorporating flexible rubber vanes on the delivery 'paddle'. It was also easy to fill and, if more capacity was required, could easily be extended by adding an additional tube (or upturned bottle) to the top. It seemed to do a fairly good job of keeping the food fresh too thanks to its lid and reasonably-sealed flapper arrangement (having six vanes means at least two are always closing off the tube).

With the main body of the dispenser mounted on a board all I had to do was attach a motor and I'd be away...

Flapper - Left View

Dispenser

Flapper - Right View

Of course, this seemingly innocuous step threw up quite a significant hurdle... The torque required to turn the paddle could get quite high, particularly when food starts to get caught which it invariably does. I didn't measure it but it was certainly a fair old force required - I think under 'normal' arrangements with human hands you might back-off if resistance was felt and turn it the other way. For semi-automated motor operation I wanted to avoid the complication of fancy load detection and backoff mechanisms so opted instead for brute force. This required gearing, which in turn would also help avoid inadvertently making some form of catfood Gatling gun! I found a high torque gearbox motor which runs at a nice sedate 4 RPM. Even better, in exchange for this leisurely pace it gives a maximum (stall) torque of 25kg·cm - plenty of grunt for even the most awkard of cat food pellets. The motor was mounted using a Cisco rackmount bracket.

No sooner was that hurdle out of the way the next was rapidly approaching... connecting the motor and its 'I'm not stopping for anything' torque to the food dispenser in a secure fashion. The dispenser came with a 3/10ths-of-an-inch diameter D-shaped shaft (with a handwheel onit) which, whilst obviously suitable for the flapper end, was proving difficult to attach to the 6mm D-shaped shaft (and corresponding coupling) of the motor. The problem was not so much the size differential but that the coupling had to somehow not make mincemeat of the plastic at the required levels of torque. Having filed down the shaft to suit the coupling and performing a few trial runs the grub screw in the coupling failed to securely hold the plastic shaft in place. It just wasn't going to last for any reasonable length of time.

The shaft had to go, or rather be replaced with something made out of metal. The form and shape of the shaft was such that it was anything but an off-the-shelf item and so somebody suggested making a plea for help in the uk.rec.models.engineering Usenet group. A couple of kind souls - Dave Sanderson and Richard Edwards - both offered to make what I needed for me; Dave pulled the short straw and took on the task of turning and milling a shaft out of an old printer bar. Despite my best attempts at confusing the requirement with an initially-nonsensical engineering drawing (hey, I was using Word - it was never going to look spot on even if the figures were!) he came up trumps and eliminated what was threatening to become the Achilles' Heel of the whole project.

Shaft - Top View

Shaft Drawing

Shaft - Bottom View

The final stage of food delivery was a splitter i.e. something to split a single source of food into two bowls, ideally in roughly equal portions! Here I used some 0.5mm aluminium sheet which I knew would come in handy one day (admittedly I didn't think I'd be storing a dozen 4'x3' sheets of it in the loft for seven years for this though!). It was fabricated using a single continuous piece - for no other reason than to maintain mechanical sturdiness that could be lost through using fixings. Metallic Origami if you will!

Splitter - Side View

Splitter - Top View

Splitter - In Situ

With the physical food delivery mechanism sorted I now needed a method to provide remote control...

Network Interfacing/Connectivity

In order to allow user-driven operation rather than leaving things to a timer (which could lead to all sorts of problems) I opted to connect the feeder to my house network. I considered using a locally-sited PC but dropped this idea because I didn't really want a dedicated PC sat alongside it... particularly in the kitchen. Okay, I admit, it wouldn't have bothered me all that much... but my girlfriend on the other hand...

I also opted not to go for connectivity/control based around something like the Arduino platform which seems to be the pervasive convention for this sort of project. There's nothing wrong with using one, but it went against my design principle of minimising costs and, ideally, making use of what I already had.

Before this cat feeder project came charging in I was (~~and indeed still am~~ Edit 11 Feb 2010: Not any more - I've passed!) in the final stages of studying for Cisco's CCNA networking qualification and whilst sat there wondering why mutli-channel Ethernet relays cost so much (e.g. this one for £249) it dawned on me that I had all this highly-configurable Cisco kit sat around and if I could tap in to some of the port status LEDs, which I could turn on and off, then I'd have myself a multi-port network-enabled relay interface for no cost at all! (Even buying in, a 1900-series switch often goes for less than £15 on eBay). Better still, the configuration of such a device meant that I would feel less guilty about skipping my studies (admittedly that's stretching things a bit!) and provides the opportunity for a whole load of puns relating to the use of CatOS...

I pulled the cover off an old Cisco C1924 Catalyst switch (Enterprise edition hence allows command-line access) and poked around with a multimeter (don't try this at home if you don't know what you're doing!). I found that the LEDs were driven using HC595A shift registers with TTL (5v) outputs. These made ideal points from which to piggyback onto in order to provide the necessary signalling feeds to an external motor control board (details later). I could also take a +12v (1A) power feed from the built-in PSU.

HC595A Shift Registers	LED Driver Output for Port 20	LED Driver Output for Ports 21 and 22	Power Cable Soldered Underneath
Ground Obtained from Chassis Screw	Completed Wiring	Terminal Block for External Connections	RJ45 Loopback Adapters

A slight unexpected gotcha (the CCNA syllabus unfortunately, yet unsurprisingly, doesn't cover modifying switches to control motors...) was that you cannot illuminate a port status LED without something plugged into it, not on demand at least. However, I then discovered the concept of RJ45 loopback cables (basically an RJ45 plug wired such that its output goes into its input, and vice versa) so I made up a few plugs and was back on the road - these trick the port into thinking something is connected to the other end (it doesn't realise it is conversing with itself) and so you are then able to have full control over the state of the port, and hence its LED, without it stubbornly remaining in an down/error-disabled state.

I tapped into three port LEDs - ports 20 and 21 to trigger forward and reverse motor operation respectively, and port 22 to allow for an 'emergency cutout' function such that I could electrically isolate the motor should anything go wrong.

The switch required only a very basic configuration (available here) with the three 'control ports' set to shutdown mode and remote access enabled to allow the port states (and LEDs) to be toggled. Obviously the novelty of manually logging in soon wears off and so I wrote a shell script (available here) which uses the 'Expect' tool - an excellent way of automating interactive applications such as Telnet. The script simply runs through a series a pre-determined commands based on what it expects to see and hence can automatically log in, enter configuration mode, toggle the port states and log out again.

Motor Control

With the ability to control the LEDs over the network the next step was to design and build an interface board to take the low power signals from the port status LEDs and in turn switch the high(er) power required to drive the motor. I designed a relatively simple circuit (it looks more complicated than it is) using only a handful of common components (transistors, relays, LEDs etc). The relays are wired such that it is possible to control the direction of the motor (i.e. by reversing the polarity of the applied voltage) and to also include a cutout relay designed to allow me to remotely cut the power in the event of a problem (e.g. out-of-control port, latched relay etc).

Circuit Schematic

Mounted Control Board

The control board also features its own 8mm status LEDs for visual feedback - the red LED signifies power (and that the cutout hasn't activated) and the green/yellow LEDs signify forward/reverse (clockwise/anti-clockwise) feeding. I later also added a button (not shown in the photo) to allow manual (i.e. local) direct control without having to use the PC.

Software

With everything connected up the multi-purpose single-command access was now available using the control scripts from my server (e.g. 'catfeeder.exp forward 5' would feed for 5 seconds, 'catfeeder.exp cutout' would kill the power preventing any/all feeding, etc) the next logical step was to design a point-and-click web interface.

The main web interface consists of five frames (see left-hand image below). The top frame lays out a series of buttons providing timed feeds, emergency stop (resetable) and other general controls. The middle frame provides the zoomable live video streaming (details below), the bottom-left frame shows the last 10 recorded 'events' i.e. detected motion from food delivery and/or the cats eating and, finally, the bottom-right frame shows the output from the control script i.e. the transcript of the login session with the Cisco switch.

A cut-down 'lite' interface (right-hand image below) was also created providing simple controls and static (non-streaming) imaging - this is more suited for mobile access via my PDA (an HTC Touch Diamond).

Standard Web Interface

Mobile 'Lite' Version

In accordance with my design principle of attempting to reuse what I already had I followed suit with the video streaming using a Panasonic BL-C1 IP camera interfaced into my existing open-source ZoneMinder-based CCTV security/surveillance system (for a long time now we've had such a camera monitoring the catflap so we can tell whether the cats are in/out wherever we might happen to be!). In addition to provide live video streaming (or refreshable static images when using the mobile interface on low-bandwidth connections) ZoneMinder also provides automatic event recording using its motion detection capabilities. This is achieved by defining 'zones' (see below) within which to watch for movement, the configuration of which can be tweaked in order to detect the cats eating but not reacting to other changes such as moving cloud cover, lights being switched on/off, etc.

IP Camera
(It can also be mounted on the feeder itself)

Motion Detection 'Zones'

Zone Configuration

Conclusion: The Proof of the Pudding...

The modular approach to the design of the system i.e. seperate functions for the web frontend(s), video monitoring/capturing, networking and motor control allow for truly flexible operation and expansion. This also allowed me to borrow from the Unix design philosophy of designing each component to 'do one thing and do it well'.

It will be a relatively simple matter to expand the functionality if required. A fully-automatic feeding capability (fancy name for a simple cron job to control feeding in the absence of any manually-initiated feeds in the last 12 hours) has already been introduced so as not to rely entirely on Internet access although I do have out-of-band remote dial-in access available (I will document how this was done if anyone's interested as it has all sorts of users, particularly for maintenence of remote servers without relying on Internet connectivity). That said, this was only implemented for 'geek points' - if it ever got to the stage of the Internet connection being down I wouldn't hesitate to then call the neighbour in to take over - even I have to admit there's only so much you can be reliant on technology!

We've been testing the feeder for a while now (initally whilst we were at home of course) and so far so good! Indeed it has gone so well there's very little to report - it just works!

Comments/Suggestions?

If you have any comments, suggestions or feedback please feel free to sign my guestbook and/or contact me directly here.

162,612 Visitors
(since Apr '03, updated hourly)

Visitor location map for the previous year - Click for bigger version

Current server date/time is Thursday 11th March 2010 / 01:59:51 GMT

© 2002-2010 Mathew J. Newton

Unless otherwise notified, all content on this site is licensed under a Creative Commons Attribution-Non-Commercial-Share Alike 3.0 Unported License
Any reproduction/reuse of content must comply with this license and be attributed to Mathew J. Newton

If you're human, don't click here, here or here