• The results of your project are to be captured in a written document of 10 to 20 pages and are to be presented orally, with slides.
• You may, if negotiated with me in advance, use your work to extend or complement the work you do within some other project.
• You are welcome to work together in teams, just like in the real world. However, separate written work and oral presentation are to be done, as everyone is to have that experience.

A 1-2 page proposal will be due in class on the Wednesday after spring break (March 29^th), or to the course secretary, Peggy Edwards, at rm 37-367 by the end of March 29th. I would encourage you to give me the description before Spring break, in which case I'll give you prompt feedback so you can begin progress on your project immediately. Please give me your description in class, drop it off with Peggy Edwards, or drop it in the slot outside my door at 37-381.

A schedule for project presentations is to be determined. Students doing projects should come together outside of normal class hours to debug their presentations.

Additional Readings

A list of additional readings has been added to the web pages that goes beyond those papers associated with the course lectures. This list of readings was recommend by top researchers in autonomous systems, planning and scheduling, propositional reasoning and search, constraint and reactive programming, Bayesian inference, model-based reasoning, hybrid systems.and formal verification.

Projects can be, but are not limited to, any of the following types:

• A simulated area exam. This concept may only be familiar to Course 6 students. You read several papers and do a scholarly critique. Part of the process is to pick a set of dimensions along which to compare and contrast the papers. Hopefully you move beyond the comparison to an interesting proposal for how the research approaches can be synthesized. You conclude with a description of the degree to which you are moved, and why.
  
  For example, you could contrast the work of J. Pearl (Bayes nets) with that of L. Zadah (fuzzy sets), viewed as efforts aimed at intelligent monitoring and control; you could compare various recent papers on planning based on propositional encodings, plan graphs and model-checking; or you could contrast techniques for tracking hidden Markov models both from the POMDP and model-based reasoning literature. When you have a rough idea of what you might want to do, I can perhaps recommend particular papers. Feel free to send email to me (williams@Mit.edu) with "16.499 project advice" in the subject line.
  
  The simulated area exam is your safety net; if your other attempts do not work out, or you just cannot identify something you want to do, this is the sure-fire, finite time, still highly educational, way out.
• A research proposal. You propose a mechanism by which an intelligent embedded system performs some clearly defined task. You write your idea up in the form of a thesis proposal or funding proposal, with all the usual parts expected of such proposals.
  
  One way to generate ideas is to write a set of paper names from the course on slips of paper, put them in a hat, and draw two at a time, asking if they make any sense.
  
  For example, you might draw a Brooks paper and Kaebling paper and ask how Reinforcement Learning might be folded into the subsumption architecture, or draw a model-based diagnosis paper and a formal verification paper, and ask how formal verification may be used to verify diagnostic models.
  
  If you get inspired and passionate about something, you might just find yourself with a real thesis proposal when you are done with this. After all, Dave Huffman discovered Huffman coding while doing a term paper in Bob Fano's information theory class.
• A reimplementation. You pick one of the papers that describes an implemented idea for controlling embedded systems and you reimplement it, reporting on the surprises that emerge as you understand the work at the level required to write code. You also report on improvements you make.
  
  For example, you could redo any number of the papers presented or to be presented in the course: a model-based diagnosis system, a temporal planning and execution capability, a system for solving POMDPs, …
  
  A reimplementation is risky, because everyone seems to overestimate what they can do by the end of the semester. On the other hand, if sufficient detail is given, and you are a good coder, this can be a lot of fun.
• A novel intelligent embedded system. This is closely related to reimplementation, but involves both technical innovation and implementation. You pick one or more methods from the papers you've read, perhaps find implementations available over the web, and you design and implement a novel intelligent embedded system. You demonstrate this capability in simulation, or if real ambitious, on real hardware. You report the innovations of the design and any experimental results and findings.
  
  For example, you might want to prototype a soccer ball size micro-spacecraft that navigates around space station, looking for leaks in its hull. You might focus on the path planning problem, evaluating a variety of the path planning algorithms such as PLR, or you might try different approaches to reactive control, such as Brooks Subsumption architecture or Jim Firby's Raps system.
  
  This is even more risky than reimplementation, particularly if you plan on integrating with a real system. Using a simulator is much safer, but still risky. This is beyond the call of duty. You might accomplish more by working in teams, but then you are exposed to weak-link problems exacerbated by the part-time, conflicting pull nature of student labor. Caution is advised, along with especially clear and modest goals. On the other hand, if you succeed this can be extremely rewarding. Once you come up with an idea I might be able to suggest places where you can get code or additional papers.