SEEING LIKE A BIKE: Calibration and system de-bugging

Sensor calibration was the group’s main focus for the sixth week of the program. The Gas sensor and the GPS proved to be tougher to tame than the others.

The gas sensors seemed to be providing a wide range of values with absolutely no consistency. So to calibrate them we need to measure the voltage of the sensor when it is in an atmosphere devoid of the gas whose concentration is to be measured. This voltage serves as the base value which we feed into the code and which we would consider as the “zero”.

The first method we tried in an attempt to calibrate was to gently release Helium gas over the sensors using Helium balloons bought at the local store. This proved to be an inefficient method as the release of Helium was quicker than the response rate of the sensor and there was never really enough time for the sensors to record the voltages corresponding to the Helium before the balloon ran out of gas. Another downside to this method was that Helium balloons usually still do contain about 5% of normal air in them too, which would affect calibration of the sensors.

So to avoid this the next thought was to use a vacuum chamber which we could fill with Helium and allow the sensors to receive ample time to adjust to the environmental changes, while also getting rid of interference from the External air. We then went on a hunt for a vacuum chamber but turned up empty handed.

The option that opened up to us next was godsend. We are going to be given access to the nearby sensing station, where we will co-locate our sensor with the existing sensors and then be able to detect any variances in the values and adjust our sensors respectively.

Another issue that arose was the fact that every gas, if present in a certain concentration, has an effect on the other sensors.


The matrix situated at the front, has an LED array to indicate the status of different sensors.
The color “Green” means the sensor is working and receiving data.
The color “Blue” is working but not receiving correct data.
The color “Red” is that it is not working at all.

During the final setup and mounting of the system on a bike we realized the sensors from the Arduino were red. This posed a huge problem as the major portion of the system had now decided it just didn’t want to work!

At first we thought it was the fact that the raspberry had a certain delay on startup, which the arduino didn’t have and hence there was no sync between the two boards. We turned out to be right, partially.

It turned out that at first the arduino sent out garbage “nack” values. These values followed a particular sequence before the actual data transmission began. This was the cause of the time lapse between data transmission and collection. So we then proceeded to code the raspberry to be a Master device which would control the Slave Arduino. It could now find out when the last character in the sequence of garbage appeared and then reset the arduino for data transmission so that the two boards would be in sync.


Yesterday saw the first 15 min. test run of the system fully functional, but with certain sensors non calibrated.
The Pilot data on running preliminary data visualization yielded the following charts.


In the first row we see the Left Sonar Data and Right Sonar Data respectively.
The second row shows us the Gas Sensor Data.
The Left LIDAR shows lesser peaks, than in comparison to the Right LIDAR. This is correct keeping in mind the fact that on the Right we have many obstacles on the side where the sidewalk is present, as compared to the road side.

The Gas sensor data was plotted just to see if the sensors were producing data in real time conditions. They mean nothing as they have not yet been calibrated.

For some reason, 3min into the test, the GPS stopped writing to the JSON file and hence we were limited to the 3min for test data.
We aren’t really sure as to why this problem arose and that would bring me to the part of what we plan to do for the coming week.


The next week would see the usage of the sensing station for gas sensor calibrations. We would also be making adjustments for the effect of gases on the other’s sensors.
De-linking the data collection frequency of other sensors from the GPS time would also be a task. This would allow us to use data even when the GPS fails.
Speaking of failing GPS, we would have to understand and troubleshoot why the GPS stopped writing to the JSON file.


Half way to Justice

  This week we put a lot into JUMA, the Justice Map, for the Atlanta Legal Aid Society. After adding various socioeconomic layers, a search box, and edit features, our contact with the Society was so impressed she wants us to do much more! … [Continue reading]

Food for Thought: A Heap of Data Chores

Last Friday, we met with our partners from the Food Bank and they gave us further insights on the directions they would like us to take for our data collection. In addition, they gave us feedback on the SNAP app that we are building for them. They … [Continue reading]

Modeling Energy Usage at Georgia Tech

We started out with just two pieces of information to model energy usage at Georgia Tech: the date-time and the energy usage at every hour for the past three years. Below is a visualization of the raw data for one of the buildings. As you can see, we … [Continue reading]

Housing Justice: From Maps To Models

This week, we made good progress on both of our projects, the Anti-Displacement Tax (ADT) model and the Harbour Portfolio mapping tool. We read a paper from Dan Immurgluck relating to the ADT that gave us insight into what Dr. Immurgluck has done so … [Continue reading]