Final Project Information

The final project will be your opportunity to take what you've learned in the class and put it towards an application of your choice.

Here are some guidelines:

  • The projects should demonstrate a high level of understanding and functional ability to use the tools of the class.
  • A good level to aim for is: work comparable to a published research paper from the past 10 years. Reimplementing published work, perhaps with your own approach (or on a different system) can be very valuable.
  • Previous years' final projects have even evolved into published work. For example: Feedback Control of the Pusher-Slider System: A Story of Hybrid and Underactuated Contact Dynamics
  • The provided simulation environment via Drake will provide a good framework in which to develop final projects.

In previous years, it has been very popular to choose some set of tools from the class and apply them to a new problem or model that you think is interesting: for example, applying LQR-RRT* to bicycles, or developing a mode-switching controller for longboarding. But you're encouraged to think big and go beyond direct application in creating your projects. For example, each of these high-level questions or directions could lead to many interesting projects:

  • Experiment with a novel (ideally computational) control approach for one of the model systems described in class. In particular, the acrobot, compass gait, and perching glider systems all have relatively accurate models which we could provide, and if you demonstrate very nice performance in simulation then we could potentially allow you to try implementing your idea on our real robots.
  • Those familiar with both LQR and Kalman filtering might recognize that they're very similar in spirit -- and, in fact, are deeply related. What other approaches from underactuated control can you make work for state estimation? What are the "dual" state estimators of sampling-based or trajectory optimization controllers/planners?
  • Value iteration is excellent for generating controllers for systems with very complex dynamics, but scales poorly with state space dimension due to its need to densely sample in state space. Consider applying value iteration to higher-dimensional systems. Can you come up with more efficient ways to partition state space to make value iteration work for 10+ dimensional systems?
  • Value iteration produces an (approximate) global policy for a given system, but does not store it efficiently. Given a system on which value iteration works consistently, can you find a principled way to translate the sampled optimal policy into a minimal (and hopefully more intelligible) description? What if the optimal policy is discontinuous?
  • Experiment with a computational control approach that we did not cover in class on one of the model systems described in class. Interesting examples might include: trajectory optimization via CHOMP or DMOC (google will know the acronyms), or different trajectory stabilization algorithms.
  • Perform region of attraction estimation on a real robot (e.g., for an LQR stabilization task). There are natural ways to incorporate uncertainty into the verification (just ask the staff). What types of uncertainty do you need to include to get a reasonable verification of the true system?
  • Robust hybrid limit cycle stabilization. In practice, we often artificially turn down the gains of a periodic LQR stabilizer around impact to avoid small errors in sensing the collision to cause large errors in performance. Can a robust periodic stabilization generate this behavior automatically, if we introduce time-of-collision uncertainty in the model?
Many of you will be able to do a project that is closely related to your current research. This is completely acceptable, as long as the subproblem you are solving for this class is clearly defined. If you plan on doing a team project, please make this clear in your proposal. The course staff will provide you with feedback on the scope on direction of your proposal shortly after we receive it.


  • A short project proposal is due on Wednesday, April 11th, as part of Problem Set 4.
  • Brief (1-paragraph) project updates are due on Wednesday, April 25th (as part of Set 5) and Wednesday, May 9th leading up to the presentation week.
  • A 5-minute presentation of your results on Tuesday, May 15 or Thursday, May 17 -- schedule TBD.
  • A final paper summarizing your reports, along with any code you'd like to provide (we'll love it!) is due on Friday, May 18.
  • Projects can be completed in small groups, but the expectations for projects will scale linearly with group size. Each member of the group will need to be able to point out specific interesting contributions that demonstrate mastery of the course material.
You'll be in communication with the course staff throughout this progress -- we can help you come up with project ideas, refine your proposal, debug issues, or whatever else you need! There will be no assignments during the project period, so your full attention can be on enjoying the lectures and working on your project.


The project proposal is intended as a forcing function for you to crystalize a project idea, and gives us a chance to offer feedback to help you make sure it's worthwhile but feasible. It should be approximately one page (< 500 words) detailing your idea for the project. It should:
  • Define exactly what the project deliverable is.
  • Briefly describe why the project is worthwhile and interesting.
  • Discuss any related prior work you have found that is relevant. (This is especially important if you're replicating previous work or applying it to a new system!)
  • Define specific goals that you expect to have accomplished before each of the progress updates.
It doesn't have to be extremely polished, but it does need to provide us with enough information to understand what you're hoping to do. Otherwise, we won't be able to help you!

Progress Updates

We'll expect 1-paragraph project updates on May 2nd and May 9th in order to keep us up to date with how you've progressed.


The last two days of class (May 15 and May 17) will be dedicated to students presenting their projects. Each presentation will be given a 3-minute slot during which you will present to the class what you accomplished. Precise scheduling will be determined closer to the presentation dates.

Final Paper

We expect you to provide a final report of your project by 11:59pm on Friday, May 18. Using the IEEE template for conference proceedings (probably the Latex one, unless you really enjoy using MS Word), write a summary of what you accomplished during your project. Write it, as much as possible, like a conference paper -- you should include:
  • An abstract.
  • An introduction of your project and why you think it is interesting.
  • A related work section (at your discretion -- this part will depend a lot on the nature of the work you do).
  • Your results (partial or work-in-progress results is expected, and fine!).
  • A discussion of your results and potential next steps.
We don't have any requirements on length, but realize that this is worth a very large portion of your overall grade, so be as thorough as possible in demonstrating mastery of the course material. For reference, reasonable lengths could be anywhere between 3 and 8 pages, with figures and a few citations where relevant. Videos are encouraged as well, as a way to showcase simulation / hardware results and provide visual explanation.