Our app is designed to be the user interface for our smart shoes. It gives our user an easy way to load directions into their shoe attatchment in a familiar format that looks similar to Google and Apple maps. The user simply taps on or searches for the location the wish to be directed to, and clicks start. The app then guides them through the navigation on their screen, and sends data over bluetooth to the shoe attatchment so that it vibrates left or right depending on which way they need to turn. Check out our commented code on our github: here .
A more in-depth overview of how our app works
Our app was created using Android Studio and utilizes the mapbox API to get direction data and display the directions on the user's phone. In order to give directions, our app requests direction information in the form of a JSON file from mapbox. It then parses through the JSON file to extract data about the directions. More specifically, it grabs the location data and direction (turn left, stay straight, etc.). Then it keeps track of the user's current location and continually checks it against the location of the next step. If the two locations are equal, it sends the step direction (i.e. turn left) to the arduino over bluetooth. We loaded code onto our arduino that deals with different bluetooth data differently in order to translate data from the app into motor controlling commands. Check out our arduino code here.
Why bluetooth?
We wanted our user to be able to put their phone in their pocket or backpack and not look at it at all while they are walking or biking to their destination. Thus, we decided to send all of the data from our app to our shoe attatchment using bluetooth.
Why Mapbox?
When we started building this app, we used the Google Maps API to get directions data. After a long time developing this app, we realized that Google Maps doesn't want people using the API to be able to access specific data about the directions. So, they obscured the methods for how to get that information and how to use it. We finally realized that we simply wouldn't be able to get the information we needed using the Google Maps API, so we pivoted to Mapbox.
A storyline of how we got to our final app.
First Version
We made the first version of our app in MIT App Inventor. The purpose of our first app was to test the bluetooth functionality and have something up and running that could send data. We also created arduino code for this iteration that responded to the bluetooth data sent. We tested the app using an LED. When we sent "a" to the arduino using bluetooth, the LED turned on, and when we sent "b", it turned off.
Second Version
We focused on getting an app to work with maps functions for our second iteration. In order to do so, we used the Google Maps API in Android Studio. We put the bluetooth functionality on hold for a bit as we wrestled with using Android Studio and coding in the unfamiliar language of Java. This version of the app got directions from Google Maps and drew a line on a map of the path that the user should follow.
Third Version
For our third version, we focused on getting some bluetooth functionality in android studio and building turn-by-turn functionality into the app. In order to split up work, we worked on two seperate apps, one that sent bluetooth data and one that had the maps functionality. The bluetooth app was a recreation of our first app in MIT App Inventor, so it sent strings that the user typed over bluetooth. Unfortunately, we had a lot of trouble getting specific direction data from Google Maps API, which we later learn was because Google Maps doesn't want people using the API to be able to get turn-by-turn directions.
Final Version
For the final version of our app, we pivoted from using Google Maps API to using Mapbox, a different maps API that is specifically intended for developers. This allowed us to finally access turn-by-turn direction data. Now our app gets directions between two points that the user specifies, and walks them through the directions on their screen. In order to do so, it checks your location against the location of the next turn, and once they're equal, it tells you to turn one way or the other. It also sends data over bluetooth, but unfortunately due to our late pivot to a new API, the app isn't totally integrated yet. If everything were integrated, the app would send bluetooth data to our arduino through the bluetooth module when your location matched that of a turn.
What would be our next step if we had another sprint in this project?
If given another sprint, we would ensure that everything is integrated properly. Then we might work on dealing with directions that are more complicated than "turn left", "turn right", and "stay straight". This would make our app more applicable to people that are travelling in ways other than walking, such as biking or driving.
What would we have done differently if we were able to start the project over knowing what we know now?
If we were to start the project over again today, we would definitely start out with Mapbox as our maps API, since it was impossible to get the functionality we were counting on through the Google Maps API. We would also work on integrating our app sooner, or trying to find a way to make it simpler, because it was really hard to get enough functionality in the app to be able to integrate it without full-on finishing the whole thing.
Thoughts on "what could we have done differently"?
For this project, learning how to create an app was probably over-scoped, given what we knew coming in. Learning how to use java and different APIs and bluetooth all while making an app that would work with the rest of our team's progress was simply too much to do successfully. It would have been ideal to figure out a way to make smart shoes without creating an app, because I believe we could have found a path that would have been easier to find resources on campus about, and also one that would have allowed us more learning opportunities. Given that we did create an app, I think that finding more substantial help early on would have been really helpful. Our questions were so specific that it was hard for the teaching team, or any of our peers to address them, and so we were just lost in our own confusion.