People aren't fully aware of what they say and how often they say things. We want to change that.

What it does

Vohab is a continuous speech-tracking wearable that helps users improve their vocabulary habits. Vohab continuously tracks and calculates user word frequency and tone data from a Raspberry Pi (our wearable) and Microsoft's Cognitive Services API suite. Users can view a history of their "vohabulary" (user speech analysis highlighting periodic word frequency, tone analysis, and even swear counts) on our website!

How we built it

The Raspberry Pi handles audio input using the Python library, PyAudio. Through clever aggregation of multiple samples, we minimize the number of API calls necessary for our application to make. We call Microsoft Cognitive Services API to get speech analysis metrics, and then send data to our MongoDB database. We have the domain from the .co company, and host our website on Azure. We then use jQuery to send data and sync the user's dashboard with c3 charting tools to visualize speech metrics.

We were combining lots of different paradigms in this project. Low level raspberry pi sending REST API calls. Integrating cognitive services into intuitive charts and graphs.

Challenges we ran into

Biggest challenges included taking detours that we now know set us back, time-wise. Choosing the right database and hosting relationship took us from Azure and SQL to Amazon Web Services and MongoDB, to finally sticking with Azure and MongoDB. We were so lucky to be able to work with patient Microsoft technical evangelists to work through our bugs and to learn how best to integrate our design choices.

Accomplishments that we're proud of

Unique social and technical application In deciding which hardware to use to track user data, we felt that no existing wearables truly fit the form and function of the Vohab functionality. Instead of settling with any of the existing wearable technologies and adapting our idea to its particular hardware limitations (microphone, access to API calls, compatibility with software), we made the decision to work with the Raspberry Pi.

UI/UX research and planning What we learned from a really insightful UI/UX workshop led by Jose Caballer Saturday morning was the importance of developing key customer profiles before even touching code. After learning about the importance of identifying the user demographics and psychographics, our team sat down and discussed the functionality that would be necessary to serve the user's wants and needs. This early planning made our end product goal clear throughout the weekend, and this helped us manage our efforts working on higher-priority components of Vohab that best served the user.

From this planning, we've learned that there shouldn't be too much work involved in figuring what to say during a product pitch because your UI/UX research should primarily inform you of that from the beginning. The end of product implementation should be a time for teams to learn how to best communicate their product vision and application to the user and market.

Our team We call ourselves Team (4-3-2-1) Lift-Off. But why is that? Our team is particularly unique because we are comprised of two USC students and two UCLA students, one freshman, sophomore, junior, and senior. Through our hacking this weekend, we've demonstrated the value of collaboration beyond school rivalries and the importance of innovating for the sake of solving real world problems. We delegated work based on skillsets and interests and this kept everyone engaged and feeling valued.

What might come across as surprising is that our team met each other for the first time here at LA Hacks! Over the last day and a half, our group dynamic and communication efforts have only improved, and we've all enjoyed working on Vohab with a similar drive and motivation.

What we learned

We've learned a lot from our weekend at LA Hacks (donuts are great, sleeping in basketball arenas can be comfortable...). A few things we've learned include the following:

  1. In a time crunch and a high-pressure low-time setting such as a hackathon, it's important to choose the shortest path to final implementation possible, for sake of completion and sanity. What we really appreciated and enjoyed doing was walking around and speaking with sponsors before even sitting down to decide what to make. By asking sponsors for their advice and their experiences, our team was more aware of what technical guidance we could receive from which individuals at this event. What we found as worked on our project was that Azure is difficult to work with as first-time users, and we struggled because of this.

  2. Refactoring is possible to do at hackathons. We implemented a script that only recorded from the Raspberry Pi when it picked up loud enough amplitudes which was awesome, but was even more awesome was our team's willingness to make that recording process even more efficient by signaling the end of a recording through amplitude decrease.

  3. It's okay to save implementation for future thoughts. Which leads us to...

What's next for Vohab

"Vohabulary" complexity, synonym recommendations for most frequently used words, collaboration between users and ability to share their "vohabulary" analytics, voice isolation recognition, conversation topics.

We want to solidify on the technologies we used. We believe our greatest strength is utilizing the unique experiences each tool provides. We want to explore how else we can captivate potential users, and helping everyone see the benefit of better dictation

Built With

Share this project: