The EcoTech Blog
Introduction
My friend and I wanted to participate in a hackathon for a long time. We came across a hackathon on Unstop called the ‘WCE Hackathon’. With only a couple of hours left for the deadline, we went through the problem statements and finalized one of them. We quickly created the PPT using the template given and recorded a video demonstrating the user flow and mockups we had come up with in the meantime. I worked on the UI prototypes and Burhanuddin worked on the user flow diagram and created the video for the idea submission round. We finished just 1 minute before the submission deadline. Phewww!
Ideation
In the ideation phase, Burhanuddin and I fixed one problem statement out of the various mentioned on the hackathon website. We selected the problem statement, E-Waste management using modern technologies and machine learning. We ideated an overview of the project and what features we would need to implement. We discussed the probable screens and user flow. After this, I created the Figma designs for the UI and Burhanuddin created the FigJam for the user flow diagram.
Planning
Once the ideation phase was over and we had submitted the idea presentation with the video, we waited for about a week after which we got an email stating that our idea was shortlisted for the next phase of the hackathon, the development phase. Upon this announcement, we started planning the actual flow of the app, the database models, what kind of data would be required, and what API endpoints would be needed. We came up with a possible approach to implementing the ML classifier. We documented all of this using google docs and Figma as collaboration tools. Once all of the planning was done and documented, it became easier for us to start working on the project as we could now function parallel to each other while following the blueprint we had designed to generate the final solution.
Database Design
We followed the approach of going through the user flow and the mockups and identified the various models and relations that would be required. We created a schema for the database based on the final output we had presented.
API Endpoints Analysis
For analyzing the API endpoints, we followed a similar approach. We went through the actual designs and the user flow and created a blueprint for the endpoints needed. We maintained a shared doc as a resource we could look up for reference while developing.
Deciding the Tech Stack
Based on our use-case we finalized the tech stack for rapid development but at the same time one that was appropriate to execute the task at hand, that is to create the E-Waste management-oriented product. We finalized the following tech stack: Flutter for the mobile app, Django Rest Framework (DRF) for the backend, PostgreSQL for the database (Django ORM managed), NextJS for the frontend, and Python for the ML classifier model.
Backend
Burhanuddin worked on developing the backend APIs to be used in the mobile application, the admin dashboard, and the recycler dashboard. He also implemented swagger for automatic documentation of the API endpoints.
Testing
We maintained a postman collection for unit testing the API endpoints individually. This also served as a live API reference and documentation. This gave the exact structure of the request and expected response, and the type of headers required.
Mobile App
I worked on developing the mobile app using Flutter. I tried to replicate the Figma UI as closely as possible. Firstly, I developed the onboarding and authentication (login and register) screens. After which, I developed the process of reporting E-Waste using various packages in Flutter. Upon clicking the Report Waste button, the user is prompted to select an image of the supposed E-Waste. After this, the coordinates of the user are fetched (of course with their permission ;) ) using the GeoLocator package. The MapMyIndia API was used for reverse geocoding these coordinates to receive an approximate address of the user. The image, location along with the type of E-Waste is then sent to the backend using the APIs. Along with the E-Waste reporting process, a dashboard for the user’s statistics was also designed, using the syncfusion_flutter_charts package.
Admin & Recycler Dashboard
Burhanuddin worked on both these dashboards. These dashboards were developed using NextJS and TailwindCSS for the styling. We tried replicating the Figma designs that we submitted in the ideation phase as closely as possible.
ML Model
This was one of the challenging parts of the project as both Burhanuddin and I did not have much of a background in ML. But as we had taken a class in Data Science and Big Data Analytics in the ongoing semester, we had an idea about classifiers and how they worked. We had to figure out a way to classify images (in data science, we mostly worked with CSV data). Another challenge was to determine what type of classification was needed, as we needed to identify E-Waste out of possibly anything. Hence, we classified the data as E-Waste or Not E-Waste, which we could not find anywhere (a classifier that identifies a picture having a particular feature or not). So as we had limited time, we came up with a makeshift approach of using scenery images as Not E-Waste and Electronic gadget images as E-Waste. Finding the dataset for E-Waste was also one of the major problems, but we managed to find one and train the model and it performed decently (not the best as there were too many scenarios that were missing for the not E-Waste class).
MLOps
Finally, when it came to integrating the model into our service, there was one major problem concerning how the model made predictions. It took 20–30 seconds for the model to train and then we could use the model for prediction. So we needed to find a way to make the model run once for training and then use the trained instance of the model object every time to make predictions. We had two approaches, one that we came up with and the other we found on the internet. The first one was to create a class Predictor and train the model in the data attribute declaration in the class (I know it’s a super bad design, but we had to figure out one-way fast :p ). One variation of this was to have a constructor which would train the model and a static method that would be the predictor method (but this led to bad design again, as a global instance would be shared between multiple users). So, we skipped these and moved to the second way, which was to store the binary object of the trained model on the disk and load it in runtime for making the predictions. We used Pickle to implement this and added a .pkl file of the trained model to the server. It did work, but sadly we were deploying it on the free tier and exceeded the limit for the size of the application. Hence, we had to roll back this feature for deployment and migrated it over to a different branch altogether in the version control (Git). Quite unfortunate, but we had a great learning experience through this process of trial and error.
DevOps & Deployment
The project backend is deployed on Heroku free tier with the PostgreSQL database as an addon. The frontend NextJS-based dashboards have been deployed on Netlify free tier. We also got the domain name eco-tech.cf for hosting the frontend. The recyclers dashboard is hosted on subdomain recyclers.eco-tech.cf. Now, for the DevOps part of the project, the backend is containerized and the container image is pushed on DockerHub. The project has also been configured to run on a Kubernetes cluster. All the configurations for the Kubernetes pods, services, ingress, and the horizontal pod autoscaling have been added to the repository. This configuration has also been tested by running locally using Minikube. Another interesting thing, we learned during this development phase was to merge multiple repositories into one mono repository preserving all the commits made in the separate repositories, as we needed to have all the code in a single repository for evaluation as per the guidelines of the hackathon.
Closing
Towards the end of the development phase, we had to create a video demonstration of the solution and a presentation. We made the required video and presentation and submitted the final developed and deployed project just in time. After a few days, we got to know we had qualified for the final round of the hackathon along with 8 teams. An online judging round was scheduled for the next day where all the teams presented their ideas one by one followed by a question and answer session. All the projects that got shortlisted for the grand finale were quite amazing. Two days after the grand finale, we had the final announcement of results, and our team ‘BurhanHere’ was declared the winner of the hackathon. It was quite an amazing journey right from participating amongst the 650+ participants spread across the 100+ teams, to our team winning the hackathon.
Product Demonstration Video
System Architecture Diagram
GitHub Repository
If you have come this far, thanks a lot for devoting your time to reading all of this. Any constructive criticism would be appreciated.
