## Inspiration

During last year's World Wide Developers Conference, Apple introduced a host of new innovative frameworks (including but not limited to CoreML and ARKit) which placed traditionally expensive and complex operations such as machine learning and augmented reality in the hands of developers such as myself. This incredible opportunity was one that I wanted to take advantage of at PennApps this year, and Lyft's powerful yet approachable API (and SDK!) struck me as the perfect match for ARKit.

## What it does

Utilizing these powerful technologies, Wher integrates with Lyft to further enhance the process of finding and requesting a ride by improving on ease of use, safety, and even entertainment. One issue that presents itself when using overhead navigation methods is, quite simply, a lack of the 3rd dimension. A traditional overhead view tends to complicate on foot navigation more than it may help, and even more importantly, requires the user to bury their face in their phone. This pulls attention from the users surroundings, and poses a threat to their safety- especially in busy cities. Wher resolves all of these concerns by bringing the experience of Lyft into Augmented Reality, which allows users to truly see the location of their driver and destination, pay more attention to where they are going, and have a more enjoyable and modern experience in the process.

## How I built it

I built Wher using several of Apple's Frameworks including ARKit, MapKit, CoreLocation, and UIKit, which allowed me to build the foundation for the app and the "scene" necessary to create and display an Augmented Reality plane. Using the Lyft API I was able to gather information regarding available drivers in the area, including their exact position (real time), cost, ETA, and the service they offered. This information was used to populate the scene and deep link into the Lyft app itself to request a ride and complete the transaction.

## Challenges I ran into

While both Apple's well documented frameworks and Lyft's API simplified the learning required to take on the project, there were still several technical hurdles that had to be overcome to complete the project. The first issue that I faced was Lyft's API itself; While it was great in many respects, Lyft has yet to create a branch fit for use with Swift 4 and iOS 11 (required to use ARKit), which meant I had to rewrite certain portions of their LyftURLEncodingScheme and LyftButton classes in order to continue with the project. Another challenge was finding a way to represent a variance in coordinates and 'simulate distance', so to make the AR experience authentic. This, similar to the first challenge, became manageable with enough thought and math. One of the last significant challenges I encountered and overcame was with drawing driver "bubbles" in the AR Plane without encountering graphics glitches.

## Accomplishments that I'm proud of

Despite the many challenges that this project presented, I am very happy that I persisted and worked to complete it. Most importantly, I'm proud of just how cool it is to see something so simple represented in AR, and how different it is from a traditional 2D View. I am also very proud to say that this is something I can see myself using any time I need to catch a Lyft.

## What I learned

With PennApps being my first Hackathon, I was unsure what to expect and what exactly I wanted to accomplish. As a result, I greatly overestimated how many features I could fit into Wher and was forced to cut back on what I could add. As a result, I learned a lesson in managing expectations.

## What's next for Wher (with Lyft)

In the short term, adding a social aspect and allowing for "friends" to organize and mark designated meet up spots for a Lyft, to greater simply the process of a night out on the town. In the long term, I hope to be speaking with Lyft!
## Inspiration

Our inspiration came from the idea of emergencies and to help out the people in distress. So, if there is a minor emergency such as a Room has been locked and someone is stuck inside. He/She can Mark the place and comment it through the AR App allowing everyone in the nearby location to see and respond to it directly. This AR App allows you to receive help from not just your friends but by people who are nearby and are willing to help you out.

## What it does

This AR App posts messages in AR using GeoLocation of the user which allows people around the user with the App to see it and post messages themselves in real-time. This is a great way to help someone in distress, as sometimes they are unable to contact relatives, but someone might see their message from this App This AR App could be used as a social network to connect various people to each other.

## How we built it

For the AR portion of the App we used Swift for the Front-End and Back-End Portion of the apps while the while connecting to the Amazon Web Services through Dynamobd as the database. The website is made using HTML, CSS, and JavaScript with a small hint of the Google Maps API and the Facebook Login API with the website being hosted on Firebase. Facebook Login API is used for authentication of the user to login into the App itself, to start marking points around you. It was also used for the website to login the user into their screen which shows where the markers are placed! Google Maps API is used mainly for the website to view the markers around you.

## Challenges we ran into

Working with Amazon Web Service's Dynamobd for the back-end portion of this AR Hack. All of us were new to developing in iOS, using Swift and also using Amazon Web Services which made it very hard but an ambitious project! Another major difficulty we ran into was even though we are doing a iOS/Swift Hack, only one of us had a iPhone to test it on and 2 Macbooks which slowed down our progress and set us back on our timeline.

## Accomplishments that we're proud of

Throughout this hackathon, we had problems with programming in Swift as it was a new take for all of us. Throughout the duration of this hackathon, two of our members worked for the entire time to ensure that the AR App was completed. We are proud that even though we divided this into two mini projects, The Web Portion and the AR App itself, we were able to communicate between each other and be on the same path to avoid future problems.

## What we learned

Throughout this hackathon, the team members who programmed the AR portion of the App did not know Swift and learnt the language on Friday and went on to finishing the hack well before the deadline of this submission. Additionally, none of us knew Firebase and learning it along the way was a struggle for us, but we were able to come through and have the Firebase portion of the application working!

## What's next for shARe

Currently only supported for iOS devices, we want to furthur this application by getting support for Android and developing the Application for Android devices as we noticed only one of our team member was a Apple User while the rest were Android users and it would've been very beneficial if we hacked in Android!
## Inspiration

One of our teammate’s grandfathers suffers from diabetic retinopathy, which causes severe vision loss.
Looking on a broader scale, over 2.2 billion people suffer from near or distant vision impairment worldwide. After examining the issue closer, it can be confirmed that the issue disproportionately affects people over the age of 50 years old. We wanted to create a solution that would help them navigate the complex world independently.

## What it does

### Object Identification:

Utilizes advanced computer vision to identify and describe objects in the user's surroundings, providing real-time audio feedback.

### Facial Recognition:

It employs machine learning for facial recognition, enabling users to recognize and remember familiar faces, and fostering a deeper connection with their environment.

### Interactive Question Answering:

Acts as an on-demand information resource, allowing users to ask questions and receive accurate answers, covering a wide range of topics.

### Voice Commands:

Features a user-friendly voice command system accessible to all, facilitating seamless interaction with the AI assistant: Sierra.

## How we built it

* Python
* OpenCV
* GCP & Firebase
* Google Maps API, Google Pyttsx3, Google’s VERTEX AI Toolkit (removed later due to inefficiency)

## Challenges we ran into

* Slow response times with Google Products, resulting in some replacements of services (e.g. Pyttsx3 was replaced by a faster, offline nlp model from Vosk)
* Due to the hardware capabilities of our low-end laptops, there is some amount of lag and slowness in the software with average response times of 7-8 seconds.
* Due to strict security measures and product design, we faced a lack of flexibility in working with the Maps API. After working together with each other and viewing some tutorials, we learned how to integrate Google Maps into the dashboard

## Accomplishments that we're proud of

We are proud that by the end of the hacking period, we had a working prototype and software. Both of these factors were able to integrate properly. The AI assistant, Sierra, can accurately recognize faces as well as detect settings in the real world. Although there were challenges along the way, the immense effort we put in paid off.

## What we learned

* How to work with a variety of Google Cloud-based tools and how to overcome potential challenges they pose to beginner users.
* How to connect a smartphone to a laptop with a remote connection to create more opportunities for practical designs and demonstrations.
How to connect a smartphone to a laptop with a remote connection to create more opportunities for practical designs and demonstrations.
How to create docker containers to deploy google cloud-based flask applications to host our dashboard.
How to develop Firebase Cloud Functions to implement cron jobs. We tried to developed a cron job that would send alerts to the user.

## What's next for Saight

### Optimizing the Response Time

Currently, the hardware limitations of our computers create a large delay in the assistant's response times. By improving the efficiency of the models used, we can improve the user experience in fast-paced environments.

### Testing Various Materials for the Mount

The physical prototype of the mount was mainly a proof-of-concept for the idea. In the future, we can conduct research and testing on various materials to find out which ones are most preferred by users. Factors such as density, cost and durability will all play a role in this decision.