CS23 Winter'09 - Team project

The assessment of CS23 this term includes a major team project contributing 50% of each student's assessment. The project commences in week 6 of term, and culminates in a project demonstration of each team's project. Tentatively, the demonstrations will be held on Wednesday 11th March.

See also - (always under construction...)


Project overview

It's an ambitious project ...
Random J. Student

The project involves the development of software to control Garcia robots, our Martian Explorers, on the unexplored Martian surface.

The robots run a version of embedded Linux, that provides the necessary control, sensing, and communication facilities to achieve the goals of the project. Each robot is equipped with wireless networking facilities (WiFi) for communicating with the robot's remote command software, proximity sensors to detect the presence of nearby obstacles, and a basic color webcam to capture still images.

There are three requirements for the project's software -
  1. to determine the shape and area of an unexplored area of the Martian surface (Sudikoff corridors), and to map the perimeter of the environment and any significant obstacles located in the area.
  2. to locate a number of spherical Earth-energy-crisis-solving modules (tennis balls), and to herd them into the cargo bay of your Martian Lander spacecraft (a cardboard box) (see Clarifications) to move each one to see what's under them.
  3. to provide a simple graphical interface, running on a Linux or Mac laptop, that displays information about and from the robot, and accepts commands to control the robot.

The software running on the robot, and the software to run on your Linux or Mac laptop, will be written in the standard C99 programming language, and may make calls to the Linux operating system and the robot and networking APIs (which will be provided). The simple graphical interface, most of which will be provided, with be written in the Tcl/Tk scripting language, called from your C99 program.



The project teams

Projects will be undertaken in teams of 4 or 5. Each team member will be responsible for different components of the project. Team members will be evaluated on their individual contributions and the success of the entire project.

Team orange - Jonghoon Choi, Sam McIntire, Andrew Vartanian, and Johari Wiggins.
Team black - Alex Knapp, Zhifei Song, Lillian Xia, and Qianqian Zhao.
Team red - Katelin Bailey, Andrew Bloomgarden, Darren Cheng, Matthew Elkherj, and Nancy Zheng.
Team green - John Eikens, Kate Schnippering, Jingzhou Shen, and Jason Victor.
Team blue - Kathleen Champion, Alan Faubert, Mu Lin, James Mercado, and Ryan Speers.


Project goals and outcomes

While the project runs for short period of time it represents a microcosym of what you would find in the industry. Your project team has to design, implement, test and integrate a complex system in a fixed period of time. You have to quickly determine the strengths and weakness of your team and once the design is complete come up with a sound strategy to divide and conquer; that is, parcel out the implementation and work together to deliver good software and a robust solution that you must demonstrate.
The goals of the project are:


Project grading

The overall course grade for the project is 50%. The project grading is further broken down between: the overall design (20%), the implementation and demonstrated testing of code (40%), the demonstration of the system (20%), and the content (not visual appeal) of the team's webpage (20%).

Please note that all members of a team will receive the same grade unless there is some large imbalance in effort.

The fine print

To maximize the success of their projects, it is strongly recommended that teams undertake the following steps and practices:
  1. team members should hold and initial meeting, and discuss their perceived strengths and weaknesses that may affect the outcome of their project.

  2. there will be an introductory tutorial, describing the features of the robot and the provided software, and to clarify requirements, in our normal class time on Wednesday 18th February,

  3. teams should develop and maintain a webpage of their project. As the project evolves, the webpage must include:

    • the motivation for the project.
    • names of the team members.
    • a description of the project's requirements.
    • the initial software design and its rationale.
    • the initial project timeline.
    • the assignment of subtasks to team members.

    • a description of the final significant software components, their responsibilities, and their interfaces to other software components.
    • a description of data-flow throughout the software.
    • instructions on running the final software, including a full description of program arguments and configuration, expected format of any input files and directories, an explanation of the program's outputs, and an explanation of any anticipated errors or exceptional conditions.
    • a brief description of the approach taken, and a summary of the successes of the project.

    Any significant changes to the webpage, including modifications made in hindsight, additions, and deletions, must include the date and name of the person making the change.

    Your team's webpage will be linked to the CS23 course webpage, allowing you to show friends and prospective employers your work.

  4. teams should undertake several hours on the design phase - before any coding is undertaken. It is recommended that no coding be undertaken before your first team meeting with Chris McDonald. Once the majority of the design is completed, teams should initially divide the project into a number of subtasks, assign team members to undertake each subtask, and clearly record an estimate of the time to be devoted to each subtask. It is not essential that this step be performed in exacting detail but, at the conclusion of their project, teams should reflect on how well their initially planning went.

  5. teams should employ a shared, network SVN repository - to support the development of their code. In particular, SVN should be used to maintain a clear and consistent annotation of the project change history. Details of SVN repository names will follow.

  6. teams should hold at least two meetings per week - to report on their progress, and to plan activities to be undertaken before the next meeting. All team members should attend every meeting (unused class times and the X-hour should be available to all).

  7. one of the team meetings, each week, should be held with with Chris McDonald or Nick Foti. Their role is not to inject new ideas, nor to correct current plans, but to act as a devil's advocate and act as a sounding board for each team's ideas and approaches.

  8. during each team meeting, one team member should always act as the team's secretary (perhaps on a rotational basis). That person is responsible for taking minutes of the meeting, including the topics discussed, decisions taken, the delegation of new and continuing tasks, and the date/time of the next meeting. Each's meeting's minutes should be entered on the team's webpage (not during the meeting) and reviewed at the next meeting.

Good luck, you'll need some!
Chris McDonald, February 2009.