 Yeah, that was an issue with IoT and battery supplies and unexpected last-minute complications, which of course there are many. So welcome to our talk, finally. What do you need? Oh, yeah. Oh, one. Thank you for coming to the conference auditorium. I'm here to present my friends, Joel Savins, Grace Chin, and Charlie Mulabberle, IoT for Environmental Monitoring. Enjoy the talk. Okay, thank you, Nandan, for that excellent introduction. Now, of course, our first slide is going to be an introduction. So welcome to IoT for Environmental Monitoring. Maybe we should have called it IoT for Climate Change or Climate Science, but it's too late. We already had it on schedule. So yeah, my name is Joel Savins. I am an intern on the Red Hat Enterprise Linux, core kernel generalist development team, an undergraduate student at UMass Lowell. I don't look like the guy in the picture because I am dressed for work. I mean, my finest development, flip-flops. And I previously worked in Dr. Fred Martin's Engaging Computing Group laboratory where this project is being developed. So my name is Grace Chin. I also previously worked at Engaging Computing Group. That's where I got involved in this project. But currently, I'm a co-op intern at Red Hat and I'm going to let Charlie introduce himself. Hi, I'm Charlie. I'm a current UMass Lowell student and I'm currently working at the Engaging Computing Group where this project is being developed. And so I am the lead developer and like lead technical, the technical lead for the development on this project. I'm excited to give you this talk. That's back to Joel. Alright, so this project began as a collaboration between two professors, kind of an interdisciplinary sort of thing. One, James Heiss, a recent addition to UMass Lowell, a new professor in the Department of Environmental Earth and Atmospheric Sciences, to his hypothesis that's being tested using sensor networks that we're going to talk about in collaboration with Professor Fred Martin, a longtime professor of computer science and the recently promoted to the associate dean for student success at the Kennedy College of Sciences. And of course, he is the director of the Engaging Computing Group Research Lab where this project is being developed. And so this originally began where Fred Martin has a research lab with a bunch of students and we had recently finished some similar projects, some OT related projects that I guess they've been talking and they decided to sort of loan us to James Heiss and that's how this project got started. So this is the right talk for you. If you are interested in a couple of different things, first of all, the climate and understanding the way the climate works, the way that we can model it and how we can understand it and the way it's changing in order to actually be able to adapt and react appropriately. As if we don't really know what's going on, we can't even make any decisions on what to do. Of course, it's about the Internet of Things, those are talks called IoT. Internet of Things actually made the text wrap way too weirdly, so we just use an O. But of course, you know, they're really just a bunch of little devices connected to the Internet that rely on, you know, power and standard things. But it's a very nice buzzword, so we use it. And of course, research, testing hypotheses. I mean, nothing particularly novel about that, except that we're undergraduates, so it's, you know, interesting. And of course, human survival. I mean, usually, originally, we were going to say, save in the Earth, but then, of course, you realize, you know, it doesn't really matter what we do to the climate, the Earth will be just fine. It's human survival that we actually have to be concerned about. So in this talk, we are going to present you with an Arduino sensor network of very important features. First of all, that is open source, of course, is the main theme of this talk and this whole development conference. In order to provide the world with the greatest inspectability and make our project of the greatest use to the greatest number of people, we publish all of our source code and all of our ideas online in public with as much documentation as possible. Of course. And at the same time, that's kind of open source on the software side to provide similar levels of functionality on the hardware side. We aim to make it as low cost as possible by using chips that are low cost. I mean... So at the same time, we wanted to keep it extremely scalable so that you could have, you know, one data collection node or you could have, you know, some data collection nodes. I mean, we're going to say like any number, but within reason, pretty large number of nodes. And of course, we wanted to keep it flexible so you could use all sorts of different sensors and different combinations depending on your precision needs, depending on your power needs, you know, and just depending on what kind of metrics you want to gather. So now I'll just give a brief overview of what we're going to talk about. First, we're going to give you some background on the science behind this project and then we'll give you an overview of our hardware and the general architecture of the project. Then we'll talk about some of our challenges that we currently face, the problems that we're currently trying to overcome. Then we'll talk about our MVP, our minimum viable product, the system that we've been able to construct thus far. And then we'll talk about some of the related work, similar systems that have done similar things with our aduinos for slightly different purposes with slightly different features that we think are lacking in a couple things that we're going to present about. And then we'll discuss our next steps, what we plan to do with the system in terms of testing and deployment. And finally, we will conclude with a brief demonstration of our minimum viable product as it stands today. So without further ado, I'll pass it off to Grace, who will give you some overview of the scientific background. So as we probably all know by now, the earth has gone, has undergone concerning climate changes over the past few decades and these have been determined by scientists to be caused by human activity. And therefore it's in our best interest to take appropriate action because as Joel alluded to, if we want to have a chance of surviving as a species, then we need to make some changes. And in order to make those changes, we need to understand what exactly is happening to our oceans, wildlife, beaches, agricultural systems, and more. All of the things that you see on the screen right now are related with one another. So if anything bad happens to one of them, then they'll all suffer and ultimately will lose access to resources that we need. So in this particular project, our focus is on understanding beach aquifers. And an aquifer is basically an underground layer of rock which contains in transmits water, as you can see in the picture. And so now I want to talk to you about something called eutrophication. It's a problem that we should all care about. It causes when there's an excess of nutrients from farming that leach into the oceans via groundwater. An excess of nutrients can lead to an overgrowth of algae which can block sunlight and cause plants to not have access to sunlight and to die. And when the plants die, the bacteria use up the remaining oxygen in the water and replace it with carbon dioxide. And this causes fish and wildlife to become unhealthy and to die without oxygen to breathe. And so obviously this is a problem and it has adverse health effects for our ecosystems. And so one way that we want to understand this problem is by keeping track of the amount of dissolved oxygen in the water. And so we can see how severe, severely eutroph... eut... severely... eutrophicated? Don't say something like that. The water is and then we can make appropriate changes to fix that. But not just dissolved oxygen is what we're interested in. We also want to keep track of things like pH, temperature, pressure, oxidation reduction potential which is basically a measure of how chemically reactive the water is and electrical conductivity which is the salt content in the water. And so we can form these two fundamental research questions and they are on the geosciences side. What happens to groundwater during extreme weather conditions such as storm surge and intensified wave conditions? Like what is going to change in the metrics that we're studying? And for the engineering side of the question, how do we develop a low cost modular sensor network that collects the required data to answer this question? And so in the next slide, Charlie is going to present a solution for the engineering side of the question. Great. So this is an overview of the sensor network that we are constructing. This is a diagram of what we have going on here. In this picture we can see the representation of two nodes and a base station. This is an arbitrary number that could be different numbers of nodes. But the idea is these nodes are self-contained units that are out in the fields that have sensors that are collecting the data and they can use their radio communications to bring that data back to the base station where it can be processed and uploaded to the internet for scientists to look at. And to really highlight some of the flexibility of this network, I want to zoom in on one particular node here. If I label these sensors I could label them all being four temperature sensors but the idea here with this network is that that's kind of an arbitrary choice just as easily these could be half-temperature and half-oxidation reduction potential or three of them could be conductivity and one could be temperature. It doesn't even need to be four sensors. The idea here is that we can use whatever sensors, whatever metrics we need to be collected, we can use the right sensors to figure out what's going on in the groundwater and we can use the right number of nodes in the right positions, etc. to figure that question out in the way that's most effective and that's really the flexibility that our system offers. Now to start talking about some of the hardware we're using to do this, I'll go back to this picture here. This is kind of like the first picture we had but we're using pictures of the actual devices. So you can see the base station there is a microcontroller connected to a computer and then the two nodes are microcontrollers that have sensor peripherals attached to them. Again, that sort of modularity of the nodes, the flexibility of the system, we can see that highlighted here. These four nodes, it doesn't need to be four, but again these nodes, they can all have different setups. These different colored boards represent different metrics that we're collecting and the four of them here we see might have some that are all one metric, one that have just a couple sensors, one that has a wide variety and all of these nodes coexist in one network and can really gather whatever data is needed to answer the scientific question we're looking at. Now I want to talk about how we chose the particular devices we're going to look at and I want to start with the Feather 32U4 with low-raw radio. So this is an Arduino compatible microcontroller made by Adafruit. Their whole platform, the Feather 32U4 platform, has built-in support for a battery and then the particular one we're using has a built-in radio module. So this device is small, it's easy to use because you can program it with Arduino with the Arduino IDE and with easy to use code and the built-in battery makes it easy to make the remote deployment. The whole thing is small and compact and easy to put out in the field. It was an easy choice for us just because we needed to have something small that could use a radio. Another one is the Raspberry Pi that we're using for computer at the base station. We just needed something that could run some Python code to analyze and collect our data and it's nice and small and lightweight. So it was a good choice for us. We'll just put it in like a ranger station or somewhere dry where it can have an internet connection and power and then it can just receive the messages and do a little bit of processing and then put that right up into the cloud. And now this last technology is really one of the things that really allows us to do this. So these are ESO boards from Atlas Scientific. These boards really take the hard questions of how do you take a digital measurement of the analog world and how do you do that in a way that's easy to use. There's tons of scientific literature on how to do good science for measuring things. But the short answer is it's complicated and it's a bit beyond the scope of people who are just trying to write a problem with all the electronics and all the equipment needed to measure and operate the sensors and they present themselves as a device that we can communicate with on a bus, an ice-cred sea communication bus, and the microcontroller can just send a message to one of them saying, hey I'd like a reading and it can reply with a reading and text. So something like a temperature sensor we can just say I'd like a reading and then it says oh it's 23.67 and we can easily use that for processing. So these boards really make it easy for us and that's how we get that modularity. We can switch them out on the fly, whatever set up we need to make these nodes. We can put the right boards in there and plug in the right sensors and it makes it very straightforward for us to collect the data. Now of course I've made it sound like it's all been easy but if I talk about some of the challenges there of course are some things we've faced when we're working with these. So if I go back to these Atlas scientific boards they are easy to use but to take an accurate reading of something like electroconductivity for instance you need to compensate for the temperature of the water that is currently around the sensor and so to make an accurate reading we need to make sure that we have a temperature sensor nearby that can compensate that. We need to make sure that if we have multiple of these sensors on one node that the microcontroller can figure out which one pairs with which. So we've had to develop a spoon for how to address the devices so that on startup the node can discover what is plugged into it and figure out how to make those links internally so that it can correctly offset the readings and everything so that these boards can do that correctly for us. So that was one challenge and we're still working to implement that. We have a plan for that. Another one that was really challenging was we wanted to measure pressure with a suitable pressure sensor at the hobbyist level. We found some hobbyists or like I wouldn't say amateur but sensors that were in a similar price range similar quality to the atlas scientific ones that we were using to measure pressure but they were not really designed for underwater use. They were difficult to waterproof or impossible to waterproof and so they weren't really applicable and we struggled to find what was good for our needs. So we had to find a more expensive and more industrial grade water pressure measuring sensor that's designed to actually be submerged and then because that was like a custom thing we had to write our own sort of interface for that so a device that we can talk to that actually does some of the electronics to take a reading from that pressure sensor. So that was a challenge but that's the thing we've most recently worked out we've managed to find this pressure sensor and develop the necessary glue logic sort of between the pressure sensor and the microcontroller so they can talk to each other and so that's where we're at with the pressure sensor and having done that we do have Mino and Bio products so I want to talk about where we're at currently with the project and essentially the great thing is if we go back to this schematic we do have full data flow, if we have data going to the sensor the sensor is able to communicate back to the microcontroller and bring that data up to the node node is able to use its radio and communicate that data over to the base station which is connected to the Raspberry Pi and it can grab that data and send it up to the cloud and here is a graph that we did using a test that we're doing so this was in our lab bench we set up a temperature sensor on our bench with a one node and a couple of sensors but this is just a temperature reading and we can see a graph here of the temperature over 24 hours over the span of two days you can see a big spike at the beginning where my co-worker held on to the sensor for a couple of minutes and you can see how that brought the temperature right back up and then it came down and you can see the ambient temperature in the room how it kind of rose after they turned off the AC in the middle of the night and then right back down again at about six in the morning when they turned the AC back on in the building so that's kind of interesting and that really highlights we think what our system is capable of it's a nice demonstration that we're actually able to get that full data flow so yeah I'll pass it off to Grace to talk a little bit about some of the related work and some of the other sensor networks that are being developed or have been developed and how they stack up against our network and what we think sets ours apart so yes as Charlie mentioned there have been other efforts to create environmental monitoring systems such as ours but until now nothing has achieved all four of the major goals that we mentioned at the beginning of our talk open source low cost scalable flexible there have been systems that have achieved flexibility but not much else let's look at the aquatrol 600 for example the cost of one device one no device is $3,500 and this is without sensors and we've been able to achieve the same functionality for 100 times cheaper with the out of fruit feather there have been on the converse systems that are open source low cost and scalable but lack the flexibility of being able to use a wide range of sensors and numbers of sensors so let's look at some examples of that in essence the other Arduino sensor network deployments have had different research interests and overall they've yielded much less data and much less metrics data about much less metrics so for example there was a cave investigation from bettos at all and they only focused on three metrics pressure temperature and conductivity so it was sort of a smaller scale project and also they did not have a modular system like what we're trying to achieve and they also it wasn't wireless and also there was a soil monitoring project from pyro at all where the only metric that they cared about was the moisture content of the soil and a seismic reading project from solar lorens where similarly only one metric was collected with the acceleration of the ground movement so I'm going to pass it off to Joel who's going to conclude the talk and tell you about what our next steps are okay thank you very much Grace and now I will do exactly those things so first of all now that we have a minimum viable product we next have to take some steps to harden our system and in order to do that we have different kind of categories of tests that we want to do first of all we need to make sure that we actually can communicate in the kind of range that we want to that we can actually communicate across the beach and from what are the actual parameters for deployment so first we want to determine the communication range and we also want to see if they actually are resistant to weather we have this idea that they're going to be waterproof they're going to be partially submerged in beaches and in groundwater so we need to actually do some real world tests to make sure that that's actually true first we're thinking of doing a river test the Merrimack River is very close to our lab so we do one nearby then maybe at the Woods Hole Oceanographic Institute perhaps which is a little further away but a little more realistic and that will feed into that's similar to our actual deployment environment that we'll get to in a minute and of course the third category is software stability we don't want some calculation or some counter or something to be just slightly off in a way that over months and months it turns out that all our data was useless the entire time so we need to actually make sure that the software works which is just as important as the other two because then we want to actually deploy our system because we want to go hurricane hunting that is the initial deployment of our system we want to install our sensor network around two to three months before the hurricane season in Duck, North Carolina at the US Army Corps of Engineers research facility so first we want to get kind of a baseline control data set that's why we want to install a few months before and then once the hurricane season actually starts we can gather an experimental data set and then from that contrast to be able to build a data model of what kind of changes are actually occurring how the climate is changing how these metrics are actually being affected by general changes to the climate because that's really what science is about these days we just want to gather large amounts of data and then run algorithms on it so that's what we want to do we want to scale the data set and then draw conclusions from there and so now just to give a brief overview of what we discussed we run over the scientific problem that we know that the climate is changing and there are many different granular aspects of that change that we just don't understand that we just don't have enough data to really make accurate conclusions about and so that's what we're doing we just want to gather lots and lots of data using a scalable low cost modular sensor network and of course where we are today we have the data flow and we have the chips working talking to each other and we want to harden the system and iterate on it and improve it to the point where we can actually start gathering these large data sets and so finally I will conclude with a brief demonstration of the system and so we do not have our sensor network set up here but we do have a small deployment going on at our laboratory so just as a reminder here is our architecture and I have an open SSH session ok I was signed in but now I'm just going to sign it again because leaving it inactive for too long close the connection so we have an active data set collection going on but yeah I'm just going to get it in first so now I'm going into school servers and then from there I'm going into a specific computer where we are actually gathering the data and now I'm in and so here we are there are some welcome messages here it is so here is our data being gathered in real time unfortunately there was some connection that fell out so the data ends at around 10, 20 last night but you know before that I was saving around every 5 minutes and so as you can see we have timestamps and then we have a node ID and then a sensor ID say like this so like 68 represents the temperature which is unplugged so it didn't actually work we have C7 represents the battery life and so it represents it in little volts yeah it's like it's analog digital conversion thing it's not the most straightforward number honestly and another one I think is measuring conductivity but you know there's not really much that's being conducted there's no water but you know it's gathering data which aspect okay so we have the node identifier for some particular feather device and then we have IDs for the particular sensors on the nodes so here for C7 we have there's a representation of battery life it's using kind of weird units so it's not it's not entirely straightforward to convert that to volts or something and then here this one was this temperature unfortunately was unplugged so it's giving us a little error value that's what we attempted to do was go and plug in the temperature sensor and then there was an error in kind of connectivity but we still do have the data so it's yeah so using that we have a mapping of the sensor IDs to the actual sensor types of the units and then with that we can process this text file and process the data yeah that's a hardware error electrical conductivity although I think that it's dependent oh no it's oxidation reduction potential yeah so if we're going to start questions I don't want to run your talk that's what I was going to say in 10 seconds from what I was saying but yeah so without further ado can open it up to questions so yeah any questions yeah so as people ask questions please do raise your hands I'll get the mic to you and if you can, if you're not near the end of an aisle please move to one so I'm going to start alright hey guys so I just had a question about so your sensor nodes here the idea is that they're running on battery eventually right so I was curious did you come up with a power budget yet I know that a lot of these sensors can be particularly power hungry so you might have to think about putting into sleep states and stuff like that yep that's absolutely something we're working on so for whatever reason there's a photo that didn't show up but the big concern is when we're writing the code how do we make sure we're putting devices in a low power and sleep state where possible these Atlas scientific ESO sensors support built-in sleep mode and so we just have to make sure whenever we ask them for reading we just say okay now go back to sleep and we also had to investigate how to put the microcontroller into a deeper sleep and so yeah we're using both of those to minimize the power usage that we're running right now actually was a battery life test and so I guess we'd hope that we'd finish sooner so we could bring the system here but it went a little bit longer I guess we have more battery life than we had expected and so we can only show you the data from where it's still being collected but yeah that's a big concern is how do we make sure we're not using enough, not using too much power and how do we conserve that so we can go for the couple of months that we want to collect the data so that's really a great question and also for other Arduino sensor networks solar energy has been implemented so that's something that we could look into as well we have any further questions what's your plan for on the schematic you should be going into the ground how deep do you see them going and are you actually going to be digging them out you're going to get some machinery where you want to be what's your plan for getting the sensors into the ground yeah so the short answer is we're the software people so you talked to our dear colleague Mr. James Heist but the gist of it is I believe we're looking for a deployment of maybe between 5 to 10 maybe even down to 15 meters or so and just at different depths and placing the sensors in there and then measuring the water I mean because it's right near the beach and so even if we're only 5 or 10 meters down you're starting to run into obviously like beach water and groundwater from the aquifer and really like we're looking at that interface between them and how that changes so we can measure like essentially how much of that water at that depth is sort of how salty is it and other things like that to really understand where we're at in that mixing and obviously how that changes in response to the things we're trying to investigate yeah how long is the program expected to run for so we want to have an initial deployment of 2-3 months plus another deployment for the summer so around 5 to 6 months total is our target yeah in 2 stages so maybe with a change of battery in the middle but the software should be able to last that entire period looks like we might be ready to wrap up questions certainly if you have questions that you want to ask face to face I think you folks will be able to take those questions outside the conference room is that right alright thank you very much thank you everyone