Eyes of Ender

A set of smart glasses that sound off when in range of collision for blind users (beeps faster the closer you get).

Comment

Inspiration

Initially, we were thinking about assistive technologies that can assist emergency responders during disasters such as a building collapsing, so a device that is not high tech or cumbersome to integrate. Then we began considering every day scenarios, and thought about the drawbacks of canes. They depend on the user poking and prodding around their environment, which takes up valuable time and depends on having the cane available at all times. We thought that integrating those ideas into an everyday accessory would be more convenient as a versatile aid for a range of disabilities.

What it does

Our smart glasses will alert users of oncoming collisions through an auditory cue as a series of beeps. The beeps accelerate as the user approaches an object. We accomplished this with a handful of electrical components, and our main goal was to get a functional MVP of a handful of components working synergistically, specifically:

  • Component 1: Distance reading
  • Component 2: Auditory Cues

We chose glasses as the accessory since there was an established convention of similar products coming out of Meta and other consumer electronic companies in this space. We thought it would be a good starting point since there was existing inspiration in terms of fitting in the components (and we did end up finding some cool diagrams online!)

How we built it

First off we needed a base for the glasses, so our resident CAD expert Samantha Chin modified an open source glasses frame, along with a container to preserve our wiring. Measurements and exact cuts proved to be an issue, and finding 3D printers that could take our files in time proved to be challenging, but we got it done!

Next was the electronics and the wiring. Getting the correct components was its own journey, and it took some looking to find components that were even modestly sized, making our later goal of fitting all of this hardware into the slim form factor of a glasses frame more difficult than we expected. Since we got a lot of our materials secondhand from Cornell's Makerspace, we first ran tests to make sure our components were functional. Sometimes, it wasn't a component issue, but a documentation bottleneck. Especially for generic parts, understanding why our code wasn't functioning as intended took exploring new electrical engineering approaches (also YouTube, lots of that). An example of this is we were initially going to focus on an increasing volume of sound to signal rather than a repetitive pattern, and we planned to map the rise in volume to greater voltage. Then we realized our speaker didn't work and that we couldn't control the volume of the buzzer, so we had to pivot to the current model we have now.

Once we verified what we had available, we began searching for code samples online and other documentation relevant to the problem at hand. After our foundation was set, we began writing different helper functions that could algorithmically see the world through our eyes (so to speak). Specifically, by organizing the data we could easily receive from the physical world as input and processing it into action as output. After some modeling and unit conversions, we had a working demo of our gadget. Our final step of refinement was choosing what values were fit for a demo.

Challenges + Growth

First off, we underestimated the size of the hardware we would have access to as first timers. We had one experienced electrical engineer on the team (Luca Spencer) who took a central role in ideation, outlining the scope and constraints, organizing our team, and helping us get up to speed on programming and wiring microcontrollers. Ultimately, even though we couldn't get our components to completely fit in the frame, our team worked to solve the next closest problem. We designed components, experimented, and iterated on the fly, learning new things along the way.

Secondly, pacing. Given that everyone on our team really only had 12 hours to work on this project at a time, it was crucial that we had to make the right choices on what was achievable in that timeframe. A lot of us hadn't worked on projects purely off of our own intuition of what should work. Our team is still really proud of what we put forward, scuffs and all.

Finally, the real learning curve for our team was adapting to the physical world with noise and unexpected consequences at every turn. Both as beginners to Hackathons and starry eyed engineers, we approached this project with ambition, heart, and zeal. We've grown to understand the scope of our current skillsets as well as how to expand them independently through projects, competition, and communities like Big Red Hacks :D.

Contributions

While designing our mounts and base, Samantha learned how to design around model constraints, evaluate tolerance, and visualize how components assemble together cleanly. Rhys got our distance sensor up and running, and wrote a large chunk of our code base along with Luca, who took the lead on the algorithm for the series of tones accelerating in line with the distance sensor. Even as each piece had limits and its own operational quirks and limitations, they experimented with what we had access to and successfully deployed a functional MVP. Jana worked on wiring, coding, 3D printing, documentation, logistics, and designing the slide deck/final submission. Collaborating with the team on key decisions such as the parts we would be able to realistically integrate into our working demo was crucial to establish before building, along with ensuring that our staggered schedules would not prevent us from completing what we set out to do.

Our team wanted to acknowledge an additional range of contributions that made thankful to Major League Hacking for graciously providing such robust hardware competition materials to our team of tinkerers, Antranig Baghdassarin for trusting us with an old pair of glasses that helped expand our options for prototyping (and picking up at 3 AM to answer some questions), and Brandom Guzman and Wally Ahmed for their guidance, advice, and generosity in sharing their materials with our team.

Accomplishments

What matters is we learned a lot about taking an idea, running with it, and building it from the ground up outside of the classroom. Ultimately, that sense of freedom allowed us to collaborate openly with each other, our fellow Hackathon participants, mentors in the competition, our friends around campus, and even strangers online who were kind enough to write the detailed documentation that helped us really bring these components together!

Our technology can have additional applications in vehicle safety, such as cars zooming into blind spots on the road while drivers are merging. Especially in urban areas with aggressive drivers and dense traffic, a preemptive warning of oncoming traffic accelerating could save lives. We also had ideas for how we could expand our glasses beyond form factor.

  • Since sound signals are constrained by loud atmospheres, haptic feedback could be an alternative method for sending a signal to alert users
  • Cameras attached at the bridge or either end of the frame to read out signs through OCR, or using Computer Vision identify objects and obstacles in day to day life. Although a constraint our team observed with this idea is if a user was blind they wouldn't know where to point their head for readings.

What's next for Eyes of Ender

Considering systems that were adaptable and responsive to a wide variety of factors was no small feat, especially when working with limited materials and time. Our team has definitely gained a newfound experience for what it means to "learn, build and share." Bringing our ideas to life was a tremendously fulfilling (and humbling) experience for us all, and we can't wait to carry the lessons we've learned into our future creations.

TLDR; Cheers to more Hackathons, more builds, probably more late nights, and most importantly more laughs!

Share this project:

Updates

Submission history