It’s been over a year since we’ve had chickens and we’ve missed them, so this Christmas we got Lizzy and Charlotte an incubator so that we could try hatching some this spring.
When we went to purchase eggs, we found that you could most easily get them 10 at a time from the hatchery we have used in the past, Murray McMurray. Since the incubator we got the girls could only hold seven, we would need something for the other three. Some searching found that you could use a styrofoam cooler and a lamp to create a makeshift incubator, so I planned on that.
Once I had a plan to create an incubator, I knew I would have to overcomplicate things. Four years ago I built a webcam for our chicks so I figured I would do that this time too. Also, just setting a lamp and thermometer in and hoping for the best seemed like a potential waste of good eggs, so I wanted to monitor the temperature and humidity, and regulate them.
My initial design was a Raspberry Pi connected to a cheap DHT11 temperature and humidity sensor, controlling a relay that could turn the light on and off. All of it would be hooked up through a PID controller to keep the temperatures right where we want them. Eventually, I added a thermocouple with a MAX6675 for more accurate temperature readings.
Raspberry Pi, Relay and a mess of wires.
The server side would be designed similarly to the previous chicken cam, except written in Go. The stats would be tracked in InfluxDB and Grafana would be used for viewing them.
After I got all the parts I did a little testing, then soldered things up and tested it to see how it ran.
Initially I wrote everything in Go, but the DHT11 reading was very spotty. Sometimes it would respond once every few seconds, and sometimes it would go a minute or more failing to read. I wired on a second DHT11 and tried reading from both, but I didn’t get that much better performance.
Eventually I tried them from the Adafruit Python library and had much better luck, so I decided to just read those from Python and send them to my main Go application for consumption. I still have trouble with the DHT11’s, but I suspect it’s my fault more than the sensors fault.
My next issue was that it was extremely jittery, the readings would vary by degrees one second to another, so I collected readings in batches of 5 seconds then averaged them. That smoothed it out enough that graphs looked reasonable.
On. Off. On. Off. On. Off.
Temperature was now well regulated, but the air wasn’t humid enough. I switched to a sponge and found I could manage it much easier that way. I briefly tried a 40W bulb thinking I could spend more time with the lamp off, but temperatures still plunged at the same rate when the light was off, so I mostly just created quicker cycles.
After putting the 25W bulb back in, I still wanted a longer, smoother cycle, so I wrapped up a brick (for cleanliness) and stuck that in there. That got me longer cycles with better recovery at the bottom, it didn’t get too cold before the lamp came back on. Some slight improvements to the seal of my lid helped as well. I had trouble with condensation and too much humidity, but some vent holes and better water management took care of that.
Before the brick.
After the brick.
For the server side, I mostly duplicated the code from the previous Chicken cam, but in Go. Then I used the InfluxDB library to get the most recent temperature and humidity readings for display.
At this point, I felt ready for the eggs, which was good because they had arrived! We placed them in the incubator and we’re just waiting now. On day 8 we candled them with a homebuilt lamp i.e. a cardboard box with a hole cut in it.
Candling
Things seem to be progressing well so far, so here’s hoping something hatches!
Yesterday I published a Chicken Cam for Buttercup farm, basically just a webcam for the 21 chicks we got a few weeks ago.
Oh, hey.
I had decided to do this project on a whim. I had a Raspberry Pi lying around unused, and I figured it would be simple to get running. It was a simple project, but I hit a few constraints which made it take longer.
Bandwidth
One of the first problems I came across was bandwidth. I live 10 minutes from Omaha, and 10 from Blair. We do not have blazing internet out here. I have ADSL which is spotty when the weather is bad. I can’t afford to dedicate too much of my upstream to a chicken cam.
My first thought was to take a photo at an interval, and push it out to S3. That would save bytes since it would push the cost of serving more than one user outside of my link. The problem with that, is I didn’t have a simple mechanism to tell my camera to start and stop sending images. It was always on, and always consuming bandwidth.
My second thought was a proxy type system, and that’s what I ended up using. I wrote a quick node app with a background function on an interval which requests a new image from the camera. It stores this JPEG into a buffer and sleeps. When it wakes up, it checks a timestamp to see if someone has recently requested a new frame. If they have, we loop again, otherwise we wait a while and check again.
This way we serve images at a decent rate, and don’t use bandwidth when no one is watching.
var http_callback = function(response) {
var img = '';
response.setEncoding('binary');
response.on('data', function (chunk) { img += chunk; });
response.on('end', function () {
latest_image = img;
latest_image_timestamp = +(new Date());
setTimeout(updateImage, REFRESH_INTERVAL);
});
};
function updateImage () {
if(( +(new Date()) - last_request ) > PAUSE_TIMEOUT) {
setTimeout(updateImage, PAUSE_INTERVAL);
}
else {
http.request(http_options, http_callback).on('error', function (e) { setTimeout(updateImage, BACKOFF_INTERVAL); }).end();
}
}
I put this proxy up on Heroku and it’s been humming along just fine.
tinycamd
The RPi has decent specs, it’s not a really wimpy machine in an embedded context, but I figured, why push it? I wanted to find a really lightweight way to serve up the images.
I initially looked at motion, but it was way too feature rich and heavy. Likewise I ruled out ffmpeg because I wanted stills on demand, not an MJPEG stream.
Luckily, I eventually found tinycamd, a little c program which worked well after a few tweaks.
I had to compile this myself on the RPi since it’s not in the Debian repos. Easy enough. I started with the CNXSoft minimal image and installed build-essential and libjpeg-dev.
[email protected]:~/# apt-get install build-essential libjpeg-dev
Let that run for a bit and then you can build the program. It’s a very simple program, with a very simple build process. No autotools, just type “make”.
One change I had to make to get it to compile was turn off -werror for the compiler, it was dying on a “variable set but not used” warning, which isn’t really a big deal to ignore.
[email protected]:~/tinycamd# make
cc -Wall -Werror -O2 -MMD -c -o tinycamd.o tinycamd.c
tinycamd.c: In function 'main':
tinycamd.c:280:15: error: variable 'httpdThread' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make: *** [tinycamd.o] Error 1
[email protected]:~/tinycamd#
Removing -werror from the CFLAGS lets it build, which it does pretty quick.
Index: Makefile
===================================================================
--- Makefile (revision 46)
+++ Makefile (working copy)
@@ -1,5 +1,6 @@
-CFLAGS := -Wall -Werror -O2 -MMD $(CFLAGS) $(COPTS)
+CFLAGS := -Wall -O2 -MMD $(CFLAGS) $(COPTS)
+#CFLAGS := -Wall -Werror -O2 -MMD $(CFLAGS) $(COPTS)
LDLIBS += -ljpeg -lpthread -lrt
HOSTCC ?= cc
The next hurdle I encountered might be specific to my hardware. I’m running a Logitech UVC webcam I had laying around. It claims it can stream JPEG’s straight from the hardware, and it claims you can set the JPEG compression rate, but it was dying during the ioctl for setting that compression level, VIDIOC_G_JPEGCOMP error 25, Inappropriate ioctl for device.
Rather than fighting it further, I commented out that chunk of tinycamd and ran it with the YUYV format and pushed JPEG compression of the camera and into libjpeg. This makes it consume more resources, but it was the quickest workaround for me.
Index: device.c
===================================================================
--- device.c (revision 46)
+++ device.c (working copy)
@@ -439,6 +439,8 @@
fatal_f("Unable to set requested pixelformat.\n");
}
+ comp.quality = quality;
+ /*
if (-1 == xioctl( videodev, VIDIOC_G_JPEGCOMP, &comp)) {
if ( errno != EINVAL) errno_exit("VIDIOC_G_JPEGCOMP");
log_f("driver does not support VIDIOC_G_JPEGCOMP\n");
@@ -449,6 +451,7 @@
if (-1 == xioctl( videodev, VIDIOC_G_JPEGCOMP, &comp)) errno_exit("VIDIOC_G_JPEGCOMP");
log_f("jpegcomp quality came out at %d\n", comp.quality);
}
+ */
if (-1 == xioctl( videodev, VIDIOC_G_PARM, &strm)) errno_exit("VIDIOC_G_PARM");
strm.parm.capture.timeperframe.numerator = 1;
With all that done I installed it as a daemon (it ships with an init script) and I was good to go.
Running, it stays under 30% CPU and 3% of memory, and that is with YUYV conversion and 40% compression on the JPEG frames. Pretty good.
The Bunker
The final hurdle was our garage, where the chicks are kept. We have a very unusual garage, consisting of a concrete silo with very thick concrete walls. It’s also the furthest point from the router in the house. Wifi is slow and spotty out there, so I bought a bridge and ran 50′ of Ethernet cabling from the garage into the house where the bridge was set up. This decreased latency enough to make the camera viable.
The End Result
It took more effort than I thought it would, and a few days of waiting for hardware to ship, but I think it was worth it. I intend to try and keep the camera running as they grow up and move outside, which will involve running even more cabling and probably a power line. We’ll see if I stick to it or not.
If you want run tinycamd on your own pi, I’ve included my build with an install script. This is the version with device JPEG compression disabled, so be aware of that if you decide to stream JPEG instead of YUYV. tinycamd-rpi-debian.tar.gz
You can also download my patch file if you want to build it yourself.
Update (2013-10-09)
In the comments Matt asked for clarification on the configuration, so I thought I would put that up here.
There are two services running, tinycamd on the RPi and my node app on Heroku. Both are HTTP servers. I’ve port forwarded 8080 through my router to the RPi (shown as 192.168.1.117 on the diagram) which means that the tinycamd HTTP server on the RPi is available on the public internet if you know my WAN IP (direct chicken access!)
The Heroku app is configured with that WAN IP, so it knows where to make an HTTP request for a new JPEG. To simplify configuration, I actually have it pointing to a dynamic DNS host, which is kept up to date by software on my router.
So when you make a request to Heroku for an image, Heroku doesn’t forward that request to tinycamd, it just serves you whatever image is currently in memory. In this way, it’s not really a proxy, that’s a bad term. It’s more of a self-updating cache, because it goes out and updates the frame on it’s own schedule, not due to incoming requests.
Matt made a good point that web sockets would be a better control mechanism. I agree, but this system doesn’t have very hard real time constraints, and I’m fine with leaking a few kb for unused frames. Polling is gross, but sometimes it’s the simple option. S3 is no longer involved in serving frames, that was my first approach, which I abandoned.
Salutations!
It’s been another lovely year for us Hobbseses. This won’t be a long letter this year, as I am writing it the day of from the Borders cafe and there is a trekkie in the sci-fi/fantasy aisle eyeing the Death Star sticker on my laptop. Things could turn ugly at any moment. Any. Moment.
Good thing I’m packing my DL-44 with the shaved down barrel sight.
So, what happened to us this year? Well, I think this year has been defined by chickens. Against the outcry of friends and family we got four little chicks this February. Much to our surprise they do not stay small and fluffy. They turned into chickens. What the heck?!
What else happened? We went to Colorado to visit the hippies Rogers.
As you can see from the top photo, we had a great time.
I got to drive Steph’s scooter. We ate wild mountainside honey, and, um, you know, hung out and stuff. It was well worth the drive. Manitou is beautiful, even with all the crazies.
Darcy is rocking two jobs, working nearly full time. Well, she’s at work nearly full time, I can’t attest to how much actual working she does. At least a third of the time I bet.
She’s a pre-school teacher again this year, herding around a class of three year olds and a class of four year olds. Even better she works at Borders, where we go to spend all of our money on books, but at a discount!
I switched to a new job just two weeks ago. It’s going well, I miss the solitary work I was doing before, but this is pretty cool too.
Socially speaking it’s probably better, since I have to interact with other humans on a daily basis.
So, let’s see, other adventures of the year. Nan and Ryan still aren’t married. Lazy bums. Darcy made beer (like 5 gallons of it) and then everybody drank it. We grew pumpkins. Darcy went to Chipotle with me (twice I think).
Our last little bit of news is an addition to the family. No, not a baby, but another cat. Darcy got Pigwidgeon (or Pig for short) for Christmas this year. She’s a little speed demon, and we don’t think she’s going to get very big. Hence the name.
So if you are allergic to cats, our house just got a little bit worse for you. We don’t like you. Stop coming over. How many cats do we have to get before you take the hint?!
So that’s it for us, we hope you have a Merry Christmas, and if you are one of the people we have professed to love in the past, then we still love you!
– John & Darcy Hobbs
Photos From 2010
Right before we left the chickens gave us a surprise, the first egg!
Needless to say Darcy was very excited, and Gloria was not (we think she’s the layer). By the time we got back we had a half dozen and ate some delicious scrambled eggs for dinner.
