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
-
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:
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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:
- Overview of the project and your approach
- Hardware/software platform and tools used
- 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.
- Demo -- could be interleaved with the presentation or performed right after
- 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:
- Introduction & Problem Definition
- Outline of your Approach and how it compares to existing projects
- Algorithms and Formal Models used
- Major Technical Challenges in the Design/Implementation and how you tackled them
- Summary of Results -- what worked, what didn't, why, ideas for future work
- A one-paragraph narrative on the roles each team member played in the project
- How the project applied 2 or more of the key concepts from the course.
- 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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
|