Home

Contents

• Introduction
• Project Outcome
• Initial Design
• Final Design
• Team Dynamic and Planning
• Design Documentation
  • Constraints and Standards
  • Architecture
  • Hardware Parts List
  • Schematic
  • Pictures
  • Software Flow Diagram
  • UI and UX
  • Maintenance
  • Test Report

Introduction

With dog ownership being so popular in modern society, we sought out to solve what we thought was a pressing issue. Dogs, like children, require care multiple times a day. Many dog owners struggle to run simple errands, maintain their social life, or even focus on their jobs due to their furry friend needing frequent bathroom breaks and play time. Our IoT DoggyDoor solves this issue. We took your everyday doggy door and made it smart. With a user friendly phone application, the pet owner can control the function of their doggy door. Whether that be by unlocking the door with the push of a button, or summoning their pet with the sound of a buzzer. One super smart feature that gives a pet owner more peace of mind is the ability to track their pets movement through a chip in their collar and allow for proximity access to the door. What this means is that, if the owner chooses, when their pet gets within a small range of the doggy door, the door will unlock and allow the pet to use it as needed. With our design, pet owners will now be able to go about their daily lives knowing their pets are safe, happy, and free.

Project Outcome

While our project did not follow all of our objectives, requirements, and constraints exactly as we wrote them in our proposal, in a general sense it follows them well. Throughout the semester as our project evolved we had to make some small changes to some of the original points we added.

Our objectives included custom options for the user to control how the door works, a method to interact with the dog in some way to train them to come back inside, the controller for the door being a smartphone interface, and an overall robust design to protect the house from the elements and security threats. These goals are all present in our project. The owner has the ability to enable or disable the Bluetooth tracking system, which allows the door to unlock when the dog is nearby and lock when it is not. Disabling the tracking allows the user to manually lock or unlock the door from the phone interface. The door is equipped with a buzzer that is activated from the phone interface; this is meant to be used to train your dog to come back inside without the owner opening the door and calling for their pet. The door is also equipped with three lock points ensuring security and protection from the elements.

Initial Design

The initial design for our project was a motor controlled french door (double door) that would open via a phone application or if the user chooses, whenever the pet is within a given range of the door. Our initial design also included IR sensors mounted on the door to avoid closing the door when an object or pet is in the way. The door was also equipped with one lock at the bottom for security. The user phone application would give the user control of the unlocking and locking of the door, a training buzzer for their pet, and live updates of the door’s current state whether that be unlocked, locked, open, or closed. The web application also would allow the user to turn on the collar tracking feature so that their pet could have proximity access to the doggy door without the need of their owner interfering.

Final Design

Some of our requirements that were set in our proposal were not fulfilled in our project. Because we bought a premade door, we don't have a system that opens and closes the door depending on the position of the pet, which was our first requirement. The reason for going with the premade door is that it allows the pet to push the door open as it pleases, but will still shut on its own. Our original design needed motors to open and close the door each time the pet was in proximity, which seemed to overcomplicate the simple idea. One benefit to the door we chose is that the pet can lay near the door without the door opening, say if the pet just happens to take a nap by the door. The prebuilt door also offers a more simple and “risk free” design. No need to worry about broken door motors or extra moving parts at risk of breaking in cold weather or from everyday wear and tear. Another concern with our original design was foreign objects and strain on the motors. If a foreign object were to get in the way of the current door, the door will not lock, and no stress will be placed on any of the components; whereas, in our original design, the motors would constantly be driving the doors even if an object was in the way. To avoid this, it would require extra programming to ensure that the door did not continuously try to open or close when it could not. Since there is not an automatic system for opening and closing, we determined that there is no need for a monitoring system that checks for any foreign object in the way of the door before it closes. However, the door does have a sensor that checks if it is fully closed before the locks are engaged and indicates on the interface if it is not completely closed. The last requirement that was not implemented was allowing the user to select a time frame when the dog can go in and out as they wish. One main reason we neglected to include this feature was time. The feature would allow pet owners to set specific time windows on a given day for when their pet could gain access to the door. With this, pet owners could go about their day and not have to worry at all about their pets' needs. Aside from those few requirements, all others were met. These include: unlocking the door when the dog is near, the door remaining locked or unlocked if manually chosen by the user with the tracking disabled, the lock and unlock process finishing within 2 seconds, the maximum distance the dog can go before being out of range (3 feet), and the system isn't easily compromised if forceful entry is used.

Despite us deviating from some of our requirements and not following our objectives exactly, our project meets all of our outlined constraints from our proposal. We did not take the actual weight of the final project, but it is unlikely that it weighs more than 15 lbs. The components we used all meet the industrial standards for operational temperature therefore our project is protected across a large temperature range. As mentioned in the last paragraph, any action processing is performed within 2 seconds, and the range of the Bluetooth sensor is about 3 feet. For the last constraint, we decided that the door should be able to withstand 50 lb-ft of force when locked. This was another constraint that we have not tested to get a definite result; however, we think that, with the three locking points, the door should be able to withstand that much force if not more.

Team Dynamic and Planning

We split our team up into a hardware team and software team. John and Mitch made up the hardware team and were responsible for any part of our project involving a physical component. John was mainly responsible for setting up the ESP32 WiFi and Bluetooth microcontroller to create the proximity sensor. Mitch was mainly responsible for setting up the lock and unlock system as well as mounting all of the components to the door itself. Isaac and Pamela made up the software team, and they were responsible for setting up the phone interface as well as any Python code that the Raspberry Pi needed to run to control the door or process incoming signals from the ESP32 or the Arduino.

To keep track of our progress during the lab, we used a variety of applications. To create an overview of the tasks we wanted to accomplish, we created a Gantt chart, which outlined each task along the y-axis and each week along the x-axis. Each task has a tentative time frame where we want to start working on that task and when it should be finished. We used Pivotal Tracker to keep track of who is working on what and for a more detailed and up to date version of our Gantt chart. For code management, we used GitHub to store files and to easily share our code with other members of the group and keep track of previous versions. These tools were very useful to keep our group organized and on task, which led to smooth progression throughout the project.

As mentioned before, we accomplished almost everything that we originally intended to do; however, there were still some tasks that we were not able to implement. We think the biggest factor that led to that was time. Our project not only has large software and hardware components, but it also has considerably large mechanical components. To minimize the amount of time that we spent learning mechanical engineering concepts to design the door from scratch, we opted to buy a premade door and attach our electrical component to that. Because of this, we had to abandon some of the features that we mentioned in our project proposal. Another instance of this happening was with a treat dispenser that we started to plan, but we decided to discard the idea since we were unable to find a simple dispenser online that we could build off of (similar to our door). It is important to note that the treat dispenser was not a part of our initial proposal, but was something we hoped to get to if time permitted.

Figure 1 shows our GitHub commit statistics throughout the duration of the process. In the top graph, you can see that we were planning each component of our project and gathering parts until early February and then we took a break in early March for spring break. There are a few points regarding each team member's contributions that should be addressed. John's total lines added is significantly higher than others because the files that are used to program the ESP32 are about 46,000 lines each and there are two copies on the repository. The actual Arduino .ino files are around 100 lines each. The second point that needs to be addressed is Pamela's low commit count. Her and Isaac were working together on the control interface but only Isaac was committing the code from his end.

Design Documentation

This design consists of a door that is divided into two sections that opens like a typical french door. We planned to have two sensors to detect if there was a pet in the way and thus would not shut if something was in the door. After researching multiple types of doors and what sensors to use, we drastically changed the final design of our door. Now, we have a pre-built door that has a magnetic strip on the bottom so that when nothing is acting on the door, it will remain shut until force is applied against it. This design is a typical flap of a dog door; we decided to go with this pre-built door instead because of safety issues. This new door will always remain shut when not being used allowing for weather and bugs to not enter if the dog is not currently using the door. Now, we don’t have to use sensors to detect if the pet is in the way because the door will always default to being shut. We then incorporated a magnetic strip sensor on the door to tell if it is open or not. This is a very simple device that has been very reliable. The user can see on the phone application if the door is currently open or closed. Originally, we were going to have two Arduinos to control the locking mechanism of the door, but we changed it to one Arduino in our final design. This helps save power and simplicity of the overall design.

For the software side, we changed our plan entirely. We originally planned to use C++ and SQL database for control of data. To keep our software design even simpler, we used the default language of a Raspberry Pi, which is Python. Then, we completely abandoned the SQL database because we did not want to rely on a service entirely. The Raspberry Pi is capable of hosting its own server. If for some reason it fails, a simple reset of power will fix the problem. However, we did use C++ for controlling the ATmega328P.

Our design does meet most of the requirements and specifications we promised. The door can unlock and lock by the request of the user. The door can detect if the door is open and let the user know from a live status update on the application. The door is a very sturdy design that can withstand a force of 50 lbs of force. The door is weatherproof from the outside of the homeowner. The door responds within two seconds of the request from the user. The door, upon user request, will lock or unlock based upon the pet’s position (if it is nearby or not). The owner can summon their pet with a buzzer and train their pet to come inside after hearing that buzzer. The door is controlled via WiFi from the user's phone. Some of the requirements that were not met are as follows: Controlled timer for when the door is locked or unlocked. Since the user has access to the door and if the pet is nearby at all times, we decided it was better to keep it a manual decision if the door was to be locked or unlocked. Another requirement we did not incorporate was when the system was compromised. If for any reason someone does break into the house through the door, the user will not know. Only if the door loses power all together will the user know if something is wrong. As mentioned before, we did not use C++ in the Pi or SQL because we found better alternatives.

Originally, we were going to design a door that would simply open its door upon the user’s request or when the pet was nearby. This, however, is a terrible design when it comes to security. Having a door just constantly open is a bad idea and can let other animals, bugs, or weather inside the home. We then went with a better design that stays shut all of the time and has three small plastic locks that can be slid into place from our servo motors. The door flap stays shut from a built-in magnetic strip, and can easily be opened when the three plastic pieces are unlocked, and some small amount of force is applied to the door.

We were originally going to have IR sensors to detect if there was something blocking the door. We went with a better design decision of using a magnetic strip to determine if the door was open. We also had to incorporate this because now our door remains shut as the default. In our original design, we were going to actually open the door but now that is not necessary. This design tradeoff will also result in better power consumption.

Another important decision that we had to take into account was the unlocking and locking for when the pet is nearby. We were originally going to use a NFC tag of some sort, but we realized a more reliable and secure option was a Bluetooth tag. Each tag has its own specific MAC address that the door will only unlock if it finds that exact address. This significantly improves the security of the door.

One major tradeoff we decided on was not including a treat dispenser. We did not have this originally in the proposal, but we thought about it as the semester went on and would attempt to incorporate it if we had the time and resources. Unfortunately, a final design was never reached that satisfied us. We decided instead to make the overall product look better and minimalistic with less maintenance and not include a treat dispenser.

Constraints and Standards

The following System Constraints were from our final proposal and were all satisfied in our final design:

• SC1: The system as a whole shall not weigh more than 15 pounds.
• SC2: The system shall withstand the industrial temperature range of -40°C to +85°C.
• SC3: The system shall respond to all user requests within 2 seconds.
• SC4: The system shall detect if the pet is nearby within 3 ft of range.
• SC5: The system shall be able to withstand 50 ft pounds of force to the locked door to avoid break-ins.
• SC6: All electrical terminations will be properly fitted. i.e. USB-C charging port.
• SC7: All hardware will be securely fastened to the doggy door with proper terminations and short circuit avoidance.
• SC8: Doggy Door and phone application will connect via WiFi.

After satisfying all of our previously stated constraints, we identified a new list of constraints that we did/did not satisfy:

• SC9: The system should be rain, snow, dirt, and dust resistant.
  • This constraint was partially satisfied. Due to the door being mounted on the interior of the house, water, snow, and dirt resistance was not as big of a concern given our time frame. While some components remain resistant to all elements, the doggy door and its components as a whole do not. Our device however is resistant to any regular household dust build-up, so there is no concern of the device losing functionality inside the owner’s home.
• SC10: The device and user interface must be secured and accessible only by the owner.
  • We were able to satisfy this new constraint by adding software security to our user application. The user is required to enter a username and password in order to access the functionality of their door. Without this access, the door will remain in its most recently set state. We also ensured that no other Bluetooth device could access the door’s feature. In order to do this, the collar's unique Bluetooth identity is registered with the owner's device from production. All owners and their respective doors would have a complete unique Bluetooth identity with no possibility of other Bluetooth devices interrupting functionality.
• Our design will use C++ programming language standards.
  • Our design used a combination of Arduino IDE and Python.
• SC12: Our design will utilize SQL database standards.
  • We did not use a database in our project and therefore did not need to use SQL.
• SC13: Hardware and the Arduino will use I2C communication.
  • Our project did not use any component(s) that use I2C serial communication. We used direct connections with level shifters to adjust the voltage going to the Arduino, Raspberry Pi, or ESP32.
• SC14: Our design will utilize HTML and CSS programming standards.
  • We used HTML and CSS to design the phone interface.
• SC15: Our design will utilize Python programming standards.
  • We used Python for the PiServer, dynamic elements on the phone interface, and setting the output pins on the Raspberry Pi.

Architecture

The hardware schematic for this project is shown in Figure A. The foundational components of our project are the Raspberry Pi 4, the ATmega328P and our 3 Servo motors. The three servos are controlled by their own arduino IDE script through the ATmega328P that has the correct angles of rotation, timing, and safety logic for each of the servos, allowing them to unlock and lock the door with great precision. The Raspberry Pi hosts a server that runs our web application for the user. From here, the Pi and the ATMega328P talk to each other through a voltage logic level shifter. This way, when a user presses a button on the application, the ATmega328P also receives the signal and manipulates our servo motors to unlock or lock the door.

Along with these foundational components are some more technical interworking components such as our Bluetooth chip that allows for a wireless connection between the functions of our door and the collar of the user's pet. This Bluetooth chip, the ESP-WROOM-32 works with our voltage logic level shifter and Raspberry Pi to receive signals from the web application. Those signals begin, whether or not the user has turned “collar track” on or off, and if the collar is close to the door, requiring it to unlock if “collar track” is enabled.

Another important component is our magnetic reed switch. This switch is mounted to the door and indicates through a red LED whether or not the door is open or closed. This LED is connected to the ATmega328P, and can send a signal to our Raspberry Pi if it is open, telling the Pi to disable the locking function until the door is closed. All of these components work together to give a seamless, functional, and smart doggy door. For a complete list of hardware parts, see Table 1.

Hardware Parts List

Item	Quantity	Data Sheet	Description
Raspberry Pi 4	1	Click here	Used to deploy our server and communicate with ATmega329P and ESP32.
ATmega328P	1	Click here	Used to control servo motors and other small components. Also communicates with Pi.
ESP-32	1	Click here	Used to enable collar tracking. Communicates with Raspberry Pi server.
HiLetGO Level Converter	2	Click here	Used to allow proper communication between the Pi and the ATmega328P since the Pi communicates on 3.3V and the ATmega328P communicates on 5V
SG90 Servo Motor	3	Click here	Used to control the locking and locking of the doggy door.
Magnetic read Switch	1	Unavailable	Indicates whether the door is open or closed via an LED upon connection.
LED	2	N/A	Red is used to indicate if the door is open or closed. Green is used to indicate power.
Buzzer	1	N/A	Used as a training feature for the user to signal to their dog to do a given command.

Schematic

Pictures

Software Flow Diagram

Described in Figure B is the overall flow chart for all of the software that is run across the Raspberry Pi, ATmega328P, and ESP32. All of the devices are similar when they first start up when the door is initially plugged in. Once receiving power, they are booted up normally and configure their pins to either output or input. Additionally, the Raspberry Pi starts the server automatically when an internet connection is established.

The Raspberry Pi is responsible for hosting the server and communicating with both the ATmega328P and ESP32. After initial bootup, the Pi loads a login page for the user to sign into. The user has to fill in the correct username and password in order to advance to control the door itself. After successfully logging in, the Pi then waits for GET and POST requests from the user. By default, GET requests will run every three seconds automatically to update the user with the most recent data from the hardware on the door (e.g. if the pet is nearby). During every GET request, the Pi communicates with the ATmega328P and ESP32 to receive if the door is locked or unlocked, pet is nearby or not, and if the door is currently open or closed. Once this information has been updated on the server of the Pi, it is sent to the user in the form of an HTML page for the user to access. A POST request is made when the user decides to lock, unlock, enable/disable pet tracking, summon pet, or logout. During a lock, unlock, or pet tracking POST request, the Pi will talk accordingly with the ATmega328P to properly follow the command that the user requested. If the user creates a ‘Summon Pet’ POST request, a buzzer is enabled for the pet to hear. Lastly, if a ‘logout’ POST request is created, the user is brought back to the login page and must re-login with the correct credentials to access the door again.

The only job of the ATmega328P is to lock/unlock the door accordingly and let the Pi know when it is locked/unlocked or if the door is open/closed. There are different conditioned if statements in the ATmega328P to tell it if it should lock or unlock when the user requests or when pet tracking is enabled. There is a simple magnetic strip that will change states if the door is open or closed, and the ATmega328P relays this information to the Pi when that change happens. The ATmega328P is also always letting the Pi know if the door is currently locked or unlocked. Lastly, the ATmega328P will only go into its locking function if the door is closed.

The ESP32 has the simplest code flow of all devices. The device was programmed using the Arduino IDE and there are libraries that contain functions to scan for all nearby BLE devices. We then modified the code to look for the MAC address of one of the BLE tags we purchased. Once it has found the tag and the tag’s RSSI (Received Signal Strength Indicator) value is above a certain threshold, the ESP32 signals to the Pi and the ATmega328P that the tag is near. The Pi and ATmega328P then deal with this information accordingly. The ESP32 begins a scan for the tag every two seconds to always update to the user when the pet is nearby or not.

UI and UX

Figure C shows the mobile interface of our application. It prompts the user to log in with a unique username and password. If the user enters an invalid username and/or password, they are denied access to the doggy door. A message will display indicating that the credentials are invalid. Otherwise, valid usernames and passwords allow full access to the doggy door.

Figure D shows the main page of the mobile interface upon successful login. At the top of the page, there are live updates of the status of the lock, the status of the door, and if the pet is nearby (if the Collar Track feature is enabled). Each feature has short text beneath it, which describes the functionality of the button. For security purposes, the user is prompted to log out at the bottom of the page.

Maintenance

Our product requires minimum maintenance by the user. The server that deploys the application for doggy door is controlled and operated by IoT DoggyDoor. The user will have to change out the battery on their pets collar every 2-3 months to allow for the best functionality. Any potential software updates for the door would be deployed to the user via an update to their phone application.

Some enhancements that could be made to our doggy door would be a more slender design. Due to our limitations in parts manufacturing abilities, we have components mounted inside of obtrusive and bulking containers that take away from the pleasant design of a normal doggy door. Some other limitations to our design were the mounting of our motors and the material used to maneuver our three locks. Our servo motors are made of plastic and mounted via a strong adhesive. In the future we would have liked to use aluminum casings and swing arms to move our locks. This design does not affect safety or strength of the door when it is locked. One extension of our product that we were interested in pursuing if we had the time was a treat dispenser for the door. This door mounted treat dispenser would be controlled by the owner as a way to reward their pets for good behavior.

Test Report

Number	Description	Requirements	Results	Result Notes
1	Web application unlocking and locking	The user should be able to control the unlocking and locking of the door from the application with a delay no longer than 2 seconds.	PASS	Response time is satisfied and the status of the door updates
2	Web application collar tracking	The user should be able to toggle on or off the collar tracking capabilities with a delay no longer than 2 seconds.	PASS	Response time is satisfied and the status of the door updates in real time inside of the application.
3	User log-in page	User log-in page should be secure to the user's unique username and password.	PASS	False username and/or password attempts properly deny access to the doggy door. Correct usernames and passwords allow full access to the doors capabilities.
4	Bluetooth collar chip response time	When the Bluetooth collar chip is within range of the door and Bluetooth collar tracking is turned on by the user, the door should unlock/lock with a delay no longer than 2 seconds.	PASS	Bluetooth collar chip response within the time restraint and functions as expected. When Bluetooth collar tracking is turned off, the collar does not have access to the door’s unlocking and locking features.
5	Web application startup	The user web application should deploy when the device is connected to power. The device should be ready in less than 2 minutes.	PASS	The server deploys when power is connected and remains on until power is disconnected. The server deploys and the device is ready within our written time constraint.
6	Unlocking and locking live update	The user application should display a real time update on the current status of the door - unlocked or locked. The status should change each time the page refreshes itself.	PASS	The application displays the correct status of the door locks each time the server refreshes the webpage.
7	Pet nearby update	The web application should give a real time update on if the user's pet is near the door. This update should take place each time the server refreshes the web page.	PASS	The owner is able to see a real time update on if their pet is near the door or not. This update happens within our time constraint.
8	Door opened or closed	The web application should display a live update on whether the door is open or closed. This data should be displayed to the user each time the server refreshes the web page.	PASS	The user is able to see a live update on the door’s status (open or closed) each time the web page is refreshed by the server.
9	Door lock when door is open	The door should not lock when the door is open.	PASS	The door will not lock when the door is open, it will wait until the door has been closed for a full second before locking.
10	Servos perform locking/unlocking maneuver	All three servos should lock or unlock the door when commanded in under 2 seconds.	PASS	Servos work as needed and satisfy time constraints.
11	Industrial temperature range	All components should be able to withstand the standard industrial temperature range of -40°C to +85°C	PASS	We chose components that were manufactured with this temperature range in mind, thus all components working together will be able to withstand this range. The door remains on the interior of the house so this was not a huge concern.
12	Physical security	The door should be able to withstand the average 50 lb force punch in the event of a break-in, etc.	PASS	The door’s three locks work together to provide a strong, safe, and secure door.
13	Summon pet	The user should be able to summon their pet via a buzzer from the web application.	PASS	The user is able to press a button in the application that sounds a quick buzzer for their pet. This is a training feature that the owner and their pet would have to work on.
14	Door auto close	The door should automatically close when not being used.	PASS	The door is closed via a magnet. When the door is left to swing free, the magnet slows the door to a stop and holds it in position for it to be either locked or unlocked.
15	Logout function	The user should have the ability to log out of their doggy door account to avoid security risks.	PASS	The web application is equipped with a logout button to allow the user to disconnect from their doggy door but still have the door function as requested.
16	LED status Indicators	RED and GREEN LED should indicate if the door is open or closed.	PASS	LEDs light up when the door is open or closed in green and red respectively.
17	Weather seal on door	The seal around the door should be weatherproof.	PASS	The door is equipped with a brush seal around the entire door to keep wind, weather and debris from entering into the user's home.
18	Bluetooth tag and collar	The bluetooth tag should remain fixed to the pet's collar under most extreme circumstances, such as pet running, rolling, sleeping, jumping, etc.	PASS	Tag stays fixed to the pet's collar very well.
19	Wiring	All wires should remain fixed behind the door to avoid loose wiring and risk of damage.	PASS	Wires are fixed in place to avoid damage or pet interference.
20	Bluetooth collar tag startup	The bluetooth collar tag should connect to the bluetooth sensor in the door within 2 minutes of being turned on.	PASS	Bluetooth connection is established after 25 seconds +/- 10%