Guard tour supervision is essential to ensure that guards are meeting the required standards outlined in the contract. Events monitored include: - Patrols being completed on time - Critical areas secured - Frequency of conducted inspections etc. A Guard tour system reduces the amount of manual supervision required by using automated monitoring, workflows, and alerts.
The basic component of this project is the Kemet Pyroelectric sensor with WiFi connectivity to a Gateway, thus forming a network of checkpoints detecting the time of passage of person (assumed to be the guard) and transmitting info to the cloud. A Kemet Pyroelectric sensor node detects human presence for a specific amount of time as a guard patrol passes by preselected points. The node determines the time and duration of the patrol event, preprocesses this info against preset limits and transmits the data and any deviations detected, to the cloud via wifi.
The Resources.- 1 x Custom PCB
- 1 x KEMET Pyroelectric sensor
- Micropython Interpreter
- ThingSpeak Cloud service
For this project I designed a circuit (see above photo) that provides an interface to the KEMET sensor and an integrated MCU/ WiFi modem (optionally there is a temperature/humidity sensor as well). The MCU is supported by MicroPython, so I selected this as my application environment. For the Cloud service I selected Thingspeak which offers amble resources and is very straightforward to use.
For the custom circuit, the schematic, the Bill of Materials, and the Gerber Files are included in the attachments. The PCB is powered by a any 2V to 4V source and provides the 5V required by the KEMET Sensor plus the power rails for the modem/MCU and temp/humidity sensor.
If you do not wish to build this circuit then you can use any ESP32 WROOM board, in order o provide Cloud connectivity to the KEMET sensor with the micropython code provided here.
1. Initially you need to download the most recent MicroPython firmware .bin file to load onto your ESP32 device. You can download it from the MicroPython downloads page:
https://micropython.org/download#esp32
There is also a micropython tutorial available at:
https://docs.micropython.org/en/latest/esp32/tutorial/intro.html
This tutorial will guide you through setting up MicroPython, getting a prompt, using WebREPL, connecting to the network and communicating with the Internet, using the hardware peripherals, and controlling some external components.
Once you have downloaded the MicroPython firmware you need to load it onto your ESP32 device. There are two main steps to do this:
- first you need to put your device in bootloader mode,
- and second you need to copy across the firmware.
For best results it is recommended to first erase the entire flash of your device before putting on new MicroPython firmware.
Currently there is only support for esptool.py to copy across the firmware. You can find this tool here: https://github.com/espressif/esptool/, or install it using pip:
pip install esptool (or pip3 install esptool)
Versions starting with 1.3 support both Python 2.7 and Python 3.4 (or newer). An older version (at least 1.2.1 is needed) works fine but will require Python 2.7.
Using esptool.py you can erase the flash with the command:
esptool.py --port /dev/ttyUSB0 erase_flash (Replace ttyUSB0 with the name of the serial port that your ESP32 circuit has created. If in Windows it will be COMxx).
And then deploy the new firmware using:
esptool.py --chip esp32 --port /dev/ttyUSB0 write_flash -z 0x1000 esp32-20180511-v1.9.4.bin
(Replace esp32-20180511-v1.9.4.bin with the filename of the downloaded firmware).
Once you have the firmware on the device you can access the WebREPL (Python prompt) over UART0 (GPIO1=TX, GPIO3=RX), which is connected to a USB-serial convertor. The baudrate is 115200. WebREPL is the latest standard for communicating with and controlling a MicroPython-based board. The WebREPL client and related tools for MicroPython are to be found at:
https://github.com/micropython/webrepl
An additional useful tool that you should install is Ampy (Adafruit MicroPython Tool). Ampy is meant to be a simple command line tool to manipulate files and run code on a CircuitPython or MicroPython board over its serial connection. With ampy you can send files from your computer to the board's file system, download files from a board to your computer, and even send a Python script to a board to be executed. Ampy is easily installed with pip or pip3
pip3 install --user adafruit-ampy or pip install adafruit-ampy
and for additional info on Ampy you can visit:
https://github.com/scientifichackers/ampy
2. Once you are done setting up the board, you need to obtain an account with Thingspeak. Go to https://thingspeak.com/ and follow the instructions for registering. Next, follow the instructions to create a Channel and take note of your Channel ID and Write API Key. These will be used in the MicroPython code that will be downloaded to the board. Communication between the WiFi board and the cloud is performed via the MQTT protocol.
The MQTT broker is the central point of communication, and it is in charge of dispatching all messages between the senders and the rightful receivers. A client is any device that connects to the broker (our circuit with the KEMET sensor in our case), and can publish (to the Thingspeak cloud), or subscribe to topics to access the information. A topic contains the routing information for the broker. Each client that wants to send messages publishes them to a certain topic, and each client that wants to receive messages subscribes to a certain topic. The broker delivers all messages with the matching topic to the appropriate clients.
ThingSpeak has an MQTT broker at the URL mqtt.thingspeak.com and port 1883. The ThingSpeak broker supports both MQTT publish and MQTT subscribe.
The Code.The algorithm that we implement is based on the time on which proximity events are detected by the KEMET sensor.
First we define the tour_int variable which indicates the duration of a Guard tour in seconds (apparently this should be adjusted to each specific use case).
tour_int=900 # 15 minutes
and a reasonable error margin percentage for completing the tour before or after tour_int, i.e.
margin=int(tour_int/5) # 20%
tour_max=tour_int+margin # Maximum Tour Duration
tour_min=tour_int-margin # Minimum Tour Duration
We also define two time intervals based on the original duration, namely:
first_m=int(tour_int/6)
second_m=int(tour_int/2)
Thus, based on the above we distinguish the following categories of a proximity event, based on the elapsed time (Time), from the previous one:
1. Time>tour_min and Time<tour_max: Guard detected within acceptable time limits.
2. Time>tour_max and Time<tour_max+first_m: Guard detected but round completion is characterized as Late.
3. Time>tour_max+first_m or Time==tour_max+first_m: Guard did not check in!
4. if Time<tour_min:
Case 1: if Time>tour_min-first_m: Guard completed tour early!
Case 2: if Time<tour_min-first_m or Time==tour_min-first_m: Event is False, Ignore it!
Once the event is detected and characterized then the board connects via WiFi to the ThingSpeak Cloud and uploads the data. In the following various scenarios are presented through the ThingSpeak cloud service:
Top Left: Event Characterization, Top Right: Event No., Bottom Left: Graph of Event Types (Discrete Types, 0,1,2,3,4,5), Bottom Right: Time passed from previous detection.
In concluding, it is important to point out that the sensor is very sensitive (producing lots of false detection events), if exposed to strong ambient light, so casing is a very important aspect of a commercial version of such a project.
Comments