Design Document Check

updated Fa 2020

Description

The Design Document Check (DDC) is intended to aid your team as it prepares its Design Document. The DDC focuses narrowly upon providing feedback on the preparation of historically problematic Design Document elements. If these elements fall short during your Design Review the following week, precious time is lost.

What are the course staff looking for? i) Evidence that the overall idea of the design is sound; ii) A check of a small subset of required components indicates that the project is on the right track.

The DDC provides feedback on your preparation of the following Design Document elements:

  1. Introduction
    1. Start with a brief summary (30 sec) or elevator pitch following this template:

      I will build ___A___ (my core product) for ___B___ (my core customer: the person who pays my company or uses the product).

      My customer has a problem ___C___ (describe the problem your customer has)

      My product solves my customer’s problem by ___D___ (how do you solve the problem?)

    2. Be expected to explain further what the problem is, what’s your idea to solve it, and why your idea is novel.
  2. High-level Requirements
    1. HL requirements are derived from the problem you are trying to solve (put yourself into the customer's shoes). HL requirements should be the essential features that your customers/users really care about. These features distinguish your product from others (e.g. ones available in the market or previous 445 designs). Be abstract (no tech details, you may come up with different design due to other constraints but still solve this problem), quantifiable (no words like continuously, accurately, etc), and unambiguous. HL&RV slides(P.5) has a good example.
    2. We will look at your HL requirements and check if they are what your customers/users really care about. Be prepared to defend your requirements, so that when you get challenged, you can give a well thought out explanation.
  3. Block Diagram
    1. Block Diagram slides
    2. We will check whether this design appears to solve your problem. 
    3. We will check if formatting is clear (lines, legends, etc). Extra caution is needed as students often make mistakes here (but you shouldn't!).
  4. Physical Design (if applicable)
  5. Requirements & Verification Tables
    1. HL&RV slides: from P. 1-17
    2. Block Module Requirements: Break down your HL requirements into block level requirements. These are the requirements in the RV table (they are not the specs of the parts you have chosen).
    3. Verification: A step-by-step approach allows another 445 student to test if the BL requirement is satisfied. This is like an instruction for your module's unit test (with some surrounding dummy modules, a.k.a, mock object(s)
    4. We will review one piece of it. Show us an important one.
  6. Plots
  7. Circuit Schematics
  8. Tolerance Analysis
    1. Identify an important part that you need to perform some quantitative analysis on. This part should have quantitative values critical to the design and require you do calculations and make trade-offs in order to achieve your best design.
    2. Common mistake: Many students do calculations for tangential parts to pad the space.
  9. Safety & Ethics
  10. Citations

During the DDC, your team will have 5-8 minutes to present an example of each of these elements. Expect to share the 30-minute DDC session with two other design teams. Come prepared to learn from their work - both the good and bad.

Your task is to prepare and upload the above elements in a single PDF document to the course website. During your DDC session, you will present directly from your submission, which will be projected for all to see.

The focus of the DDC is not on the details of your design but rather on the details of your formatting; the design of your project will be covered in-depth during the Design Review. Organize your submission in accordance with the Design Document guidance and the example Design Document.

The course staff will focus on providing feedback on the format of your sample DDC elements - the very limited available time will not afford detailed feedback on your design. Please go to office hours for further guidance.

Requirements and Grading

Upload your DDC submission to your project page on PACE (i.e. ECE 445 web board) before arriving at your DDC session.

As in your Design Document, number pages after the title page in your DDC submission.

An example DDC submission is provided here for reference. The corresponding Design Document for this DDC submission can be found on the Design Document assignment page.

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.

The course staff at the DDC will assign individual grades to each student based on:

Submission and Deadlines

Sign-up for the Design Document Check on the ECE 445 course website - specifically at the Sign up for Team Presentation item on the PACE tab. Sign-up will open the Monday one week prior to the DDCs.

Upload your DDC submission (.pdf format) to the ECE 445 course website before your DDC session - specifically at the My Project item on the PACE tab.

While you will not complete peer reviews during the DDC, you are expected to actively contribute to the discussion.

Tech must-know and FAQ for design

Here is the link of "Tech must-know and FAQ for design" which is accessible after logging into g.illinois.edu.

Over semesters, ECE445 course staff have encountered repeated mistakes from students. The document above is designed to provide students with the essential knowledge needed in order to have a good design. Spending 5 min reading it might save you 15 hours later. Also, there might be some quiz questions in your DDC or Design Review. Please help us improve this document. We value your feedback!

A Wearable Device Outputting Scene Text For Blind People

Hangtao Jin, Youchuan Liu, Xiaomeng Yang, Changyu Zhu

A Wearable Device Outputting Scene Text For Blind People

Featured Project

# Revised

We discussed it with our mentor Prof. Gaoang Wang, and got a solution to solve the problem

## TEAM MEMBERS (NETID)

Xiaomeng Yang (xy20), Youchuan Liu (yl38), Changyu Zhu (changyu4), Hangtao Jin (hangtao2)

## INSTRUCTOR

Prof. Gaoang Wang

## LINK

This idea was pitched on Web Board by Xiaomeng Yang.

https://courses.grainger.illinois.edu/ece445zjui/pace/view-topic.asp?id=64684

## PROBLEM DESCRIPTION

Nowadays, there are about 12 million visually disabled people in China. However, it is hard for us to see blind people in the street. One reason is that when the blind people are going to the location they are not familiar with, it is difficult for blind people to figure out where they are. When blind people travel, they are usually equipped with navigation equipment, but the accuracy of navigation equipment is not enough, and it is difficult for blind people to find the accurate position of the destination when they arrive near the destination. Therefore, we'd like to make a device that can figure out the scene text information around the destination for blind people to reach the direct place.

## SOLUTION OVERVIEW

We'd like to make a device with a micro camera and an earphone. By clicking a button, the camera will take a picture and send it to a remote server to process through a communication subsystem. After that, text messages will be extracted and recognized from the pictures using neural network, and be transferred to voice messages by Google text-to-speech API. The speech messages will then be sent back through the earphones to the users. The device can be attached to glasses that blind people wear.

The blind use the navigation equipment, which can tell them the location and direction of their destination, but the blind still need the detail direction of the destination. And our wearable device can help solve this problem. The camera is fixed to the head, just like our eyes. So when the blind person turns his head, the camera can capture the text of the scene in different directions. Our scenario is to identify the name of the store on the side of the street. These store signs are generally not tall, about two stories high. Blind people can look up and down to let the camera capture the whole store. Therefore, no matter where the store name is, it can be recognized.

For example, if a blind person aims to go to a book store, the navigation app will tell him that he arrives the store and it is on his right when he are near the destination. However, there are several stores on his right. Then the blind person can face to the right and take a photo of that direction, and figure out whether the store is there. If not, he can turn his head a little bit and take another photo of the new direction.

![figure1](https://courses.grainger.illinois.edu/ece445zjui/pace/getfile/18612)

![figure2](https://courses.grainger.illinois.edu/ece445zjui/pace/getfile/18614)

## SOLUTION COMPONENTS

### Interactive Subsystem

The interactive subsystem interacts with the blind and the environment.

- 3-D printed frame that can be attached to the glasses through a snap-fit structure, which could holds all the accessories in place

- Micro camera that can take pictures

- Earphone that can output the speech

### Communication Subsystem

The communication subsystem is used to connect the interactive subsystem with the software processing subsystem.

- Raspberry Pi(RPI) can get the images taken by the camera and send them to the remote server through WiFi module. After processing in the remote server, RPI can receive the speech information(.mp3 file).

### Software Processing Subsystem

The software processing subsystem processes the images and output speech, which including two subparts, text recognition part and text-to-speech part.

- A OCR recognition neural network which is able to extract and recognize the Chinese text from the environmental images transported by the communication system.

- Google text-to-speech API is used to transfer the text we get to speech.

## CRITERION FOR SUCCESS

- Use neural network to recognize the Chinese scene text successfully.

- Use Google text-to-speech API to transfer the recognized text to speech.

- The device can transport the environment pictures or video to server and receive the speech information correctly.

- Blind people could use the speech information locate their position.