This project is motivated by the events impacting the Atlantic Coast: the passage of Hurricane Joaquin in October of 2015, the passage of Hurricane Matthew in October 2016, and the passage of Hurricane Irma in September 2017. Although only Hurricane Matthew and Hurricane Irma made landfall, all three storms resulted in massive flooding, underscoring the need for local and state governments, emergency management teams, and decision-makers to effectively plan and respond to oncoming storms. Indeed, over the past three decades, flooding has been responsible for more than half of the deaths associated with tropical cyclones . Unfortunately, existing surge, inundation, and flood forecasting are limited, as evidenced by the recent passing of Hurricane Irma. As the powerful storm bore down on the Florida Keys and the mainland peninsula, high-resolution forecasts were significantly hindered by a lack of on-the-ground information and inadequate numerical modeling strategies. Speculation concerning the anticipated surge on both the Atlantic Eastern Seaboard and the Gulf of Mexico coastline ranged from 5 ft to 20 ft, rendering the forecasts of limited value to community decision-makers and private citizens. At the same time, the potentially catastrophic impacts of blow out tide were not disseminated through official channels. A similar storm with a different angle of approach and different forward speed could cause such an extreme surge.
In this paper, we present the work completed in the Phase I of the project―design and development of the smart drifter, which consists of sensors used to collect essential measurements. The measurements are expected to improve surge forecasting over sub-grid domains on the order of one kilometer or less―effectively, at the street-by-street level.
2. The Smart Drifter
The Phase I of the project focused on creating the prototype of the smart drifter to build the foundation of the sensing element. The effort has involved electrical design, software design, mechanical design, and experimentation. This section summarizes major activities associated with the design aspects of the work.
2.1. Hardware Design
The hardware platform was designed to acquire measurements from inertial measurement and GPS chipsets, reliably store the measurements, and provide low-power beaconing to support device recovery. The design was completed in stages to build upon increasingly robust proofs of concept (and to simplify software development). The design leverages an off-the-shelf development board that combines a 9DoF inertial measurement unit (Inven Sense MPU9250) , an ARM Cortex-M0+ processor (Atmel SAMD21) , a microSD slot, a single cell lithium-ion charge controller, and an LED. The MPU9250 is a state-of-the-art 9 degree-of-freedom MEMS IC comprising a 3-axis gyroscope, 3-axis accelerometer, and a 3-axis magnetometer, with sampling speeds up to 1 kHz. The sensor allows each drifter to measure tilt, lateral and vertical movement, and spin of the drifter’s body. The SAMD21 is a 32-bit Cortex-M0+ ARM processor that has an integrated USB stack and runs at 48MHz. This allows for the quick processing needed for collecting and storing the large amount of data collected by the sensors. The CC1101  is a 433 MHz radio chosen for beaconing as it has a low current draw of 20 mA in transmit mode and offers long range due to its lower frequency of transmission. The storage used is a SanDisk 32 GB class 10 micro-SD card. The GPS device is from NaviSys (GP-735T)  and can handle 51 channels at 10 Hz, with current consumption 37 mA. The earliest design incorporated an energy harvesting circuit based on the BQ25504  from Texas Instruments to help support the first generation’s smaller battery. Prototype units included small, flexible solar panels. This was later determined to be unnecessary given the larger batteries used in subsequent designs.
The project has resulted in three electrical designs. The first version included the Razor board, the SD card, and the GPS device. This allowed the programming team to create software components that were validated and then integrated. The board was powered by a single cell, 800 mAh lithium-ion battery. While tests were successful, several limitations were identified. The device had to be opened as part of normal use. The lid of the device held the GPS chip, while the body contained the Razor and battery. This put strain on the wires connecting the two halves when the device was opened and closed, creating a failure point via mechanical fatigue of the wires. The center of gravity of the device was also near its midpoint, allowing for a high probability of roll while in the environment. Finally, the battery was not adequate to support long duration tests; it offered a maximum run-time of about 20 hours. The next design incorporated the addition of the energy harvester, the CC1101, a second 800 mAh lithium-ion battery, and two (very) bright LEDs to support retrieval. A daughter board was created to hold all of these components. It was positioned directly above the Razor board via header pins and secured via standoffs. These additions allowed for longer run times via the larger total battery size, and easier retrieval of the device. With an expected run time of 40 hours and the addition of the larger LEDs and CC1101 radio, the operational utility of the design was significantly improved. Still, limitations remained. The device still needed to be opened as part of normal use. Further, the addition of the brighter LEDs and the CC1101 beaconing radio created a larger current draw, impacting device lifetime. Finally, there were now two lithium-ion batteries in parallel. This could lead to differences in battery aging and could lead to premature failure with no independent charge regulation.
The final hardware design incorporates all lessons learned from prior designs. A low-power load switch activated by a magnetic reed switch was added to disconnect the battery. The reed switch was incorporated in the second revision of the drifter’s lid and uses an external magnet to turn the device on and off. A waterproof USB port was introduced to simplify data access and charging without opening the device. These two changes made operating the device much more user friendly. Equally important, the device became more reliable, as the seal did not need to be reset each time the unit was opened for maintenance or data retrieval. A larger capacity, 2400 mAh single cell lithium-ion battery was added to provide even longer run times. As a secondary advantage, the larger, metal-cased battery provided a lower center of gravity for the device, which resulted in greater stability at the water’s surface.
2.2. Software Design
The software implementation collects data from the inertial measurement unit and GPS and stores the data to a micro-SD card. It manages data collection and data storage via three phases: 1) During the initialization phase, the microcontroller and peripherals are initialized. The GPS is initialized first to activate its real-time clock module, used to track time. The micro-SD card is then initialized; the FAT32 file system is used to provide read/write access to the card. A timer is used to trigger measurement recording. 2) During the collection phase, the inertial measurement unit and GPS are read. When the timer fires, the system reads acceleration, rate of rotation, and heading information from the inertial measurement unit. Since the drifter is designed to move at a slow speed, the location changes relatively slowly, so every few seconds the GPS is put into standby mode for several seconds to conserve energy. The GPS chipset maintains satellite information when in standby mode, ensuring that a sample can be ready within one second after it is switched to active mode. 3) During the save phase, IMU readings, GPS locations, and corresponding timestamps are written to the micro-SD card. The system first checks if the current file size exceeds the pre-defined limit, and a new file is created if it does.
SD storage is organized by sectors, and each sector is written as a whole, even if the size of the data to be written is smaller than the size of a sector. Consequently, collected data is written to the card in blocks of the sector size to achieve the best performance. To coordinate the collection and save phases, a double-buffer is employed. During the collection phase, the system reads IMU and GPS data and temporarily saves the readings in one buffer until this buffer is full. Then the temporary buffer is switched to the other buffer, and the system continues writing to this new buffer. At the same time, the save phase is triggered, and the data in the filled buffer is written to the micro-SD card. The size of the buffer is carefully measured and adjusted to ensure that the data in the filled buffer is saved to the SD card before the new buffer is filled.
The first version of the software was implemented based on Arduino. However, although the Arduino-based software solution worked as intended and achieved reasonable battery life, the solution suffers from two limitations. First, due to the nature of Arduino, it provides poor power management support. The microcontroller must stay in the active mode to keep the Arduino core running, enabling the services Arduino provides. Second, the implementation of the Arduino USB module is used to support Arduino programming and debug messaging; it cannot be used to transfer the files saved in the SD card.
To support fine-grained energy management and file transfer without opening the drifter, the second version is based on the Atmel Software Framework, which provides full support for the desired functions. The system is shown in Figure 1. FreeRTOS  is used as the operating system and two major tasks were created. The collection task collects data from the sensors and the save task saves the data to the micro-SD card. The double-buffer is used and a semaphore is employed to coordinate the two tasks. The save task blocks on the semaphore while waiting for a buffer to be filled. Once the buffer is full, the collection task starts writing to the other buffer and gives the semaphore to the save task, which starts saving the data. The collection task has higher priority than the save task, so that it continues data collection while the save task writes data to the micro-SD card. To ensure that the save task finishes saving a buffer before the
Figure 1. Drifter software tasks.
other buffer is full, the size of the buffers was adjusted based on the sample rate, size of the sample, and SD card write speed.
2.3. Mechanical Design
The first version of the drifter design was evaluated as a proof of concept. The design is shown in Figure 2(a). The drifter housing encloses a Razor board, a GPS receiver, and one lithium-ion battery. The buoyancy of the design was carefully adjusted so that the top of the drifter is above the water to maintain acceptable GPS signal strength. The second version of the drifter design is similar but includes additional space for two lithium-ion batteries, increasing the system's run time. The design is shown in Figure 2(b). Validation experiments were conducted using both designs. The experiments showed that the drifters worked as intended, providing robust data collection in a package capable of weathering difficult aquatic environments. However, the experiments also exposed opportunities for improvement in future revisions. Most important, the drifter is water-tight. Reaching the internal components requires disassembly, risking damage to the o-ring used to seal the top and bottom halves of the design. This was a particular issue for accessing the power switch and removing the micro-SD card for data transfer.
The improved drifter design is shown in Figure 2(c). A magnetic reed switch was added to allow switching the system on and off without opening the drifter. When the key switch is plugged in the slot, the system is off; when the switch is removed, the system is on and ready take samples. A water-tight micro-USB connector was added to allow data retrieval and battery charging without opening the drifter. The size of the drifter was increased to hold a new daughter board and a larger battery. The new design incorporates a Texas Instruments CC1101 radio for wireless beaconing and data trans-mission. Figure 2(d) shows the current version of the drifter design. This version further in-creases the inner
(a) (b) (c) (d)
Figure 2. Drifter enclosure prototypes.
void area, providing more room for the electronics, increasing buoyancy to improve the signal strength for both the GPS and the CC1101, and reducing materials costs. Structural strength appears to be unaffected by the design changes. Figure 3 show the enclosure with the hardware inside it. All floaters were printed using the Form 2 3D printer .
Laboratory testing focused on validating software functionality and measuring hardware power consumption using an oscilloscope and a high-resolution current meter. Sleep mode was enabled during the test. Results for the first version of the board are summarized in Figure 4. Results show that average power consumption when the GPS is on and off is 65 mA and 30 mA, respectively, for this design. Mechanical testing was also done in the lab, followed by another test in a swimming pool. The drifter was immersed in water with a depth of 3 meters (10 feet) for 30 minutes. No leakage was observed, giving the drifter a IP67 rating. The system continuously collected data for 20.7 hours with one 820 mAh battery; a total of 5,431,230 IMU samples and 10,696 GPS samples were recorded. Figure 5 shows the first 30,000 IMU samples collected by the system.
After several buoyancy trials performed in the lab environment, field tests were conducted in two channels close to the research facility, shown in Figure 6. Test results from the field test are summarized in Figure 7 and Figure 8. Figure 7 shows the readings collected from the IMU, separated by each axis. Figure 8 shows the recorded GPS locations. Other tests were also performed, including tests within the Savannah River, conducted by the CCU team. Results presented here are representative.
Weather events resulting in significant coastal and inland impacts are increasing both in frequency and intensity as the climate of the planet continues to change. The massive inland flooding caused by the weather events underscore the need for local and state governments, emergency management teams and decision-makers to effectively plan and respond to incoming storms. Our approach is focused on the design and implementation of sensing, modeling, and forecasting infrastructure to support flood forecasting.
In this paper, we present the first phase of our approach: design and build the
Figure 3. Drifter prototypes. (a) Sealed; (b) Open.
Figure 4. Drifter enclosure prototypes.
Figure 5. First 30,000 IMU samples.
Figure 6. Field tests. (a) Field Test 1; (b) Field Test 2.
Figure 7. Field Tests 1 IMU Readings. (a) Acceleration; (b) Rotation rate; (c) Heading reference.
Figure 8. Field Tests 1 GPS Readings. (a) Unfiltered GPS during test; (b) Unfiltered GPS in vehicle.
smart drifter used to collect the data that will be used in modeling and forecasting. The performance of the drifter and the quality of the data are essential to the next phases. We present the revisions of hardware, software, and mechanical designs. Laboratory and field tests show that the new design is a practical and reliable tool for collecting fine-grained surface water dynamics before, during, and after storm events.
This work is supported by the National Science Foundation through award RAPID-1763203.
Special thanks to Chancey Kelley, Luu Tuan Linh Dang, Nicholas Lee Yee, and Drew Van Zwieten.
 National Oceanic and Atmospheric Administration (2017) Hurricane Flooding: A Deadly Inland Danger. http://www.nws.noaa.gov/ohd/hurricane/inland_flooding.html
 Inven-Sense (2019) MPU-9250, 9-Axis MEMS MotionTracking Device. https://www.invensense.com/products/motion-tracking/9-axis/mpu-9250/
 Texas Instruments (2019) CC1101, Low-Power Sub-1 GHz RF Transceiver. http://www.ti.com/lit/ds/symlink/cc1101.pdf
 Texas Instruments (2019) BQ25504, Ultra Low-Power Boost Converter. http://www.ti.com/lit/ds/symlink/bq25504.pdf
 The FreeRTOS Kernel. Market Leading, De-Facto Standard and Cross Platform RTOS Kernel. http://www.freertos.org/