Tracking Hen Activity with Raspberry Pi and Matlab in Hobby Chicken Coop
A friend of mine who I met through one of the hackathons that I organized has backyard Chickens in St. Paul, Minnesota which he and his family had raised for a few years. He wanted to build an Internet of Things solution of some kind which would help him track his chickens and understand more about their proper care.
Part of his concern was how the temperature in a chicken coop or other unseen, unknown factors might affect the hen’s capability to lay eggs on a daily basis. He had observed that sometimes the hens would lay eggs on an irregular basis and he just wanted to rig up his coop, have some fun with it, and try to understand more about what the chickens do on a daily basis.
The architecture for a monitoring system we came up with was the following:
This was in lieu of an RFID-based system, in which chickens would physically walk through an RFID scanner and have tags tied to their legs. He later built this system, but I was not involved in that phase of the project.
Benefit and to Whom
Backyard or hobby chicken farming is a very common practice, which I used to do myself in fact when I was young. Part of the idea would be that if we could design something of sufficient value that could be productized, there could possibly be a wide range of customers in a fairly easy to reach niche.
Unfortunately, or perhaps fortunately, after a couple of years of work on this project, my friend decided it was a bit of a dead end. The expense of equipment and low complexity of backyard chicken farming did not lend itself well to discovering a dire problem in need of an excellent solution. The project ended up being deployed at a few neighbors for small subscription fees, but nothing pointing toward a large scale market.
Project Status or Outcome
An early part of the design project involved a quick calculation to understand whether such a system could be independently solar powered and what kind of solar system would be needed to keep it running. I did some quick calculations for the heck of it, but for prototyping purposes we just kept the system grid-connected:
The camera, electronics and physical box were rigged together as shown below. Rather than opting for a fancy, Raspberry Pi camera with software-defined image recognition, I recommended using a pre-built image capture camera designed for robotics applications, the Pixy, along with a Wifi-connected Arduino Yun to cut down on complexity and power consumption.
In addition to the pixy camera sending signals to the cloud through our Arduino-based C++ code that we wrote, we found that we needed a quick way to confirm whether objects were actually being detected on-site without having to look at a computer screen. When you’re standing inside of a chicken coop, you don’t really want to have to run back and fourth between a laptop to rig things up and make sure everything is fitting correctly, you just want a general indicator light to tell whether objects were being detected or not.
So, I put together a good old-fashioned multi-function LED indicator panel which showed us four different events based upon a specification we wrote. As I’m writing this I don’t precisely remember what those events were, but they were something along the lines of - 1) Connected to the Internet. 2) Detected Object. 3) Sent Signal. 4) Signal Received.
Part of the architecture we had built and why we needed a, “signal received” indicator light was because we included the use of MQTT, which is a lightweight transport layer designed for low power and low data internet of things applications, in place of HTTP. MQTT has the advantage of being much more lightweight than HTTP per packet, because it doesn’t include as much header, but it also does not call a function back and fourth to ensure a message received as HTTP does. MQTT just sort of throws messages out into the void and hopes that the server on the other end caught the data. MQTT is commonly used for cellular applications where data is expensive and intermittent, and where data is a nice to have rather than absolute necessity.
Hence, we built a hook function to let us know that the MQTT server received the signal, so that data was being picked up and registered, which on HTTP would have been a given, but for MQTT is not necessarily.
We collected image data on the entrance of the chicken coop, looking at chicken movement over many days and weeks to understand chicken behavior over time. Here is a viewpoint with a reference axis showing what kind of data points, involving X and Y coordinates, we would pick up.
Observing an image overlay of chicken movement vs. the actual coop entrance, we could clearly see data points map out showing the majority of detected chicken movement being on the ramp leading up to the coop, which makes intuitive sense. However we also noticed a huge grouping of datapoints on one end of the ramp, which did not seem very, “chicken like.” We determined that these datapoints were actually reflected light on the ramp during a particular part of the morning when the sun was shining on that ramp.
After de-gaussing, (or rather, cleaning out the morning reflective light data points, so de-Blondeling, after Andre Blondel, inventor of the lumen), we were able to observe a string of chicken activity over time. The below graph shows chicken activity over time in the Z-axis.
What we were able to see is that the chickens entered and exited the coop several times per day, but typically around 8AM and then again around 2PM, and then going in for the night around 8PM in late May 2016. The morning exit was attributed to morning feeding at 8AM, but the 2PM re-entrance to the coop was an unexpected finding.
In the end, my friend wanted to achieve an even more accurate, precise understanding of chicken entrance and exit and opted for RFID tags tied to the chicken’s legs, and I moved on to other projects.