*banner
 

EECS 149

Contents
Home
Overview
Logistics
Technology

Schedule
Reading
Assignments
Lab & Project

bCourses
Piazza

Reading
References
Resources

Course Development
Wiki
SVN


Course Project Guidelines, Fall 2015

Projects will be performed in teams of three to four people. And all projects will be evaluated on the basis of the quality of the design plan, documentation, and execution with particular attention on the methodology used. It is neither necessary nor sufficient to have a "cool demo" to get a good grade.

Good projects usually have:

  • A good technical plan with realistic timelines.
  • Effective use of models. Models could cover physical and/or cyber components, dynamic behavior of the system, safety and reliability, and timing.
  • High quality software architecture: Modular, well-defined components with well-defined interfaces. Code should be well documented, with procedures clearly labeled with their functionality, with the names of variables and procedures carefully chosen to reflect their role, etc. Modularity implies, for example, that a software component interfacing a sensor is distinct and separable from another software component controlling an actuator.
  • Good choices of hardware, considering cost, capability, reliability, and availability (watch out for long lead times on ordering parts!). Again, modular designs with clean architectures are better. Each component should have a clearly defined role and a well-chosen interface, and should be of the right scale and capability for the task at hand.
  • Attribution. At every opportunity, when presenting your project or writing about it, you must credit your sources of inspiration and technology. Who wrote the sample code that you downloaded and modified? What is its copyright? What YouTube video inspired you? Who created the web page describing the project that you are emulating? Everything we do as engineers depends on what other people have done before us. It is extremely important to give credit to those people.
  • Effective use of platform-based design and model-based methodologies you have learned in the class. Define clearly how you will use models for design, validation, analysis, and testing, and what software tools you used for modeling, simulation, and software development.
Key Deliverables:
  1. Project Charter: October 20 on bCourses.
  2. Project Mini Updates: In class, first half of November.
  3. Project Review with mentor/GSIs: During Nov 17-24.
  4. Project milestone report due: November 24.
  5. Project Presentations: December 14. Each team will have 10 minutes for a presentation and demo.
  6. Final Report: Four page, two-column final report due online December 16.
  7. OPTIONAL: Video demo: A short video demonstrating your project. Submit along with final report. Due December 17 with report (include YouTube URL in report).
  8. Peer Evaluation Form. Submit with final report. Due December 17.
Notes:
  • Always identify you and your team by name
  • Always credit the work of others that you are building on (youtube videos, open-source software, etc.).
  • Giving demos early in a presentation, or even right at the beginning, is better than at the end.
Final Project Reports:
  • One report per team. Hard deadline: December 17, 12:00pm PST. Submit on bCourses as a PDF file.
  • Recommended length: four pages, two columns, 10 point font.
  • Illustrate algorithms and models with diagrams, include pictures of your hardware, screenshots, etc.
  • Keep the report short and precise; avoid lengthy and verbose descriptions!
  • Project reports should articulate how the project involves two or more of the key concepts in the course:
    • concurrency -- interrupts, threads, processes, other concurrent models of computation;
    • modeling of physical dynamics, sensors and actuators;
    • reliable real-time behavior;
    • modal behavior governed by state machines;
    • formal analysis (specification, verification);
    • reliable networking;
    • security and privacy;
    • control theory and implementation, and
    • design methodologies for embedded systems design.
Final Project Presentation/Demo:
  • Final presentations will be on Monday, December 14, 10 am - 4 pm PST, split between 540 Cory and 204 Cory.
  • Recommended format: short presentation and demo, together timed for 10 minutes without questions.
  • Presentation should answer the following questions:
    • What is the problem you are solving?
    • What is novel about your approach? --- this could include things like models/algorithms, design of hardware/software/sensors/networking components, new applications, etc.
    • Articulate how the project involves two or more of the key concepts in the course (see list above)
    • Role of each team member (ideally all team members should be involved in the presentation)
Hardware: Your project can use the hardware in 204 Cory. You can also leverage the partnership with Citris Invention Lab, which can make the Invention Lab Inventory available to the projects for more components. Each team will be given a $200 budget for hardware (this includes the parts you get from the lab and Invention Lab). If you have a compelling need that exceeds this budget, please see the instructors. Your lab GSI is your primary point of contact for obtaining hardware.
  • Sensors: Sensors that are readily available include Accelerometers, Gyroscopes, Photocells, Flex sensors, Force Sensitive sensors, Temperature sensors, Switches, Gas sensors, Infrared proximity sensors, moisture sensors, and microphones. Interfaces, timing characteristics and models will be provided.
  • Computation platforms: We have several of the following embedded boards: (contact one of the GSIs if you would like to use these in your projects) Associated with the above, we have several mbed application shields.
  • Communication: ZigBee, Bluetooth, BLE, Wifi (CC3000, and Electric Imp)
  • Actuators/Robotic Platforms: NeoPixel LEDs, Step Motors, Solenoids, Electric Switches (Relays), Buzzers/Speakers, iRobot Create, iClebo Kobuki, etc.
  • List of items available in the CITRIS Invention Lab.
©2002-2018 Chess