photos to see larger versions. Full-size originals available on
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
feed them if arriving back late from the office, or whilst we're away
for short periods (e.g. overnight or perhaps weekends) 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
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, in November 2009 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,
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.
was no real requirement for controlling the provision of water as both
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.
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
persuasion - I do hope the neighbours aren't reading this as they
probably don't need reminding that cats don't tend to use
back garden either! ;-)
Moving swiftly on; here's a video of how it all turned out...
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...
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
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
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...
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
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
grunt for even the most awkard of cat food pellets! The motor was
mounted using a Cisco
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
3/10ths-of-an-inch diameter D-shaped shaft (with a handwheel onit)
which, whilst obviously
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
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
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
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
took on the task of turning and milling a shaft out of an
old printer bar. Despite my best attempts at confusing the
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
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
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
physical food delivery mechanism sorted I now needed a method to
provide remote control...
(Mark 1 Version - Cisco C1924) (there is now a Mark 2 - see
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
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 in the final stages of
Cisco's CCNA networking qualification (Edit 11 Feb 2010: Not any more - I'm now qualified! :-) ) 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
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
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
and poked around with a multimeter (don't try this at home if
know what you're doing!). I
found that the LEDs were driven using HC595A shift registers with TTL
These made ideal points from which to piggyback onto in order
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.
Output (Port 20 in this case)
Power Sourced from Main Power Block
Obtained from Chassis Screw
Block for External Connections
Port Status LEDs
slight unexpected gotcha (the CCNA syllabus unfortunately, yet
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.
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
logging in soon wears off and so I wrote a shell script
which uses the 'Expect'
excellent way of automating interactive applications
such as Telnet, SSH, etc. The script simply runs through a series a
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...
(Mark 2 Version - Cisco-Linksys WRT54GL)
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:
- 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.
Whilst not deserving of the term 'noisy' I also wouldn't say it was
silent either, despite fitting an ultra-quiet 40mm fan.
- 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...
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
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
'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 Network Address Translation (NAT), port
forwarding and various other
tricks, most of which come with numerous drawbacks. In the case of Carrier-Grade NAT (CGN), the last-ditch attempt to keep IPv4 alive, it'd be practically impossible, at least without employing some form of clever client-side polling to provide a reverse connection with the outside world (if you think that sounds complicated wait until you try and implement it!). 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
manipulation whatsoever and, for hex fans(?!), the IPv6 address does of
course end with ::feed
World IPv6 Day
has been and gone, and Frankie and Elmo are back to two meals a
On the 8th June 2011,
the Internet Society
along with many
of the 'Internet giants', took part
in 'World IPv6 Day' - a first-of-its-kind event in the history of the
Internet that enabled a large scale test of the 'new Internet
The event saw a mass enabling of IPv6
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 worked, and of course what didn't!
What was my contribution to this unique event? Well, in addition to
taking part in a user trial of native IPv6 connectivity
provided by my ISP (Plusnet)
I also opened up
control of my cat feeder - the world's first to support IPv6 - to
anyone that cared to give my cats a treat. Anyone, that is, that had
IPv6 connectivity of course... ;-)
Why? Good question... I could say it was 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
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 was mainly just a bit of fun...
how did it go? Well, very well in fact. Our cats thought Christmas had
come early so it was a real success in their eyes, and they still don't
know what IPv6 is! But that's the point - IPv6 is an enabler,
something that operates behind the scenes, and shouldn't be the concern
of the typical end user (admittedly cats probably don't fit that
Was/is IPv6 worth it then? Well, put it this way: Prior to the 8th
June the cat feeder would, typically, feed the cats twice in 24hrs...
On World IPv6 Day they were fed 168
times from all over the world by those with IPv6 so a quick calculation reveals that IPv6 is 84 times better
than IPv4. Fact. ;-) The amount of IPv6 seen worldwide accounted for 0.04% of overall traffic on that day and, accordingly, there were 1000's of 'read only' visitors to the catfeeder coming in over IPv4 but we've got to start somewhere so all-in-all the day was quite a success!
Anyway, back on-track, I picked a Linksys up off eBay for £15 and set
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.
WRT54GL Router - 'Pre Op'
and GND (Bottom)
(Left) and Orange LED (Right)
(Looped through holes for strain relief)
Rear of Feeder
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,
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.
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
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).
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.
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.
main web interface consists of five frames (see left-hand
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
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).
Various other interfaces were subsequently created such a cut-down versions for use on mobile devices (original my Windows Mobile PDA but later Android phones also) as well as a dual-screen implementation specifically 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.
(It was later mounted on the feeder itself)
The live video stream was critical to allow instant vertification of the cat feeder actually working, and to also observe all being well with the cats. All movement was automatically recorded and filed and could be replayed at the touch of a button to see all previous activations and the cats coming and going so even if we might not always see the cats live we could still check that they'd both recently been around.
Comments, Suggestions or Other Feedback?
If you have
any comments, suggestions or other feedback please feel free to sign my guestbook
and/or contact me directly here.