nowo’s ark – LTE Version
Things used in this project
Hardware components
|
ELEGOO UNO R3 Board ATmega328P ATMEGA16U2 with USB Cable | × 1 |
|
ELEGOO UNO R3 Project Complete Starter Kit | × 1 |
|
Pushbutton switch 12mm | × 1 |
|
LED (generic) | × 1 |
|
Resistor 100 ohm | × 1 |
|
Breadboard (generic) | × 1 |
| PVC Pipe | × 1 | |
|
SORACOM Air Global IoT SIM | × 1 |
|
Wio LTE US Version - 4G, Cat.1, GNSS, JavaScript(Espruino) Compatible | × 1 |
Software apps and online services
|
AWS EC2 | × 1 |
Hand tools and fabrication machines
|
3D Printer (generic) | × 1 |
| Handsaw | × 1 |
Story
Problem
Even in the modern world, floods continue to be one of the most common and most destructive natural disasters. Collectively, they are responsible for billions of dollars in damages annually and often claim thousands of lives. River flooding, in particular, is widespread and devastating, causing large losses of property, economic stability, and human life.
As global temperatures continue to increase due to climate change, flooding will become increasingly more frequent and deadly. A 2014 New York Times reportestimates that one out of every forty people will be living in a flood-prone area by the end of the century if current climate trends continue. However, those affected by rising water levels are located disproportionately in poorer South and East Asian nations, such as Vietnam and Bangladesh. 9 out of 10 nations named “most at-risk” are in the report are in this region. Despite recent developments of advanced levees and warning systems, such nations are unable to implement such solutions due to financial or environmental barriers. Death tolls, injuries, and damages due to flooding will continue to increase if the problem of flooding is left unresolved.To help alleviate the destructive effects of floods, we propose nowo’s ark, an inexpensive device aimed at flood-prone countries for warning people about rising water levels before floods strike.Planning and Research
In developing this device, our research primarily focused on uncovering why flooding remains such a destructive force in South and East Asia in particular. We identified this area as especially vulnerable to floods but were unsure as to why current solutions have failed to address the issue. Our goal was to answer this question in order to guarantee the applicability and usefulness of nowo’s ark where more common approaches have failed.During our research, we saw certain solutions coming up again and again. Some are listed below alongside their flaws. We do not include programs such as flood insurance, as such programs do not prevent damage or are unavailable in most regions.
Levees — This structure is most common in developed areas that have grown alongside flooding (i.e. the Netherlands and the Mississippi River delta). They are extremely effective at preventing regular flooding; however, they are susceptible to sudden swells and require significant investment in both time and money to maintain. The regions we are targeting usually do not have such resources to implement levees.Monitoring/Warning Systems — This strategy involves placing a series of gauges along the length of a river and some form of communication with residents of the areas affected. These gauges are monitored for changes; if it detects the water level rapidly increasing, people nearby are alerted. Monitoring for changes is usually handled by a government agency. This system is currently used in the United States, where the NOAA and the USGS are responsible. Current designs feature a sensor tower with water intakes connected to a satellite antenna for communication. Though widely applicable, such sensors are expensive to implement and maintain as they require altering the riverbank to fit them in. In addition, communication is a problem. Alert systems in Vietnam, for example, rely on a web-based portal created by the Pacific Disaster Center. In regions where free, accessible, and reliable internet access is not a given, this design is flawed.Barriers and dams — Infrastructure to hold back water is particularly common in places like Louisiana or along the Yangtze River, where floods are cyclical and common. Though effective, these projects not only require a significant investment in time and money to implement and maintain but also remain ineffective for years before use. In addition, these engineering efforts may be susceptible to large swells.Relocation — Perhaps the most effective strategy in preventing deaths and injuries, relocation involves moving residents away from regions where floods and other natural disasters are common. Incentives for relocation usually come from the government in the form of home buyouts and sponsored evacuations away from bodies of water. Therein lies the problem; rivers provide an accessible means of transportation and economic growth, especially where road infrastructure is not developed. The loss of river access is extremely detrimental to growth, even without factoring in the large fiscal impact of incentives.Throughout the course of our research, we realized that the array of issues with existing solutions essentially boils down to two factors: time to deploy and cost of the solution. We eventually decided to work off of current monitoring system designs. Because of the problems we have found above, we focused on minimizing cost while also maximizing the number of people we can reach.
Project Proposal
Our team hopes that our project, nowo’s ark, will be widely used and help minimize loss due to flooding globally. It will be anchored by river banks such that it is partially submerged under normal conditions. The device itself will be enclosed in an ABS plastic pipe which will act as an enclosure for electronics inside. We plan to use an Arduino, which will be triggered by a floating disc on the water’s surface below. Upon activation, the microcontroller will use an included GSM SIM to ping a central server. From that point, our server can process received information before alerting residents via a more accessible method of communication: the SMS text messages.Because minimizing cost is central to our design, we have opted for an almost entirely plastic chassis, with the Arduino as the most expensive component at under $15. The entire electronics of the project could be found in a simple Elegoo Starter Kit. The device remains dormant until water level rises, so battery consumption is not an issue. These choices will make manufacturing and deployment easier in areas previously unreached by existing solutions.
HackSC Prototype
Link to HackSC Devpost submission: https://devpost.com/software/nowos-arkWhile researching datasets, we noticed a particularly interesting one on flood data. We noticed there were many floods in the United States but relatively few deaths and displacements as a result of them. In contrast, we noticed that many Southeast Asian countries had about the same number of floods but a much higher number of deaths and displacements as a result of them. Through more thorough research, we found that a big reason why is because of the lack of accessible warning systems. Also, we named it because of our obsession with owo and uwu.
At HackSC, we had a limited amount of time to develop a working prototype. We had an Elegoo Starter Kit with us which contained a variety of buttons and wires for us to quickly prototype with. I quickly designed a simple disk with Autodesk Inventor that would function as the button presser. Because of the density of PLA and our infill settings, the disk would float on water. As water levels rise due to flooding, the disk would float up with the water level and contact the button. With increasing water pressure, the disk would activate the button. Using the Qualcomm Dragonboard 410C and the Arduino from our Elegoo Starter Kit, the Arduino would write to the serial indicating a button press. Since the Dragonboard is connected to the Internet, it would send a HTTP request over to a serverless compute instance on Cloudflare. This serverless compute instance would then contact the Twilio API to send messages to all affected residents of the flood. Overall, the price of the entire flood sensor would cost less than $15.
Finally, we overheard many people jokingly remark owo and uwu at USC. I felt a strong urge to utilize these important words into our project and thus, nowo’s ark was born.For those unfamiliar, nowo’s ark is a pun on the Noah’s ark story from the Bible and owo.
Polishing the Prototype
One of the biggest issues about our HackSC project was the lack of enclosures. If there was a flood, then there must be rain. Water could seep into the electronics easily as the electronics were only strapped on using electrical tape. I designed a few enclosures to ensure that rain would be less likely to destroy our electronics.
Another issue is with flood water. How could the flood water enter the contraption when the ABS tube was completely covered? To fix this problem, I simply drilled 8 holes around the tube. Water would enter through those holes and cause the disk to rise.
An issue during the demos at HackSC was the disk falling out as we were transporting the device. I placed sticks into four of the holes drilled earlier. This way, the disk would not fall out of the device.
Originally, I wanted the electronics to be clipped and hanging from some 3D printed clips. However, this idea was scrapped as I ran out of time in making them work properly. Instead, I created a support layer which would contain the electronics in the flood detector. There are two hooks along the side to hook onto the lid. The lid is a simple cylinder with a lip and two holes cut out for the hooks of the support layer. To securely attach the lid, I could simply align the holes and hooks and then twist the lid. Now the lid cannot fall off the support. In the future, I might implement a screw design which would be even more secure, but I created this simple lid as a proof of concept.
Unfortunately, I made the lid and support too small to fit the Arduino’s USB cable and power. Next time, I will make it larger.
After fixing a few mistakes with the initial prototype, we used the Seeed Wio LTE board to transition this project to use cellular data rather than WiFi. With cellular, we can set up flood sensors anywhere with a data connection rather than being limited by the range of WiFi signals. We used the Grove kit provided to recreate the project with Grove components. This made our project tidier.
Testing
CAD
This is a clip for the electronics. Two of them are intended to hold up the Arduino. This is not being implemented into the project because I realized it was a dumb idea 30 minutes after printing them out. The current way I am using to hold the electronics in place is with a copious supply of electrical tape.
This is the disk that floats up to contact the button. It is less dense than water because of infill settings. I tested its density by tossing the disk into a bathtub.
This is the support. It supports the Arduino through a lot of electrical tape. Notice the two hooks.
This is the lid. Notice the two holes.
Electronics
The wiring is quite simple for this project. There is an Arduino connected to a Linux board through the USB cable. DC power is connected to the Linux board. On the Arduino, one of the legs of the button is connected to pin 8. The adjacent leg is attached to 5V. The opposite leg is attached to a resistor connected to ground. This way the default value is LOW while the switch value would be HIGH. An optional LED can be attached to pin 9. This LED would light up for 3 seconds when the button is pressed.
The Arduino code is also quite simple. It does a timer check to ensure there is no web server spamming. If this was deployed into production, I would change this to the flood detector only detects a single button press and turns off.
On the Linux board side, we use `pyserial` to communicate with the Arduino. An infinite loop is established which would attempt to read the Arduino serial. If a flood was detected, an HTTP request is sent to our server which will log flood data and warn residents of an impending flood.
Software
Our server can be set up on Google Cloud and AWS easily.
Google Cloud
We used Google Cloud’s App Engine, which supports Node.js and handy tools and configurations out-of-the-box.
Using the web command-line interface (CLI), we cloned the server code from GitHub. Keep in mind that the public code is missing the vitalsecrets.js (this file contains private database and API keys) and app.yaml (which will be created in the next step). There are a few steps left before the server is fully deployed. First, some dependencies for the server are required. Luckily, Node.js’s package manager, npm, makes this step trivial; typing in the command npm install is all that’s needed assuming Node.js is properly installed. Next, each app on Google Cloud requires an app.yaml file specifying what is deployed. With any command-line text editor (e.g. vim, nano, emacs, etc.), create app.yaml in the same directory. This file tells Google Cloud to use Node.js. Below are the contents of the file:
Finally, create a secrets.js with your Twilio credentials. This file must export a JSON object with three fields: authToken, number, and id. It is required for SMS texting to be functional.After running gcloud app deploy and agreeing to the prompts, Google Cloud will automatically deploy the application after a couple of minutes. AWS
The setup on AWS is more traditional than Google Cloud. Using AWS, we can launch an EC2 instance (any will do) running Ubuntu. Be sure to create a new security configuration that allows for HTTP access through port 3000 (very important otherwise the application will not be exposed to the Internet).
Run this to update
sudo apt updateRun this to install node and npm
sudo apt install nodejs Clone the repo:git clone && cd nowos-ark/serverInstall packages
npm install Create asecrets.js with your Twilio credentials. This file must export a JSON object with three fields: authToken, number, and id. It is required for SMS texting to be functional.Run the app
nodejs app.jsTo run the app in the background
nohup nodejs app.js & The URL for the app is<YOUR EC2 INSTANCE URL>:3000To deploy the actual device itself, one just needs the Arduino IDE. Plug in the cable from your Elegoo kit and hit the upload button (the arrow button).
On your Linux board, clone the repository. Open `controller.py` and replace the `/dev/ttyACM0` on line 8 with the port associated with your Arduino. This line establishes a serial connection between the computer and the Arduino.
It is the highlighted line. Also replace the next line with the URL from Google Cloud (or whatever web server you deployed the Node app on).
Run the Python code with this command: `python controller.py`. If you would like to put the process in the background, run `nohup python controller.py &`. Ensure your computer/Linux board has an appropriate data connection to the Internet.
Soracom and Cellular
I followed this guide: https://soracom.io/iot-starter-kitto set up my Soracom account. Using the Wio LTE board, I inserted the Soracom SIM card to provide a cellular connection for our project. I inserted a Grove button into the Grove slot labeled D20. This will act as contact for the disk.
To program this board, I used Arduino with this library: https://github.com/Seeed-Studio/Wio_LTE_Arduino_Library. This library makes it simple to do anything a normal cell phone can do. You can make calls, send SMS messages, and connect to the Internet. For this project, I decided to use it to make SMS messages to people affected by floodings in a particular area. The code for this is practically identical to the Arduino version. The part where the LED turns on is replaced by sending a SMS message. Be sure to replace the character array number with your actual number. In the future, we may implement this as a vector or call a server to retrieve a series of numbers.
Uploading the program is a little trickier than uploading a program to an Arduino. You have to hold the BOOT1 button and press the RST button once then release the BOOT1 button. Now, you can upload the sketch.
Data Visualization and Analysis
We retrieve live data from the server and stream it into an OmniSci instance. OmniSci provides an easy way to visualize collected data on a map. Below shows an example with historical flood data that we have collected from a study by the University of Colorado, Boulder:
We followed this tutorialto enable our server to act as a data source for the map. As each sensor is triggered, it is added to the heatmap as an event. Visualizing this data makes flood activity much more obvious, so assessing where to place the sensors is easier. Furthermore, this data collected from our sensors can be used by other institutions to more accurately pinpoint flood activity.