Skip to content

Project Policies

Grading

The project is worth 5% of your grade. Here is a breakdown of the pieces of the project, as portions of your final grade:

Weighting Component
1% Design doc
1% Final presentation
3% Evaluation rescues

The 3% that comes from grading rescues is determined by ranking everyone for how they did on all inputs, then grading based on each group's average rank. A leaderboard will be kept using Gradescope for the evaluation rescues, which will tell you your approximate position among the class.

We think that everyone in the class should be able to get 3% without too much work - putting some effort in the project will show in your design doc and final presentation, and you will be able to pick up an additional 1% on evaluation.

Timeline

Day Released Due
Monday 4/8 Spec
Monday 4/15 Skeleton Groups
Monday 4/22 Evaluation rescues Design doc
Monday 4/29
Monday 5/6 Evaluation rescues, Final presentation

Assignments

Groups

Please sign up your group by 4/15 using this google form. You must submit this form, even if you are working alone. We assign group tokens using this form, and if you do not submit this form by 4/15 you will not be able to be evaluated.

Design Doc

Please write and submit to Gradescope 1 page answering the following questions:

  1. If there was a Guavabot on every node, what sequence of scouts and remotes would you do to get them all home?
  2. More generally, if you knew where all the bots were, what sequence of scouts and remotes would you do to get them all home?
  3. If you didn't care about getting the bots home and just wanted to find their locations as quickly as possible, what sequence of scouts and remotes would you do?
  4. What ideas do you have for solvers? Please provide at least 2. What are their advantages/disadvantages?
  5. What kinds of inputs do you think your solvers will do well on? Do poorly on?

There are no right answers. This is different than a homework problem: we are not grading this on correctness, just on effort and answers that show some understanding of the problem. This is your time to think of interesting ideas and write them down, you can test them with the test inputs later.

You don't have to write LaTeX if you don't want to. Any neatly typed report PDF is fine. The names of all group members should be on the PDF.

For grading, we will give you 1% if the design doc looks good and 0% if we think it needs some work. We will send you an email if you are given a 0%, and if you meet with us you can get the 1 if you don't want to. Any neatly typed report PDF is fine

Evaluation Rescues

3% of your grade will come from a set of evaluation outputs. (These are common to the entire class.) We will drop the lowest 12% of your evaluation scores. If you complete any evaluation rescue by 5/1 at 11:59pm, we will drop an additional 1% of your evaluation scores. In this case, "complete" means submitting a token with your score(s) on the Gradescope leaderboard assignment.

WARNING: YOU CAN ONLY BE EVALUATED ON EVERY OUTPUT ONCE. We will not create additional outputs for fairness for the class, so you should run the evaluation outputs once you are confident in your solver. Again, for fairness we cannot give you more outputs.

The skeleton will warn you when you are running on evaluation rescues, and it only lets you run some number at a time. We highly recommend you start evaluation early, and evaluate at a good pace leading up to the deadline.

When you run on some evaluation inputs, the API gives you a submission token describing how you did. Submitting that token to Gradescope updates the leaderboard, showing you how well you are doing compared to other students in the course. YOU ARE ONLY GRADED ONCE YOU SUBMIT THE TOKEN TO GRADESCOPE, YOU WILL NOT RECEIVE ANY POINTS FOR EVALUATION RESCUES CONDUCTED AFTER THE DEADLINE.

Evaluation rescues will all be released on 4/22, and all evaluation rescues will be due on Monday 5/6.

Final Presentation

During the Friday of the last week of lecture and Monday and Tuesday of RRR week, we will hold final presentations. These are for us to get a sense of how the project went for you, what approaches you tried, what worked and didn't work. Your entire group must be present, otherwise you will not receive full credit.

Outline

Please submit a short outline 3 hours before your presentation answering the following three questions:

  1. Describe briefly what you implemented for your solver (describe at least one and at most three approaches you considered/attempted)
  2. Explain which of your approaches worked best, and why you believe it did so.
  3. Explain how you'd refine your current algorithm to improve its performance, if you had more time.

You will lose points if you do not submit this outline.

Signing Up for a Final Presentation

Make sure you are signed into your Berkeley email for the following.

If you are at all late or miss your slot, sign up for a new open slot on the spreadsheet -- do not ask TAs individually whether they can make time to have you present to them, as you'll potentially make other groups have to wait.

  1. Find your 3-digit group number from the student IDs of your group members from this spreadsheet. If something looks wrong, email cs170@

  2. Use this spreadsheet to sign up for a slot.

    • Write your team number and one team member's name in the slot you wish to sign up for by Thursday 11:59pm.
    • Slots are first-come, first-serve, so you should do this ASAP
    • Each row in the spreadsheet corresponds to a particular TA, room, and block of time.
    • Each column corresponds to an index into that time block in 5 minute intervals.
    • For example if my row says: "F 5/3: 9am - 10am (Wozniak Lounge) | Max," and my column says ":20," then I will be presenting to Max from 9:20 till 9:25 on Friday in the Wozniak Lounge.
    • Do not overwrite another group's sign ups. We will be monitoring the edit history, and anyone caught doing so will receive a 0 on this portion of the project.

  3. Each presentation is only 5 minutes long so show up at least 5 minutes before your slot so that you can find your TA in the room and we can ensure everything runs smoothly.

    • In the previous example, I should arrive at the Wozniak Lounge by 9:15 to make sure I can figure out where in the room Max is (We recommend taking a look at the staff photos beforehand to make this easier).

If your entire group cannot make any of the times, please email cs170@

Presentation

During the 5-minute presentation, a TA will ask you about these three questions, and gauge if all group members can adequately answer to them.

All group members should be prepared to answer any questions the TA may have about their solver. Please fully understand your own algorithm and why you decided to use it.

Collaboration and External Resources

Here are some rules and guidelines to keep in mind while doing the project:

  1. You can collaborate freely within your group.
  2. No sharing of any outputs, in any form
  3. No sharing of code, in any form. This includes making public forks of the skeleton on Github and modifying them. Please keep your repositories private.
  4. Informing others about available libraries is encouraged in the spirit of the project. You are encouraged to do this openly, on Piazza.
  5. Informing others about available research papers that are potentially relevant is encouraged in the spirit of the project. You are encouraged to do this openly, on Piazza.
  6. Informing others about possible reductions is fine, but treat it like a home-work question - you are not to give any substantial guidance on how to actually think about formulating the reduction to anyone not in your team.
  7. As a general rule of thumb: don’t discuss things in such detail that after the discussion, the other teams write code that produces effectively the same outputs as you. This should be a general guideline about how deep your discussions should be.
  8. If in doubt, ask us. Ignorance is not an excuse for over-collaborating.

You may only use free services (academic licenses included). This includes things like free AWS credits for students. If you use AWS or any other cloud computing service, you must cite exactly how many hours you used it for in your project report. We should be able to replicate the results that you cite. If you use any non-standard libraries, you need to explicitly cite which you used, and explain why you chose to use those libraries. If you choose to use the instructional machines, you may only use one at a time PER TEAM. Anybody who uses multiple instructional machines will receive a zero for the evaluation part of the project.

As a final note, as staff, we generally trust that students will make the right decisions when it comes to academic honesty, and can distinguish collaboration from cheating. However, we’d like to point out that what has made this project so interesting in the past is the wide diversity of student approaches we observe to a single problem. We could have elected to give you yet another problem set, but we believe that the open ended nature of this project is a valuable experience for students to have. Do not deprive yourselves or us of this by over-collaborating or simply taking the same approaches you find your peers using.

If you came here from Getting Started, we recommend checking out the skeleton details!