Internet-Enabled Cat Feeder

Page last modified Monday, 06-Jun-2011 14:14:11 BST

Today is World IPv6 Day - and the Internet-Enabled Cat Feeder is open to the public!
(as long as you've got IPv6 connectivity that is...)

Today, the 8th June 2011, the Internet Society along with many of the 'Internet giants', are taking part in 'World IPv6 Day' - a first-of-its-kind event in the history of the Internet that will enable a large scale testing of the 'new Internet protocol', IPv6. The event will see a mass enabling of by those participating (content providers, transit providers, ISPs and end users) in order to give the protocol a run for its money to see what works, and of course what doesn't...

What's my contribution to this unique event? Well, in addition to taking part in a user trial of native IPv6 connectivity being provided by my ISP (Plusnet) I will also be opening up control of my cat feeder - the world's first to support IPv6 - to anyone that cares to give my cats a treat. Anyone, that is, that has IPv6 connectivity of course... ;-)

Why? Good question... I could say it is to help demonstrate in a practical way how more and more devices are being hooked up to the Internet in such numbers that the dwindling pool of IPv4 addresses simply cannot hope to accomodate them, or that how such devices can be connected with relative ease given the lack of NAT configuration, port forwarding, etc. However, truth be told, it's just a bit of fun... and I'm sure our cats will appreciate it too!

So, if you've got IPv6 and want to turn those extra IPv6 bits into bytes (oh please...) then click the link below! By the way, the whole purpose of today is to see what breaks so if that happens then, well, I'm only doing my bit... ;-)

ipv6catfeeder.com

Internet-Enabled Cat Feeder - Mark 2
(The World's First (and Last?!) IPv6 Cat Feeder!)

Ranked #2 in Mac|Life Magazine's Top Ten Wonders of the Home Automation World ! (Mar '10, pp 30-31)

	(Click photos to see larger versions. Full-size originals available on request)

Background

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 RFID 'microchip' 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 necessarilly having to bother the neighbours 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 several 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 not to 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 some form of pipe/tube 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 good old-fashioned 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 250kg·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 don't know if it has fully justified storing a dozen 4'x3' sheets of it in the loft for seven years 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. That, and I wanted to give Metallic Origami a try...

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 (Mark 1 Version - Cisco C1924)
(there is now a Mark 2 - see next section)

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! :-) ) 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, SSH, etc. 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.

As the title of this section mentioned, this was the Mark 1 method of providing network access to the feeder. Before I move on to the rest of the hardware (and software) it is worth going through some enhancements I made in this area which formed the 'new and improved' Mark 2...

Network Interfacing/Connectivity (Mark 2 Version - Cisco-Linksys WRT54GL)

The Cisco switch method of providing network access worked well - very well in fact. However, that didn't mean it couldn't be improved upon... In particular, there were a number of areas I wanted to focus on:

Size - Cisco switches aren't the smallest/lightest of equipment and given all I needed from it were three of its port LEDs I'd be the first to admit it was a touch on the large side.
Noise - Whilst not deserving of the term 'noisy' I also wouldn't say it was silent either, despite fitting an ultra-quiet 40mm fan.
Esoteric - I had one, and knew how to configure it, but many of the people who got in touch wanting to implement something similiar (not necessarilly to control cat feeders, but rather anything requiring simple control over a network) understandably considered an old Cisco switch to be something you'd only find in the darkest cornest of eBay and asked if there was anything more modern, of greater availability and easier/safer to hack in to...

Enter... the Linksys WRT54GL Router. This device, for those that don't know, has near-legendary status in some circles (okay, that's pushing it but it is pretty good) as not only does it function well out-of-the-box but, being based on Linux firmware its source code has been made available to anyone that wants it (here's the lowdown on how this came to be). So what? Well, being open source means that others can more easily write complete replacements for the stock firmware and, in doing so, provide additional functionality to those that want to get more out of the device, and perhaps use it for purposes it was not originally designed for...

It fitted the bill perfectly and directly addressed the aforementioned issues. Specifically, it was small (it can therefore be easily mounted on the rear of the feeder), completely silent (by virtue of it being fanless), readily available (you can still buy them new, but are also available cheaply on eBay) and safer to poke around in given there are only low voltages inside the device.

There were other benefits too including wireless capability (I didn't need this given my house has a full wired network but acting as a bridge it does enhance the existing wireless coverage and allows for greater portability if required), SSH access, and ...wait for it... IPv6! Okay, so this latter one may appeal to only a select few and I'd be the first to admit that a cat feeder is far from being one of the much-awaited 'killer apps' for IPv6 (indeed, some might argue it is more deserving of joining the list of 'apps that might kill IPv6'!) but it does demonstrate one of the principle advantages of IPv6 - globally unique addressing for any device that wants it, even cat feeders. With the impending IPv4 address exhaustion it is becoming increasingly difficult to provide true end-to-end connectivity to networked devices without the use of NAT, port forwarding and various other tricks, most of which come with numerous drawbacks. The size of the IPv6 address space is such that even my cat feeder now has its own globally-unique address, reachable from anywhere without any in-transit packet manipulation whatsoever and, for hex fans(?!), the IPv6 address does of course end with ::feed ... ;-)

Anyway, back on-track, I picked a Linksys up off eBay for £15 and set to work... The first task was to install third-party firmware on it - I opted for OpenWRT. This provided me full access to the workings of the device and, most importantly, allowed me to control a variety of status LEDs which in turn could control the operation of a motor exactly as per the Cisco switch. The LEDs I chose for the forward/reverse motor control were the otherwise-unused (when running OpenWRT) white and orange SES LEDs that sit behind the 'Cisco Systems' button on the front panel (Cisco now own Linksys so whilst I've dropped their C1924 switch I've at least still kept things within the family!). I also tapped into the DMZ LED to faciliate the 'emergency cutout' functionality. A +12v (1A) power feed was taken directly from the back of the DC power socket.

Linksys WRT54GL Router - 'Pre Op'	Case Dismantling (Screwless)	Router Innards	PCB Removed from Case
+12v (Top) and GND (Bottom) Connection Points	White LED (Left) and Orange LED (Right) Connection Points	DMZ LED Connection Point	Completed Wiring (Looped through holes for strain relief)
Pre-rebuild Testing	External LED View	Mounted on Rear of Feeder	External Connections

Aside from installing the OpenWRT firmware and providing basic configuration (wireless settings, IPv4/v6 addresses etc - easiest done via the web interface) I modified/created a few files/scripts (/etc/banner, /instructions, /etc/init.d/nvram and /etc/init.d/defaultled) to set the default states (on or off) of the LEDs during/after the boot process - this is necessary because during boot the state of the LEDs would otherwise be all over the place resulting in the feeder inadvertantly activating. It's not that big a deal, and indeed the device should only reboot if there's a power cut (and restore) so unless your cats are in the habit of flipping the master switch every now and then.... ;-)

Speaking of LEDs, it is worth mentioning at this point that the Linksys uses inverse logic to control them i.e. the general purpose input/output (GPIO) pins on the CPU are connected to the cathode ('negative') side of the LEDs with the anode ('positive') side connected to +3.3v. Hence, to illuminate an LED the CPU effectively outputs 0v and to extinguish an LED it outputs 3.3v (CMOS logic levels). Rather than modify my external motor control hardware (detailed in the next section) I handled this change of behaviour (when compared to my previous Cisco switch operation) in software i.e. by modifying the control script (available here) to set the appropriate state based on the user instruction.

Motor Control

With the ability to control the LEDs over the network (whether using the Cisco or the Linksys) 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 (PDF)

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 respectively. I later also added a button (not shown in the photo) to allow manual (i.e. local) control without having to use the PC.

Software

With everything connected up the feeder could now be controlled using the control scripts (i.e. the Cisco version or the Linksys) so, for example, '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 to handle these commands on the user's behalf.

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 (or the Linksys router of the Mark 2 version).

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

Later Revision (created for World IPv6 Day)

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 was later 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. A case in point was the transition from using a Cisco switch in the Mark 1 design to a Linksys router in the Mark 2- this not-insignficant change had minimal impact on the rest of the system and required only a slight tweak in software. The modular approach also allowed me to borrow from the Unix design philosophy of designing each component to 'do one thing and do it well'. For example, it would have been possible to host the web frontend on the web server built-in to the Linksys router but this would not provide the greater performance and functionaility that Apache can on my Linux server and wold also unlikely to have coped with the heavy lifting required of the video streaming and motion detection.

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.

The brave new world of IPv6 - the IPv6-enabled fridge

1,804,330 Visitors
(since Apr 2003)

© 2002-2024 Mathew Newton

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

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