A Low-Cost Remotely Configurable Electronic Trap for Insect Pest Dataset Generation

Abstract

The precise monitoring of insect pest populations is the foundation of Integrated Pest Management (IPM) for pests of plants, humans, and animals. Digital technologies can be employed to address one of the main challenges, such as reducing the IPM workload and enhancing decision-making accuracy. In this study, digital technologies are used to deploy an automated trap for capturing images of insects and generating centralized repositories on a server. Subsequently, advanced computational models can be applied to analyze the collected data. The study provides a detailed description of the prototype, designed with a particular focus on its remote reconfigurability to optimize repository quality; and the server, accessible via an API interface to enhance system interoperability and scalability. Quality metrics are presented through an experimental study conducted on the constructed demonstrator, emphasizing trap reliability, stability, performance, and energy consumption, along with an objective analysis of image quality using metrics such as RMS contrast, Image Entropy, Image sharpness metric, Natural Image Quality Evaluator (NIQE), and Modulation Transfer Function (MFT). This study contributes to the optimization of the current knowledge regarding automated insect pest monitoring techniques and offers advanced solutions for the current systems.

1. Introduction

Integrated pest management (IPM) is currently considered the primary strategies for reducing pesticide usage [1,2,3]. Indeed, low pesticide-input IPM systems are of obligatory implementation in the European Union Member States (Directive 2009/128/EC) and the United States [4]. The Directive 2009/128/EC of the European parliament and of the council establishing a framework for Community action to achieve the sustainable use of pesticides defines IPM as a “careful consideration of all available plant protection methods and subsequent integration of appropriate measures that discourage the development of populations of harmful organisms and keep the use of plant protection products and other forms of intervention to levels that are economically and ecologically justified and reduce or minimize risks to human health and the environment”.

In this regard, the efficiency of the decision-making process based on economically and ecologically robust intervention levels relies on the accuracy of the techniques used for monitoring insect pests’ population dynamics [1,2]. Thus, the data collection procedure should be improved to ensure the best implementation of the subsequent agricultural operations.

In the context of IPM, traps are considered effective tools for attracting insects, thus allowing the determination of the seasonal population to make decisions for control in case populations exceed treatment thresholds [2]. These traps are also allowing the study of insect behavior, such as flight, oviposition, parasitism, mating/calling, response to semiochemicals, and others [5]. To improve trapping efficiency, lures were traditionally used as a main component of the trapping system to enhance their efficiency of specificity, with colors and odors being the primary monitoring tool complements [6].

Nevertheless, the conventional method of monitoring insect pests is highly time-consuming, very expensive, and lacks precision, primarily due to a deficiency in the expert knowledge required to differentiate relevant species [7]. To address this, the integration of technology is crucial to streamline the process, resulting in time and cost savings, and enhancing the efficiency and effectiveness of trapping systems. It is, therefore, essential to further research low-cost alternatives that provide effective and economical solutions. Significant progress is being made in the biomedical [8], industrial [9], and marine biology [10] sectors.

In this regard, automated monitoring has been introduced as a new tool that plays a crucial role in IPM functionality. However, the practical application of these techniques is hindered by several issues, encompassing challenges in both structure and functionality. This hinders the ability to achieve precise localization and accurate identification of pest organisms across diverse cropping systems. Additionally, incorporating these systems into a wider market share of precision spraying machinery for horticultural production is crucial [11].

As of now, there is a limited presence of innovative solutions in the market, particularly those offering automated identification of insect pests. Some works have been carried out to develop pest detection and classification systems. According to Sciarretta and Calabrese [12], there are three types of insect pest monitoring systems: fully automated, semiautomatic, and manual. The most common ones are the manual systems, in which manual tasks are used for each of the stages: deployment, gathering, detection, counting, and classification. These systems are highly time-consuming, tedious, and largely susceptible to errors. Obviously, these systems cannot deal with online real-time monitoring of the environment.

To automatize the detection of pest individuals, computer imaging [13,14] has gained large importance in this type of electronic traps. Gonçalves et al. [15] introduced a methodology for pest classification in viticulture. Images from traps were manually captured using smartphones by winegrowers and taxonomy specialists. The collection of traps and image capture were performed manually. Multiple image processing techniques were then applied to enhance the image quality for subsequent detection and identification stages. The detection and identification of pests are carried out using lightweight Machine Learning (ML) models that can be directly executed on smartphones.

Further studies, carried out by Deng et al. [16], improved the detection of multiple pests and diseases with images taken from complex real environments. These authors proposed the use of an improved faster region Convolutional Neural Network (CNN), which provides better accuracy levels and faster detection rates than previous approaches. However, these authors do not deal with the procedure to automate the capture the images in the environment and use a High-Performance Computer to compute the detection task.

In this context, Li Rui et al. [17] indicated that CNN-based methods for pest localization and recognition are not sufficiently effective for practical field prevention. This is due to the varied scales and orientations of the pests. To address these challenges, they propose an effective data augmentation strategy involving rotating the images at various angles and then cropping them into different grids. Conversely, the study by Li Jiangtao et al. [18], driven by the need for extensive data and the considerable effort required for training deep neural networks, proposed a method to create a dataset consisting of synthetic insect images. This dataset is designed to provide meticulously labeled images, thereby facilitating insect detection tasks.

Therefore, given the need for retraining and the diversity in scales and orientations of pests, there is a growing trend towards classification in cloud systems, which can adapt and retrain in real-time according to specific pest requirements. Additionally, these systems can integrate with new devices developed using standardized interfaces such as API or MQTT. An example of such a system would be XFARM’s IoT Hub [19].

Alternatively, the manual acquisition of images from traps requires specific parameters to be met for the obtained frames to be used in subsequent stages for pest detection and classification. Faria et al. [20] outlined a two-step methodology for optimal image acquisition of vineyard insect traps. Parameters such as camera focus, shadow/reflection detection, automatic cropping of traps, and perspective correction are automatically adjusted on the smartphone used for image capture. Other authors emphasize the importance of the quality of pest identification and classification. For example, Kathole et al. [21] assessed the performance of an improved classifier based on a Convolutional Neural Long Short-Term Memory (CNLSTM). However, the proposal does not consider the image capture subsystem, which has been shown to significantly influence the quality of the response.

The integration of electronics, computing, and wireless communications for the development of advanced and efficient devices and protocols has significantly impacted the evolution of fully automated insect monitoring systems. Certain studies [22,23,24,25,26,27] represent a significant progress in the development of fully automated insect pest monitoring systems. Preti et al. [23] conducted an extensive analysis of the components that these systems typically incorporate. Typically, fully automated insect pest monitoring systems are deployed in agronomic environments with a pre-set configuration, to monitor insect traps without human intervention (or with minimal maintenance). As part of their functionality, they make use of remote servers to send either the captured images or the result of their processing at the edge (usually the number of individuals captured).

Among the challenges faced by this approach, the correct pre-set configuration is very relevant, because its optimization is based on several criteria. On the one hand, from a technical point of view, the camera calibration depends greatly on the intrinsic parameters of the camera system [28], the location and position of the trap, as well as the different surrounding elements that can create shadows on the object to be captured; moreover, from an agronomic point of view, the most convenient period of the year and times of day to schedule the most significant image captures is likely to depend on the type of pest under study, which has a direct impact on the configuration, as its parameters need to be adjusted to the expected exposure to light.

The challenge of correct configuration can be addressed by enabling a remote reconfiguration protocol, a cloud-to-edge return path, which allows the trap to be remotely operated in order to set the appropriate parameters in real time, without the need to move suitably trained staff for that purpose. This innovation has not been addressed in the scientific literature and represents the main motivation for this study.

Furthermore, there are other issues to be addressed in the current state of the fully automated insect pest monitoring devices. For instance, some works are able to make the detection and classification with highly powerful processors. These processing units consume a lot of energy, so that direct power, large batteries, or renewable energy capturing elements must be included. This constraint causes the devices to become very expensive, making them unsuitable for large deployments in rural non-attended areas. Thus, some type of balance between pest detection quality, power consumption, and economic costs needs to be reached.

In this article, we propose a network-connected, low-cost device with a camera. One of the main advantages of the proposed device is that it can be accessed and configured remotely, which is a feature that has not been found in any other trap. The configuration can be set using intuitive and easy-to-follow webpages with standard API commands. This will allow users to check parameters on-the-fly, which is a novel feature not found in other works. Moreover, the configuration of the parameters of the camera can be set almost automatically by making use of objective quality metrics. We have not found this issue in any other trap. Thanks to the use of this feature, little expertise in image processing is required to obtain high-quality images.

2. Materials and Methods

This section delves into the technical description of the trap prototype system. It comprises two key parts: on the one hand, the physical device responsible for insect capture and image acquisition, and on the other, a remote service facilitating trap reconfiguration and hosting the repository of insect images. The section is structured as follows:

• Components: This section details the components that constitute the solution, encompassing both hardware and software elements, both within the local device and the remote service.

• Design and Architecture: In this section, the operations, organization, and communication between the previously described components are explained.

• Physical Attributes and Power: Physical attributes of the trap prototype are described, along with a discussion of its energy considerations in the context of deployment.

• Camera Image Quality Evaluation: The image metrics used to assess the quality of the cameras and configurations are described.

• Experimental Methodology: This section encompasses the procedures and setups used to carry out practical experiments and measurements. It outlines the methods, tools, and conditions employed to validate the technical aspects of the prototype and gather quantitative data.

2.1. Components

In the subsections that follow, a detailed overview of the components comprising the trap device is provided. These descriptions encompass both the hardware and software elements integrated into the device.

2.1.1. Microcontroller Board

Based on the works of Suto [29,30], the ESP32-CAM platform device was selected. An ESP32-CAM is shown in Figure 1. ESP32 is a System-on-Chip (SoC) developed by Espressif (Shanghai, China), with dual-core 32-bit Tensilica Xtensa LX6 CPU at 240 MHz, with 520 KB SRAM and 8 MB PSRAM. It also has Wi-Fi and BLE wireless connectivity. This SoC is installed in a board, named ESP32-CAM, which is a development board released by AI Thinker Tech (Shenzhen, Guangdong, China). with an ESP32 microcontroller and a standard camera 24-pin DVP connector.

ESP32-CAM has a size of $20\times 40.5\times 4.5$ mm. This reduced size is ideal for embedded systems. Besides, this device is able to deep sleep with an ultralow current of 6 mA. This device can be powered either with 5 V or $3.3$ V. Some technical reports inform about the power consumption of an ESP32-CAM with a typical camera. In Table 1, the power consumption of the ESP32-CAM is shown. Two states are considered: standby with no operation (either capturing frames with the camera or sending/receiving network messages) and streaming (capturing continuous images with the camera, processing images, and sending them via Wi-Fi).

2.1.2. Embedded Camera

The OV2460 and OV5460 cameras were selected for the system. OV2460 is a 2MPixel camera with a fixed focus length lens. OV5460 is a 5MPixel camera with AutoFocus enabled. Both cameras are shown in Figure 2 and were acquired through the Arducam website.

Both cameras are among the recommended ones to work with ESP32-CAM platform, as they have drivers and support for the microcontroller device. Table 2 describes the most relevant specifications for both camera models (OV2640 and OV5640).

Commercial OV2640 versions vary depending on the installed lenses or mount lens holder. It can be purchased with a M12 or a C-mount lens holder to attach a large variety of lenses. However, this is an expensive option, as the M12 or C-mount lens holder and the optics must be bought separately. There are other non-interchangeable lens that are much cheaper. They are sold with different view angles, ranging from ${24}^{\circ }$ to ${200}^{\circ }$. Some of them are adjustable focus length lenses, although they are more expensive than the fixed focus length.

Many manufacturers build OV2640 cameras. All of those cameras uses the same sensors and can be accessed using the same drivers. However, it has been noted that there are differences in quality among them, mainly in the calibration procedure carried out by each manufacturer. In particular, some OV2640 cameras that labeled RYS in their serygraphy show better overall performance than others without that label. Therefore, we used two OV2640 cameras with ${60}^{\circ }$ width with a fixed focus length: OV2640 (standard model) and OV2640 (RYS model).

The OV5640 camera is distributed in several different versions, according to the installed lens. OV5640-A has a fixed $2.8$ mm Effective Field Length (EFL) lens with a view angle of ${63}^{\circ }$, OV5640-B has a wide view angle of ${170}^{\circ }$ with a fixed $2.0$ mm EFL (fisheye) lens, and finally, OV5640-C has an autofocus-enable lens with a (software-adjustable) $3.37$ mm EFL and (adjustable) ${67.4}^{\circ }$ view angle. This last version (OV5640-C) has been selected.

2.1.3. Embedded Device Structure

The programming of ESP32-CAM was carried out utilizing ESP–IDF (version 5.1.2), which is the development framework offered by Espressif, the system-on-chip (SoC) manufacturer. This framework, based on C++, provides a hardware abstraction layer and incorporates the FreeRTOS real-time operating system, drivers, and supplementary modules that streamline the development of embedded systems. Figure 3 illustrates the deployment of the most pertinent hardware and software modules within the project. The uppermost layers correspond to the developed code.

The ESP32 SoC features two 32-bit Xtensa microcontrollers with LX6 cores. To harness the process-level parallelism inherent in this architecture, the “State Machine Abstraction Library (SMAL)” was devised, a collection of thread-safe methods and structures that leverage the FreeRTOS scheduler to define the system in terms of states and transitions. This programming approach fosters loose coupling, high-level abstraction, and eases error handling, thereby enhancing the robustness of a system that must operate continuously without interruption.

Using the SMAL Library, the system defines a series of tasks, which are independent units of programming that can run concurrently or in parallel, depending on whether they share a processor or not. The following tasks make use of the SMAL library and collaborate in the operation of the embedded system:

• Main Task: As the initial task of the system, it is responsible for configuring the state machine states, setting up event handlers for the communication driver, allocating memory for necessary data structures, and launching the initial state of the system. While the SMAL library does not directly control this task, its continuous execution is imperative for the system’s proper functioning.

• Configuration Task: This task, when active, runs periodically and is responsible for requesting the current device configuration from the remote service. The remote reconfiguration mechanism is implemented within this task.

• Perception Task: This cyclic task accesses the integrated camera to capture images of the trap. It collaborates with the Communication Task to transmit the images to the remote server. Given its computational demands, this task is exclusively scheduled on one of the processors.

• Communication Task: This task handles the transmission of images captured by the Perception Task to the server.

• WebServer Task: This task initiates an embedded web server designed to host a remotely accessible web interface for camera configuration and visualization.

2.1.4. Central Server

The central server enables remote management and configuration of the devices through bidirectional communications, in addition to allowing real-time tracking of the pest’s evolution. The server, running Windows 11, is a personal computer with an 11th generation Intel(R) Core(TM) i5-1135G7 processor (Intel, Santa Clara, CA, USA) (2.40 GHz base, 2.42 GHz boost) and 16 GB of RAM. It hosts crucial services for remote configuration, including a robust Web API for image configuration, a dedicated database for configuration details and image metadata storage, and an image repository for secure trap image storage. Figure 4 presents an overview of the constituent modules of the server.

• Hosting Layer: This layer is built on top of Internet Information Services (IIS) 10.0, serving as the foundational component within the WebServer infrastructure. This layer is responsible for hosting and managing the Web API, ensuring its accessibility and performance. It acts as an intermediary between client requests and the Web API, efficiently managing the processing and delivery of web content. The hosting layer is essential for the smooth operation of web services and plays a key role in maintaining the stability and responsiveness of hosted applications.

• Web Application Layer: This layer is responsible for processing user requests, executing business logic, and generating dynamic content. Situated within this layer is the Web API, built using ASP.NET Core 7, within the confines of the .NET Core 7.0 runtime environment. The endpoints, which facilitate remote configuration, are described in Table 3. The API documentation is administered through the utilization of the Swagger user interface, enabling a graphical interaction with the API, all without necessitating a detailed understanding of the underlying implementation logic.

• Data Layer: The Data Layer is responsible for the management and persistence of data within the WebServer architecture. This layer encompasses database systems, repositories, and data storage mechanisms, ensuring the integrity, security, and availability of critical information. At the core of the Data Layer lies a relational database, namely SQL Server, alongside the image repository. The development of the database was undertaken utilizing SQL Server Management Studio (SSMS) and Microsoft SQL Server 2019 Express (SQLEXPRESS). Within the realm of database connectivity and management, ADO.NET Entity Framework is employed to establish the database context, with a specific focus on Entity Framework 7 (EF7). Figure 5 shows the main entities of the database. With regard to the image repository, a two-track approach has been defined, where one track is designated for the storage of test status images (Camera Testing State) and the other for monitoring status images (Monitoring State). Within the database, metadata are recorded for each image, which includes the relevant trap configuration parameters.

2.2. Design and Architecture

The following subsections delve into the system’s collective functionality, providing detailed insights into component interactions and system dynamics.

2.2.1. Embedded System Operation

The trap is managed internally using a state machine developed in C++ under the ESP-DIF framework. Figure 6 shows the 6 internal states of the trap and their relationships. In the following paragraphs, a brief description of each state is included.

• State: Connection. In this state, event handlers for the Wi-Fi driver are configured, and the connection with the remote service is initiated. This state persists until a connection is established, with controlled retry attempts to prevent lockups.

• State: Configuration Waiting. After establishing the connection, the system transitions to this state. Here, a system cyclic task (Configuration Task) is launched, which periodically queries the current device configuration through a GET request to the API.

• State: Camera Testing. This state corresponds to a remote reconfiguration regime. Upon entry, the Perception and Communication tasks are initiated, responsible for capturing images and sending them to the server via a POST request to the API. Given the configuration regime, this cycle accelerates, as does the Configuration task, to facilitate agile configuration changes. Images captured in this testing regime are not stored in the final image repository but in a specific temporary testing storage.

• State: Monitoring. This state corresponds to the normal operation cycle of the trap. Upon initiation, the Perception and Communication tasks are launched with a standard working period, and the captured images are sent to the server for storage in the regular repository.

• State: WebServer. In this state, the device initiates the WebServer Task, which implements an embedded web server. Upon access, it presents a user interface with full camera configuration accessibility, along with a real-time frame streaming feature that enables users to experiment with real-time configuration adjustments. This state is designed for deployment scenarios to expedite the initial device setup.

• State: Idle. When device configuration determines it, it remains in a latent state with no image capture and transmission. In this state, the only active task is the Configuration task.

In Figure 7, every state is described in detail. Colors of the boxes representing tasks have been assigned according to the color of the States in Figure 6.

The trap starts connecting to Wi-Fi, as described in “State 0: Connection”. This task remains active checking the Wi-Fi connection is alive all the time. After that, the trap checks if there is a new configuration sent by the server in “State 1: Waiting for configuration”. This state is alive checking periodically if there is a new configuration. If a new configuration has been assigned, it is applied in “State 2: New configuration”. Depending on the configuration, up to 4 states may be started: “State 3: Testing camera”, “State 4: Monitoring”, “State 5: WebServer”, and “State 6: Idle”. The “State 2: New configuration” is in charge of selecting different states according to the configuration set by the server. Therefore, this state is probably the most complex. If there is a change in camera parameters without changing the working mode (either Monitoring or Testing), the Camera task is stopped, the new configuration parameters are applied, and the Camera task is started again. In case the period is set to 0 in the configuration, “State 6: Idle” is activated, in which tasks Camera and WebServer are stopped. If the new selected mode is either Monitoring or Testing, the WebServer task is stopped (in case it was active). The main differences between the Monitoring or the Testing modes are the URI parameter, which is set to a different destination, and the sending image period, which is faster in testing mode. In both cases, the Camera task is restarted applying the new set of parameters (including URI). Finally, if the selected mode is WebServer, the Camera task is stopped and the WebServer task is launched and a stream of frames captured from the camera is served on port 80 via HTTP.

2.2.2. Device–Server Communication

In an electronic trap, the server is where both the configurations of the devices and the repository of captured images are stored for future processing. This service features an API that functions as the interface for both the system user and each electronic trap. The API-based communication between the trap and the server involves periodic retrieval of its current configuration. This retrieval is executed within the Configuration Task every T_conf seconds, where this period is part of the configuration settings. Upon receiving the configuration, if it differs from the current one, the Configuration Task is responsible for implementing it within the system. This involves starting or stopping tasks that are applicable in each specific case, depending on the configuration. Upon device initialization, the interval commencing with the initiation of the Configuration Task and ending with the reception of the initial configuration is occupied by the transient state referred to as Configuration Waiting.

The configuration retrieval is conducted using the GET method at the entry point/api/DeviceSetting/id, where id corresponds to the ID of the device making the query. The modifications to device configurations and the retrieval of images from the repository are also performed by the user via API. In this article, the Swagger user interface has been employed to access the entry points from any web browser.

The configuration parameter Mode determines the trap’s operating cycle. The modes correspond to the Camera Testing, Monitoring, and WebServer states described before; the remaining configurations concern camera parameters, which are outlined in Table 4, and do not affect the communication sequence.

In Figure 8, there is a sequence diagram that exemplifies the API communications that occur between the device and the server for the Monitoring mode, from the moment the user sets it in the configuration until replacing it with the Idle mode, which stops the process. The diagram illustrates both the period of the Configuration Task (Tconf) and that of the Camera Task (T), which is responsible for capturing images and transmitting them to the server via POST at the endpoint /api/Image/UploadImage/id. In the Monitoring state, the transmitted images are stored in the repository, associating them with the originating device in the database. This association enables the retrieval of the upload timestamp, along with all the characteristics inherited from the device configuration that impact the image (latitude, longitude, brightness, contrast, saturation, sharpness, etc.).

The Testing Camera mode has a communication sequence analogous to the Monitoring mode, with two differences: (a) the image upload is performed with a POST request to the endpoint /api/Image/UploadImageTest/id and (b) the T and Tconf periods are significantly shortened to allow the user to quickly make changes to fine-tune the configuration for the desired outcome. To serve this purpose, images in this mode are not stored in the final repository but directed to temporary storage.

In Figure 9, the sequence diagram of communications for the WebServer mode is depicted. In this mode, the Configuration Task initiates the WebServer Task in the operating system (if necessary, it would stop the others). This task deploys a web server that accepts a single client connection and serves a real-time configuration page with interactive controls for each camera configuration parameter (see Table 4). The purpose of this task is to enable quick and easy-to-follow configuration of each device during deployment.

2.3. Physical Attributes and Power

This section deals with the design of the embedded device that takes and sends images. The board used has the necessary hardware resources to perform the task (processor, camera, and communications interface); consequently, the physical design of the trap has small dimensions and extremely low power consumption. Figure 10 shows the prototype device.

The left side of the image shows the box where the ESP32-CAM board is mounted, with a hole machined in the front to keep the camera lens uncovered, to eliminate distortion of the case material, which initially was chosen to be transparent in order to keep all the electronics inside. A panel parallel to the camera lens, with a sticky surface where insects are trapped, is arranged on the right side. We followed the procedure proposed by Ricolfe-Viala and Esparza [31] for the camera with Autofocus; however, the focal length provided by the manufacturer is inexact and the results are not as precise as expected. Therefore, some manual adjustments on distances of the camera to the trap are required. Thus, the mounting was carried out on two rails that allow the panel to be moved closer or further away from the electronics.

In terms of energy, the design is intended to accommodate a long-lasting, replaceable battery or one that can be recharged using a small solar panel. However, this prototype primarily serves as a technical feasibility test, and the device energy consumption in all its operation modes will be experimentally measured to determine the best solution.

2.4. Camera Image Quality Evaluation

In order to compare different cameras and capture processes in terms of quality, several metrics were analyzed. Huge efforts have been made by image processing scientists to provide metrics to evaluate the quality of the captured images. There are two main fields for quality evaluation: with a reference image and without any reference. On the one hand, the first approach requires a reference image to compare the captured image. The reference image is taken as the best one. Therefore, the captured image checks for the loss of quality with respect to the referenced one. On the other hand, the second field tests the images to obtain objective quality metrics without a reference image. In this case, several common and general features are selected, such as focus, edges, contrast, etc. These features must be taken as general indicators of the quality of the images [32]. However, some features may behave worse in some images because of the intention of the capture. For instance, some shots distort the background to focus on the main foreground objects. Thus, the background is intentionally out of focus, which may lead to worse focus-related metrics.

In our case, as there is no reference image to check the captured pictures by each camera, the studies focused only on non-reference image metrics. Therefore, the generic metrics selected to assess the quality of the images are as follows.

2.4.1. RMS Constrast

The root mean square contrast [33] metric (RMS Contrast) is defined as the standard deviation of the pixel intensities of an image I of size $N\times M$ pixels normalized in the $\left[0,1\right]$ range, as shown in Equation (1). In the case of insects captured in a trap, the insects, usually dark-colored, stick to a sticky film, usually light-colored (white or yellow). Intermediate colors (mostly gray) are mainly caused by low-resolution or wrongly focused images. Therefore, the larger the RMS Contrast, the clearer the insect with respect to the background. Thus, insects in large RMS Contract images can be extracted more easily:

(1)$\mathrm{RMSC}(I,M,N)=\sqrt{{\displaystyle \frac{1}{M·N}}\sum _{i=0}^{N-1}\sum _{j=0}^{M-1}{\left(I_{ij}-\overline{I}\right)}^2}$

2.4.2. Image Entropy

Entropy [34] provides the amount of information of a given stream of data, in this case, of the image. Moreover, in an image with high structural similarity, that is, with a uniform background with little changes, the entropy is low. This allows for the detection of relevant features that are largely different from the background [35]. That is, if the insects are clearly highlighted, the entropy will be higher.

As a first approach, images are commonly treated as a zero-order Markov model, given that the probability of each pixel $p_i$ is independent of the previous pixels. This approach has some limitations, as some pixels may be influenced by the pixels in their neighborhood. However, as a general quality metric, it is good enough to consider the images as a zero-order Markov model. The information entropy of the whole image is introduced in Equation (2):

(2)$H=-\sum _{i=0}^k{p}_{i}log\left(p_i\right)$

2.4.3. Image Sharpness Metric

The sharpness of an image is an approximation of the acuity of the objects in the image. The more blurry the objects on the image are, the worse the metric is.

Zhu et al. [36] provided a survey on different methods for objective evaluation of the image sharpness. One of the simplest sharpness metrics is the sharpness index obtained by applying the standard deviation of all the pixels of image. Better-quality images provide higher image sharpness.

2.4.4. Natural Image Quality Evaluator

A non-reference image quality evaluator, named Natural Image Quality Evaluator (NIQE), was proposed by [37], where the lower the NIQE value, the better the quality of the image. The image is divided into square patches same size, where up to 36 Natural Scene Statistics (NSS) are extracted in each patch. In order to remove those parts of the image where some natural defocus may appear (because of limited depth of field, DOF, of the camera). The variance field of each patch is analyzed and ordered by that value. All the patches below a given threshold are discarded. Finally, a Multivariate Gaussian Model (MVG) is applied to the patches, to obtain a fit to the natural MVG model. The distance of the natural MVG model and the MVG model fitted from the patches is the NIQE metric. For the sake of simplicity, the full description of the method is not included in this work. Please refer to [37] for an explanation of the metric.

2.4.5. Modulation Transfer Function

In [38], Chapter 15.8, the Modulation Transfer Function (MTF) is described. MTF is a common measure to compare the performance of the optical systems, by measuring the capability of a lens to transfer precisely the closest contrast changes at a given resolution. Thus, it is the measurement of an optical system to transmit fine details of an image. The resolution in optics refers to the amount of distinguishable line-pairs per millimeter. Line-pairs are sequences of black and white lines. Equation (3) shows the spatial frequency of a captured image as the relation of number of line-pairs ($lp$) per millimeter ($mm$):

(3)$\xi ={\displaystyle \frac{lp}{mm}}$

The closer the two lines are in an image (represented by the spatial frequency), the harder it is for the lens to transmit precisely those changes. Equation (4) describes the MTF formula, according to the $\phi$ stated in Equation (5). In this case, ${\xi }_c$ is the cut-off spatial frequency by the optical system:

(4)$\begin{array}{ccc}\hfill MTF\left(\xi \right)& =& {\displaystyle \frac{2}{\pi }}\left(\phi -cos\phi ·sin\phi \right)\hfill \end{array}$

(5)$\begin{array}{ccc}\hfill \phi & =& {cos}^{-1}\left({\displaystyle \frac{\xi }{{\xi }_c}}\right)\hfill \end{array}$

Therefore, the higher the MTF is, the better an optical system is at transmitting fine details.

These metrics allow an objective and automatic evaluation of the quality of the images. They have been implemented using the Matab programming language and the image analysis toolbox.

2.5. Remote Configuration

A key feature of the development is its remote configuration capability, which allows each device to be customized in real time. These configurations can be carried out in two ways: via the web API or via the embedded system. In both cases, intuitive web interfaces have been developed to allow users to configure WebServer without technical knowledge. Both configurations are briefly described below.

2.5.1. Web API Configuration

This configuration mode is performed in state 3, called “camera testing”. When the system is running in this state, the configuration parameters can be changed through the API, which is managed through an intuitive web interface developed to Swagger specifications (see Figure 11). After each adjustment, the device sends a test image that is evaluated using both objective quality metrics and the user. This process can be repeated as many times as necessary until the desired image quality is achieved. The test images are stored in a separate repository.

2.5.2. WebServer Configuration

This configuration is performed in state 5, called “WebServer”. To make adjustments in this state, users must connect to the integrated web server in the device, which provides access to a web interface where parameters can be modified in real time (see Figure 12). This type of configuration requires continuous streaming of real-time video. Therefore, this method is typically used during initial configuration phases or when there are no power constraints. The potential of this method relies on the real-time streaming, which allows the user to observe directly any modification.

2.6. Experimental Methodology

To conduct empirical experiments and measurements, two devices were constructed in accordance with the specifications outlined in Section 2.1. A testing and validation methodology was subsequently devised, founded upon the principles of reliability, stability, performance evaluation, and image quality. This methodological framework involves the systematic and continuous execution of tests spanning a duration of 2 months, employing both devices within a controlled environment. These tests cover the evaluation of the device across its operational states, encompassing the acquisition of data pertaining to energy consumption and the quality assessment of captured images.

The testing and validation process is described in detail below.

1. The device initializes and establishes a connection to the remote service (Connection State).

2. It awaits configuration via the Web API (Configuration Waiting).

3. Images are transmitted at fixed intervals specified in the configuration (Monitoring State).

4. Remote configuration is carried out via the Web API (Camera Testing).

5. Configuration mode transitions to WebServer (Web Server State).

6. Streaming is initiated for remote configuration via WebServer.

7. Image quality is assessed using metrics, including RMS contrast, Image Entropy, Image sharpness metric, Natural Image Quality Evaluator (NIQE), and Modulation Transfer Function (MFT).

8. The device returns to the state described in point 3 (Monitoring State).

In order to expose the device to rigorous and sustained stress testing, image captures were acquired at one-minute intervals, as evidenced by the consumption study depicted in Figure 13, with the most frequent sampling interval typically observed in applications of this nature set at 6 h. To evaluate the remote configuration, four test scenarios were designed in a controlled environment with varying natural and artificial lighting conditions. This enabled the reconfiguration of the device by adjusting the parameters listed in Table 4 via the web API (Table 3) and/or the web server. The images captured during this testing phase were automatically evaluated using the proposed quality metrics, which facilitated the selection of the optimal configuration.

These tests are instrumental in the identification of potential reliability and durability issues that may emerge during prolonged, continuous usage, allowing for necessary corrections prior to the device’s deployment in a real-world environment.

3. Results

3.1. Energy Consumption

To characterize the energy requirements of the trap, system consumption is monitored during the timed sequence of actions specified in Table 5. This table represents a timed sequence of interactions with the prototype, designed to differentiate the time intervals of the most representative consumption regimes of the system (monitoring mode, remote configuration mode without video streaming, and remote configuration mode with video streaming).

During experimentation, an Agilent 34405A laboratory digital multimeter is used along with a Python script, which acquires and stores measurements continuously through the VISA protocol for post-processing. The results obtained are displayed in the temporal graph in Figure 13, where the intervals corresponding to the activities described in Table 5 have been identified. Finally, to facilitate interpretation of the experiment, Table 6 shows the average consumption values for each of the device’s operational modes.

The average energy consumption in each of the identified regimes is shown in Table 6. These results indicate that, for a typical duty cycle in Monitoring mode (standby, capture image, send image), the trap consumes 623 mW during standby and exhibits peaks of 960 mW during the brief transmission interval (presumably negligible). During the remote reconfiguration mode, when the user accesses the WebServer interface for this purpose, the prototype consumes between 641 and 647 mW, rising to 1017 mW when video streaming is activated to facilitate configuration adjustments.

Excluding transient states such as system start-up or configuration via WebServer, which in the lifetime of the device will be insignificant periods, the trap can be modeled energetically considering the consumption during the sending of each image, as well as the baseline consumption, which appears in the figure without marking (in white). These states will alternate in the monitoring mode at the rate of the configured T period (60 s in the experimental set-up). The fewer times an image is uploaded to the server, the lower the power consumption is. These values may be reduced even further if some optimizations, based on more relaxed duty cycle times, are applied.

It is worth noting that even in highly demanding regimes, such as streaming mode, energy consumption remains at $1.017$ W. While this is a relatively low energy consumption, it would have a tangible impact on the system’s battery life. Therefore, these modes should be avoided if longer operational lifespans are required.

3.2. Image Quality

In order to evaluate the quality of the images captured by the different cameras, metrics were used that do not require a reference image, since there is no reference image. These metrics make it possible to evaluate quality parameters, intensity variations within the image itself, and sharpness or the ability to transmit fine details, among others.

The evaluation of these parameters allowed the correct calibration of the cameras through the different remote configurations (test and monitoring). The best results for each camera are shown in Table 7.

As can be observed from Table 7, the results obtained with the higher resolution camera (OV5640-C) are slightly better than those obtained with the other two cameras, but they are not very far from those obtained with the OV2640 camera (RYS model). Therefore, in order to optimize the volume of data and information transfer, the tests were carried out in a controlled environment with this camera. Figure 14 shows one of the images obtained with this camera.

4. Discussion

Digitalization can make a major contribution to one of the main challenges of IPM of pests of agricultural, forestry, urban, or medical importance by, namely, reducing the workload and increasing the decision-making accuracy. It is well known that different regions may be infested by different types of pests. Deep Learning and other AI techniques are based on learning objects using images with enough quality. However, learning objects that will not be likely to appear in that environment would be useless and could even provoke forgetting the actual required objects. To obtain the best classifier, a dataset containing images of the local pests should be used. In this sense, the proposed system will be able to provide specific datasets of local pests with enough quality images.

This proposal aimed to design and implement an electronic trap system based on remote configurability for insect monitoring, therefore allowing remote reconfigurations in real time to adjust the acquisition parameters to the specific requirements of the object of study. Recent studies performed image acquisition manually using smartphones, pursuing the optimization of acquisition parameters with the aim of improving downstream stages, namely classification [15] or even using smartphones to achieve precise adjustments in the quality of image acquisition [20]. There is currently an open debate or dilemma in the scientific community between pest detection at the edge and external service processing [22,25]. The former has garnered significant interest, as these systems directly transmit information about the number of insects (and potentially, the type of each) to a central server. These devices are intended for long-term use and entail higher computational load. Consequently, they are equipped with solar panels and batteries. However, both implementations have their advantages and limitations; edge processing, for instance, minimizes communication requirements, while external server processing provides greater computing capacity and facilitates the acquisition of new images for future training stages. Our study has focused on the image acquisition device, with processing on an external server, aiming to integrate remote reconfigurations for enhanced flexibility and adaptability to various pests and conditions. It is important to note that a key advance in this field is the ability to make changes remotely. Being able to remotely adjust the way the system captures images in real time is essential to adapt to changing survey conditions and different insect pest situations [39]. This feature makes the system more resilient and effective, representing a major step forward in insect monitoring technology [39]. Therefore, it is noteworthy that the innovation presented in this research lies in the remote reconfiguration capability enabled through intuitive web interfaces provided by the API (Swagger) and the WebServer, allowing for real-time dynamic adjustments. This capability eliminates the need for on-site visits and reduces the dependence on specialized knowledge for implementation and testing. Additionally, image quality is automatically validated using pre-defined objective metrics, ensuring system accuracy without direct expert intervention. Thus, thanks to these configuration interfaces and the automatic image quality validation system, the deployment and configuration can be managed by any user, regardless of their technical expertise level. This novel feature ensures the adaptability of the system to diverse insect pests and specific study conditions, thereby amplifying its efficacy in capturing accurate and pertinent data.

Apart from this unique property of remote configuration, our device has been designed with a criterion that is also key to a trap, such as its cost-effectivity. Indeed, in a recent analysis of the strengths and weaknesses inherent in insect detection devices, it was highlighted that the prototype development has to follow key criteria such as a compact design, miniaturizing the electronic components, reducing final dimensions, and ensuring field maintenance-free operativity, together with high-quality, cost-effective, and widely available products, to facilitate large-scale production [40]. Our device aligns with these requirements, as it has been developed in a compact form factor ($5\times 7\times 10$ cm), with a low cost (50 EUR) and low power consumption (120 mA in standard (non-sleeping) working mode). Parab et al. [22] described a system based on the transmission of images to a remote service for classification. However, the hardware included in that work is much more complex and expensive than the one in this work. Similarly, Preti et al. [23] developed a prototype of an intelligent trap within a limited budget (less than 375 EUR), basing their development on the EXPRESSIF ESP32 microcontroller, renowned for its low power consumption and compact design. Consequently, our results in terms of power consumption closely align with theirs, though our costs are lower and our system possesses the capability for remote reconfigurations, unlike previous systems.

The proposed system demonstrates notable advancements in the field of remote insect monitoring, yet certain limitations inherently define its operational scope, presenting opportunities for further optimization. The device’s reliance on specific operational modes impacts battery life, particularly in high-demand settings such as streaming mode, which may reduce operational autonomy. Nonetheless, this limitation is offset by the system’s compatibility with external power solutions, including solar panels, which enhance field usability. Additionally, although stable network connectivity is required for real-time monitoring and remote reconfiguration, the system’s low data transmission requirements make it feasible for deployment even in moderately connected rural settings. Regarding scalability, while continuous data collection across multiple devices could present data management challenges, the system’s modular API-based architecture supports flexible data processing and storage that can be scaled with appropriate server resources as necessary. Lastly, although the study evaluated a limited selection of camera models, the device proved robust in controlled environments, establishing a practical foundation adaptable to a variety of field conditions. These considerations underscore the system’s versatility as a low-cost solution with promising adaptability in pest management applications.

This work presents a significant advancement in the field of IPM by leveraging digitalization to address the crucial challenge of reducing workload and enhancing decision-making accuracy. The remote reconfiguration capability of our system distinguishes it from previous studies, eliminating the need for on-site visits and allowing real-time adjustments to acquisition parameters. This capability not only aligns with recent trends in optimizing image acquisition for downstream processes but also provides enhanced flexibility and adaptability to diverse pests and environmental conditions. Our compact, low-cost, and low-power design meets essential requirements outlined in previous research, such as the need for a compact device with minimal maintenance during field deployment.

5. Conclusions

This work provide an efficient working prototype to be deployed for insect pest monitoring. Several advances have been included compared to the current insect pest monitoring devices described in the scientific literature. Some monitoring devices take photos and count the number of detected insect from a given type. In those cases in which there are remote communications, only one number is sent from the device to the server. No visual evidence is stored to confirm these values. Thus, these systems cannot detect other insects unless they are stopped and updated one by one with new detection models. On the other hand, the present prototype would enable the remote detection of more insects, as it would feed remote repositories with images of the real insects attached to the trap and new models could be developed. Other monitoring systems take photos and sent them to a server, but working parameters cannot be updated. Therefore, our proposal is an advanced monitoring system, in which the device can take photos with the best parameters for that environment and time, as they can be remotely updated.

The device has been built using low-cost components, which makes the final product economically affordable. Moreover, it has been proved that the device has a low energy consumption profile, which makes it suitable for deployment in the fields with batteries or renewable sources, such as photovoltaic panels. We have tested the prototype for power consumption, showing that the current is the range of 120 to 200 mA in standard (non-sleeping) working mode without sending images to the server and rising to 350–400 mA when uploading images, for few seconds, at most. Nevertheless, the frame uploading can be configured to be carried out fewer times so that this current profile can be extended for long periods of time.

The most relevant and distinctive feature that sets this insect pest monitoring system apart from others, as highlighted in the scientific review, is its remote management capability. The system communicates with the server through a standard Web API, making it easy to upgrade and enhance. Additionally, this setup allows for bidirectional communication, enabling the updating of execution modes and working parameters of the electronic trap device.

In this work, three compatible cameras (two versions of the OV2640 cam, with 2 Megapixels, and the other, OV5640-C, with 5 Megapixels) have been tested and analyzed. The results suggest, as expected, that the OV5640-C provides slightly better overall values than the other cameras. An objective quality evaluation has been carried out to determine the response of the cameras with different metrics. Therefore, these results prove the technical viability of a low-cost IPM system with remote management, providing the best visual evidence.

Hence, the present prototype allows for the acquisition of a large dataset of different insect pests, which would help to tune the detection models with more insects, providing higher levels of accuracy and precision.

Future improvements could focus on enhancing energy efficiency and scalability to broaden the system’s applicability across various operational contexts. One effective way to improve energy efficiency is by utilizing the microcontroller’s low-power mode, which could significantly reduce energy consumption. However, implementing this feature may add complexity to the reconfiguration protocol, potentially requiring scheduled communication windows or alternative triggers to prevent a continuously open communication channel. This strategy would support energy efficiency while maintaining the device’s remote configurability. Regarding scalability, we find it interesting to deploy electronic trap networks while adhering to a low-cost philosophy. This can be achieved through local hierarchical networks using technologies like LoRa 2.4 GHz or similar, which provide reasonable coverage in rural environments. Such a network architecture would enable large-scale deployment without the need for extensive infrastructure. By employing traffic optimization techniques to avoid data redundancy, as referenced in [41,42], we can enhance scalability while reducing energy consumption and conserving network resources. Together, these improvements would contribute to a more sustainable and cost-effective monitoring solution, increasing the system’s robustness and adaptability for Integrated Pest Management (IPM) in diverse field environments.

This proposal provides a solid foundation for pest monitoring. Besides, the low cost of the device makes it highly suitable for deployment in densely populated areas. As a result, a large number of these network-connected devices, strategically placed with location awareness, would enable researchers to track pest evolution in real time. This setup would facilitate the detection of the origins of an infestation and its progression vector. Ultimately, this could help identify where pests start causing damage to crops and how they evolve over time, making a significant contribution to the field of agriculture.

Author Contributions

Conceptualization, F.L.-G. and C.M.-R.; methodology, F.L.-G., C.M.-R. and J.M.P.; software, F.L.-G., C.M.-R. and J.M.P.; resources, E.Q.-M. and M.Y.-Y.; writing—original draft preparation, F.L.-G., C.M.-R. and J.M.P.; writing—review and editing, E.Q.-M. and M.Y.-Y.; project administration, E.Q.-M. and M.Y.-Y.; funding acquisition, E.Q.-M. and M.Y.-Y. All authors have read and agreed to the published version of the manuscript.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

The code and results of this work are publicly accessible in repositories “agroflies_device” and “photocaptureapi”, both available at the URL “https://bitbucket.org/proyecto-mosca/workspace/projects/PHOT”, accessed on 9 October 2024.

Conflicts of Interest

The authors declare no conflicts of interest.

Footnotes

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Figures and Tables

Figure 1. ESP32-CAM.

Figure 2. OV2640 and OV5640 (with autofocus) cameras.

Figure 3. Trap-embedded device structure.

Figure 4. Central server structure.

Figure 5. Database entities and relationships. * The <configuration> aggregation in DeviceConfiguration are described in Table 4.

Figure 6. Internal working states of the trap.

Figure 7. Detailed procedure of the trap states. The figure illustrates the concurrent processes programmed in the electronic trap device through various flow diagrams. Each black circle symbolizes the start of execution for each process, each diamond represents a conditional situation that adapts the logic, and the solid arrows indicate procedural flow. The dashed arrows represent events that trigger the initiation of a task.

Figure 8. Sequence diagram for user–trap interaction via the server API in Monitoring mode.The sequence diagram illustrates the interaction between the user and the trap through the server API in Monitoring mode. It shows the chronological sequence of data transmission and reception events from top to bottom, along with the computational load triggered at the receiving end. Three types of lines are used in the diagram: bold vertical dashed lines represent the passage of time for each task, smaller dashed line segments along these bold lines mark specific time periods within each task, and solid horizontal lines indicate the sending and receiving of events. The diagram includes the processing threads for the trap processes—Configuration Task and Camera Task (enclosed within the green square on the left)—the processing thread for the server API (within the red square in the center), and the user’s interaction with the API (displayed on the right side of the figure).

Figure 9. Sequence diagram for user–trap interaction via the server API in WebServer mode. The diagram is interpreted in the same way as described in Figure 8.

Figure 10. Trap device prototype.

Figure 11. Web API configuration interface.

Figure 12. WebServer configuration interface.

Figure 13. Energy consumption of the trap with relevant intervals labeled. From left to right: (a) system start-up, (b–f) frame upload to the server, (g) activation of the web server without clients, (h) active web server with a connected client, and (i) active web server with a client in streaming mode.

Figure 14. Example of an image captured by the OV-2640 (RYS model) camera.

Table 1

Power consumption of an ESP32-CAM.

Mode	Power Consumption
Standby	80 mAh
Streaming	100–160 mAh

Table 2

Specifications of OV2640 and OV5640 cameras.

Features	OV2640	OV5640
Sensitivity	0.6 V/lux-sec
Optical sensor	1/4″ (4:3 format)
Resolution	$1600\times 1200$	$2600\times 1920$
Frame rate	2MP@15fps	5MP@15fps
Autofocus	N/A	Available in OV5640-C

Table 3

Details of endpoints accessible via the Web API.

Endpoint	Request Method	Description {Parameters}
/api/Device	GET;POST	Retrieve information about devices/Create a new device resource
/api/Device/{id}	GET;PUT	Retrieve information about a specific device by its ID/Update an existing device resource by its ID {id (int32)}
/api/Device/IPDevice/{id}	GET;POST	Retrieve the IP address associated with a specific device by its ID/Update the IP address for a specific device by its ID {id (int32)}
/api/Image	GET;POST	Retrieve information about images/Create new image resource information
/api/Image/{id}	GET;POST	Retrieve information about a specific image by its ID/Upload an image for a specific device by its ID {id (int32)}
/api/Image/UpLoadImage/{deviceId}	POST	Upload an image taken by a specific device given by its ID in the monitoring phase. {deviceId (int32)}
/api/Image/UpLoadImageTest/{deviceId}	POST	Upload a test image taken by a specific device given by its ID in the testing phase. {deviceId (int32)}
/api/SettingDevice	GET;POST	Retrieve information about device settings/Create a new device setting resource
/api/SettingDevice/{id}	GET;POST	Retrieve information about a specific device setting by its ID/Update an existing device setting resource by its ID {id (int32)}

Table 4

Parameters that can be modified in Testing and WebServer states.

Parameter	Range Values	Description
{Type}	{Default Value}
framesize {uint8_t}	0–22 {11}	0: 96X96; 1: QQVGA; 2: QCIF; 3: HQVGA; 4: 240X240; 5: QVGA; 6: CI; 7: HVGA; 8: VGA; 9: SVGA; 10: XGA; 11: HD; 12: SXGA; 13: UXGA; 14: FHD; 15: P_HD; 16: P_3MP; 17: QXGA; 18: QHD; 19: WQXGA; 20: P_FHD; 21: QSXGA; 22: INVALID.
scale {bool}	{0}	Image scaling.
binning {bool}	{0}	Grouping of px.
quality {uint8_t}	0–63 {5}	Overall excellence or level of perfection.
brightness {int8_t}	−2–2 {0}	Overall lightness or darkness.
contrast {int8_t}	−2–2 {0}	Difference in brightness or color intensity between different parts of an image.
saturation {int8_t}	−2–2 {0}	Intensity or purity of colors.
sharpness {int8_t}	−2–2 {0}	Quantitative measure of the clarity.
denoise {uint8_t}	0–8 {0}	Reducing or eliminating unwanted noise.
special_effect {uint8_t}	0–6 {0}	0: No_Effect; 1: Negative; 2: Gray_Scale; 3: Red_Tint; 4: Green_Tint; 5: Blue_Tint; 6: Sepia.
wb_mode {uint8_t}	0–4 {0}	Overall excellence or level of perfection.
awb {uint8_t}	0–4 {0}	Automatic White Balance.
aec {uint8_t}	0–4 {0}	Auto Exposure Compensation.
ae_level {int8_t}	−2–2 {0}	Compensation to be applied to the exposure.
aec_value {uint16_t}	0–1200 {0}	Specific value used to set automatic exposure compensation.
agc_gain {uint8_t}	0–30 {0}	Automatic Gain Control.
gainceiling {uint8_t}	0–511 {248}	Maximum gain level.
bpc {bool}	{1}	Black Point Compensation.
wpc {bool}	{1}	White Point Correction.
lenc {bool}	{1}	Line Length Compression.
hmirror {bool}	{0}	Horizontal image mirror.
vflip {bool}	{0}	Vertical image flip.

Table 5

Working regime in the experiment.

Time (s)	Event	Expected Regime
0	System start-up configured in monitoring mode, with a frame upload period of 60 s and framesize of 1280 × 720.	After an unspecified start-up period, it enters monitoring mode.
300	Remote reconfiguration to web server mode.	After an undetermined time until the system queries the server for configuration, the image upload is stopped and the web server is started.
360	Client connection to web server.	The web server task responds to the client and serves the web page.
420	The client starts streaming from the web page.	The system launches a parallel task to the web server that sends frames continuously.

Table 6

Average power consumption in each regime.

Regime	Time Interval (s)	Average Power Consumption (W)
System start-up (a)	0–7	0.925
Image upload (b, c, d, e f)	7–13, 62–68, 122–128, 181–187, 242–247	0.960
Web server Idle (g)	304–362	0.647
Web server Servicing (h)	362–423	0.641
Web server Streaming (i)	423–480	1.017
Idle	Other intervals	0.623

Table 7

Best values obtained for the metrics evaluated with the different cameras.

	OV2640 (Std Model)	OV2640 (RYS Model)	OV5640-C
RMS Contrast	8.214 × 10−2	1.187 × 10−1	1.539 × 10−1
Image Entropy	6.513	6.665	7.523
Image Sharpness	26.217	33.920	49.152
NIQE	8.606	6.403	5.989
MFT	23.260	81.146	42.082

References

1. Dent, D.; Binks, R.H. Insect Pest Management; 3rd ed. CABI: Oxfordshire, UK, 2020; [DOI: https://dx.doi.org/10.1079/9781789241051.0000]

2. Pedigo, L.P.; Rice, M.E.; Krell, R.K. Entomology and Pest Management; Waveland Press: Long Grove, IL, USA, 2021.

3. Azfar, S.; Nadeem, A.; Ahsan, K.; Mehmood, A.; Siddiqui, M.S.; Saeed, M.; Ashraf, M. An IoT-Based System for Efficient Detection of Cotton Pest. Appl. Sci.; 2023; 13, 2921. [DOI: https://dx.doi.org/10.3390/app13052921]

4. The Federal Integrated Pest Management (IPM) Coordinating Committee (FIPMCC). A National Road Map for Integrated Pest Management; Technical Report United States Environmental Protection Agency: Washington, DC, USA, 2018.

5. Costa, C.M.; Camargo, A.P.; da Silva, E.A.; Bento, J.M.S. Automated Barometric Chamber for Entomology Experiments: Arthropods’ Behavior and Insect-Plant Interactions. Appl. Sci.; 2022; 12, 6971. [DOI: https://dx.doi.org/10.3390/app12146971]

6. Stringer, L.D.; Soopaya, R.; Butler, R.C.; Vargas, R.I.; Souder, S.K.; Jessup, A.J.; Woods, B.; Cook, P.J.; Suckling, D.M. Effect of Lure Combination on Fruit Fly Surveillance Sensitivity. Sci. Rep.; 2019; 9, 2653. [DOI: https://dx.doi.org/10.1038/s41598-018-37487-6] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/30804349]

7. Böckmann, E.; Pfaff, A.; Schirrmann, M.; Pflanz, M. Rapid and low-cost insect detection for analysing species trapped on yellow sticky traps. Sci. Rep.; 2021; 11, 10419. [DOI: https://dx.doi.org/10.1038/s41598-021-89930-w]

8. Khan, S.; Vasudevan, S.; Maurya, M.; Ansari, M.S. Development of a Compact, Cost-Effective Photoacoustic Spectral Response Measurement System for Biomedical Applications. IEEE Trans. Instrum. Meas.; 2023; 72, pp. 1-11. [DOI: https://dx.doi.org/10.1109/TIM.2023.3284949]

9. Guagalango-Gomez, P.J.; Balbuena-Campuzano, C.A.; Chunab-Rodriguez, M.A.; Rodriguez-Arce, J.; Vinolas, J.; Santana-Diaz, A. Raspberry Pi-Based Low-Cost System for Electrical Parameters Gathering and Analysis for Performance Evaluation of Electric Vehicles. IEEE Trans. Instrum. Meas.; 2023; 72, pp. 1-9. [DOI: https://dx.doi.org/10.1109/TIM.2023.3244815]

10. Nguyen, D.K.; Nguyen, L.; Le, D.V. A Low-Cost Efficient System for Monitoring Microalgae Density Using Gaussian Process. IEEE Trans. Instrum. Meas.; 2021; 70, pp. 1-8. [DOI: https://dx.doi.org/10.1109/TIM.2021.3119142]

11. Cantelli, L.; Bonaccorso, F.; Longo, D.; Melita, C.D.; Schillaci, G.; Muscato, G. A Small Versatile Electrical Robot for Autonomous Spraying in Agriculture. AgriEngineering; 2019; 1, pp. 391-402. [DOI: https://dx.doi.org/10.3390/agriengineering1030029]

12. Sciarretta, A.; Calabrese, P. Development of Automated Devices for the Monitoring of Insect Pests. Curr. Agric. Res. J.; 2019; 7, pp. 19-25. [DOI: https://dx.doi.org/10.12944/CARJ.7.1.03]

13. Cardim Ferreira Lima, M.; Damascena de Almeida Leandro, M.E.; Valero, C.; Pereira Coronel, L.C.; Gonçalves Bazzo, C.O. Automatic Detection and Monitoring of Insect Pests—A Review. Agriculture; 2020; 10, 161. [DOI: https://dx.doi.org/10.3390/agriculture10050161]

14. De Cesaro Júnior, T.; Rieder, R. Automatic identification of insects from digital images: A survey. Comput. Electron. Agric.; 2020; 178, 105784. [DOI: https://dx.doi.org/10.1016/j.compag.2020.105784]

15. Gonçalves, J.; Silva, E.; Faria, P.; Nogueira, T.; Ferreira, A.; Carlos, C.; Rosado, L. Edge-Compatible Deep Learning Models for Detection of Pest Outbreaks in Viticulture. Agronomy; 2022; 12, 3052. [DOI: https://dx.doi.org/10.3390/agronomy12123052]

16. Deng, F.; Mao, W.; Zeng, Z.; Zeng, H.; Wei, B. Multiple Diseases and Pests Detection Based on Federated Learning and Improved Faster R-CNN. IEEE Trans. Instrum. Meas.; 2022; 71, 3523811. [DOI: https://dx.doi.org/10.1109/TIM.2022.3201937]

17. Li, R.; Jia, X.; Hu, M.; Zhou, M.; Li, D.; Liu, W.; Wang, R.; Zhang, J.; Xie, C.; Liu, L. et al. An Effective Data Augmentation Strategy for CNN-Based Pest Localization and Recognition in the Field. IEEE Access; 2019; 7, pp. 160274-160283. [DOI: https://dx.doi.org/10.1109/ACCESS.2019.2949852]

18. Li, J.; Su, Y.; Cui, Z.; Tian, J.; Zhou, H. A Method to Establish a Synthetic Image Dataset of Stored-Product Insects for Insect Detection. IEEE Access; 2022; 10, pp. 70269-70278. [DOI: https://dx.doi.org/10.1109/ACCESS.2022.3188282]

19. XFARM. Protección de Cultivos|Software y App xFarm. 2024; Available online: https://xfarm.ag/es/xfarm-analytics (accessed on 6 November 2024).

20. Faria, P.; Nogueira, T.; Ferreira, A.; Carlos, C.; Rosado, L. AI-Powered Mobile Image Acquisition of Vineyard Insect Traps with Automatic Quality and Adequacy Assessment. Agronomy; 2021; 11, 731. [DOI: https://dx.doi.org/10.3390/agronomy11040731]

21. Kathole, A.B.; Vhatkar, K.N.; Patil, S.D. IoT-Enabled Pest Identification and Classification with New Meta-Heuristic-Based Deep Learning Framework. Cybern. Syst.; 2022; 55, pp. 308-408. [DOI: https://dx.doi.org/10.1080/01969722.2022.2122001]

22. Parab, C.U.; Mwitta, C.; Hayes, M.; Schmidt, J.M.; Riley, D.; Fue, K.; Bhandarkar, S.; Rains, G.C. Comparison of Single-Shot and Two-Shot Deep Neural Network Models for Whitefly Detection in IoT Web Application. AgriEngineering; 2022; 4, pp. 507-522. [DOI: https://dx.doi.org/10.3390/agriengineering4020034]

23. Preti, M.; Moretti, C.; Scarton, G.; Giannotta, G.; Angeli, S. Developing a smart trap prototype equipped with camera for tortricid pests remote monitoring. Bull. Insectology; 2021; 74, pp. 147-160.

24. Albanese, A.; Nardello, M.; Brunelli, D. Automated Pest Detection with DNN on the Edge for Precision Agriculture. IEEE J. Emerg. Sel. Top. Circuits Syst.; 2021; 11, pp. 458-467. [DOI: https://dx.doi.org/10.1109/JETCAS.2021.3101740]

25. Doitsidis, L.; Fouskitakis, G.N.; Varikou, K.N.; Rigakis, I.I.; Chatzichristofis, S.A.; Papafilippaki, A.K.; Birouraki, A.E. Remote monitoring of the Bactrocera oleae (Gmelin) (Diptera: Tephritidae) population using an automated McPhail trap. Comput. Electron. Agric.; 2017; 137, pp. 69-78. [DOI: https://dx.doi.org/10.1016/j.compag.2017.03.014]

26. Hadi, M.K.; Kassim, M.S.M.; Wayayok, A. Development of an Automated Multidirectional Pest Sampling Detection System Using Motorized Sticky Traps. IEEE Access; 2021; 9, pp. 67391-67404. [DOI: https://dx.doi.org/10.1109/ACCESS.2021.3074083]

27. Azfar, S.; Nadeem, A.; Ahsan, K.; Mehmood, A.; Almoamari, H.; Alqahtany, S.S. IoT-Based Cotton Plant Pest Detection and Smart-Response System. Appl. Sci.; 2023; 13, 1851. [DOI: https://dx.doi.org/10.3390/app13031851]

28. Zhang, J.; Yu, H.; Deng, H.; Chai, Z.; Ma, M.; Zhong, X. A Robust and Rapid Camera Calibration Method by One Captured Image. IEEE Trans. Instrum. Meas.; 2019; 68, pp. 4112-4121. [DOI: https://dx.doi.org/10.1109/TIM.2018.2884583]

29. Suto, J. Hardware and Software Support for Insect Pest Management. Agriculture; 2023; 13, 1818. [DOI: https://dx.doi.org/10.3390/agriculture13091818]

30. Suto, J. Codling Moth Monitoring with Camera-Equipped Automated Traps: A Review. Agriculture; 2022; 12, 1721. [DOI: https://dx.doi.org/10.3390/agriculture12101721]

31. Ricolfe-Viala, C.; Esparza, A. The Influence of Autofocus Lenses in the Camera Calibration Process. IEEE Trans. Instrum. Meas.; 2021; 70, pp. 1-15. [DOI: https://dx.doi.org/10.1109/TIM.2021.3055793]

32. Hevia, L.V.; Patricio, M.A.; Molina, J.M.; Berlanga, A. Optimization of the ISP Parameters of a Camera through Differential Evolution. IEEE Access; 2020; 8, pp. 143479-143493. [DOI: https://dx.doi.org/10.1109/ACCESS.2020.3014558]

33. Peli, E. Contrast in complex images. JOSA A; 1990; 7, pp. 2032-2040. [DOI: https://dx.doi.org/10.1364/JOSAA.7.002032]

34. Li, Q.; Wang, H.; Li, B.Y.; Yanghua, T.; Li, J. IIE-SegNet: Deep Semantic Segmentation Network with Enhanced Boundary Based on Image Information Entropy. IEEE Access; 2021; 9, pp. 40612-40622. [DOI: https://dx.doi.org/10.1109/ACCESS.2021.3064346]

35. Ji, W.; Wu, J.; Zhang, M.; Liu, Z.; Shi, G.; Xie, X. Blind Image Quality Assessment with Joint Entropy Degradation. IEEE Access; 2019; 7, pp. 30925-30936. [DOI: https://dx.doi.org/10.1109/ACCESS.2019.2901063]

36. Zhu, M.; Yu, L.; Wang, Z.; Ke, Z.; Zhi, C. Review: A Survey on Objective Evaluation of Image Sharpness. Appl. Sci.; 2023; 13, 2652. [DOI: https://dx.doi.org/10.3390/app13042652]

37. Mittal, A.; Soundararajan, R.; Bovik, A.C. Making a “Completely Blind” Image Quality Analyzer. IEEE Signal Process. Lett.; 2013; 20, pp. 209-212. [DOI: https://dx.doi.org/10.1109/LSP.2012.2227726]

38. Smith, W.J. Modern Optical Engineering; 4th ed. SPIE Press: Bellingham, WA, USA, 2007; Volume PM180.

39. Barbedo, J.G.; Castro, G.B. Influence of image quality on the identification of psyllids using convolutional neural networks. Biosyst. Eng.; 2019; 182, pp. 151-158. [DOI: https://dx.doi.org/10.1016/j.biosystemseng.2019.04.007]

40. Preti, M.; Verheggen, F.; Angeli, S. Insect pest monitoring with camera-equipped traps: Strengths and limitations. J. Pest Sci.; 2021; 94, pp. 203-217. [DOI: https://dx.doi.org/10.1007/s10340-020-01309-4]

41. Leon-Garcia, F.; Palomares, J.; Olivares, J. D2R-TED: Data—Domain Reduction Model for Threshold-Based Event Detection in Sensor Networks. Sensors; 2018; 18, 3806. [DOI: https://dx.doi.org/10.3390/s18113806]

42. Leon-Garcia, F.; Rodriguez-Lozano, F.J.; Olivares, J.; Palomares, J.M. Data Communication Optimization for the Evaluation of Multivariate Conditions in Distributed Scenarios. IEEE Access; 2019; 7, pp. 123473-123489. [DOI: https://dx.doi.org/10.1109/ACCESS.2019.2936918]