18-642 Project 3
Page last updated 8/25/2019(changelog)
This project takes your code from Project 2 and asks you to take concrete
steps to clean it up. We ask you to follow a checklist, and to compare the
changes you make in project 3 to the ones you made in project 2.
- Please follow the handin naming convention: every filename (before the
file extension) must end in [AndrewID]_[FamilyName]_[GivenName].
- Don't forget to look at recitation slides!
- The turtle simulation is meant to represent a simplified PHYSICAL system.
That means spinning or moving takes time and space. Just because a simulator
lets you get away with something, such as spinning the turtle 360 degrees in
zero time while sampling sensors and teleporting across the maze does NOT mean
it is OK to do. There are rules you'll need to obey later in the semester that
enforce things like taking time to move, inability to go through walls, and
other properties of physical embedded systems and robots.
- The "Spaghetti Factor" is covered in a recorded lecture. We
recommend you watch that lecture early in the week BEFORE completing this
- Ensure that your ANDREWID_student_turtle.cpp in
~/catkin_ws/src/ece642rtle/student is at at working version (solves
the maze using either the left-hand rule or right-hand rule based on how you
did on Project 2. Revert to a working version using the source control you set
up, if need be. If you have to start with the initial code from Project 2
- Download and print out a physical version of the
Code style checklist (It's only one
- Go through the checklist and make changes to your code. Check the checkbox
after you make the change. You can do this in any order you like, but before
you check a box make sure that you've looked at all the code for compliance
with that checkbox.
- Note: You might or might not agree with all of these rules. The rules have
been carefully selected based on past semester problems we've seen with student
code to guide everyone to a reasonably consistent starting point for later
project phases. Later in the semester you'll have more flexibility. (In
industry there is often a house style sheet that everyone has to conform to
whether they like it or not. Consider this a microcosm of that type of
- In some cases the rules might not seem like overkill. This is because we
want you to get some practice in particular techniques even if the case for
using them is not compelling in such a short program. For example, while it is
certainly possible to skip typedefs in some cases, we want you to use typedefs
so you understand how they work. In larger programs the case for them is far
more compelling. So this is a way to keep the assignment size reasonable while
still exposing you to the concepts we want you to see.
- Note that in grading you can skip a few rules if you run out of time or are
unsure how to comply. You'll have to fix these later, so don't abuse this
- You are graded primarily on code style for this project (not on how your
turtle behaves at runtime). However, in future projects, you will be asked to
make sure that your turtle obeys the following rules. Deviate at your own
risk -- you'll have to clean up any messes before the end of the course! If
you change the functionality of your code, please keep these rules in mind (by
'Tick', we mean one call to studentMoveTurtle, or, in future projects,
- The turtle shall not move more than one adjacent square per call to tick.
- The turtle shall rotate at most 90 degrees per tick.
- The turtle shall either rotate or move, but not both in a single tick. (No
movement at all is also valid.)
- The turtle shall only move in the direction it is facing, which is in even
multiples of 90 degree increments.
- The turtle shall be facing the potential wall segment that it is calling
bumped for. (The bump sensor is in the nose of the turtle.)
- The turtle shall make at most one call to bumped per tick.
- The turtle shall not move through walls.
- Build and run your turtle using ./build_run_turtle.sh in the
- The rubric has points for correct build and execution. The turtle must
solve the maze. It does NOT have to follow the rules above for full credit in
this project. But it will eventually. So do your best. If you are
violating a rule and not sure how to resolve, see TAs at office hours to get
help now rather than at a deadline later where following the rules is
- In a text document, answer the following questions: (Generate text however
is convenient and legible; hand-in will be Acrobat)
- Your name. (If they are printed out, the file name info is lost.)
- Q1. What was the Spaghetti Factor of the module with the highest SF? If
any modules have an SF greater than 10, why? (Note that a "module" is
a single procedure or subroutine, and each module has its own SF number. It is
NOT necessarily all the code in a single .c file.)
- Q2. List the numbers of the checklist items that you had already attempted
on Project 2.
- Q3. Do you strongly disagree with any items on the checklist? Which ones,
- Q4. Is there anything important you think should be added to the
- Q5. You are permitted to not fix up to three checklist items. List zero
through three items you skipped. ("none" if you didn't skip)
- Q6. Would you change anything about Project 3? If so, what?
- A scan or photo (pdf preferred even if it is a converted photo; jpg and
png accepted) of your completed checklist. Call this file
- Your modified student_turtle.cpp file. Call this file
- Your answers to the questions. Call this file
Zip these three files and turn them in on Canvas as
Project03_[Andrew ID]_[Family name]_[Given name].zip
Please do NOT put these files inside a subdirectory. When
unzipped they should not have any directory associated with the file name, and
should just unzip into the current directory. (The file name convention will
retain whose work it is.)
The rubric for the project is found here.
BE SURE to use the rubric to understand what is expected on this hand-in; there
are many moving parts in this assignment!
- 8/25/2019 5:00PM: released