Design Document

Description

The design document communicates the complete and detailed design of your project. It is substantially more detailed than the proposal and prepares you for the assembly phase of the semester. A quality design document is the key to a successful project (sample document). Use the following format:

  1. Introduction

    • Problem and Solution:

      One to two paragraphs explaining the context of the problem to be solved by your project, including any relevant references to justify the existence and/or importance of the problem (i.e., the need or want for a solution). Justify the novelty of your solution or explain the expected improvements of your solution over previous results.

    • Visual Aid

      A pictorial representation of your project that puts your solution in context. Not necessarily restricted to your design. Include other external systems relevant to your project (e.g. if your solution connects to a phone via Bluetooth, draw a dotted line between your device and the phone). Note that this is not a block diagram and should explain how the solution is used, not a breakdown of inner components.

    • High-level requirements list:

      A list of three to four objective characteristics that this project must exhibit in order to solve the problem. These should be selected such that if any of these requirements were not met, the project would fail to solve the problem. Avoid vague requirements that can be interpreted a number of ways (e.g. "The radio subsystem should work reliably."). Each high-level requirement must be stated in complete sentences and displayed as a bulleted list.

  2. Design

    • Block Diagram:

      A general block diagram of the design of your solution. Each block should be as modular as possible and represent a subsystem of your design. In other words, they can be implemented independently and re-assembled later. The block diagram should be accompanied by a brief (1 paragraph) description of the critical subsystems and what they do.

    • Physical Design (if applicable):

      A physical diagram of the project indicating things such as mechanical dimensions or placement of sensors and actuators. The physical diagram should also be accompanied by a brief one paragraph description.

    • [Subsystem X]

      For each subsystem in your block diagram, you should include a highly detailed and quantitative block description. Each description must include a statement indicating how the block contributes to the overall design dictated by the high-level requirements. Any and all design decisions must be clearly justified. Any interfaces with other blocks must be defined clearly and quantitatively.

      Include any relevant supporting figures and data in order to clearly illustrate and justify the design. Typically a well justified block design will include some or all of the following items: Circuit schematics, simulations, calculations, measurements, flow charts, mechanical diagrams (e.g. CAD drawings, only necessary for mechanical components).

      You must include a Requirements and Verifications table. Please see the R&V page for guidance on writing requirements and verification procedures.

    • [Subsystem Y]

      ...

    • [Subsystem Z]

      ...

    • Tolerance Analysis: Through discussions with your TA, identify the block or interface critical to the success of your project that poses the most challenging requirement. Analyze it mathematically and show that it can be feasibly implemented and meet its requirements. See the Tolerance Analysis guide for further guidance.
  3. Cost and Schedule

    1. Cost Analysis: Include a cost analysis of the project by following the outline below. Include a list of any non-standard parts, lab equipment, shop services, etc., which will be needed with an estimated cost for each.
      • Labor: (For each partner in the project)
        Assume a reasonable salary
        ($/hour) x 2.5 x hours to complete = TOTAL
        Then total labor for all partners. It's a good idea to do some research into what a graduate from ECE at Illinois might typically make.
      • Parts: Include a table listing all parts (description, manufacturer, part #, quantity and cost) and quoted machine shop labor hours that will be needed to complete the project.
      • Sum of costs into a grand total
    2. Schedule:

      Include a time-table showing when each step in the expected sequence of design and construction work will be completed (general, by week), and how the tasks will be shared between the team members. (i.e. Select architecture, Design this, Design that, Buy parts, Assemble this, Assemble that, Prepare mock-up, Integrate prototype, Refine prototype, Test integrated system).

  4. Discussion of Ethics and Safety:

    1. Expand upon the ethical and safety issues raised in your proposal to ensure they are comprehensive. Add any ethical and safety concerns that arose since your proposal.
    2. Document procedures to mitigate the safety concerns of your project. For example, include a lab safety document for batteries, human/animal interfaces, aerial devices, high-power, chemicals, etc. Justify that your design decisions sufficiently protect both users and developers from unsafe conditions caused by your project.
      Projects dealing with flying vehicles, high voltage, or other high risk factors, will be required to produce a Safety Manual and demonstrate compliance with the safety manual at the time of demo.
  5. Citations:

    Any material obtained from websites, books, journal articles, or other sources not originally generated by the project team must be appropriately attributed with properly cited sources in a standardized style such as IEEE, ACM, APA, or MLA.

Submission and Deadlines

Your design review document should be uploaded to PACE in PDF format by the deadline shown on the course calendar . If you have uploaded a mock DR document to PACE, please make sure that it has been removed before DR.

Smart Glasses for the Blind

Siraj Khogeer, Abdul Maaieh, Ahmed Nahas

Smart Glasses for the Blind

Featured Project

# Team Members

- Ahmed Nahas (anahas2)

- Siraj Khogeer (khogeer2)

- Abdulrahman Maaieh (amaaieh2)

# Problem:

The underlying motive behind this project is the heart-wrenching fact that, with all the developments in science and technology, the visually impaired have been left with nothing but a simple white cane; a stick among today’s scientific novelties. Our overarching goal is to create a wearable assistive device for the visually impaired by giving them an alternative way of “seeing” through sound. The idea revolves around glasses/headset that allow the user to walk independently by detecting obstacles and notifying the user, creating a sense of vision through spatial awareness.

# Solution:

Our objective is to create smart glasses/headset that allow the visually impaired to ‘see’ through sound. The general idea is to map the user’s surroundings through depth maps and a normal camera, then map both to audio that allows the user to perceive their surroundings.

We’ll use two low-power I2C ToF imagers to build a depth map of the user’s surroundings, as well as an SPI camera for ML features such as object recognition. These cameras/imagers will be connected to our ESP32-S3 WROOM, which downsamples some of the input and offloads them to our phone app/webpage for heavier processing (for object recognition, as well as for the depth-map to sound algorithm, which will be quite complex and builds on research papers we’ve found).

---

# Subsystems:

## Subsystem 1: Microcontroller Unit

We will use an ESP as an MCU, mainly for its WIFI capabilities as well as its sufficient processing power, suitable for us to connect

- ESP32-S3 WROOM : https://www.digikey.com/en/products/detail/espressif-systems/ESP32-S3-WROOM-1-N8/15200089

## Subsystem 2: Tof Depth Imagers/Cameras Subsystem

This subsystem is the main sensor subsystem for getting the depth map data. This data will be transformed into audio signals to allow a visually impaired person to perceive obstacles around them.

There will be two Tof sensors to provide a wide FOV which will be connected to the ESP-32 MCU through two I2C connections. Each sensor provides a 8x8 pixel array at a 63 degree FOV.

- x2 SparkFun Qwiic Mini ToF Imager - VL53L5CX: https://www.sparkfun.com/products/19013

## Subsystem 3: SPI Camera Subsystem

This subsystem will allow us to capture a colored image of the user’s surroundings. A captured image will allow us to implement egocentric computer vision, processed on the app. We will implement one ML feature as a baseline for this project (one of: scene description, object recognition, etc). This will only be given as feedback to the user once prompted by a button on the PCB: when the user clicks the button on the glasses/headset, they will hear a description of their surroundings (hence, we don’t need real time object recognition, as opposed to a higher frame rate for the depth maps which do need lower latency. So as low as 1fps is what we need). This is exciting as having such an input will allow for other ML features/integrations that can be scaled drastically beyond this course.

- x1 Mega 3MP SPI Camera Module: https://www.arducam.com/product/presale-mega-3mp-color-rolling-shutter-camera-module-with-solid-camera-case-for-any-microcontroller/

## Subsystem 4: Stereo Audio Circuit

This subsystem is in charge of converting the digital audio from the ESP-32 and APP into stereo output to be used with earphones or speakers. This included digital to audio conversion and voltage clamping/regulation. Potentially add an adjustable audio option through a potentiometer.

- DAC Circuit

- 2*Op-Amp for Stereo Output, TLC27L1ACP:https://www.ti.com/product/TLC27L1A/part-details/TLC27L1ACP

- SJ1-3554NG (AUX)

- Connection to speakers/earphones https://www.digikey.com/en/products/detail/cui-devices/SJ1-3554NG/738709

- Bone conduction Transducer (optional, to be tested)

- Will allow for a bone conduction audio output, easily integrated around the ear in place of earphones, to be tested for effectiveness. Replaced with earphones otherwise. https://www.adafruit.com/product/1674

## Subsystem 5: App Subsystem

- React Native App/webpage, connects directly to ESP

- Does the heavy processing for the spatial awareness algorithm as well as object recognition or scene description algorithms (using libraries such as yolo, opencv, tflite)

- Sends audio output back to ESP to be outputted to stereo audio circuit

## Subsystem 6: Battery and Power Management

This subsystem is in charge of Power delivery, voltage regulation, and battery management to the rest of the circuit and devices. Takes in the unregulated battery voltage and steps up or down according to each components needs

- Main Power Supply

- Lithium Ion Battery Pack

- Voltage Regulators

- Linear, Buck, Boost regulators for the MCU, Sensors, and DAC

- Enclosure and Routing

- Plastic enclosure for the battery pack

---

# Criterion for Success

**Obstacle Detection:**

- Be able to identify the difference between an obstacle that is 1 meter away vs an obstacle that is 3 meters away.

- Be able to differentiate between obstacles on the right vs the left side of the user

- Be able to perceive an object moving from left to right or right to left in front of the user

**MCU:**

- Offload data from sensor subsystems onto application through a wifi connection.

- Control and receive data from sensors (ToF imagers and SPI camera) using SPI and I2C

- Receive audio from application and pass onto DAC for stereo out.

**App/Webpage:**

- Successfully connects to ESP through WIFI or BLE

- Processes data (ML and depth map algorithms)

- Process image using ML for object recognition

- Transforms depth map into spatial audio

- Sends audio back to ESP for audio output

**Audio:**

- Have working stereo output on the PCB for use in wired earphones or built in speakers

- Have bluetooth working on the app if a user wants to use wireless audio

- Potentially add hardware volume control

**Power:**

- Be able to operate the device using battery power. Safe voltage levels and regulation are needed.

- 5.5V Max

Project Videos