## Inspiration

People across the globe are buying cars everyday just to use them for a fraction of the time. What if we put this idle time to use? What if the average car owner pocketed quick cash when not using their car? Enter, **CommunalCars!**

## What it does

CommunalCars is *everyday cars put to communal use*.

With CommunalCars, users may register as a car owner or a rider. Those who wish to rent a vehicle can browse available cars in their community and rent them according to the owner's pre-established availability. Car owners may label their cars as “available” when working or travelling.

As stated before, this idea comes from the fact that most cars only see 1-2 hrs of use a day and just sit idle the rest of the time, wasting so much earning opportunity for the car owners. Additionally, this would help the environment as this would result in less people buying cars overall.

## How we're different

Unlike popular transportation apps like Uber or Lyft, CommunalCars gives opportunities for users to earn money without even having to be in their car. CommunalCars serves as a side income for those who are busy during the day and a more affordable, short-term option for users who need to rent a vehicle. Moreover, as compared to other rental cars which usually only allow you to rent for long periods of time such as over the span of a few days or weeks, CommunalCars is targeted towards those who only need a vehicle to get around for a few hours, and for renters to be able to rent out their cars while they're shortly away from them at work.

## How we built it

CommunalCars is a mobile application, with the frontend built using React Native and Redux, and the backend with Node.js and Express.js, using MongoDB as the database. Axios was used to fetch data from the backend to render to the frontend. Mongoose was used for object document mapping and MongoDB Compass was used for easier database management. Postman was also used to test HTTP API requests. The Twilio Chat API was also utilized.

## Challenges we ran into

Our team initially struggled with setting up our development environment, as well as learning React-Native for the first time. We struggled with trying to connect our React-Native app with our Express backend through our RESTful API. None of our team members worked with React-native before, and none of us had an experience connecting frontend with backend server calling APIs. It was a succession of learning and struggling for all the members. We eventually got everything setup and successfully connected React-Native with Express using Axios for some APIs, but unfortunately did not have enough time to use the full APIs implemented on the backend server.

We were also trying to integrate the Twilio Conversations API for chat messaging but kept on running into several errors and realized we had to tweak and think of how to get it to work for only two users talking to each other at one time. As this feature is introduced for multiple users within specific channels on the actual Twillio API getstarted docs.

## Accomplishments that we're proud of

Firstly, we are proud that our actual application ended up looking extremely similar to our Figma prototype design.

Secondly, one of us had worked with React-Native before so that's been a big milestone. Additionally, we all faced issues with the set-up of Andriod Studio and Xcode, and connecting the emulator. And after hours of debugging and installing dependencies, we successfully ran the app! Furthermore, we also figured out how to structure the backend for our specific use case and integrate the backend to the frontend for mobile applications - a task no one on the team has done before.

Moreover, because it was our first React-Native project, environment set-up was a nightmare, but we pushed through despite mainly failed attempts on connecting virtual machines.

We are also proud that we were able to actively collaborate, struggle together, and find solutions together to solve multiple problems we faced while making our full stack mobile application.

## What we learned

Our biggest takeaways are:

* Learning mobile development with React Native
* Using Postman for API testing
* Connecting backend and frontend for mobile applications

## What's next for Communal Cars

As mentioned we have tried to implement the Twilio Conversations API to add chatting between the person owning the vehicle and the person trying to rent it but due to time constraints, it was difficult to do so. We would add this feature for sure, as well as video and audio calling so that the car can be shown live over camera and so the users can talk to each other over call. We would also add in features like location based suggestions as well as different options according to the needs of the user like whether a sedan, SUV or luxury car is wanted/needed. A live GPS tracker would also be useful to show the owner where the person renting the car is roughly around. This could also be used to show how far the person is from picking up the car. We would eventually also add in a web app once we see a growing user base.
## Inspiration

As avid cyclists who are interested in wearable tech, this idea came naturally to us. After stumbling upon a news article, we were shocked to discover that nearly 8000 canadian cyclists are seriously injured each year. 1 in 3 of all cyclist deaths occur in poor lighting conditions. We knew that we could create a product that could help mitigate the amount of cycling injuries. From there, we thought of Helmetx and many more features that could optimize the cycling experience.

## What it does

Helmetx is a multifunctional cycling helmet with many safety features. The helmet’s main feature is a stunning LCD screen, which allows cyclists to view biking metrics, such as speed and acceleration. Cyclists can cycle through the metrics by pressing the button at the side of the helmet. The helmet uses an accelerometer to measure the acceleration and from there, the speed was able to be derived and displayed. Additionally, if the helmet’s ultrasonic detects an oncoming vehicle, the LCD will display a warning message with the vehicle's proximity to the user. The lights around the helmet will also flash to alert the vehicle. To manually control the lights, cyclists simply have to press one of the side buttons on the helmet. The LCD can also display directions to the cyclist’s location on the screen.

## How we built it

We divided our team into two separate teams: hardware and software. The hardware team was responsible for all electronics related aspects of the project and the software team worked on our code and the Google Maps direction API. On the hardware side, after brainstorming our idea, we did a lot of research into what features this helmet should have and which devices would be best for the task at hand. Then, we got started by testing out different sensors individually and then combined them into our main program. We did a lot of tests along the way and once all our features worked, we assembled the electronics onto the helmet. On the software side, we researched the Google Maps API and how to use it. We wrote code which extracts the directions and then outputs an integer representing the type of turn. Then, the code on the helmet converts the integer back to the appropriate direction and displays it on the LCD screen.

## Challenges we ran into

Building Helmetx came with many challenges, but we were always able to solve them! Our biggest challenge as a group was learning how to use the Raspberry Pi and the Google Maps API, which was new to each member in the group. As such, we had to do an immense amount of research. On the hardware side, we had an issue with the LCD screens. When we first started to prototype with the hardware, we attempted to use 128x128 pixel LCD screens. After researching troubleshooting methods to fix the screens, we swapped to using a 16x2 LCD screen. On the software side, we had many technical issues with using certain APIs. After much trial and error, we switched to using the Google Maps API.

## Accomplishments that we’re proud of

Overall, we are proud of how we were able to take on a project that was out of our comfort zones, face the challenges that we approached, and create a working end product. As a team, we entered the project with many uncertainties but we were able to come out victorious. We are most proud of how well we all worked together and how our skills complemented one another.

## What we learned

Our team learned how to use the Google Maps API to direct the Raspberry Pi. Both of these systems were quite new to us, and required a significant amount of research before we could start playing around with them. At the end, we were able to develop a method which involved extracting directions and outputting them as an integer which represented a specific type of turn. We also learnt how to incorporate different sensors into our main program.

## What’s next

Going forward with this project, we would like to improve on the screen and look into the possibilities of incorporating a transparent display. We definitely want to incorporate additional sensors to provide the cyclists with more metrics and explore the possibility of having an onboard camera to record rides. We would also make use of a 3D printer to print a proper casing for our electronic components. In the future, we will make use of bluetooth or internet connectivity with the phone and Raspberry Pi to have accurate and updated directions based on GPS data.
## Inspiration

In a world where finance is extremely important, everyone needs access to **banking services**. Citizens within **third world countries** are no exception, but they lack the banking technology infrastructure that many of us in first world countries take for granted. Mobile Applications and Web Portals don't work 100% for these people, so we decided to make software that requires nothing more than a **cellular connection to send SMS messages** in order to operate. This resulted in our hack, **UBank**.

## What it does

**UBank** allows users to operate their bank accounts entirely through **text messaging**. Users can deposit money, transfer funds between accounts, transfer accounts to other users, and even purchases shares of stock via SMS. In addition to this text messaging capability, UBank also provides a web portal so that when our users gain access to a steady internet connection or PC, they can view their financial information on a more comprehensive level.

## How I built it

We set up a backend HTTP server in **Node.js** to receive and fulfill requests. **Twilio** with ngrok was used to send and receive the text messages through a webhook on the backend Node.js server and applicant data was stored in firebase. The frontend was primarily built with **HTML, CSS, and Javascript** and HTTP requests were sent to the Node.js backend to receive applicant information and display it on the browser. We utilized Mozilla's speech to text library to incorporate speech commands and chart.js to display client data with intuitive graphs.

## Challenges I ran into

* Some team members were new to Node.js, and therefore working with some of the server coding was a little complicated. However, we were able to leverage the experience of other group members which allowed all of us to learn and figure out everything in the end.
* Using Twilio was a challenge because no team members had previous experience with the technology. We had difficulties making it communicate with our backend Node.js server, but after a few hours of hard work we eventually figured it out.

## Accomplishments that I'm proud of

We are proud of making a **functioning**, **dynamic**, finished product. It feels great to design software that is adaptable and begging for the next steps of development. We're also super proud that we made an attempt at tackling a problem that is having severe negative effects on people all around the world, and we hope that someday our product can make it to those people.

## What I learned

This was our first using **Twillio** so we learned a lot about utilizing that software. Front-end team members also got to learn and practice their **HTML/CSS/JS** skills which were a great experience.

## What's next for UBank

* The next step for UBank probably would be implementing an authentication/anti-fraud system. Being a banking service, it's imperative that our customers' transactions are secure at all times, and we would be unable to launch without such a feature.
* We hope to continue the development of UBank and gain some beta users so that we can test our product and incorporate customer feedback in order to improve our software before making an attempt at launching the service.