To take stock in a group collaboration, I have joined Varun and Graham’s joint project in mapping the quality of street surfaces around New York City. Ultimately deciding on the Tessel platform for [literally] various plug-and-play reasons, we are now polling for data and writing to a CSV file. Ultimately, the goal of the project would be to assist the city in gaining a readily updated survey of street surfaces to assist efficient allocations of repair teams and resources. At the moment, the Department of Transportation sends survey teams with clipboards around the city to capture this same data. The results are collected slowly, at a fairly high cost, and ultimately are not updated often. The barrier of entry to improve this collection method is fairly low. Using the Tessel and its branded accelerometer, GPS, GPRS, and SD card reader modules, we are building a device to be mounted [municipal] vehicles to collect this same data. Vehicles that were already on the road for other reasons will now be doing double duty and collecting useful data for the city! The following technical considerations have come up in conversation and testing:
Aside from more answers for the above questions, we hope to demonstrate on March 24th a log and map representing data from a ‘test drive’ (bike or car mounted) around a neighborhood. Ideally we will be able to send logged accelerometer and mapped GPS data via the SMS network to a cloud based storage solution. Pulled down off the cloud, we should be able to view this data in GIS capable software for viewing and analysis. To further study the accuracy of our data, we should do the same ‘test drive’ with a clip board in hand, documenting what we believe would qualify as ‘bumpy’. If our clipboard and data classifications correlate with one another to a high degree, we are on the way to a successful sensor project! Related Work There have been a number of studies done in the field of measuring road surface quality using mobile devices and sensors. While researching this area, three studies turned up that are closely related to the work we are seeking to do, although there may be more. Perhaps the most well-known study, known as the Pothole Patrol (P2), was conducted in 2008 by MIT in Boston [1]. The P2 used a small Linux-based computer, GPS, and accelerometer to collect, filter, and classify road surface anomalies. While the study provided encouraging results, there appears to room for improvement in terms of deciphering between potholes, manhole covers, joint expansions, and railroad crossings, as well as providing ground truth. Two other studies were conducted by a team of researchers in Italy. The first was to determine if commercially available mobile devices (smartphones, tablets) could be used to detect “bump events” [2]. Similar to the above mentioned study, this was able to reliably detect road surface anomalies, but no work was done to attempt to classify the events. The second study conducted by this group focused specifically on finding the optimal thresholds of vertical impulse measurements to determine a bump event for a variety of smartphones [3]. This may provide us valuable direction when attempting to calibrate our device. While our project may initially mirror the work done by MIT, we seek to ultimately differentiate our project by collecting and synthesizing image data collected from areas where a road anomaly is detected. This will provide two advantages. First, images may be analyzed using machine learning and aid in the classification of anomalies. Second, it will provide ground truth, so regardless of how an anomaly is classified by our system, manual verification or reclassification can easily be done without requiring someone to physically travel to the location of the anomaly. Credits to Varun for this mockup image
So many sensors, so many directions My career as a control systems programmer always leaves me thinking of in the realm of digital logic. A high enough form of programming that alleviates me from thinking of voltage and circuit boards but low enough that inter connectivity involves more than off the shelf cables and example code off of Stack Overflow.
Coming from that angle, I've had gripes with the lack of flexibility of hard wired thermostats in homes. Specifically, thermostats register temperature readings from their physical locations, locations that are likely not ideal for comfortable or efficient readings. The market is just starting to introduce remote sensors into the hardware lineups, allowing averaging of sorts, but they are quite expensive and have way more features than most people need. For various reasons, i'm leaning towards the idea that the most flexible and cheap solution for do-it-yourself retrofit projects would be to make a transmitter/receiver hardware concept to transmit the digital logic for the HVAC contact closures. Reusing the thermostat one already owns, wire it to this transmitter device and place your thermostat bedside/console table if you like instead of by that drafty window it was previously next to. Wire the receiver unit directly to the HVAC system using the same wires the thermostat had previously been connected to. Pair the two, perhaps low-powered bluetooth. If price could reach $50 or lower, I'm thinking it could be extremely useful and viable. So idea aside, the raw concept is digital I/O -> Transmitter, Receiver to digital I/O and/or relays. Perhaps backup logic on the receiver side to handle loss of pairing. It should be universally compatible with all low-voltage HVAC systems where there is not some proprietary data connection to a BMS/control system. |
Justin Gordon
NYU CUSP Candidate for: |