SpotASpot

The countdown for the most prestigious event of your college career at Northeastern begins the moment you step foot onto campus. Capstone, a mandatory requirement for all undergraduates, is the final roadblock on the way to becoming a full-fledged engineer. It is an opportunity to integrate knowledge from years of classes into a viable solution for a real-world problem.

Like any other bright eyed undergraduate engineer, I had envisioned Capstone ever since I was a freshman. Sure enough though by the time senior year rolled around I was caught off guard. Despite having 5-years of coursework under my belt, I felt that there was so much more to learn. Luckily, I was on the same Capstone team as 5 of my closest ECE friends. Combined we had a plethora of interests and skills ranging from Networks to App Development. The only problem was coming up with a project that highlighted our wide range of talents equally.

The one thing that all 6 of us had in common, however, was the shared misfortune of having driven in Boston. Let’s just say Massachusetts drivers are infamous for a reason… Even putting aside the questionable behavior of local drivers, the layout of Boston streets don’t make sense. A con of being a historical city is that the city just came to be without much planning. And don’t even get me started on the traffic at all hours of the day. Needless to say, alleviating the experience of driving in Boston was near and dear to all of our hearts.

Through preliminary research we discovered that 30% of street congestion in urban settings is caused by drivers circling around for parking. The worst part is that there isn’t a shortage of open spots, but instead the difficulty seemed to lie in locating the spots. Furthermore, the technology to track open spots in indoor parking garages has been in place for years. Parking garages often display how many open spots are available at each level. But due to power constraints, challenges of outdoor weather, and increased edge cases these existing systems are unable to be implemented in outdoor settings.

Trying to figure out a way to ease the stress of street parking was an intriguing enough problem for all 6 of us. Existing parking garage systems gave us something to build off of, but that didn’t mean we didn’t have our work cut out for us. Despite the odds seemingly against us, we decided to pursue working on this issue. We were ready for a challenge.

Before we could dig in any further, we needed to narrow down a way to detect the presence of cars. To have a real-time understanding of parking spots we needed a reliable source of input. So, we conducted a survey of research to find the optimal solution:

Based on our survey of research we ended up deciding to use RFID tags as a way to sense cars. RFID tags are not only battery-less and cheap, but they also gave us the ability to ID every car. In addition, we can determine whether a car is parked correctly based on the orientation of multiple RFID tags.

RFID tags would be the focal point of our project. Since the use of them required user compliance, we wanted to simplify the rest of the system as much as possible. We weren’t just working on this project just for the sake of it. We genuinely wanted to come up with a practical solution that could be used in the real world someday. A big part of that entailed applying very little to zero changes to street infrastructure already in place. I don’t foresee any scenarios in which the government would be too thrilled to dig up the pavement for every street in a city. Which is why we decided to supplement existing parking meter structures with bands.

The bands would consist of two Ultra High Frequency Radio (UHF RFID) antennas, a USRP X310 (software defined radio – SDR), and a NVIDIA Jetson TX2 board. The SDR-based RFID reader would continuously scan for RFID tags on vehicles within a parking meter’s designated zone. Once a tag is detected in proximity, the TX2 board will send a network packet containing the ID of the RFID tags to a cloud. The cloud receives data from readers with a latency time of 15ms and is responsible for maintaining the state of the parking meters. Eventually, the cloud relays this information to a user through a smartphone application. As a result, the bands attached to the meters are agnostic to past states and will merely act as inputs to the system. Maintaining the system as agnostic to past states alleviates user-tracking and invasion of privacy concerns. The cloud maintains a single source of truth via algorithms and an SQL database.

A huge hindrance in our ability to make our design readily available for mass production was the sheer size of the hardware. Specifically, the TX2 at approximately 16cm x 16cm was too big to be put onto a band.

It is important to note that the TX2 above is a development board. This entails more elements than are needed for the scope of what we’re doing. For the actual functionality of this project, the only elements that are needed are a power switch, power jack, ethernet port, and two LEDs. Since the actual elements that are needed are significantly less than all that is offered on the board, we ended up redesigning it to be 1/4 the original size.

We really wanted to drive home (no pun intended) the usefulness of our project to the everyday driver, and what better way to do that than designing an app! All the behind-the-scenes work mentioned above would be useless if there wasn’t a way to for the user to access it. The goal for our app was to assist users in finding a parking spot in a desired area. We wanted it to not only convey what spots were available, but eventually also be able to track restricted parking times (i.e., scheduled street cleaning), and collect payment.

To track users, the application has a user flow that requires logging in or creating an account. The landing page for any app user is a map of parking spots nearby. Parking spots are added to the map by accessing the database and the availability of spots are updated based on sensor readings.

Currently, the app uses points of green or red color to indicate whether or not a spot is occupied.

After months of research and hard work we were finally able to share our findings with everyone else through our demo video. Our video below showcases the small-scale prototype we were able to successfully create with a 90% accuracy rate!

Of course, our project is still a long way from being put out into the real world. As much as all 6 of us would have loved to see this go further, we simply didn’t have the bandwidth. Between part-time jobs, classes, and graduation around the corner we all had our hands full. Despite all that I am very proud of what my team and I were able to accomplish in a short amount of time.

The end of Capstone is a bittersweet memory. While it was a relief to see our efforts come into fruition, it also signified that the end of college was here. The weeks after Capstone are all a blur of senior week activities, painful goodbyes, and ultimately commencement. It is when I think back to this time of my life that I finally realize what being an engineer means. I don’t think that any number of years let alone 5 can prepare you for the challenges of engineering. But what I did learn in my time as an undergrad is how to learn and tackle new challenges each and every day. It is what I did in all of my classes, at all of my co-ops, and for Capstone. Engineering is a lifelong process of learning. For which my time at Northeastern was just the beginning.