The app at the end of the hackathon.
a 4:45am we've-finally-finished selfie
The idea for this app first came when, as we were moving into our dorm room for the first time, Qi Tao mentioned to Garrett how annoying it is that you never know if there are any parking stalls open in the Templin hall parking lot before you drive all the way up here.
What it does
WaitNoMore uses a Raspberry Pi-powered camera to monitor a parking lot (or lots) to track available stalls and accessible parking. This data are pushed to a mobile app which can help people find places to park with greater ease.
How we built it
WaitNoMore is comprised of three core pieces of software. First is the camera backend. This is written in Python and runs on a Raspberry Pi with a webcam attached to it. When the backend is loaded, it pulls its configuration from the admin panel, then it takes images of the parking lot every few seconds and compares each parking stall to a reference area to determine the likelihood that the stall is in use. If said likelihood falls above a given threshold, then it updates the parking stall's status.
The app is the next major component. Written in Flutter to enable cross-platform use, the app communicates with the backend to get the general layout of the tracked parking lots, then it renders each stall as a square in the UI, and changes the color based on availability. Clicking the squares will give additional information, such as whether or not the stall is designated accessibility parking.
The final piece of the proverbial WaitNoMore pie is the web-based administration panel. This panel allows site administrators to create new lots by uploading reference images of them, then mapping the individual stalls using a pointer-based GUI. The web panel is also responsible for the creation of centrally managed config profiles that are pushed to the Raspberry Pi units.
WaitNoMore uses Firebase Cloud Firestore as its storage driver. Data is organized by lot, then by stall. This allows data to be shared in real time between the three components of the platform.
The image recognition is done by computing the average color of a specified region. That average color is then compared to the average color of a specified reference region. The three RGB channels are then run through a quartic-root normalization formula to yield a value (internally referred to as Ê) that quantifies the probability that a given region is occupied.
Challenges we ran into
Image Processing was a big challenge. The initial plan was to use TensorFlow or similar to track stalls by recognizing cars/pedestrians/bicycles/etc as they arose. However, we quickly discovered that, no matter how hard we tried, TensorFlow would not accept the fact that our model cars were, in fact, cars and not cell-phones (72.681335%). The second plan was to use image differentials to compute areas where the image would have changed from one time to the next. However, due to our low-quality webcam having very high levels of noice, this proved... impractical. Garrett finally settled on using the average color method.
The Flutter application was also a major challenge. Never having programmed in Dart or with asynchronicity, Thomas had a steep learning curve on how to properly retrieve and display information from the Firebase in the appropriate context while still attempting to maintain good coding practices.
Accomplishments that we're proud of
Well, it works. That was up in the air for a long time. None of us had ever participated in a hackathon before, and we fully expected to fall flat on our faces with this one. Also, the application successfully ports to both iOS and Android. We also made use of version control throughout the entire process, which helped with testing along the way.
What we learned
We learned that hackathons are a surprising amount of fun. We learned how to work as a group when it comes to programming and creating a project while simultaneously trying not to break each-other's code. We also learned the path to Wal-mart after 11pm. Twice. Seriously. We learned a lot about how image processing works and the mathematics behind it. Also, we learned that changing hardware in the middle of a project can pose a serious issue (we got a better web-cam).
What's next for WaitNoMore
We want to clean up the UX in the mobile app and tie down integration with the database better. We want to expand the accessibility tools and implement a reservation system with Push notifications. Cleaning up the code base in general and making it more friendly to maintain and expand is also a must. We have also considered designing a device that can be placed at each stall to indicate whether it is accessible or reserved, as well as to assist with enforcement of parking laws.
This application is designed to relieve some of the little stresses of every-day life to help us all go about our days in just a bit better of a mood. Our integration for designating accessible parking is designed to empower those of all walks of life.
This application is the copyright of its respective developers.