AMMonitor: Remote monitoring of biodiversity in an adaptive framework with r

Ecological research and management programs are increasingly using autonomous monitoring units (AMUs) to collect large volumes of acoustic and/or photo data to address pressing management objectives or research goals. The data management requirements of an AMU‐based monitoring effort are often overwhelming, with a considerable amount of processing to translate raw data into models and analyses that have research and management utility. We created the r package AMMonitor to simplify the process of moving from remotely collected data to analysis and results, using a comprehensive SQLite database for data management that tracks all components of a remote monitoring program. This framework enables the tracking of analyses and research/management objectives through time. We illustrate the AMMonitor approach with the example of evaluating an occurrence‐based management objective for a target species. First, we provide an overview of the database and data management approach. Next, we illustrate a few available workflows: temporally adaptive sampling, automated detection of species sounds from acoustic recordings and aggregation of automated detections into an encounter history for use in an occupancy analysis, the outcome of which can be analysed with respect to the motivating management objective. Without a comprehensive framework for efficiently moving from raw remote monitoring data collection to results and analysis, monitoring programs are limited in their capacity to systematically characterize ecological processes and inform management decisions through time. AMMonitor provides an option for such a framework. Code, comprehensive documentation and step‐by‐step examples are available online at https://code.usgs.gov/vtcfwru/AMMonitor

The practice of using autonomous monitoring units (AMUs) to monitor ecological systems has grown in the past decade, with monitoring projects focused on target species (including birds, bats, amphibians, insects and terrestrial/marine mammals; August et al., 2015;Burton et al., 2015), phenology (Crimmins & Crimmins, 2008;Miller-Rushing, Evenden, Gross, Mitchell, & Sachs, 2011) and soundscapes (Lynch, Joyce, & Fristrup, 2011;Miller, 2008;Pijanowski et al., 2011). AMUs confer many benefits. Primarily, they can be deployed for long periods of time to collect massive amounts of data, such as audio recordings and photographs. Having a record of audio and photo data allows researchers to carefully verify and analyse species identifications or other research targets a posteriori (Hobson, Rempel, Greenwood, Turnbull, & Wilgenburg, 2002;Willi et al., 2019).
However, automated methods have several limitations. First, the data management requirements of an AMU research effort are often immense. A monitoring program is a collection of research objectives, monitoring locations, equipment, people and data files, with multiple components to manage. Lacking a systematic data management approach, new entrants to the field may make imprudent choices about data organization and subsequent automated processing. Second, monitoring data are typically stored on AMUs until retrieved by researchers, causing time lapses between data collection, analysis and results. Such delays hamper the ability to efficiently address pressing ecological challenges and track progress towards management objectives. Without a comprehensive framework for moving from raw data collection to results and analysis, monitoring programs are limited in their capacity to characterize ecological processes and to inform management decisions (Williams, 2011;Williams & Brown, 2016).
To address several of these issues, we developed AMMonitor, an open source r package dedicated to collecting, storing, organizing and analysing AMU data in a way that (a) can efficiently process and store large quantities of diverse information; (b) use statistical learning algorithms to detect acoustic targets of interest; and (c) leverage existing R analytics, while inviting new analytical approaches. The AMMonitor package builds upon our r packages, monitoR (Hafner & Katz, 2018;Katz, Hafner, & Donovan, 2016a, 2016b and AMModels , and is freely available at https://code.usgs.gov/ vtcfw ru/ammon itor. The website's Wiki provides thorough documentation and instructions for use, including extensive examples and sample data. Windows users can download the zip file from https://code.usgs. gov/vtcfw ru/ammon itor/-/archi ve/maste r/ammon itor-master.zip. Mac or Linux users can download the tar.gz file from https://code.usgs.gov/ vtcfw ru/ammon itor/-/archi ve/maste r/ammon itor-master.tar.gz. These condensed files can be installed in R from the package archive file. We invite the R community to collaborate by submitting a pull request. Broadly, the AMMonitor approach starts with ecological hypotheses or natural resource management objectives (Figure 1a). To test hypotheses or to evaluate the state of a resource with respect to a management objective, data are collected using AMUs (Figure 1b).
The AMUs optionally use a wireless network to deliver acoustic recordings and photographs to disk or cloud storage (Figure 1c). Raw and processed data are stored in a SQLite database (Figure 1d). Data can be analysed with a variety of analytical methods, such as species occurrence models or soundscape analyses (Figure 1e). Analyses can be summarized and reported (Figure 1f), and resulting outputs assessed with respect to hypotheses or objectives to track progress towards research or management goals. The cycle can then repeat.
Thus, the AMMonitor package places the monitoring data into an adaptive management framework (Williams, 2011).
The AMMonitor approach was developed with a prototype of 20 smartphone-based AMUs, with a focus on acoustic monitoring (Balantic & Donovan, 2019a, 2019b, 2019c. Since then, we have added the capacity to use the smartphone's camera by enabling timed photographs and motion-triggered photographs, allowing the smartphones to act as camera traps (Donovan et al., in prep.).
However, AMMonitor does not require the use of smartphones. Its flexibility permits the analysis of data collected by other autonomous devices, and further facilitates storage of results from other analytical systems for additional processing in R.

| OVERVIE W OF FUN C TIONALIT Y
AMMonitor consists of R functions for analysis of AMU data and an accompanying data management system based on SQLite. SQLite is F I G U R E 1 The AMMonitor framework begins with basic research hypotheses or applied resource management objectives (a), proceeds to data collection (b) with external storage on cloud or disk (c), where raw and processed data are stored in a SQLite database (d), and finishes with stored analyses (e) that can be compared to the motivating objectives via reporting and data summary that provides results a researcher or manager can evaluate (f) a 'self-contained, high reliability, embedded, full-featured, public domain, SQL database engine' (SQLite, 2019). Unlike client/server SQL database options like MySQL, Oracle, SQL Server or PostgreSQL, SQLite poses the advantages of simple user set-up and no requirement to configure or maintain a server process. AMMonitor employs the r package RSQLite (Müller, Wickham, James, & Falcon, 2018) to connect R with the database and uses R functions to retrieve externally stored AMU files. Users can create a new, empty AMMonitor database with the dbCreate() function, or a sample database with the dbCreateSample() function, which allows new users to explore and test the package functions using simulated data. Both functions create a single '.sqlite' file, which can store all of the monitoring program's data up to 140 terabytes. New tables can be added by SQLite code passed with function, DBI::dbSendQuery(). Monitoring programs that process extremely large amounts of data (>1 TB) have multiple concurrent users, and have a dedicated database manager may consider adapting the SQ Lite database to a server/client version.
Database tables (highlighted in bold in this paragraph) store data and metadata about the overall monitoring effort. The tables in Figure  Database tables (capitalized in bold in boxes) store data and metadata about the overall monitoring effort. Example field names are identified with a bullet, with primary or foreign keys highlighted in bold. The tables Objective and Assessments are highlighted with a dark border to indicate that a monitoring or research program normally starts with objectives and ends with assessments. Monitoring efforts are driven by objectives (a) which are often species-centered (b). People on the monitoring team (c) deploy equipment (d) at locations (e), tracked in the deployment table (f). Location-specific spatial (g) and temporal (h) information is also stored. Deployed equipment collects recordings and/or photos on a schedule (i). Collected files are delivered to and remain in external storage, and metadata about external-based files are stored in the recordings (j) and photos (k) tables. Team members can log annotations (l) for target signals that are linked to a signal library (m), and/or can create templates (n) that automatically search for target signals. When templates are run against incoming recordings, the scores table (o) stores metrics indicating the closeness of a signal to the template. Statistical learning classifiers can return the probability that a detected event is the target signal, stored in the classifications table (p). The soundscape table (q) is outlined with a dotted line to illustrate AMMonitor's flexible design to accommodate audio or image analysis from other r packages. Data sources can be used to analyze the state of the ecosystem with respect to research hypotheses or management objectives. The assessments table (r) can be used to store analysis metadata

| E X AMPLE WORK FLOW FOR MONITORING A TARG E T SONG B IRD
We illustrate the AMMonitor workflow with a hypothetical example for a management agency. The management agency has three management objectives (Table 1)

| Temporally adaptive sampling
Once the study design has been chosen and monitoring locations are established, the next step is to schedule sampling periods for Beyond these options, one of AMMonitor's novel methodological features, temporally adaptive sampling, was heavily inspired by smartphone-based monitoring systems (Balantic & Donovan, 2019a).
In monitoring circumstances where cellular coverage is available, a key benefit of smartphone-based monitoring is the minimal lag between data collection and analysis. Data can be transmitted from the smartphone to external storage in near-real time, facilitating rapid analysis and minimizing cumbersome field trips. A drawback of using the cellular network is that smartphone data plans can be expensive.
It thus behooves smartphone-based monitoring programs to avoid squandering sampling resources.
We developed a temporally adaptive sampling algorithm that allows acoustic monitoring events to be scheduled when target species are likely to be acoustically available for capture on an audio recording. The algorithm adapts by prioritizing monitoring activity based on previous target detections at each site. In the priorities table, users can set monitoring priority weights for target species at each monitoring location. User-specified monitoring prioritization of species (via prioritySet(), priorityInit(); Figure 3a) is combined with user-supplied target species activity models that predict when focal species will be acoustically available. Target species activity models might be built based on real data, literature values, expert opinion and/or simulation (via simGlm(); Figure 3b).
These models can be stored in and retrieved from an AMModels library  provides a comprehensive illustration of how such a simulation may be conducted.

| Semi-automated detection of target sounds
Regardless of whether monitoring is being conducted via smartphone or another AMU like an AudioMoth (Hill et al., 2018), remote monitoring programs may acquire large amounts of audio data.
Humans may inspect files individually, labelling any observed tar-  (Figure 4c). High-performing models can be used on incoming detections to predict the probability that an unknown signal is from the target species (Figure 4d), improving the quality of monitoring data (Balantic & Donovan, 2019b). The end result is a collection of target signal probabilities for each detected event (stored in the classifications table).

| Analysis and assessment example: Aggregating species detections into dynamic occupancy models
Remotely collected audio and photo data can be processed and analysed in a variety of ways. Any analytical methods undertaken should be directly informed by management objectives and associated indicators. In this section, we revisit the hypothetical management agency's first objective from Table 1 Figure 4). Now, each incoming detection for Species 1 is assigned a probability that it is a target signal.
Using shapeOccupancy(), acoustic detections are aggregated into an encounter history for a dynamic occupancy model that accommodates false positives (Balantic & Donovan, 2019c), and the r package F I G U R E 4 Workflow for semi-automated detection of target sounds in AMMonitor, with some associated functions and tables

(a) (b) (c) (d)
RPresence is used to fit models of occupancy, colonization and extinction patterns for Species 1 (Figure 5c). Results from the analysis are then compared with the agency's objectives. Figure   Other examples of recurring workflows in AMMonitor include:
3. Predicting the probability that a detected event is a target signal using classifierPredict().
Many of these tasks may be written as R scripts, logged in the AMMonitor scripts table and sourced daily or run in batch mode.