## Inspiration

Public washrooms can be a rough time for users thanks to lots of traffic, clogged toilets, missing toilet paper and more. There’s rarely opportunities to easily provide feedback on these conditions. For management, washrooms often get cleaned too frequently or rarely at all. Let’s bring simple sensors to track the status of frequently used facilities to optimize cleaning for businesses and help users enjoy their shit.

## What it does

System of IoT sensors, opportunity for gesture-based user feedback, streamed to a live dashboard to give management updates
We track:
-Traffic into washroom
-Methane levels
-Fullness of trash cans
We provide:
Refill buttons in each stall
Prompt for facility rating using Leap Motion gesture tracking

## How we built it

Used Snapdragon to attach three sensors for data collection purpose to track cleanliness in washroom
Used Leap Motion to create interactive dashboard to rate they experience through gestures - more sanitary and futuristic approach, incentivizing users to participate
All data pushed up to Freeboard where management can see the status of their washrooms

## Challenges we ran into

Tricky using documentation with Leap Motion, didn’t take into account web apps need time to load, wouldn’t load body; also challenging to build hand recognition from the ground up
Getting hardware to work: Snapdragon with shield doesn’t have documentation - normal arduino code wasn’t working
Integrating data with IoT dashboard

## Accomplishments that we're proud of

Found cool solution to get data from sensors to dashboard: wrote to serial, read that,
used a python script, and then used dweet.io to publish to freeboard
Building hand recognition in Leap Motion

## What we learned

Learned to use Leap Motion
Live data transmission with multiple sensors
Integrating a ton of IoT data

## What's next for Facile

Store data online so that we can use ML to understand trends in facility behaviour, cluster types of facilities to better estimate cleaning times
Talk to facilities management staff - figure out current way they rate and clean their washrooms, base sensors on that
Partnering with large malls, municipal governments, and office complexes to see if they’d be interested
Applicable to other environments in smart cities beyond bathrooms
## Inspiration

We were inspired to create a health-based solution (despite focusing on sustainability) due to the recent trend of healthcare digitization, spawning from the COVID-19 pandemic and progressing rapidly with increased commercial usage of AI. We did, however, want to create a meaningful solution with a large enough impact that we could go through the hackathon, motivated, and with a clear goal in mind. After a few days of research and project discussions/refinement sessions, we finally came up with a solution that we felt was not only implementable (with our current skills), but also dealt with a pressing environmental/human interest problem.

## What it does

WasteWizard is designed to be used by two types of hospital users: Custodians and Admin. At the custodian user level, alerts are sent based on timer countdowns to check on wastebin statuses in hospital rooms. When room waste bins need to be emptied, there is an option to select the type of waste and the current room to locate the nearest large bin. Wastebin status (for that room) is then updated to Empty. On the admin side, there is a dashboard to track custodian wastebin cleaning logs (by time, location, and type of waste), large bin status, and overall aggregate data to analyze their waste output. Finally, there is also an option for the admin to empty large garbage bins (once collected by partnering waste management companies) to update their status.

## How we built it

The UI/UX designers employed Figma keeping user intuitiveness in mind. Meanwhile, the backend was developed using Node.js and Express.js, employing JavaScript for server-side scripting. MongoDB served as the database, and Mongoose simplified interactions with MongoDB by defining schemas. A crucial aspect of our project was using the MappedIn SDK for indoor navigation. For authentication and authorization, the developers used Auth0 which greatly enhanced security. The development workflow followed agile principles, incorporating version control for collaboration. Thorough testing at both front-end and back-end levels ensured functionality and security. The final deployment in Azure optimized performance and scalability.

## Challenges we ran into

There were a few challenges we had to work through:

* MappedIn SDK integration/embedding: we used a front-end system that, while technically compatible, was not the best choice to use with MappedIn SDK so we ended up needing to debug some rather interesting issues
* Front End development, in general, was not any of our strong suits, so much of that phase of the project required us to switch between CSS tutorial tabs and our coding screens, which led us to taking more time than expected to finish that up
* Auth0 token issues related to redirecting users and logging out users after the end of a session + redirecting them to the correct routes
* Needing to pare down our project idea to limit the scope to an idea that we could feasibly build in 24 hours while making sure we could defend it in a project pitch as an impactful idea with potential future growth

## Accomplishments that we're proud of

In general, we're all quite proud at essentially full-stack developing a working software project in 24 hours. We're also pretty proud of our project idea, as our initial instinct was to pick broad, flashy projects that were either fairly generic or completely unbuildable in the given time frame. We managed to set realistic goals for ourselves and we feel that our project idea is niche and applicable enough to have potential outside of a hackathon environment. Finally, we're proud of our front-end build. As mentioned earlier, none of us are especially well-versed in front-end, so having our system be able to speak to its user (and have it look good) is a major success in our books.

## What we learned

We learned we suck at CSS! We also learned good project time management/task allocation and to plan for the worst as we were quite optimistic about how long it would take us to finish the project, but ended up needing much more time to troubleshoot and deal with our weak points. Furthermore, I think we all learned new skills in our development streams, as we aimed to integrate as many hackathon-featured technologies as possible. There was also an incredible amount of research that went into coming up with this project idea and defining our niche, so I think we all learned something new about biomedical waste management.

## What's next for WasteWizard

As we worked through our scope, we had to cut out a few ideas to make sure we had a reasonable project within the given time frame and set those aside for future implementation. Here are some of those ideas:

* more accurate trash empty scheduling based on data aggregation + predictive modelling
* methods of monitoring waste bin status through weight sensors
* integration into hospital inventory/ordering databases
As a note, this can be adapted to any biomedical waste-producing environment, not just hospitals (such as labs and private practice clinics).
## Inspiration

A couple of weeks ago, 3 of us met up at a new Italian restaurant and we started going over the menu. It became very clear to us that there were a lot of options, but also a lot of them didn't match our dietary requirements. And so, we though of Easy Eats, a solution that analyzes the menu for you, to show you what options are available to you without the dissapointment.

## What it does

You first start by signing up to our service through the web app, set your preferences and link your phone number. Then, any time you're out (or even if you're deciding on a place to go) just pull up the Easy Eats contact and send a picture of the menu via text - No internet required!
Easy Eats then does the hard work of going through the menu and comparing the items with your preferences, and highlights options that it thinks you would like, dislike and love!
It then returns the menu to you, and saves you time when deciding your next meal.
Even if you don't have any dietary restricitons, by sharing your preferences Easy Eats will learn what foods you like and suggest better meals and restaurants.

## How we built it

The heart of Easy Eats lies on the Google Cloud Platform (GCP), and the soul is offered by Twilio.
The user interacts with Twilio's APIs by sending and recieving messages, Twilio also initiates some of the API calls that are directed to GCP through Twilio's serverless functions. The user can also interact with Easy Eats through Twilio's chat function or REST APIs that connect to the front end.
In the background, Easy Eats uses Firestore to store user information, and Cloud Storage buckets to store all images+links sent to the platform. From there the images/PDFs are parsed using either the OCR engine or Vision AI API (OCR works better with PDFs whereas Vision AI is more accurate when used on images). Then, the data is passed through the NLP engine (customized for food) to find synonym for popular dietary restrictions (such as Pork byproducts: Salami, Ham, ...).
Finally, App Engine glues everything together by hosting the frontend and the backend on its servers.

## Challenges we ran into

This was the first hackathon for a couple of us, but also the first time for any of us to use Twilio. That proved a little hard to work with as we misunderstood the difference between Twilio Serverless Functions and the Twilio SDK for use on an express server. We ended up getting lost in the wrong documentation, scratching our heads for hours until we were able to fix the API calls.
Further, with so many moving parts a few of the integrations were very difficult to work with, especially when having to re-download + reupload files, taking valuable time from the end user.

## Accomplishments that we're proud of

Overall we built a solid system that connects Twilio, GCP, a back end, Front end and a database and provides a seamless experience. There is no dependency on the user either, they just send a text message from any device and the system does the work.
It's also special to us as we personally found it hard to find good restaurants that match our dietary restrictions, it also made us realize just how many foods have different names that one would normally google.

## What's next for Easy Eats

We plan on continuing development by suggesting local restaurants that are well suited for the end user. This would also allow us to monetize the platform by giving paid-priority to some restaurants.
There's also a lot to be improved in terms of code efficiency (I think we have O(n4) in one of the functions ahah...) to make this a smoother experience.
Easy Eats will change restaurant dining as we know it. Easy Eats will expand its services and continue to make life easier for people, looking to provide local suggestions based on your preference.