Whenever we’re away for a long time we worry about our cats. There are people who come in to feed them, play with them, and change the cat box, but still we worry. Over the years I’ve developed more and more technological solutions to allow us to check in on them remotely. Now, before we go I set up multiple wifi cameras around the house, each of which is in a likely cat activity space. I can reposition the cameras remotely and they capture based on motion and save up a nice movie of all the activity broken down by hour. They have infrared cameras and so we get twenty four hour coverage. This works pretty well and reduce worry a lot.
There was only one gap in this system, sometimes the cats decide to be completely outside of the view of all of the cameras for many hours. Being an engineer I felt compelled to try and build a solution to fill this gap. I decided that I would build a robot rover that could do the following:
Autonomously roam one or more rooms of the house
Take pictures during it’s patrol and upload them
Record sounds
Play our voices calling for the cats and offering treats
Dispense treats
Allow me to take over and control it’s functions manually over the internet
The theory would be that while a robot would likely make the cats wary, something that sounded like us and dispensed tasty treats would make them get over that and come close to be seen on camera somewhat on demand.
Now that I have the robot assembled and I’ve figured out how to program it, I’ve been working on the patrol code. It is still a work in progress but I’ve managed to get ten probes into a room and not get stuck, I have some ideas on how to get to the next level. Along the way I’ve discovered some interesting edge conditions in the python api code, for example in some locations where they convert from degrees to a number of intervals from the wheel sensor they use integer math. Not in general a problem except when the division comes back as zero in which case the onboard controller takes that as meaning “turn on the motors until you’re told to stop” instead of “stop after some number of wheel sensor signals" So, every so often everything would be going well and then the robot would need to turn a small amount and it would just start spinning in place until it hit the code to go forward which at that point was in a random direction. There was a similar issue with the code to go forward a certain number of centimeters resulting in running right into whatever wall was in front of it.
I’ve got all of the safeguards in my code now to prevent those conditions now, and it has been interesting debugging both in the code and physical world. One of the mechanical things that I ended up having to fix was that I had originally mounted the servo on the front and the ultrasound sensor on the lower deck of the robot ( they didn’t say you shouldn’t and it was out of the way of the camera .) Turns out, that you don’t get full range of motion of the sensor on the servo because the circuit board hits the upper deck. More importantly for something that rolls around the floor it was easy for the low mounted sensor to miss things that would interfere with the top half of the robot. So, I moved it up to the upper deck. I just pivot it out of the frame when I use the camera.
I also learned that you shouldn’t operate the motors and take a picture at the same time, the ribbon cable ( not shielded ) for the camera runs right past the power circuit for the motors. There is a lot of RFI when they’re running and so you get some pretty funky images as a result.
Robot showing amplified speaker, microphone, and new placement of the ultrasonic sensor
I got a very cheap USB microphone dongle to use for audio input… bad idea… the gain on the device was terrible, it worked but the audio was barely audible over the noise. The noise was because all of it’s circuits were yes, you guessed it, right near the motor controller board. I ended up using a nice USB microphone via a USB cable clipped to the side of the robot, that worked like a champ and had enough gain to pick up a cat vocalizing.
I also got a tiny rechargeable amplified speaker to plug into the Raspberry Pi’s headphone jack and that worked fine. I got a 90 degree adapter to keep the wire away from the wheels and mounted it to the back with some double stick tape. Using the pygame module it is easy to play any audio file so we should be able to record ourselves calling to the cats and use that.
Design for cat treat feeder…
The final item is the treat dispenser, this is an entire project in itself. I have a design that I’m working on and I’ve created a prototype of the dispenser mechanism. I have been using components from the Lego Technic collection of parts. The great thing is that they have all kinds of shafts, bearings, gears, wheels, beams, etc… that are all compatible with each other. I’m not qualified to machine anything or even do a competent job designing something to be machined. So, these are a godsend and have allowed me to build the core mechanism of the treat dispenser and get it working. The power for the treat dispenser will come from two additional servos one on each side which will push a peg on a drive wheel, they are set 180 degrees apart. (see video for demonstration in the prototype) Fortunately the folks who make the robot provide a kit with an add on servo controller board that can control multiple servos and it comes with a couple of big servos that should work. It also has it’s own batteries and so it won’t be dependent on the robot’s power.
You can see the up and down action of the servo being translated to rotation to drive the belt.
I’m going to make the case for the treat dispenser out of 1/8” acrylic sheet and I’m going to have to cut these parts a lot more cleanly that the last one because I intend to glue them together. My Dremel has a straight cutting bit and a guide collar and I think that would work with the panel clamped firmly to a sacrificial piece of wood and pressing the Dremel against a guide fence. I’m going to be experimenting soon.
That’s where I’m at for the moment.