Author: Saumik Narayanan

Our progress over the last week was fairly straightforward, and we are currently on track to have great results by the end of the program. We spent most of the last week without the GRIMM, so we didn’t go out to collect more data. However, we started preliminary analysis of the data we collected last Monday, testing to see if our method of mobile air quality sensing is feasible.

When the real-time clocks arrived, we connected them to the Raspberry Pi, and updated our code to take advantage of the new hardware. This was a very important step, as Pi’s themselves don’t contain a clock on-board, so when the Pi is powered off, it doesn’t actually record the passage of time, adding a significant layer of confusion onto our data collection.

In the meanwhile, Urvi has been designing a 3d printed box to place the Arduino and Air Quality sensor inside, which should hopefully mitigate the many problems we have been having with wiring. The biggest issue is simply that our current setup is only temporary, a few weeks at most, so we don’t want to take the step of soldering the wires to the Arduino. Instead, we are using hot-glue, and electrical tape, which is holding up decently, but not as reliably as we would like.

On Friday, I went out for the first time with two sensors simultaneously. Instead of going on our typical 2.5 mile route starting from Piedmont, I simply took a short loop around Georgia Tech’s campus. These results were promising, but one of our two sensors was giving us very inconsistent data, as around 10% of the time, it would just decide to not give us any data, and we couldn’t find a specific cause of this. Also on Friday, we got the GRIMM back, and to make up for lost time, I decided to go out again on Saturday to do more tests.

On Saturday, I spent the beginning part of the day setting up the entire system, and finalizing the hardware for the bike, and software for the Pi. After going for another quick ride around campus, I discovered that some of our wiring had failed on that run. The next few hours, I focused on rewiring the system, and ensuring that the system would be reliable and resistant to stress. On the second run that day, the setup worked perfectly! Additionally, the data we collected exceeded our expectations, as the two sensors seemed to be aligned perfectly with each other, and seemed to differentiate the various types of streets on the route very well. On the first three segments, the values mimicked each other, and on the 4th segment, the variance in values was significant, but easily explainable due to the positioning of the sensors on the bike (see above image), and the construction taking place on the route. In fact, we would be more worried if the data did match on the last segment!

After analyzing the data from Saturday, we went on another run today, to collect more data similar to our standard Piedmont route choice, as well as adding GPS data collected from a log on my phone. Tomorrow, we plan to have our final major data-collection day, as we will hold experiments not just on the feasibility of the system, but to collect actual, usable data! The rest of the week will be spent analyzing the data from tomorrow, and deciding our path for the last three weeks of the program.

Last week, our tasks for the week was very straightforward. All we needed to do was simply to start collecting data on our designated route in Piedmont Park. On Monday, we got the Air Quality sensors set up with the Raspberry Pi and Ardiuno, which allowed us to collect data from the sensors every three seconds. On Tuesday, we spent most of our time testing our data collection process, by collecting test runs with both the PMS Air Quality sensors, and the GRIMM, simultaneously, and comparing the two values. The PMS sensors gives us data for both PM values, and particle counts. However, the PM values, are heavily rounded, so they are not as useful for our purposes, and we decided to stick with particle counts for now.

For particle counts, both sensors data with values of 0.3um, 0.5um, 1um, 5um, etc. However, our task was made much more difficult, as the PMS gives us counts less than each value, and the GRIMM gives us counts greater than each value. For example, at 0.5um, the PMS gives us the number of particles smaller than 0.5um, but the GRIMM gives us the number of particles greater than 0.5um. This makes our comparison much harder, and less straightforward. Further complicating the issue, the PMS sensors does not give very consistent values from second to second, meaning that we need to likely aggregate data specifically depending on the type of route. Additionally, the two PMS sensors we have are not very consistent with each other, with values being off by as much as 25%. Overall, these factors will require more careful analysis after our initial data collection and calibration.

On Wednesday, we focused on getting multiple sensors connected to a single Raspberry Pi. Initially, our goal was to start data collection today, but we were still waiting on various bike parts from Amazon, so we decided to work on a related and useful task. Doing this would allow us to combine and aggregate double the amount of data on a single run, giving us more accurate data. We spent all day, running into the late evening working on this task. However due to inconsistencies with the type of text the sensors send, we were never able to have multiple sensors connected to one Pi, where our code could collect data from both sensors at startup, meaning the code would run by itself, without any human input. This was especially important, as when we are out in the field doing data, we won’t have access to a keyboard or mouse to start the program manually.

Thursday was the big day, as we came out bright and early, at 7am, and went out to Piedmont Park with a number of various types of bikes to test air quality. We made 9 bike runs, of 2.5 miles each. The route we selected had a number of diverse environments, including parks, suburban streets, urban side-roads, and major arterial with heavy construction and traffic. It was a beautiful day outside, and we had fun going around the city to get data. We also borrowed Michael, who helped us gather eye-tracking data, along with Urvi, as all of the others on our team wear glasses, which don’t work with the eye-tracking visors. Urvi and Michael each collected data on three runs. The rest of us alternated going around on the bikes collecting pollution data, so in the end, each of us went on 2-4 rides. In the meantime, we got to relax, and explore Piedmont Park!

However, once we got back, we discovered that we had made a huge mistake in our data collection code. Between each run, we needed to reboot the Raspberry Pi by unplugging and replugging it from our battery. However, because this was our first time in the field, we completely forgot about this crucial step. As a result, no pollution data was collected on this day, as our script was never run correctly. Out of the six runs with the eye-tracking visors, we were able to gather data from three of them, and the other three’s data was mysteriously corrupted. Coincidentally, all three corrupted runs were done with Michael.

On Friday, most of us took the day off, for a number of unrelated personal issues. Urvi was able to complete her research training to officially become a part of the research team. April and I were able to come in for a few hours around 4pm to finalize some of the mistakes we made on Thursday. I updated the code to create files in a different format, making data analysis simpler. We planned on doing additional test runs on Sunday to make up for the disappointing results from Thursday, but this plan was later scrapped.

Today, we went out again this morning, and collected three runs of pollution data. After these three runs, it started to rain, and we had to end our trials early. We came back to the lab, with successful data results from each run! However, as we are the bike team, more issues came up. The Raspberry Pi does not contain an onboard real-time clock, meaning that when the Pi is powered off, time isn’t kept, and it appears that time is even reset. To fix this, we have purchased real-time clocks online, and when the arrive, we will connect them to the Pi.

For the next week, our plan is to integrate the real-time clocks to our setup, and start preliminary data analysis from our results today. We will not have access to the GRIMM for the rest of the week, so we will not be able to gather any more data, but by the end of this week, we will have a robust data-collection setup, as well a solid understanding of the data we are working with. From there, it should hopefully be much easier to proceed with the project, and have meaningful results by the end of the summer

During the last week, we mainly focused on getting the air quality sensor, the PMS5003, to send data every second to the Raspberry Pi via a custom wifi chip, the ESP8266. The ESP8266 technically runs Ardunio code, so this should have been fairly straightforward, but it definitely did not end up this way.

We were given firmware directly from Purple Air, so Nic worked on setting up the files on our devices. On the other hand, I worked on using existing code from the internet which claimed to run on the ESP8266. After working on these tasks for four days, we had not made any significant progress. We consulted with April and Chris on this, and decided to make the drastic step of taking apart the Purple Air, and hooking the PMS5003 directly up to an Arduino Uno, instead of the ESP8266.

However, the Purple Air uses very non-standard wiring connectors, so we had to wire the PMS5003 to the Ardunio by finding spare wires lying around the lab, connecting them by simply sticking the wires into the pins of the PMS and Arduino, and using electrical tape to keep everything together. After uploading some simple code we found on the internet to the Ardunio, we plugged in the sensor, opened the serial monitor on my laptop, and found 3-second resolution readings! While we would have ideally had 1-second resolution instead, after dealing with 80-second resolution for the last three weeks, 3-second resolution was a godsend. When we attempted to replicate these results with the Raspberry Pi, instead of my laptop, the wiring came undone, and we couldn’t get it working for the rest of the day.

This morning, Nic came in early, and rewired the entire system using a different set of wires, with slightly thicker pins. This proved to be much more sturdy, as it stayed in for much longer. Throughout our work today, the wiring only came undone once, and it was a much more easy fix than our work on Friday. However, for our actual placements on the bike, we will need a vastly better, and more permanent solution, as biking in the real world can be pretty bumpy.

With the new wiring, we were able to get the system running fairly quickly on the Pi, and after writing some basic Python code, we could translate the code from the serial monitor to a CSV file to compare to the CSV file from the GRIMM, our research-grade air quality sensor. Our next steps for the week are to compare the data generated from our two sensors, and start calibrating the data from the sensors on our test run to Piedmont Park.

As an aside, we added a new member to our team Friday morning. Welcome to Urvi Latnekar, a Computer Science at Bennett University near Delhi, India! She will be working with us for the rest of the summer, and brings to the team her experience working with Arduinos, and air pollution data in the farmlands of India.

 

Last week, our main goal was to actually get the Purple Air and Raspberry Pi on the same network, and communicating with each other so we could get the sensor data in real-time. After a lot of work, we were able to connect the two, but we are still stuck on obtaining meaningful data from our sensors.

Both the Purple Air and the Raspberry Pi have the ability to broadcast their own networks for any device to connect to. Based on the guides we were reading, we needed to connect the Purple Air onto the Raspberry Pi’s wifi network. However, we were stuck on this for half a week trying to get the two to talk this way. We spent half a week alone on setting up the ad-hoc wifi network capabilities of the Raspberry Pi, while simultaneously connecting to the internet via ethernet.

Frustrated, we reached out to the author of a online project on Github, who had worked with the Purple Air before, and an affiliate of the University of Michigan. He told us that we needed to work the other way around, and connect the Pi to the Purple Air instead. Once we followed the steps he outlined for us, we were able to connect the two devices together fairly quickly.

However, as we learned, the Purple Air reads data every second, but only outputs its data every 80 seconds in an aggregated manner. This is far too slow for our application, as bikes can generally get very far in 80 seconds. We know technically, the underlying sensor, the PMS5003 Laser Particle Counter, is able to output data every second, and currently we are just working on actually obtaining this data.

To solve this, we are trying two different approaches. The first is to directly modify the firmware that the Purple Air runs on, which is what Nic is currently working on. The second approach is to bypass the Purple Air completely, and attempt to talk to the underlying sensor, the PMS5003, which is what I am working on. Both Nic and I have been making progress and facing challenges while trying to obtain the mystical 1-second data output.

The PMS5003 uses a wifi chip called the ESP8266, which runs Arduino code to connect the sensor to the broadcasting capability of the Purple Air. Because I don’t have any Ardunio experience specifically, I was playing around with the Ardunio IDE and trying things to immerse myself in this new technology. I tried uploading a simple script to one of our two Purple Airs, and it overwrote everything on the Purple Air, meaning that all the functionality was lost.

Fortunately, we were able to get in contact with the support team of the Purple Air, and they gave us a binary file containing the firmware for the Purple Air. From this, we can re-flash the Purple Air to get going again. Nic has been working on modifying this file we were given, and change the format of the output, so when we re-flash the sensor, it no longer aggregates the data. In the meantime, I found a very relevant project on Github designed for the PMS5003, and I am working on getting that setup.

Tonight, we visited Civic Hack Night, run by the awesome Code for Atlanta organization, and they graciously allowed us to present our projects to the greater community! We were able to connect with some very talented members of the tech community in Atlanta, and work together to solve the issues our project has been facing recently. Code for Atlanta runs Civic Hack nights twice a month, and you should definitely check them out if you are in the area.

Urban cycling is rapidly growing as a means of transportation in cities across America. Building infrastructure for cyclists has a multitude of benefits: bike infrastructure is relatively cheap to implement, it provides an alternative to automobile congestion on streets and highways, it encourages healthier and more productive citizens, and provides a path of upward economic mobility by increasing access to jobs and other opportunities for those who could not otherwise afford a car.

However, planning for biking facilities has a number of challenges, especially in a city like Atlanta, whose streetscape is dominated by sprawl, and infrastructure devoted for cars instead of people. Creating attractive cycling routes requires careful attention not only to the physical transportation details concerning the route, like speed or destinations, but also understanding the needs of the people actually on the bikes. Bike paths which feel safer and more enjoyable are often vastly preferable to paths which are more practical but feel unsafe to riders.

Last year, researchers from the 2017 Civic Data Science Program developed a platform of sensors which can be mounted on a bike to track environment data for any given bike route. This year, we will continue this prior work with two goals.

First, we will be increasing the abilities of the sensor array to collect a larger, and more comprehensive dataset of current and future bike routes in Atlanta. Specifically, the two sensor types we will be working most with during the summer are for air quality, and eye-tracking. Understanding where pollution exists is important, as cyclists can be disproportionately affected by pollutants created by general road traffic, and we can learn to create routes which avoid the heaviest pollution. Eye-tracking data will serve two purposes: understanding biker sentiment by looking at where the bikers are looking, and physiologically measuring stress levels to determine how safe a route feels.

Second, we will analyze and create geographic visualizations of the data, to better understand the potential for increased cycling infrastructure in Atlanta. This will enable city planners to design bike facilities that truly meet the needs of cyclists in the city as a viable and safe form of transportation.