Project

# Title Team Members TA Documents Sponsor
18 Smart Vision-Assisted Pet Feeder with BLE Proximity Sensing and Remote Monitoring
 Jiaao Zhang
Junwei Pan
Ziteng Qian
 Pusong Li other1.pdf
other2.pdf
other3.pdf
# Smart Vision-Assisted Pet Feeder with BLE Proximity Sensing and Remote Monitoring

Team Members:
- Junwei Pan (junweip2)
- Jiaao Zhang (jiaao2)
- Ziteng Qian (zitengq2)

# Problem

Pet owners are often away from home for extended periods and may not be able to directly monitor whether their pets are approaching the feeder, eating normally, or ignoring food. Conventional automatic pet feeders typically dispense food at fixed times and provide little information about the pet's actual interaction with the feeder. As a result, an owner may know that food was dispensed but not whether the pet actually approached or consumed it.

We propose a smart pet feeder that automatically detects when an authorized pet approaches, activates computer vision to monitor the pet near the feeding area, dispenses a controlled amount of food, and reports feeding activity to the owner remotely.

The system will also monitor simple abnormal feeding patterns. For example, if the pet repeatedly approaches the feeder or remains near the bowl for an extended period without a measurable decrease in food weight, the system can notify the owner.

# Solution

Our system combines BLE-based proximity sensing, computer vision, weight sensing, motorized food dispensing, and wireless communication.

A small BLE tag attached to the pet's collar continuously broadcasts an identifier. The feeder's main controller monitors the received BLE signal strength (RSSI). Rather than using BLE for precise positioning, the system uses RSSI only as a coarse proximity indicator. When the signal strength exceeds a calibrated threshold corresponding approximately to the pet entering the feeder vicinity, the system activates the camera and computer-vision subsystem.

The camera then provides the primary confirmation that the pet has entered or remained within the feeding area. Once the pet is visually confirmed, the main controller activates an auger-based food dispensing mechanism. A load cell underneath the food bowl provides feedback so that the system can stop the motor after the desired amount of food has been dispensed.

After dispensing, the system continues monitoring the bowl weight and camera state to determine whether the pet remains near the feeder and whether food is actually being consumed. Feeding events, food consumption information, system status, and abnormal-behavior alerts are transmitted over Wi-Fi to the owner's phone through an Internet-based messaging service.

The system is divided into four major subsystems: proximity and wireless communication, computer vision, feeding and weight control, and the main embedded control PCB.

# Solution Components

## Subsystem 1: BLE Proximity and Wireless Communication

This subsystem detects when the tagged pet is approaching the feeder and provides remote communication between the feeder and the owner.

A BLE tag attached to the pet's collar periodically broadcasts its identifier. The ESP32-S3 on the feeder scans for the designated BLE device and measures its RSSI. A moving average and hysteresis threshold will be used to reduce false triggering caused by RSSI fluctuations.

When the averaged RSSI exceeds a calibrated threshold, the ESP32 will signal the vision subsystem to begin camera processing. BLE is used only as a coarse proximity trigger rather than as a precise ranging or positioning system.

The ESP32-S3 will also use its integrated Wi-Fi interface to send information such as feeding time, amount of food dispensed, food consumption, and abnormal feeding alerts to the owner through an Internet-based messaging service.

Components:
- Espressif ESP32-S3-WROOM-1-N8R8 Wi-Fi/BLE module
- ESP32-C3-MINI-1-based BLE tag or equivalent BLE beacon for the pet collar
- 2.4 GHz PCB antenna integrated into the ESP32 modules
- Status LEDs and buzzer for local system indication

## Subsystem 2: Computer Vision and Pet Behavior Monitoring

This subsystem provides the primary confirmation that the pet is actually interacting with the feeder.

A Raspberry Pi connected to a camera will run the computer-vision software. The camera does not need to operate continuously. Instead, it is activated when the BLE subsystem indicates that the pet is likely approaching.

The vision system will determine whether a pet is present in a predefined feeding region and monitor simple behaviors such as:
- Pet enters the feeding area
- Pet remains near the bowl
- Pet leaves the feeding area
- Repeated approaches to the feeder

The system will not attempt to diagnose medical conditions or recognize complex behaviors such as chewing. Instead, visual presence information will be combined with bowl-weight measurements to determine whether feeding actually occurred.

The Raspberry Pi will communicate its detection results to the ESP32 through UART or another serial interface.

Components:
- Raspberry Pi 5
- Raspberry Pi Camera Module 3
- Sony IMX708 image sensor
- UART interface between Raspberry Pi and ESP32-S3
- OpenCV and/or a lightweight object-detection model

## Subsystem 3: Food Dispensing and Weight Measurement

This subsystem controls how much food is dispensed and measures whether food is subsequently consumed.

Dry food or equivalent test pellets will be stored in a hopper. A stepper-motor-driven auger will transport the food from the hopper into the bowl.

Rather than controlling the amount of food only according to motor operating time, the system will use closed-loop weight feedback. A load cell underneath the bowl continuously measures the amount of food present.

For example, if the target dispensing amount is 20 g, the controller will operate the auger while monitoring the load-cell reading and stop the motor when the measured increase reaches approximately 20 g.

After dispensing, changes in bowl weight will also be used to estimate whether food has been consumed. If the vision system detects that the pet remains near the feeder while the bowl weight does not decrease beyond a defined threshold, the system may classify the event as an abnormal or incomplete feeding event.

Components:
- TAL220B single-point load cell, approximately 5 kg range
- HX711 24-bit load-cell ADC
- NEMA 17 stepper motor, model 17HS4401 or equivalent
- Allegro A4988SETTR-T stepper motor driver
- Custom auger and food hopper
- Limit switch for mechanical safety, if required

## Subsystem 4: Main Control PCB and Power System

The custom PCB will serve as the main embedded controller of the feeder rather than only as a power-distribution board.

The ESP32-S3-WROOM-1 will be mounted directly on the PCB and will coordinate the other subsystems. Its responsibilities include:
- BLE scanning and RSSI processing
- Wi-Fi communication
- System state-machine control
- Load-cell data acquisition
- Motor control
- Communication with the Raspberry Pi
- Feeding-event logging
- Alert generation

The PCB will also contain the load-cell interface, motor-driver circuitry, sensor connectors, status indicators, and power regulation required by the embedded electronics.

The Raspberry Pi will act primarily as a vision-processing coprocessor, while the ESP32-based custom PCB will remain the main controller for the overall feeder.

Components:
- ESP32-S3-WROOM-1-N8R8
- HX711 load-cell ADC
- A4988SETTR-T stepper motor driver
- 3.3 V voltage regulator for the ESP32 and low-voltage electronics
- Power input and protection circuitry
- Decoupling and bulk capacitors
- UART connector for Raspberry Pi communication
- Load-cell connector
- Motor connector
- Programming/debug interface
- LEDs and buzzer
- Raspberry Pi power supply

# Criterion For Success

1. **BLE proximity triggering:**
After calibration, the system must detect the designated BLE tag entering the intended feeder vicinity and trigger the computer-vision subsystem within 2 seconds in at least 90% of 20 test attempts.

2. **Vision-based feeding-zone detection:**
The computer-vision subsystem must correctly classify whether a pet is inside or outside the defined feeding region with at least 90% accuracy on a labeled test set.

3. **Controlled food dispensing:**
For example, a target dispensing amount of 20 g, the closed-loop auger and load-cell system must dispense food within ±10% of the target in at least 9 out of 10 trials.

4. **Consumption detection:**
The system must detect a meaningful decrease in bowl weight after feeding and distinguish between a feeding event with food consumption and an event without food consumption in at least 90% of controlled trials.

5. **Abnormal feeding alert:**
If the pet is detected in the feeding region for a predefined period or repeatedly approaches the feeder without a corresponding decrease in food weight, the system must generate an abnormal-feeding alert and send to the owner's phone.

6. **Remote notification:**
Feeding-completion information and abnormal-feeding alerts must be transmitted over Wi-Fi and received by the owner's remote device within 10 seconds under normal Internet connectivity.

7. **End-to-end operation:**
The complete system must successfully demonstrate the following sequence without manual intervention:

BLE proximity detected
→ camera activated
→ pet presence confirmed
→ food dispensed
→ food weight monitored
→ feeding event classified
→ event information transmitted to the owner.

BusPlan

Aashish Kapur, Connor Lake, Scott Liu

BusPlan

Featured Project

# People

Scott Liu - sliu125

Connor Lake - crlake2

Aashish Kapur - askapur2

# Problem

Buses are scheduled inefficiently. Traditionally buses are scheduled in 10-30 minute intervals with no regard the the actual load of people at any given stop at a given time. This results in some buses being packed, and others empty.

# Solution Overview

Introducing the _BusPlan_: A network of smart detectors that actively survey the amount of people waiting at a bus stop to determine the ideal amount of buses at any given time and location.

To technically achieve this, the device will use a wifi chip to listen for probe requests from nearby wifi-devices (we assume to be closely correlated with the number of people). It will use a radio chip to mesh network with other nearby devices at other bus stops. For power the device will use a solar cell and Li-Ion battery.

With the existing mesh network, we also are considering hosting wifi at each deployed location. This might include media, advertisements, localized wifi (restricted to bus stops), weather forecasts, and much more.

# Solution Components

## Wifi Chip

- esp8266 to wake periodically and listen for wifi probe requests.

## Radio chip

- NRF24L01 chip to connect to nearby devices and send/receive data.

## Microcontroller

- Microcontroller (Atmel atmega328) to control the RF chip and the wifi chip. It also manages the caching and sending of data. After further research we may not need this microcontroller. We will attempt to use just the ens86606 chip and if we cannot successfully use the SPI interface, we will use the atmega as a middleman.

## Power Subsystem

- Solar panel that will convert solar power to electrical power

- Power regulator chip in charge of taking the power from the solar panel and charging a small battery with it

- Small Li-Ion battery to act as a buffer for shady moments and rainy days

## Software and Server

- Backend api to receive and store data in mongodb or mysql database

- Data visualization frontend

- Machine learning predictions (using LSTM model)

# Criteria for Success

- Successfully collect an accurate measurement of number of people at bus stops

- Use data to determine optimized bus deployment schedules.

- Use data to provide useful visualizations.

# Ethics and Safety

It is important to take into consideration the privacy aspect of users when collecting unique device tokens. We will make sure to follow the existing ethics guidelines established by IEEE and ACM.

There are several potential issues that might arise under very specific conditions: High temperature and harsh environment factors may make the Li-Ion batteries explode. Rainy or moist environments may lead to short-circuiting of the device.

We plan to address all these issues upon our project proposal.

# Competitors

https://www.accuware.com/products/locate-wifi-devices/

Accuware currently has a device that helps locate wifi devices. However our devices will be tailored for bus stops and the data will be formatted in a the most productive ways from the perspective of bus companies.