In 2011, a friend of mine, Ethan Frier and I had an idea. As bike commuters in Pittsburgh, Pennsylvania, we recognized a critical gap in cycling safety lighting: communication. This simple insight sparked a six year journey to redefine how cyclists and drivers can better coexist in the modern city.
Potholes, Muni tracks, distracted ride share drivers and pedestrians. These anxieties heightened by the darkness of night transform them into very real dangers.
Bikes pose a complex detection problem because they are relatively small, fast and heterogenous. “A car is basically a big block of stuff. A bicycle has much less mass and also there can be more variation in appearance — there are more shapes and colors and people hang stuff on them.”
In order to understand how to make cyclists safer, we had to understand drivers.
I conducted a few “ride-alongs” with friends, driving a pre-planned route around the city that took them through mixed areas of pre-identified bicycling activity: marked bike lanes, protected bike lanes, shared lanes.
For cyclists riding in traffic, experts emphasize riding predictably as a key safety behavior. By riding predictably, cyclists communicate their intentions and the information drivers need to safely operate their vehicle near cyclists.
Drivers can use these gestures, when available, to predict whether or not a critical moment is about to happen and then quickly take the most appropriate action for the situation.
Hand signalling was rare as most cyclists were concentrating on the complexities of weaving through dense traffic and avoiding obstacles and moving pedestrians.
Car drivers rely on a set of lighting paradigms to communicate between each other: turn signals, brake lighting, etc. By utilizing a similar language we enable drivers to better understand a cyclist’s intentions.
Currently, there are two types of lights on the market: lights to be seen and to see. Both types of lights focus on the challenge of visibility. There are very few lights that address the challenge of communicating intentions. The few that are available are either low quality products from overseas or products that are distracting to use: requiring a user to press a button on the handlebar to activate.
Enhance: the solution must enhance a cyclist’s current ability to communicate. Inform: it must inform drivers of a safer course of action while driving around cyclists. Recognizable: the solution must build off communication paradigms drivers are already familiar with. Frictionless: the experience of using the product should build off the existing behaviors of the cyclist using limited equipment
Through the process of prototyping, I sought to better understand the feasibility and desirability of the insight.
Understanding rider gestures already created a list of constraints: user wearable, low power, wireless communication. At the time, Intel Curie proved to be the most promising as it was designed for this very purpose: Arduino compatible for easy development, 3.3v low power, Nordic NRF51822 BLE SoC, 6 Axis IMU, Pattern matching engine with hardware accelerated KNN and RBF machine learning algorithms
Prototyping basically means hacking existing products until they fit your needs. Fortunately for me, the Arduino community provided fantastic documentation and a number of algorithms I repurposed for my needs. There are also bluetooth enabled bike lights on the market I was able to hack by simply sending ASCII char’s over Nordic’s Serial BLE profile.
For the first prototype, I pursued an early hypothesis that the position of a rider’s head can give 75% of the gesture information I need. My goal was to connect the Curie to the See.sense lights and trigger them based on a head turn threshold.
The helmet sensor picked up <50% of the head turns. The benefit of the system is its reliability in critical situations. <50% accuracy is simply unacceptable.
I didn’t know when the lights worked or not, leading me to further not trust the system. Fortunately my girlfriend who was riding behind me would yell whenever the lights would successfully change.
It’s still unclear what flashing means other than a “heads up”. Next step would be to test multiple lights configured like car turn signals to add more information.
For the second prototype, I sought to improve accuracy, utilizing the onboard pattern matching engine of the Curie. This meant developing a training protocol for the RBF kernel.
Decided to store data onboard to an SD card rather than stream wirelessly.
Google sheets on google sheets, I’m sure there’s a better way of doing it.
Using Intel’s PME library.
Built a custom interface in Processing to read and render IMU values and send them to the Curie over serial.
Gotta find a new module!