If you prefer, you may instead propose a variation on this task. For instance, you may want to start with an existing team and build a coach agent to control its behavior. Or you may choose to start from scratch and build a team entirely on your own. Or you may choose to create agents that can do some subtask of the full robotic soccer task (for instance, create a very good goalie or shooter). The instructor will do his best to provide you with the appropriate code to allow you to get to your proposed starting point. Expectations will be commensurate with the starting point you choose, so feel free to follow your interests.
You may work individually or as a team of 2 people. 2-person teams should only turn in one submission of the programming portion of the assignment. However, each person must turn in an independently-written proposal, progress report, and final report.
The schedule is as follows.
The proposal should be at least 3 pages double spaced. I prefer double-sided printing. Make sure you proofread and spell-check.The proposal should be written with the goal of convincing us that what you are proposing to do is interesting and non-trivial (though not necessarily completely original - see below). Connect the proposal to the class readings as much as possible. Members of 2-person teams should clearly identify what their roles will be with relation to the overall project.
The proposal will be evaluated primarily on written expression and coherence of argument. Feedback will be given both on writing and content. Please turn in two hard copies of the report at the beginning of class, and submit an electronic version via Canvas before class. Mark clearly at the top of each printed report whether your proposal is for a project in the 2D or 3D simulator. Reports that arrive after that (including partway through class) will be considered late.
It is completely legitimate to propose to do something based on something you read about provided that you are going to do the coding yourself. Just make sure to acknowledge any ideas (and code) that you borrow and be sure to clearly identify what you are going to do.
Based on experience from previous years, many of you will be tempted to do something using machine learning. That's fine. But be prepared for it to be on the frustrating side. It often takes a lot of infrastructure to get ML approaches working. My advice to those of you who want to try learning is to think carefully up front about what the inputs and outputs of the learning task will be. Proposals that say nothing more than "I propose to have a team learn using [insert-ML-technique]" will not lead to very constructive feedback. If you're going to use ML, propose to do so on some specific component of your team and try not to be too ambitious.
The progress report should be at least 5 pages double spaced. It should be written with the goal of convincing us that what you are doing is interesting and non-trivial, and that you are making progress towards your goal. It is expected that a good portion of the progress report will be identical to the proposal. Members of 2-person teams should clearly identify what their roles have been and will be with relation to the overall project. The progress report will be evaluated primarily on written expression and coherence of argument. Feedback will be given both on writing and content.
Please turn in two hard copies of the report at the beginning of class (double-sided printing is preferred), clearly marking at the top of each report whether your project uses the 2D or 3D simulator. Reports that arrive after that (including partway through class) will be considered late. Also, turn in an anonymized electronic version of your progress report, as this will be used for the double-blind peer review. Leave the paper's title intact on your anonymized version (unless it is identifying) and be sure to clearly note somewhere in your report whether you are working with the 2D or 3D simulator (you should be doing this anyway) - both of these will help us match reviews with authors. In addition, turn in your graded proposal with the progress report.
- A logfile demonstrating your progress (preferably showing a whole team on the field doing something). You only need to submit one logfile per team. Also PLEASE COMPRESS your logfile before turning it using a command such as:
tar -czvvf sparkmonitor.log.tar.gz sparkmonitor.log- An electronic version of your progress report (non-blind, pdf format).
- An electronic version of your progress report with your name, partner name, team name (if revealing), etc anonymized. Name this file blind-[first_words_of_your_title].pdf.
To turn in your logfile, progress report, and blind-review version of your progress report, use Canvas. When the logfile and pdfs are there, send us an email to that effect. In your email, be clear as to who your partner is (if you have one), and whether your project uses the 2D or 3D simulator.
You will receive two progress reports to review via email on or before November 6th. These reviews will be double-blind - you will not know whose paper you are reviewing, and they will not know who reviewed their paper. Your reviews will be evaluated primarily on written expression and quality of feedback to the authors.
Your peer reviews should comment on both the positive and negative aspects of the progress report. Some possible questions to answer are as follows. What parts were particularly clear and effective? What parts left you confused? Did the introduction make the goals of the project clear? Is there a clear indication of what has been accomplished so far, and what remains to be finished? Could you tell what the biggest risks of the project are (what may or may not work)? Is there a clear evaluation plan? Most importantly, what are your suggestions for improving the report? Please be as constructive and as detailed as possible.
To turn in your reviews, email them to us in plain ascii text in the body of an email (ie, not as an attachment). Please just respond to the email we sent you when we assigned the papers. Be sure to include the paper's title and number at the top of each review.
To turn in your logfile and code, use Canvas. When the assignment is there, send us an email to that effect. If your code does not run, the instructors will contact you ASAP to remedy the situation. If you don't expect to have time to fix bugs at that point (for instance because you're still working on the final report), make sure it works the first time.
Page maintained by Patrick
MacAlpine
Questions? Send me mail