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.

Below is a checklist of things to have ready for the design document check. Refer to the design document page and grading rubric for a full description of each item.
  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. Visual Aid
  3. 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.
  4. 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!).
  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.

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!

ATTITUDE DETERMINATION AND CONTROL MODULE FOR UIUC NANOSATELLITES

Shamith Achanta, Rick Eason, Srikar Nalamalapu

Featured Project

Team Members:

- Rick Eason (reason2)

- Srikar Nalamalapu (svn3)

- Shamith Achanta (shamith2)

# Problem

The Aerospace Engineering department's Laboratory for Advanced Space Systems at Illinois (LASSI) develops nanosatellites for the University of Illinois. Their next-generation satellite architecture is currently in development, however the core bus does not contain an Attitude Determination and Control (ADCS) system.

In order for an ADCS system to be useful to LASSI, the system must be compliant with their modular spacecraft bus architecture.

# Solution

Design, build, and test an IlliniSat-0 spec compliant ADCS module. This requires being able to:

- Sense and process the Earth's weak magnetic field as it passes through the module.

- Sense and process the spacecraft body's <30 dps rotation rate.

- Execute control algorithms to command magnetorquer coil current drivers.

- Drive current through magnetorquer coils.

As well as being compliant to LASSI specification for:

- Mechanical design.

- Electrical power interfaces.

- Serial data interfaces.

- Material properties.

- Serial communications protocol.

# Solution Components

## Sensing

Using the Rohm BM1422AGMV 3-axis magnetometer we can accurately sense 0.042 microTesla per LSB, which gives very good overhead for sensing Earth's field. Furthermore, this sensor is designed for use in wearable electronics as a compass, so it also contains programable low-pass filters. This will reduce MCU processing load.

Using the Bosch BMI270 3-axis gyroscope we can accurately sense rotation rate at between ~16 and ~260 LSB per dps, which gives very good overhead to sense low-rate rotation of the spacecraft body. This sensor also contains a programable low-pass filter, which will help reduce MCU processing load.

Both sensors will communicate over I2C to the MCU.

## Serial Communications

The LASSI spec for this module requires the inclusion of the following serial communications processes:

- CAN-FD

- RS422

- Differential I2C

The CAN-FD interface is provided from the STM-32 MCU through a SN65HVD234-Q1 transceiver. It supports all CAN speeds and is used on all other devices on the CAN bus, providing increased reliability.

The RS422 interface is provided through GPIO from the STM-32 MCU and uses the TI THVD1451 transceiver. RS422 is a twisted-pair differential serial interface that provides high noise rejection and high data rates.

The Differential I2C is provided by a specialized transceiver from NXP, which allows I2C to be used reliably in high-noise and board-to-board situations. The device is the PCA9615.

I2C between the sensors and the MCU is provided by the GPIO on the MCU and does not require a transceiver.

## MCU

The MCU will be an STM32L552, exact variant and package is TBD due to parts availability. This MCU provides significant processing power, good GPIO, and excellent build and development tools. Firmware will be written in either C or Rust, depending on some initial testing.

We have access to debugging and flashing tools that are compatible with this MCU.

## Magnetics Coils and Constant Current Drivers

We are going to wind our own copper wire around coil mandrels to produce magnetorquers that are useful geometries for the device. A 3d printed mandrel will be designed and produced for each of the three coils. We do not believe this to be a significant risk of project failure because the geometries involved are extremely simple and the coil does not need to be extremely precise. Mounting of the coils to the board will be handled by 3d printed clips that we will design. The coils will be soldered into the board through plated through-holes.

Driving the inductors will be the MAX8560 500mA buck converter. This converter allows the MCU to toggle the activity of the individual coils separately through GPIO pins, as well as good soft-start characteristics for the large current draw of the coils.

## Board Design

This project requires significant work in the board layout phase. A 4-layer PCB is anticipated and due to LASSI compliance requirements the board outline, mounting hole placement, part keep-out zones, and a large stack-through connector (Samtec ERM/F-8) are already defined.

Unless constrained by part availability or required for other reasons, all parts will be SMD and will be selected for minimum footprint area.

# Criterion For Success

Success for our project will be broken into several parts:

- Electronics

- Firmware

- Compatibility

Compatibility success is the easiest to test. The device must be compatible with LASSI specifications for IlliniSat-0 modules. This is verifiable through mechanical measurement, board design review, and integration with other test articles.

Firmware success will be determined by meeting the following criteria:

- The capability to initialize, configure, and read accurate data from the IMU sensors. This is a test of I2C interfacing and will be tested using external test equipment in the LASSI lab. (We have approval to use and access to this equipment)

- The capability to control the output states of the magnetorquer coils. This is a test of GPIO interfacing in firmware.

- The capability to move through different control modes, including: IDLE, FAULT, DETUMBLE, SLEW, and TEST. This will be validated through debugger interfacing, as there is no visual indication system on this device to reduce power waste.

- The capability to self-test and to identify faults. This will be validated through debugger interfacing, as there is no visual indication system on this device to reduce power waste.

- The capability to communicate to other modules on the bus over CAN or RS422 using LASSI-compatible serial protocols. This will be validated through the use of external test equipment designed for IlliniSat-0 module testing.

**Note:** the development of the actual detumble and pointing algorithms that will be used in orbital flight fall outside the reasonable scope of electrical engineering as a field. We are explicitly designing this system such that an aerospace engineering team can develop control algorithms and drop them into our firmware stack for use.

Electronics success will be determined through the successful operation of the other criteria, if the board layout is faulty or a part was poorly selected, the system will not work as intended and will fail other tests. Electronics success will also be validated by measuring the current consumption of the device when operating. The device is required not to exceed 2 amps of total current draw from its dedicated power rail at 3.3 volts. This can be verified by observing the benchtop power supply used to run the device in the lab.