*banner
 

EECS 149

Contents
Home
Overview
Logistics
Technology

Lectures
Reading
Assignments
Project
Seminar

bSpace

Reading
References
Resources

Course Development
Wiki
CVS


Labs and Projects

The lab content of this course begins with some exercises designed for students to gain some familiarity with programming embedded systems at various levels of abstraction with varying amounts of infrastructure support. It then progresses to team projects. Teams of three to five students will be expected to develop a plan of action including a time line and defined division of responsibilities, and then execute a project that culminates in a demo session and a poster presentation. Presentations will be held on Friday, May 15, and the project reports are due Tuesday, May 19.

Lab Times: Mondays 4-7 PM, Thursday 2-5 PM in 119 Cory.

IMPORTANT: Please read these lab safety guidelines and lab policy.

Lab Grading:
Each lab will be graded according to the following rubric:
Pre-Lab - 10% - Should be done before lab, handed in when you get to lab.
Lab Checkout - 45% - You have one week to complete the lab and show the TA.
Lab Writeup - 45% - Writeups are due exactly one week after lab.

Late policy:
Late pre-labs may be handed in during lab for half credit, no pre-labs will be accepted after lab session.
Late Checkout and Lab writeups will be deducted 10% for each day late. Late checkout does not extend your writeup deadline. The writeup is due a week after the scheduled lab date for each lab. You must notify me at least 4 days in advance for any emergency or situation to extend the deadlines.

Lab Writeup Guideline

Labs: Content and Schedule

  1. Week 2 (Jan. 26): Orientation: Getting familiar with the lab, including computing resources, LabVIEW, and techniques for interfacing to sensors, calibrating them, and processing and analyzing their data. A major objective of the lab exercise is to get familiar with signal processing using the dataflow model of computation and to understand how to interface a desktop computer to a physical sensor.
    Other docuements:
  2. Week 3 (Feb. 2): Sensor modeling: This exercise will evaluate the use of accelerometers and rate gyros for measuring tilt and tracking changes in location. A major objective of this lab is to understand how to model the behavior of a sensor, how to deal with noise, and how to evaluate limitations in precision and accuracy.

  3. Week 4 (Feb. 9): Microcontroller programming and interfacing: Students will become familiar with the iRobot Create and Luminary microcontroller. They will program a "bare iron" (no operating system) embedded application in C, interface the program to external sensors using either polling or interrupts, and program the robot to drive and avoid obstacles.


  4. Week 5 (Feb. 16): Hill Climbing: Students will program the Luminary microcontroller on the iRobot Create to climb a ramp, find the maximal point, and stop. The iRobot Create must not fall off the edges of the ramp and must avoid obstacles on the ramp. The major objective of this lab is to jointly design a modal model for the hill climbing problem that includes both its physical dynamics and exception conditions of encountering a cliff, and to understand the challenges of navigating without precise location information.
    See above for lab documents.
  5. Week 6 (Feb. 26): Model-Based Design for Hill Climbing: Part I -- Simulation: Students will repeat the Hill Climbing programming task using LabVIEW. This first part of the lab involves creating a LabVIEW model and simulating it.


  6. Week 7 (Mar. 5): Model-Based Design for Hill Climbing: Part II -- Implementation: Students will repeat the Hill Climbing programming task using LabVIEW. This second part of the lab involves downloading the model onto the Luminary/iRobot platform and evaluating the actual implementation.
    See above for lab documents.
  7. Week 8 (Mar. 12): Project management: Students will finalize project teams and project definitions, construct a plan for the project with specific milestones and assign responsibilities to project participants.
    Sample Projects

  8. Weeks 9-16: Projects
    See below for course project guidelines. Tentative Schedule:
    • Wed 3/18 - first 5-min mini project updates, milestone prediction
    • Wed 4/1 - one page milestone report
    • Wed 4/8 - mini project updates (5 min each), new milestone prediction
    • Wed 4/15 - one page milestone report
    • Sat 4/18 - Cal Day
    • Mon 4/27 - mini project updates (5 min each), new milestone prediction (including goals for the final presentation)
    • Wed 5/6 - final one page milestone report
    • Fri 5/15 - 12:30 - 3:30 pm, Project presentations and demo in the Woz
    • Tue 5/19 - Project final report due

Course Project Guidelines

Projects will be performed in teams of up to five students and should be selected from the list of suggested projects given below. In exceptional circumstances, student teams may propose projects that are not on this list. All projects should include nontrivial applications of two or more of the following key concepts in the course:

  • concurrency,
  • modeling of physical dynamics,
  • reliable real-time behavior,
  • modal behavior governed by FSMs coupled with formal analysis,
  • real-time networks,
  • simulation strategies, and
  • design methodologies for embedded systems design.
The project report (a poster presentation and demo) should make clear which of the above key concepts are being addressed and how. For example, a project that addresses the fourth and last bullet could focus on code generation from high-level modal models, and demonstrate a design environment based on LabVIEW or Ptolemy II for an embedded target.

Software platforms can be "bare iron," real-time operating systems, embedded tools like LabVIEW Embedded or Simulink/Stateflow with Real-Time Workshop, or standard operating systems such as Windows or Linux. Attention to design quality and reliability and trustworthiness of the end product is essential. For many of the projects, it is highly advised to identify a mentor (typically a graduate student) who provides familiarity with the relevant hardware and/or software.

Guidelines for Project Presentations:

  • This year's presentations will be conducted as a poster session with demos. All presentations will be videotaped.
  • Time your presentation for 15 minutes; you can additionally present slides on a laptop but only as an auxiliary aid (e.g., to illustrate ideas that need animation). The main material must be on your printed poster. It's very important to finish on time. Practise your presentation several times.
  • Topics to cover:
    1. Overview of the project and your approach
    2. Hardware/software platform and tools used
    3. Main technical challenges -- in design or implementation -- and how you tackled them. Focus on the top 3, at most one slide on each. Include any cool algorithms or design insights that you came up with.
    4. Demo -- could be interleaved with the presentation or performed right after
    5. Finish with a 1-slide summary: what did you achieve, what more can be done?
  • Each slide must convey 1-3 key ideas; don't clutter the slide; use at least 20 pt font

Guidelines for Project Reports:

  • One report per team. Hard deadline: Tuesday, May 19, 12 noon. Submit on bSpace.
  • Recommended length: 5-10 pages, use at least 11 pt font
  • Topics to cover:
    1. Introduction & Problem Definition
    2. Outline of your Approach and how it compares to existing projects
    3. Algorithms and Formal Models used
    4. Major Technical Challenges in the Design/Implementation and how you tackled them
    5. Summary of Results -- what worked, what didn't, why, ideas for future work
    6. A one-paragraph narrative on the roles each team member played in the project
    7. How the project applied 2 or more of the key concepts from the course.
    8. Feedback: List of topics covered in class that came in handy; any topics that weren't covered that would have been useful
  • Illustrate algorithms and models with diagrams, include pictures of your hardware, screenshots, etc.
  • Keep the report short and precise; avoid lengthy and verbose descriptions!
  • You must submit your Peer Evaluation Form to Prof. Seshia or Wenchao in person, or on bSpace electronically.

Suggested Project Topics

The list below is a partial list of projects that we expect to finish adding to by Feb 20. If you want to pursue a project outside of the list, please see the instructor.
  1. Maze Traversing Robot: Students will build a maze-traversing robot using hardware such as Lego NXT with programming performed using LabVIEW.
    See for example, the Micromouse competition.
    Mentors: Hugo Andrade and Trung Tran.
  2. Persistence of Vision: Create a persistent display of some message in space through a moving platform -- say, a bicycle wheel with an array of LEDs mounted. The message must change with time, e.g., displaying the velocity of the wheel. This will be a hardware-intensive project involving interfacing to sensors such as accelerometers and/or rate gyros. Extend the basic POV display to generate sounds synchronized to motion.
    Relevant link.
    Mentor: Winthrop Williams / Isaac Liu
  3. Cooperative robot localization and mapping: Build a team of 2-3 iRobots to map out an area seeded with obstacles. The project will involve interfacing to relevant sensors and wireless communication amongst the robots.
    Mentor: Jeff Jensen.
  4. Autonomous Hunter/Prey: Program iRobots to perform a "pursuit-evasion" game where one performs a "hunter" role and the other has a "prey" role. The robots should operate autonomously without central computer input. Robots must have time synchronization, or receive (only) a heartbeat from a desktop computer. At predetermined intervals, Prey becomes vulnerable for a set period of time, during which it will send a response if hit by Hunter laser. Hunter must use responses to locate and bump into Prey. iRobots can communicate through Bluetooth.
    Mentor: Jeff Jensen.
  5. iRobot Hockey/Soccer: Two or more teams compete in a game of iRobot hockey or soccer. Coordinates of robots and puck/ball provided via Bluetooth. Equipment will include the iRobot Create interfaced to the Luminary board and a Bioloid arm, plus an overhead camera and controlling computer.
    Mentors: Jeff Jensen / Shanna-Shaye Forbes.
  6. Virtual presence through Rovio: Remotely control a robot that lets you see, speak and hear from anywhere.
    For example, one could use an eye-ware display (e.g., Myvu) and with accelerometer+gyroscope attached on one's head, one can control the camera position of rovio. A Wiimote can be use to control the motion of the robot (drive the Rovio). The whole system can be integrated through LabVIEW. Relevant link.
    It would be key to minimize the latency between issuing a control command (moving your head) to having the Rovio perform that task.
    Mentors: Hugo Andrade and Trung Tran.
  7. Collision avoidance: Use the infrared communication mechanisms and bluetooth wireless extensions of the iRobot Create + Luminary to design a multi-agent collision-avoidance strategy -- something like the collision avoidance used by aircraft.
    Possible Mentors: Isaac Liu, Man-Kit Leung
  8. Self-Parking Mini-Vehicles: Program a small mobile robot to park itself. We will define parking slots for cars as rectangular slots in usual way, but which could be marked by non-visual markers (e.g., optical beam instead of white lines). Cars would have to detect occupied slots and drive around until a free slot is found. Students could try both head-in parking and parallel parking.
    Mentor: Wenchao Li.
  9. Body Sensor Network: Use a network of inertial sensors to detect human postures and motion in real time. For instance, such a system could be used to automatically detect when the wearer is falling, in the context of health-care for the elderly. This project would cover topics such as sensor calibration, machine learning, and real-time response.
    Mentor: Wenchao Li.
  10. Real-time Game Playing using Network Time Synchronization: Demonstrate a real-time game using fine-grained time synchronization (IEEE 1588) on a testbed of networked Luminary boards. Examples of underlying problems involve distributed consensus where nodes have to agree on the current global state of the system.
    One possible "game" is based on music: have a "distributed jam session" where players at the different nodes play different instruments/tracks of a song, but all of the players must be able to hear the complete song.
    Mentors: Jeff Jensen and Slobodan Matic.
You are not logged in 
©2002-2009 Chess