After landscaping we found our front yard had become "the" place for the neighborhood dogs to do their business to the point where plants were being impacted. After having marginal success, politely asking the owners to not have their dogs use our yard a solution requiring dog detection was envisioned. While the use of a high powered ultrasonic signal ("dog whistle") when a dog was detected was the first consideration, we realized we needed to condition the dog owners, not the dogs. With this in mind the larger system is comprised of a dog detection system and a sprinkler controller which can turn on segments of the yard as a deterrent to the owners, as most don't want a wet dog when they return home and certainly don't want to get wet themselves. The corresponding sprinkler controller can be found here:

A more interactive description of this project can be found here.

SprinklerController - Raspberry Pi Flask Bootstrap 4 implementation

• Continuous monitoring for dogs with accuracy > 90%
• A precision of > 75%, as false positives are not much of an issue - people will stay dry if they stay on the sidewalk.
• Low computing requirement, Raspberry Pi or similar power consumption
• Text message notification of dog detection
• E-mail notification with labeled detection image
• Sub second latency
• Manual override
• JSON client to message the sprinkler controller
• Robust, must survive power outages and software lock up. When running the Pi as hard as this application does, the system locks up about every two weeks without a watchdog.
• Remain cool enough to safely operate inside our home
• Silent or near silent operation

This provides a dog / cat detection application running an a Raspberry Pi with a Raspberry Pi High Quality Camera, and a Arducam wide angle (6mm) lens. This application uses the SSD Mobilnet V2 Single-Shot multibox Detection (SSD) neural network targeting mobile applications, running on OpenCV. V3 was available during development; however, there appeared to be incompatibility between the .pbtxt definitions and OpenCVs implementation and was not adopted. The goal of the system is as quickly as possible detect the presence of a dog in our front yard, typically on or near the sidewalk and send a notification to a separate system on the same subnet.

SMS notifications (without a SMS service) are generated for free when a dog has been detected and sends an email with the detection image including the classification regions and their confidence scores. Targeting a Pi 4, the system uses threading to both maximize the recognition frame rate and avoid messaging and network delays from impacting the frame rate. To maximize the frame rate, a digitally locked loop is implemented where delays are inserted following processing of a frame (in a thread - called a phase in this implementation) to match the average delay of the system. In each phase a captured image runs in its own thread through the object classification (the single most CPU intensive process), such that multiple images have object classification running in parallel, the results for a phase are dequeued immediately after kicking off the phase + NUMBER_OF_PHASES-1. The Pi4 has four cores so there is no value in exceeding four phases. In addition the neural net is IO limited, so there is diminishing gains in increasing the number of PHASES beyond 3. The software is configured to support arbitrary number of phases, so this can be optimized to different hardware.

The camera's viewport is configured to have a wide aspect ratio, reflecting the visual region of interest. The neural net is designed around a 1:1 aspect ratio and is tolerant to some variance in aspect ratio, but demonstrated significant degradation for an aspect ratio of 10:3. To maximize accuracy motion detection is applied to the image and the object recognition is run on a 1:1 portion (IMAGE_HEIGHT x IMAGE_HEIGHT) centered on the motions centroid. As configured the system has a frame rate of ~2.1 fps.

When running all four cores are typically in the mid 90s% load, so some form of cooling is needed. Given the requirement for near silent operation a passive cooling solution is preferable and the Geekworm Raspberry Pi 4 Case, is very effective. Unfortunately the need for WiFi range in this application WiFi is important and this case places a large block of Aluminum around the antenna, so the case was modified to create a cutout in the top side metal around the antennas. Peak memory usage is around 3GB so the 4GB of RAM would be sufficient; although, I conservatively chose the 8GB version for this project.
The application expects a RAM disk @ /var/ramdisk/ to store a cyclical list of captured images.
This is done to:

1. avoid wear on the SD card - SD card writes have a real impact on the operating life
2. improve the speed performance when needed most

Given the raised operating temperature of the system a night mode has been implemented to lower the power consumption when the image is too poorly illuminated to be useful. The digital lock loop slows down by a factor of ~120 in this mode with the goal of preserving energy and extending the life of the system (heat has an exponential impact on lifespan in almost everything, electronics included).

This solution is intended to run stand alone indefinitely and uses the OS supplied watchdog driver to interface to the Broadcom's watchdog timer. The use of watchdogs in Linux operating systems takes on a different context and purpose from embedded systems. In Linux severs the overriding purpose of the watchdog is to prevent bricking of the server itself. Unfortunately, when the original Desbian watchdog solution was implemented the authors created a name space collision when they created the daemon which would monitor other processes within the system and take responsibility for either petting a HW watchdog or maintaining a SW monitor in lieu of one, this software was also named watchdog. So configurations named WATCHDOG are either for the daemon or the driver; however, I have yet to find clear documentation that delineates between the two. Sensibly, only one SW instance is allowed to connect to the drive at a time, so if the daemon "SW watchdog" is enabled other processes are locked out from connecting to the driver. The watchdog daemon has been designed to monitor processes at the process ID resolution, resetting the system of services such as network communication cease to operate. Verifying operation via process ID is not effective for a multithreaded application, such as this one where individual threads within the application need to be monitored. As a result the hardware watchdog is called through the watchdog driver, via an os call. This implementation does not invoke the watchdog daemon; but, rather directly interacts with the watchdog driver. For this to work the watchdog can not be started at the system level. This application as an alternative owns the watchdog function and monitors critical thread(s) with the assumption that if the critical infrastructure relative to the application fails the application will fail with it. The watchdog implementation is such that the watchdog is not enabled until the application reads the ENABLE_WATCHDOG parameter from a configuration file. When it does so it writes a working configuration file to the RAMDISK to allow remote determination of the configuration state. The configuration file provides a safety measure for disabling the watchdog, as deleting or renaming the config file will disable the watchdog the next time the application is started. When first running the application it is recommended to not enable the watchdog.

To start the application following either a loss of power, including a watchdog event, a systemd service is created. See instructions in DogDetect_README.txt for installation, enabling and disabling the service.

The repository contains

• The main script, DogDetect2.py
• DogDetect_README.txt - instructions for setting up RAMDISK and systemd based init startup - needed for restarting image following watchdog
• Configuration file for enabling the watchdog, sc_config.txt
• DogDetect.service - the init configuration file for starting DogDetect2.py with systemd
• ssd_mobilenet_v2_coco_2018_03_29.pbtxt - text topology definition of the SSD MobileNet TensorFlow protocol buffer. OpenCV requires this "map" file in addition to the protocol buffer. There are methods to generate this file from the protocol buffer binary; however, I simply downloaded one.
• ssd_mobilenet_v2_frozen_inference_graph.pb - SSD MobileNet TensorFlow protocol buffer binary. For the curious a solid explanation of the SSD implementation.
• Images - Sample output images from classification

I would strongly encourage the use of a visual debugging suite. When I started developing on the Pi I ran VNC sessions, with PyCharm running locally on the Pi. On a completely separate project (AI running jobs on AWS servers) I became aware of the power of Microsoft Visual Code. I have never been a fan of Microsoft as they have regularly disappointed with how they have spent their R&D on the office suite, MS Project, and Windows; however, Microsoft Visual Code is so well thought out and so well integrated, I've switched all of my project dev environments over. The effectiveness of the remote installations and extensions is truly impressive. Depending on your local machine setting up an X11 connection to see the graphical output from the Pi may or may not be straight forward. To install this on an Linux / macOS / Windows platform (assuming you already have python installed):

1. setup / configure the Pi (you will need the IP address)
2. install the clone / download the repository
3. install the case, carefully feeding the camera's cable through the opening in the top of the case. The system should be able to run without a case; however, the temperature will rise pretty close to the operating limit of the Pi
4. create the RAMDISK (instructions in DogDetect_README.txt)
5. create your private.py definition file - see definitions with import from private in DogDetect2.py
6. modify sc_config.txt to turn the watchdog off ENABLE_WATCHDOG=0 or move the file from the DogDetect2.py directory
7. run DogDetect2.py. When not running in service mode, the application will populate a window with the current frame including the object detection bounding boxes with confidences and a frame rate. Running under Microsoft Visual Studio Code, I have yet to find the working incantation for displaying these images on the host. For debugging with image related tasks, the best solution I have to date is to run a debugger (PyCharm in my case) natively on the Pi and VNC server. Editing on PyCharm executing on an Pi4 over a VNC connection is manageable, but slow enough you will wish it was faster. I would hesitate to run PyCharm on a slower Pi.

I have built working systems with both the OpenCV implementation and TensorFlow in the Pi and find the OpenCV implementation more straightforward. I've written my own models in both TensorFlow and Pytorch and find Pytorch easier to work with even if it lacks some of the capabilities of TensorFlow, so perhaps there's just something about TensorFlow which doesn't fit my personal preference.

Overall, I'm satisfied with the detection algorithms performance as it meets the original design criteria. Moreover, the system is meeting the desired objective; having, nearly eliminated dogs doing their business in our yard. The dog owners are apparently very trainable. I've included three screen shots below. The white boxes are the portion of the image the motion detector has determined should be run through the detection algorithm. The first image is a pretty easy win for the detector, the second image shows how the motion detector can make the job harder, but still works and the last image is pretty impressive in how the detector determined the presence of a dog in an obfuscated image. The detector does false detect on people at times and oddly enough when the light on the tree in the center of the field of view has just the right pattern from the sun shinning through the leaves. I may run the system for an extended period, capture some of the false positives and positives, and retrain the NN to see if I can reduce the false positives.

Lastly, here's a video of the system in action. We actually spoke to this woman previously and she committed that she would not have her dog do its business in our yard anymore. So much for honesty.

Video - System in Operation

This application is the first half of a larger project. The second half is a sprinkler controller designed for a mobile interface.