Idea Transcript
HOME
GUIDELINES
Course Overview Assignments and Grading Ethical Guidelines Safety Guidelines
LAB
RESOURCES
PACE
MENTORS
SPONSORS
DESIGN DOCUMENT VIDEO LECTURE Video, Slides
Special Circuit Using the Website
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. Use the following format. 1. Introduction Objective: One to two paragraphs detailing the problem statement and proposed solution. Background: 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). High-level requirements list: A list of at most three quantitative characteristics that this project must exhibit in order to solve the problem. 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. In other words, they can be implemented independently and reassembled later. The block diagram should be accompanied by a brief (1 paragraph) description of the high level design justifying that the design will satisfy the high-level requirements. 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. Block Design: A detailed design for every block in the block diagram, including software and mechanical design. Each block design should include the following. 1. Functional Overview: 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. 2. Requirements and Verifications: Requirements and verifications for each block must be included. Please see the R&V page for guidance on writing requirements and verification procedures. 3. Supporting Material: Include any relevent 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 (often for software) Mechanical diagrams (e.g. CAD drawings, only necessary for mechanical components) Tolerance Analysis: Through discussions with your TA, identify a critical requirement to explore in great detail. Your analysis of that component will prove that your implementation will meet that requirement. 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. GRAND TOTAL = LABOR + PARTS 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.
GRADING The DD Grading Rubric is available for your viewing pleasure. An example is available available to illustrate the expectations for a high quality Design Document: Sample DD.
SUBMISSION AND DEADLINES Your design review document should be uploaded to PACE in PDF format by the deadline shown on the course calendar (typically midnight the Friday before Design Review). If you have uploaded a mock DR document to PACE, please make sure that it has been removed before DR.
CLOUDCONTROLLED QUADCOPTER
FEATURED PROJECT
Anuraag Vankayala, Amrutha Vasili
Design/Build:
Idea: To build a GPS-assisted, cloud-controlled quadcopter, for consumer-friendly aerial photography.
We will be building a quad from the frame up. The four motors will each have electronic speed controllers,to balance and handle control inputs received from an 8bit microcontroller(AP),required for its flight. The firmware will be tweaked slightly to allow flight modes that our project specifically requires. A companion computer such as the Erle Brain will be connected to the AP and to the cloud(EC2). We will build a codebase for the flight controller to navigate the quad. This would involve sending messages as per the MAVLink spec for sUAS between the companion computer and the AP to poll sensor data , voltage information , etc. The companion computer will also talk to the cloud via a UDP port to receive requests and process them via our code. Users make requests for media capture via a phone app that talks to the cloud via an internet connection. Why is it worth doing: There is currently no consumer-friendly solution that provides or lets anyone capture aerial photographs of them/their family/a nearby event via a simple tap on a phone. In fact, present day off-the-shelf alternatives offer relatively expensive solutions that require owning and carrying bulky equipment such as the quads/remotes. Our idea allows for safe and responsible use of drones as our proposed solution is autonomous, has several safety features, is context aware(terrain information , no fly zones , NOTAMs , etc.) and integrates with the federal airspace seamlessly. End Product: Quads that are ready for the connected world and are capable to fly autonomously, from the user standpoint, and can perform maneuvers safely with a very simplistic UI for the common user. Specifically, quads which are deployed on user's demand, without the hassle of ownership. Similar products and comparison: Current solutions include RTF (ready to fly) quads such as the DJI Phantom and the Kickstarter project, Lily,that are heavily user-dependent or user-centric.The Phantom requires you to carry a bulky remote with multiple antennas. Moreover,the flight radius could be reduced by interference from nearby conditions.Lily requires the user to carry a tracking device on them. You can not have Lily shoot a subject that is not you. Lily can have a maximum altitude of 15 m above you and that is below the tree line,prone to crashes. Our solution differs in several ways.Our solution intends to be location and/or eventcentric. We propose that the users need not own quads and user can capture a moment with a phone.As long as any of the users are in the service area and the weather conditions are permissible, safety and knowledge of controlling the quad are all abstracted. The only question left to the user is what should be in the picture at a given time.
PROJECT VIDEOS Demo video
Instructors: Can Bayram | Xiaogang Chen | Arne Fliflet | Rakesh Kumar | Michael Oelze | Karl Reinhard