SDP final report guidelines
Subject to change as the term progresses

1. Introduction

The final component of SDP in time is the Final Report, consisting of two parts: a User Guide and a Technical Specification. The expected contents are outlined below.

2. User Guide

This document should explain how to use your system.

It should be targeted towards somebody at the level of a first year CS student, and should let this person fully understand how to take your code and your robot and get it playing football per the current rules.

It should include, organised logically (but not necessarily in the order listed here):

• How to install your code, and any dependencies, onto a standard DiCE machine
• An overview of your robot sufficient to understand it well enough to use it, in two parts:
  • Structural   Main components and their function: how it can move/grab/kick, what sensors it has
  • Use   How to turn it on, swap batteries, all the stuff a day-to-day user would have to deal with
• An overview of your DICE-resident software, including
  • How to get it running, including any required calibration
  • How to actually operate it, that is, everything you would need to do to play in a match
• A troubleshooting guide

3. Technical Specification

This document should explain what's in your system, and how it works.

It should be targeted towards somebody as knowledgeable as the average student when they start SDP, and should let this person fully understand how your system was built, and why it was built that way. It should leave this person knowledgeable enough to start maintaining and modifying your system.

It should include, organised logically:

• An overview of your system architecture (as distinct from its components), including design rationale and, if appropriate, history
  • How you choose your overall architecture
  • What it was based on
  • What motivated major changes, if any
• A description of the major hardware components of your robot, likewise
  • How you choose their features
  • What it was based on
  • What motivated major changes, if any
• High level documentation of the code on your robot (really high level, think diagrams rather than actual code)
• High level documentation of the code on your controlling PC (again, think diagrams and maybe pseudocode...)
• An overview of your vision, communications, planning, strategy, etc. subsystems, covering
  • How they work
  • What they were based on (i.e. any code you imported, libraries utilised, etc.)
  • What motivated major changes, if any
• For the comms subsection, you should list the full command set you use to communicate between your robot and PC
• You should also include, at an appropriate point, information on using the sensors on the robot, i.e. what data they provide, the format they provide it in, and how it is read and utilised.

Only the final version of anything needs to be thoroughly documented: You only need to document abandoned or superseded components or approaches sufficiently to explain why you moved on.