1. Android application:
This application is responsible for obtaining GPS data and communicate the data to the microcontroller via Bluetooth communication.
2. The Microcontroller:
handles and processes the GPS data and based on a signalling algorithm, decides when and in what fashion to signal the vibrotactile actuators.
3. M1 and M2 are just the output pins on the Arduino motor shield for powering the vibrotactile actuators
-----------------------------------------------------------------------------------------------
The main parts of this project which I have been involved with so far are hardware design, microcontroller programming/haptic feedback algorithm design and documentation.
During the second iteration, I produced a simple hardware sketch by attaching the vibrotactile actuators to a dummy bicycle handlebar. In doing so, I wanted to test the feasibility of choosing such location for vibrotactile feedback. Soon after, we realized that vibration produced by the road bumps can potentially be superimposed with the vibrotactile feedback. This was a large anticipated risk in communication transparency and we decided not to go further with this setup.
While Bruce is developing the Android app., I put together a new hardware sketch, this time placing the two actuators inside of the helmet as shown in the figure below:
As shown in the above figure, the actuators are attached to left and right sides of the helmet, corresponding to the left and right temples of the cyclist's head. I had a few people including I and Bruce to try the device. I gave pulses to each actuator, testing the mapping from vibration on either side to direction of left/right. The mapping was promising.
The vibrotactile feedback algorithm design is based on the following scenario/model:
The user inputs his/her destination address into their Android and waits for vibrotactile feedback from their helmet as they start cycling. The vibrotactile actuators are connected to the microcontroller motor shield which is battery powered and sits inside of a closure box. The closure box is placed in the user's bag pack while cycling.
The path of travel calculated by the Android GPS algorithm consists of a series of turning points at which the user needs to either turn left or right. The distance to the next turning point is periodically sent to the microcontroller along with turning direction. As the cyclist is approaching the next turning point (e.g., user needs to turn left), the left actuator starts vibrating in a fashion such that the cyclist can interpret the signal as "Ok, a left turning point is approaching soon". In other words, the signal progresses from a soft/low-priority signal warning the user they need to turn left soon, to a high-priority signal telling the user they need to turn left NOW.
In order to implement the above mentioned scenario, I first tried by progressively intensifying the vibrotactile signal strength to communicate urgency. I experimented this implementation with a few volunteers including I and Bruce. This did not turn out to be very effective as it was not easily sensed by the user. After all, the incremental changes to the signal strength could not be detected by the user, especially over a relatively long period of time - e.g., 15 s.
I then came up with a different scheme:
As the cyclist is approaching a turning point, the length of ON pulses increases while the length of OFF pulses decreases.I designed an algorithm to implement the above mentioned scheme. This algorithm is time-dependent which means that a time period of pulse generation is given as input and the length of ON pulses are progressively stretched over time with a specified time resolution. While the OFF pulses are shortened over time.
The challenge is to find an optimum period during which pulses are applied. We found that using a long period ruins the goal of communicating urgency and would result in user's inability to interpret the message. The goal was for user to distinguish between low-priority pulses, medium priority pulses and high priority pulses. After experimenting with different time periods and resolutions, I found that a 18 s time period with time resolution 300 ms serves the purpose. I partitioned the period into 3 segments and in each segment, the ON pulse is stretched while the OFF pulse is shortened. In order to determine the appropriate parameter settings, we need to experiment different settings on the road.
After determining the appropriate timing, I converted the algorithm to a distance-dependent one rather than time-dependent. This means that the pulse generation starts as the cyclist is in close proximity to the next turning point. And as corresponding distance shortens, the ON pulses stretch and OFF pulses shorten. This is to avoid timing issues which can arise in real time because we can not accurately predict cyclist's speed and after all, we have a continuous update of distance to next turning point from the Android application.
Assuming the cyclist travels at an average of 20 km/h, we can convert the 18s pulse period to a distance of approximately 100 m. I believe this would be a fair distance for warning the user ahead of time.
In order to test our prototype on the road, I secured the microcontroller to an enclosure box along with the Bluetooth transciever, a 9 V battery to power the electronics. Below are images of the hardware unit along with the actuators connected to it.
To-do list:
1. Incorporate another actuator placed in the back of the helmet to give u-turn signals. The actuator would touch the back of the user's head. I anticipate that the duration of u-turn signalling should be shorter and the pulse progression would have to be done in a rapid fashion. This is because there wouldn't be any ahead-of-time warning - it would be an urgent signal notifying the user to make a u-turn NOW. We will have to test different parameter settings (i.e., time period for pulse generation, time resolution, etc.) to find an appropriate scheme for this.
2. Test signalling algorithm using Android emulator before taking bike to the road. In this case the bicycle's trajectory is 'faked' by changing the current position on the map. The distance to the next turning point along with the turning direction is then communicated to the microcontroller. The assumption that we make here is that the distance from two consecutive turning points is greater than a small threshold of let's say 90 meters. This is based on the distance calculation that was discussed above - i.e., the distance over which we excite the actuators.
3. Conduct on-the-road experiments to find which time period and time resolution is appropriate for communicating navigational guidance (very important). This would be based on the scenario discussed above. First, we are planning to use a relatively small distance between starting point and destination - i.e., consisting of a couple turning points. Because our priority is first finding an appropriate parameter setting for the signalling algorithm. Then we can hopefully do a longer run. We are hoping to recruit at least 5 volunteers to test longer routes.
