This is the sixth post in a series:
- Autonomous Moth Trap Project
- Autonomous Moth Trap Hardware Revisions
- Hardware and Software updates to Autonomous Moth Trap
- Alternatives for Autonomous Moth Trap
- Software components for Autonomous Moth Trap
- Time Lapse module for Autonomous Moth Trap
This post describes the amt_timelapse.py script used on the Raspberry Pi Zero to capture images for the Autonomous Moth Trap. This script makes use of common utility functions defined in amt_util.py.
The software is designed to control the components of the following circuit but can be configured to accommodate a number of alternatives.
- Turn on the moth light (LED light tube) and ring light at a scheduled time (or multiple scheduled times (e.g. several one-hour periods through the night)
- For each operation period, take a specified number of timestamped images at regular intervals
- Turn off the moth light and ring light after operation
- Optionally use the status light to indicate operation and when images are captured
- Optionally get temperature and humidity readings from a DHT22 (or DHT11) sensor and link these to each image
- Save metadata documenting the settings associated with the each operation period
- Support alternative arrangements of GPIO pins
- Use a real-time clock to track time when not connectd to a network
- Scheduling is controlled by crontab entries to run the script (“python3 /home/pi/amt_timelapse.py”) at defined times.
- amt_timelapse.py reads the amt_timelapse.json configuration file located in the current folder (or an alternative JSON configuration file supplied as the first command-line argument).
- amt_timelapse.json serves as a container for: the unit name; basic metadata on the unit (Raspberry Pi version, camera type, lighting options); control parameters for PiCamera; options to enable the temperature/humidity sensor and status light; destination folder for output; and options to override the default GPIO pins. This will be expanded to hold other metadata (coordinates, contact information) and could also transfer wifi settings, schedule setup parameters, etc.
- amt_timelapse.py creates a subfolder in the destination folder to receive the images and copies the JSON configuration file into the subfolder.
- The script then sets up the GPIO pins.
- The previous state of the status light (red/green/off) is remembered and the light is set to green if enabled, otherwise off.
- The moth light and ring light are switched on.
- If a temperature/humidity sensor is enabled, it is now powered up (unless it sensor VCC pin is connected directly to a 3.3V pin) and initialised.
- If specified, the script now sleeps for a specified number of seconds (since there is likely to be little point in imaging before insects can respond to the light).
- The camera is now enabled and set to preview.
- The script now captures a series of the specified number of images at the requested interval. (If the number is set to -1, the series is unbounded – this may be appropriate if the unit is intended to run until the battery fails.) Each image is named with a timestamp and with temperature and humidity if these are being sensed. If the status light is enabled, it is switched to red for each capture.
- The lights are now switched off.
- If required the temperature/humidity sensor is turned off and the status light is reset.
- Throughout, progress is written to a log file.
Many websites recommend use of the adafruit_dht package to read DHT11/DHT22 sensors. I was unable to get this successfully working on the Pi Zero – it consistently reported wiring issues or incomplete buffers, so I instead adopted a solution using pigpiod (see https://abyz.me.uk/rpi/pigpio/code/DHT.py). The daemon is likely to consume extra power, so I will evaluate whether only to start and stop it while capturing images.
Simplifying configuration and file access
For a future version, I intend to add an IP67 female USB 2.0 socket and another push button. This is to make it easier to transfer files to and from the system and to lower the technical threshold for potential users. My thinking is as follows:
- The user can edit the JSON file (which could be extended to offer specify settings for crontab). A simple command-line or form-based interface could be offered on Windows/Mac/Unix to create/validate these files before copying them to a USB storage device.
- The user plugs the USB storage device into the unit’s external USB socket.
- The user pushes the extra button on the unit and triggers a script waiting for a GPIO interrupt.
- If a USB storage device is detected, the script turns on the status light to indicate operation.
- If the unit holds untransferred folders of images, the script transfers a copy to the USB storage device.
- If the transfer is successful and all images are on the USB storage device, EITHER the script automatically deletes the on-board copies OR does so only in response to a configuration flag.
- If the USB storage device includes JSON files, the script transfers these to the unit and makes any associated changes to crontab, etc.
- The script writes a human-readable report/log to the USB storage device to document all stages and report the current configuration settings and schedule.
- The script tuns off the status light.
This would make it possible to use the device and save images, etc. even in the absence of wifi (or using a Raspberry Pi Zero without wifi support).