Skip to content

Home

Jump to bottom
Breno Fernando Guerra Marrão edited this page Jun 13, 2024 · 45 revisions

Introduction

In an era characterized by rapid technological advancement, the use of technology for the purpose of security enhancement has become increasingly widespread. This is a reality across various contexts, including residential settings. In this project, our focus lies in developing a system specialized in residential security: a doorbell camera. Through the use of motion detection technology and wireless data transmission to smartphones, this system aims to provide real-time monitoring, instant notifications, and convenient remote access to recorded footage in order to seamlessly elevate home-security.

Index

  1. Description and Objectives
  2. Requirement Analysis
  3. Modeling
  4. Specification
  5. Hardware and Software Architectures
  6. Project planning
  7. Integration
  8. Results
  9. Conclusion

Description and Objectives

The goal of this project is to create a doorbell camera that could be installed at the door of a house. The camera system should be capable of:

  • Activating upon doorbell press or motion detection.
  • Recording images in "stop-motion" format, consisting of several photos instead of a continuous video to conserve storage space.
  • Stopping the recording after 5 minutes of no motion detection.
  • Notifying the user on their smartphone upon detection.
  • Allowing users to view recorded "stop-motion" images and delete them or request a live video stream, via the smartphone app.
  • Indicating that the camera is recording through the activation of an incorporated red light.

Requirement Analysis

Functional

  • Presence Detection:

    – Detection of presence at the door must occur within 3 seconds.

  • Recording Initiation:

    – The camera should start recording within 3 seconds of either motion detection or doorbell press.

  • Video Stream Request:

    – Requesting a video stream from the smartphone app should have a latency of less than 10 seconds.

  • Minimum Presence Detection Range:

    – Presence must be detected at a minimum distance of 50 cm from the camera.

Non-functional

  • Reliability:

    – The system should ensure consistent detection and recording functionality.

  • Usability:

    – The smartphone application should have an intuitive interface for users to access live streams, recorded images, and camera controls.

  • Power Efficiency:

    – Power consumption should be optimized in order to prolong battery life and reduce energy costs

Modeling

Actor model

The actor model for the Doorbell Camera project involves four main interacting actors responsible for different tasks within the system:

  • Sensor Actor (Arduino):

    • Receives input from the motion sensor and doorbell button.
    • Notifies the Central Actor (Raspberry Pi) upon detecting motion or doorbell press.

  • Camera Agent (Raspberry Pi):

    • Captures images or streams video from the camera.
    • Controls the recording process based on commands from the Central Actor.
    • Manages the storage of recorded data.

  • Database Agent (PostgreSQL on Raspberry Pi):

    • Manages the database operations, including storing and retrieving data.
    • Responds to requests from the Central Actor or User Agent for accessing stored information.

  • User Agent (Android App):

    • Communicates with the Central Actor to request live video streaming or access recorded data.
    • Displays notifications to the user regarding doorbell presses or motion detection events.
    • Allows users to interact with the system, such as viewing recorded footage or controlling camera settings.

Actor_Model

In this actor model, each agent represents a distinct system component responsible for specific tasks. The Central Actor (Raspberry Pi) coordinates the system by receiving input from the Sensor Agent, issuing commands to the Camera Agent and Database Agent, and responding to requests from the User Agent. This modular approach enhances scalability, flexibility, and ease of maintenance.

Specification

Here is the specification of the materials used

  1. Arduino Uno Rev3
  2. Arduino WiFi Shield R3
  3. Male-to-Male Wires (x4)
  4. USB WiFi Antenna
  5. USB Web Camera
  6. Tactile Button
  7. Red LED Module
  8. 1000 Ohms Resistor
  9. Raspberry Pi 1 Model B+
  10. 32 GB SD Card (x1)

Hardware and Software Architectures

Hardware Architecture

The hardware architecture diagram illustrating this system contains 4 components:

  1. Arduino + Movement Sensor + Button + Wi-Fi Shield + Red LED
  2. Raspberry Pi
  3. Camera
  4. Android

The communication between the Raspberry Pi and the Arduino is bidirectional and is done through a Wi-Fi channel. Similarly, Raspberry Pi and the Android also communicate bi-directionally through a Wi-Fi channel, acting as a client-server interface. The communication between the Raspberry Pi and the Camera is done through a cable, where the Raspberry Pi sends commands to the camera and receives information (videos) back.

Hardware Architecture

Software Architecture

The software architecture of this project consists of four main components:

  • Sensor Agent (Arduino):

    • Responsible for detecting motion and button press events.
    • Triggers the Camera Agent upon motion detection or button press.
    • Communicates with the Raspberry Pi to convey sensor data and event notifications.

  • Camera Agent (Raspberry Pi):

    • Controls the camera module to capture images in ”stop-motion” format upon triggering by the Sensor Agent.
    • Manages image storage and stops recording after 5 minutes of inactivity.
    • Interfaces with the Database Agent to store image data and with the User Agent to provide live video streaming upon request.

  • Database Agent (PostgreSQL on Raspberry Pi):

    • Handles data storage and retrieval, particularly for recorded ”stop-motions”.
    • Ensures data integrity and security.
    • Facilitates communication between the Raspberry Pi and the User Agent for data access and management.

  • User Agent (Android App):

    • Provides a user interface for interacting with the doorbell camera system.
    • Receives notifications on the smartphone upon doorbell press or motion detection.
    • Allows users to request live video streaming, view recorded ”stop-motions,” and delete stored images.
    • Communicates with the Raspberry Pi and the Database Agent to fetch data and control camera operations

Software_Schema

The software components interact with each other in the following ways:

  • The Sensor Agent (Arduino) communicates with the Raspberry Pi to trigger camera recording and sends event notifications.
  • The Camera Agent (Raspberry Pi) interfaces with the Camera module to capture images and stores them in the PostgreSQL Database.
  • The Database Agent (PostgreSQL) manages data storage and retrieval, ensuring seamless access to recorded images.
  • The User Agent (Android App) interacts with the Raspberry Pi and the Database Agent to fetch live video streams and manage recorded images.

This hardware-independent software architecture allows for easy maintenance, and interoperability between components of the doorbell camera system.

Project Planning

At the beginning of the project development, we created a Gantt chart to outline the planned implementation over the weeks allocated for the project.

Gantt Diagram

However, as the weeks progressed, we encountered several challenges that significantly delayed our development. The need to change Raspberry Pi models and the non-functionality of our Raspberry Pi camera resulted in considerable time lost while waiting to secure new equipment. This delay severely impacted the implementation of the camera components, as suitable cameras were not readily available, requiring extensive effort to find a compatible alternative.

Additionally, the limitation of running only a single thread on our Raspberry Pi caused further delays as we explored alternative methods to implement camera functionalities.

Overall, most other project components were implemented roughly within the estimated time-frame. However, without the camera component, we were unable to fully integrate and test all system functionalities together until very close to the project deadline.

Integration

We designed and implemented all parts of our project separately. When it came to integrating these components, our primary task was ensuring the correctness of communication addresses. One challenge we encountered was the necessity of hard-coding these addresses, which would not be feasible in a real-world environment.

Results

Arduino

The outcomes with the Arduino were positive. Despite not having the movement sensor, we addressed this issue in consultation with the professor and opted to utilize only the tactile button. Integrating the sensor would have been straightforward: connecting it to the Arduino on the hardware side and adjusting the software to monitor inputs from either the button or the sensor to trigger messages sent to the Raspberry Pi.

Despite this constraint, our Arduino successfully sends Wi-Fi messages upon button presses and responds to incoming signals to control the light, demonstrating its functionality in communication and responsiveness.

Raspberry Pi

We encountered several challenges with the Raspberry Pi, which prevented us from completing the project as expected.

  1. Initial Issues: The selected Raspberry Pi lacked the necessary port for the camera module. We switched to another model, which then revealed an absence of Wi-Fi capability. We compensated for this by using a USB antenna for connectivity.
  2. Hardware Limitations: The only other available Raspberry Pi model supports only one thread at a time, significantly hampering our implementation. This limitation made it challenging to integrate the Raspberry Pi API, which manages interactions with the database, mobile application, and Arduino components, while concurrently connecting to the camera using OpenCV. Ideally, the camera should run in a separate thread to allow users to request information from the Raspberry Pi even during active recording.
  3. Workaround: To address this issue, we had to request camera recordings within the same thread used by the Raspberry Pi API. Consequently, while the camera is recording, the API remains idle and cannot perform any other tasks. As a result, users are unable to interact with the Raspberry Pi or request data during this period. While this solution falls short of our ideal scenario, it was the best workaround feasible with the hardware available to us.
  4. Camera Integration: We successfully integrated the Raspberry Pi with the camera, enabling it to initiate recordings upon receiving a signal from the Arduino indicating a tactile button press. These recordings are stored as stop-motion videos on the Raspberry Pi.
  5. Database and API: We created a database to store information related to these recordings and an API that can retrieve this information and deliver it to Android devices, along with any requested videos.

Flutter

For the user interface component, we successfully developed a mobile application that interfaces with the Raspberry Pi. This application enables users to:

  1. Request the timestamps of videos stored on the Raspberry Pi.
  2. Select specific videos for viewing by choosing a valid timestamp. The selected videos are successfully transmitted from the Raspberry Pi to the mobile app, allowing users to view them on their phones.
  3. Initiate a livestream from the camera, enabling real-time viewing of the recording. Users can start and end the livestream at their convenience, enhancing the application's functionality and user experience.

Overview

The initial objectives and the final outcomes can be summarized as follows:

  1. Doorbell Camera Activation: Our initial objective was to create a doorbell camera system that would activate upon a doorbell press or motion detection. While we successfully implemented the activation upon doorbell press using a tactile button, we were unable to include motion detection due to the unavailability of the sensor. Despite this, the system still meets the primary goal of activation upon user interaction.
  2. Stop-Motion Recording: We aimed to record images in a "stop-motion" format to conserve storage space. This was successfully implemented, and the Raspberry Pi efficiently stores these recordings.
  3. Manual Recording Management: An objective was to stop recording after five minutes of no motion detection. Since motion detection was not integrated, this specific feature was not applicable. However, recordings can be managed manually as needed.
  4. User Interaction: The application allows users to view recorded "stop-motion" images and request a live video stream, fulfilling the objective of providing access to both recorded and live footage through a mobile interface.
  5. Visual Indication of Recording: The system indicates that the camera is recording through the activation of an incorporated red light, meeting our objective to provide a visual indication of recording status.

Conclusion

In conclusion, this project successfully achieved most of its initial objectives, despite facing several challenges related to hardware limitations. We managed to integrate the Raspberry Pi with a webcam and develop a mobile application that provides users with access to recorded stop-motion videos. The absence of a motion sensor was mitigated by focusing on tactile button functionality, which proved effective in triggering recordings.

Despite the inability to reconcile the connection to the camera and the use of the Raspberry Pi API to request a livestream through the mobile app, we were still able to simulate this functionality with a Python script that acted as a Raspberry Pi simulator.

The development of a robust API and a user-friendly mobile interface enhanced the system's overall functionality and user experience.

While some objectives related to motion detection and livestreaming were not met, the project demonstrated a comprehensive integration of hardware and software components, resulting in a functional doorbell camera system.

Future work could focus on incorporating motion detection and further optimizing hardware compatibility to fully realize the initial project vision.

Clone this wiki locally