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!

Autonomous Behavior Supervisor

Shengjian Chen, Xiaolu Liu, Zhuping Liu, Huili Tao

Featured Project

## Team members

- Xiaolu Liu (xiaolul2)

- Zhuping Liu(zhuping2)

- Shengjian Chen(sc54)

- Huili Tao(huilit2)

## Problem:

In many real-life scenarios, we need AI systems not only to detect people, but also to monitor their behavior. However, today's AI systems are only able to detect faces but are still lacking the analysis of movements, and the results obtained are not comprehensive enough. For example, in many high-risk laboratories, we need to ensure not only that the person entering the laboratory is identified, but also that he or she is acting in accordance with the regulations to avoid danger. In addition to this, the system can also help to better supervise students in their online study exams. We can combine the student's expressions and eyes, as well as his movements to better maintain the fairness of the test.

## Solution Overview:

Our solution for the problem mentioned above is an Autonomous Behavior Supervisor. This system mainly consists of a camera and an alarm device. Using real-time photos taken by the camera, the system can perform face verification on people. When the person is successfully verified, the camera starts to monitor the person's behavior and his interaction with the surroundings. Then the system determines whether there is a dangerous action or an unreasonable behavior. As soon as the system determines that there are something uncommon, the alarm will ring. Conversely, if the person fails verification (ie, does not have permission), the words "You do not have permission" will be displayed on the computer screen.

## Solution Components:

### Identification Subsystem:

- Locate the position of people's face

- Identify whether the face of people is recorded in our system

The camera will capture people's facial information as image input to the system. There exists several libraries in Python like OpenCV, which have lots of useful tools. The identification progress has 3 steps: firstly, we establish the documents of facial information and store the encoded faceprint. Secondly, we camera to capture the current face image, and generate the face pattern coding of the current face image file. Finally, we compare the current facial coding with the information in the storage. This is done by setting of a threshold. When the familiarity exceeds the threshold, we regard this person as recorded. Otherwise, this person will be banned from the system unless he records his facial information to our system.

### Supervising Subsystem

- Capture people's behavior

- Recognize the interaction between human and object

- Identify what people are doing

This part is the capture and analysis of people's behavior, which is the interaction between people and objects. For the algorithm, we decided initially to utilize that based on VSG-Net or other developed HOI models. To make it suitable for our system or make some improvement, we need analysis and adjustment of the models. For the algorithm, it is a multi-branch network: Visual Branch: extracting visual features from people, objects, and the surrounding environment. Spatial Attention Branch: Modeling the spatial relationship between human-object pairs. Graph Convolutional Branch: The scene was treated as a graph, with people and objects as nodes, and modeling the structural interactions. This is a computational work that needs the training on dataset and applies to the real system. It is true that the accuracy may not be 100% but we will try our best to improve the performance.

### Alarming Subsystem

- Staying normal when common behaviors are detected

- Alarming when dangerous or non-compliant behaviors are detected

It is an alarm apparatus connected to the final of our system, which is used to report dangerous actions or behaviors that are not permitted. If some actions are detected in supervising system like "harm people", "illegal experimental operation", and "cheating in exams", the alarming system will sound a warning to let people notice that. To achieve this, a "dangerous action library" should be prepared in advance which contains dangerous behaviors, when the analysis of actions in supervising system match some contents in the action library, the system will alarm to report.

## Criteria of Success:

- Must have a human face recognition system and determine whether the person is in the backend database

- The system will detect the human with the surrounding objects on the screen and analyze the possible interaction between these items.

- Based on the interaction, the system could detect the potentially dangerous action and give out warnings.

## DIVISION OF LABOR AND RESPONSIBILITIES

All members should contribute to the design and process of the project, we meet regularly to discuss and push forward the process of the design. Each member is responsible for a certain part but it doesn't mean that this is the only work for him/her.

- Shengjian Chen: Responsible for the facial recognition part of the project.

- Huili Tao: HOI algorithm modification and apply that to our project

- Zhuping Liu: Hardware design and the connectivity of the project

- XIaolu Liu: Detail optimizing and test of the function.

Project Videos