Differences

This shows you the differences between two versions of the page.

--- teaching:student-projects [2014/07/23 15:40] – [Schedule] tenorth
+++ teaching:student-projects [2021/08/30 14:22] (current) – removed pmania
@@ Line 1: / Line 1: @@
-====== How to organize a student project ======
-This page is intended to collect good practices for organizing student projects. They are based on the lessons learned in the SUTURO project, but will hopefully be extended with experiences made in other projects.
-===== Topic =====
-The SUTURO project was about developing a complete mobile manipulation application on the PR2. On the one hand, the students liked to work on this nice platform and to develop a complete integrated system. On the other hand, it was also a very complex scenario that bound many resources, so something slightly less complex may also be appropriate.
-===== Schedule =====
-We organized the project in the following way:
-  * **Early Spring:** Presentation of the project idea and a first rough schedule on how to proceed
-  * **During the summer semester:** Seminar with presentations by the supervisors on topics required for the project (in our case, knowledge representation, plan-based control, perception, manipulation), as well as tutorials and homework assignments. The pages of this seminar can be found [[teaching/se-kiba|here]]. The assignments aimed at familiarizing the students with the basic techniques and some of the software packages to be used during the project. It wasn't done by most of the students, but most agreed later that it would have been a good preparation.
-  * **Project kick-off:** At the beginning of the semester, we had the initial meeting including a more detailed plan on what was to be implemented and how this could be achieved. As supervisors, we had sketched a plan how we'd approach the task to check whether it appeared feasible and if all required components were available.
-  * The rest of the project was organized in **milestones every 4-8 weeks**. The first two were given by the supervisors, the following ones were defined by the students as part of the report on the previous milestone. This way, they could have influence on the content of the project, but had to commit to a fixed goal beforehand. Each milestone consisted of a live robot demonstration, a presentation of the software architecture and the components that were shown in the demonstration, and a written report.
-  * **Milestone 1:** The first milestone after two weeks was about setting up the project. It involved the software development infrastructure, the project organization (roles, meeting structure, rules for e.g. missed meetings, etc) as well as the detailed definition of the subsequent milestone. The two-week deadline was very tense, but force the students to start working together early in the project.
-  * **Milestone 2, four weeks later:** This largely pre-defined milestone was a maximally stripped-down version of the final goal. In the case of SUTURO, the robot was to touch an object that was considered edible. Achieving this milestone required collaboration of all groups, though each of the groups had to do only slightly more than what was part of the homework assignments. This milestone thus served as a test case for learning to organize joint software development, testing software on the robot, and familiarizing oneself with the software libraries to be used.
-  * **The following milestones** then incrementally increased the complexity until arriving at the final goal.
-===== Plenary sessions =====
-* One plenary session
-===== Internal organization of the student team =====
-===== Grading =====