Instead of Bringing the Dog to the Food, Let's Bring the Food to the Dog

A project with Ethan Varkul and Sabrina Button for MREN 318.

Cross-section of the final design

For our MREN 318 final project, we made an automatic pet feeder. The feeder stores food, dispenses a selected number of portions and then physically moves the bowl out to the pet. We also made a website that lets you change the meal settings and control the feeder from your phone or computer.

Why?

Pet owners aren’t always home at the right time to feed their pets. We wanted to make something that could keep a consistent schedule without giving the pet unlimited access to the food. Instead of leaving the bowl out all day, our design hides it inside the machine while it is being filled and only pushes it out when it is time to eat.

We also wanted the feeder to work for either a dog or a cat. The user selects the pet on the website, and the feeder uses a camera to check that the right kind of animal is in front of it before serving the food.

What?

There are two main mechanical systems: the dispensing system and the serving system. The dispensing system uses a stepper motor and a helical screw to move kibble out of an airtight hopper. The serving system uses a servo, belt and two linear rails to move the bowl in and out of the feeder.

The electronics are controlled by an Arduino Uno R4. We used an ultrasonic sensor to tell when something was standing in front of the feeder, an IR sensor to estimate how much food was left in the hopper, an ArduCAM to take a picture of the pet and limit switches to tell when the bowl reached either end of its travel.

Everything besides the hopper and linear rails was mostly 3D-printed. The estimated cost of the whole feeder was about $195 CAD.

How?

Mechanical Design

We chose a horizontal helical screw to dispense the food. Since the screw pushes the kibble sideways instead of lifting it, it doesn’t need a huge amount of torque. Changing the stepper speed also changes the food flow rate, and the motor can be reversed if the screw ever jams.

We did some free-body diagrams to make sure our motors were powerful and fast enough. The screw needed about 0.074 N·m at 477.5 RPM, while the bowl system needed only 0.0037 N·m at 47.7 RPM. Both of the motors we selected were safely above these requirements.

Motor sizing calculations

The bowl moves along two linear rails using a GT2 belt. We used an HS-422 servo because knowing the bowl position was important; we didn’t want the carriage to drive itself into the ends of the machine. The servo only rotates 180 degrees, so we also made a small gear-up stage to get enough belt travel.

The bowl in its serving position

Portion Control

Our first idea was to put a load cell under the bowl and use PID control to slow down the screw as the food approached the target weight. Unfortunately, the reading became really noisy while food was falling into the bowl. We couldn’t get anywhere close to the one-gram accuracy advertised by the manufacturer.

Instead, we did it the simpler way. Testing showed that running the screw for three seconds gave us about one serving. If the user asks for five servings, the screw runs for about 15 seconds. It is less precise than weighing every meal, but the screw gave us a consistent flow rate and didn’t jam during our testing.

Software

I think the most interesting part of the software was the state machine. The main states were IDLE, SENSED MOVEMENT, FILLING BOWL, BOWL EXTENDED and OVERRIDE. During each loop, the Arduino checks the website, reads the food level and completes one small part of the current state. This meant we could keep responding to web requests while the feeder was doing other things instead of freezing the whole program inside one long action.

The website lets you change the pet type, number of servings, time between meals and meal duration. It also shows the bowl position, hopper fullness, current state and time until the next meal. We saved the settings to EEPROM so unplugging the feeder wouldn’t reset everything. We also added an override mode so you can manually dispense food or move the bowl in and out for cleaning and debugging.

Pet Detection

Pet detection was harder than we expected. The Arduino Uno R4 has only 32 kB of SRAM and one 480x640 JPEG from the ArduCAM takes about 12 kB. That didn’t leave enough memory to do anything interesting with the image on the Arduino itself.

Our solution was to send the image over WiFi to a Python Flask server running on a laptop. The Arduino takes a JPEG, breaks it into 256-byte pieces and sends them over TCP. The laptop puts the image back together and runs it through a cat/dog classifier. If the classifier is more than 80% confident, it sends DOG or CAT back to the feeder. Otherwise, it sends NONE. The feeder only moves to the filling state if the result matches the pet selected on the website.

Cleaning and Safety

We covered the linear rails, gears and electronics so the pet couldn’t touch any of the moving or electrical parts. The bowl also stays hidden while food is being dispensed, which prevents the pet from getting in the way or stealing extra food.

We made the parts that touch food easy to remove. The hopper, screw and bowl all detach from the machine, and the sensor mounts can be removed from the hopper for cleaning.

Detachable parts for cleaning and maintenance

Problems and Takeaways

The biggest mechanical problem was the GT2 belt slipping on the bowl system. Since the servo only rotates 180 degrees, we couldn’t just run it into a limit switch and re-home it like a continuous-rotation motor. Every time the belt slipped, the servo’s idea of where the bowl was became slightly more wrong. Eventually, the bowl wouldn’t come all the way out or would crash into the back wall.

If I remade this system, I would use a thicker HTD5M or T10 belt to reduce slipping. Another option would be a continuous-rotation actuator that can re-home using the limit switches.

I also learned not to force a sensor into a design just because it was part of the original plan. The load cell sounded more accurate on paper, but a simple time-based portion worked much more reliably. Overall, the project was a good lesson in combining mechanical design, sensors, state machines and networking into one system that actually works.