18-642 Project 10
Page last updated 11/25/2019 (changelog)
This project wraps up the ece642rtle you have been working on all semester.
You will write several new runtime monitors to check new invariants. You will
also do a final check of code style, documentation, and traceability.
- There is an in-class exercise to review your turtle source code again in
class. Be sure you are ready for it with the updated maze-solving source code!
- There is no checkpoint for this project. It has about two
weeks of heavy project work spread over 2.5 weeks of university class meetings.
Note that homeworks and recitation workload has ramped down to give you more
time for the project.
- You should get all the monitors working on all the majors (perhaps with a
couple loose ends) by the end of the FIRST week, and use the remaining time for
documentation cleanup and creating the build package.
- When you get into the real world (pretty soon for some of you) you'll be
expected to manage your time wisely. Here's a chance (or another chance) to get
- It is a stupendously bad idea to wait
until the last minute on this project. Seriously --
- You will need to get all the example mazes working, as well as create
- THIS PROJECT COUNTS DOUBLE (i.e., this is in effect a double-size
project, and the project score will be counted as two project grades in
- You can use your one "free late" on this project if you wish to
do so, and it will apply to the entire project grade even though it is doubled.
- If you submit after 8:30 AM on the last day of classes (Friday morning
day after Exam #2), we will assign you an "Incomplete" course
grade due to limited TA availability to grade your project. If you are
expecting to graduate this semester it would be a really bad idea to test that
- If there are problems with your build process you will need to make an
in-person meeting with a TA to resolve things. Make sure your build works!
- $ECE642RTLE_DIR refers to ~/catkin_ws/src/ece642rtle (or
corresponding project workspace).
- Please follow the handin naming convention: every filename (before the
file extension) must end in [AndrewID]_[FamilyName]_[GivenName].
- Recitation on Project 10
- Try out the new mazefiles
on your turtle (link). Notes:
- Mazes m1-m6 in this folder are the same m1-m6 that you have seen in
previous projects. m7-m10 are new.
- Put the mazes in the $ECE642RTLE_DIR directory.
- All of these mazes are your acceptance tests -- your turtle shall solve all
mazes m1-m10 to get the corresponding points for Project 10. Furthermore, some
or all of these mazes will be used by the graders to check for invariant
- Spend some time verifying documentation, code style,
traceability, and unit test coverage:
- Make sure your requirements are up-to-date and consistent with your
- Make sure your sequence diagrams are up-to-date and consistent with your
- Make sure your statechart(s) is/are up-to-date, with an initialization
arc, labeled states and transitions, and an input/output/internal variable
table that is consistent with the variables in the statechart.
- Make sure your non-statechart design documentation (e.g. flowcharts)
- Make sure your statechart and requirements are fully traceable to each
other, and make sure your code is traceable to the statechart (all transitions
have an annotation comment in the code).
- Make sure your unit tests fulfill the transition, branch, and data
coverage requirements of Projects 8-9, and that they all pass.
- Make sure your code compiles warning-free with the full set of warnings
used in previous projects and follows the good code style practices laid out in
- Write some monitors for some new invariants. Refer to
Project 9 for reminders on how to write and
compile these monitors. It might be helpful to factor out some functionality in
a utility file, such as ANDREWID_monitor_utils.cpp. You should also
use the structured types defined in
$ECE642RTLE_DIR/monitors/monitor_inteface.h. You are required to write
the following monitors:
Your code shall use the ROS_WARN function to indicate an invariant
violation. You should use ROS_INFO to print out any relevant
information for your monitor to display. You can use ./run_642_monitors
with any number of arguments to run a subset of all the monitors at once
and observe the violations in VIOLTIONS.txt. You can also use the
command rqt_console to view and sort ROS logging messages. Take note
of any invariant violations. Are they due to the turtle code or due to bugs in
your monitor(s)? If the latter, fix the bugs. In rare cases, ROS timing issues
might give you false positives if messages arrive out of order. If you see
these, use the message timestamps in the log to argue that the violation is a
false positive in the write-up. Fix any invariant violations.
- ANDREWID_turn_monitor.cpp: update or use as-is from previous
- ANDREWID_tick_monitor.cpp: between calls to tickInterrupt, there
shall be at most one call to each of poseInterrupt, visitsInterrupt, and
bumpInterrupt. tickInterrupt occurs after every call to moveTurtle, so this
effectively checks that your moveTurtle only makes one of each type of call.
- ANDREWID_forward_monitor.cpp: the turtle shall face the direction
it is moving. In other words, if the turtle moves from square A to square B,
and square B is direction DIR (example: east) of square A, the turtle must have
been facing DIR before moving.
- ANDREWID_wall_monitor.cpp: the turtle shall not go through walls
- Recall that the monitor connects to the system and eavesdrops on ROS
messages, so it does not actually have a ground-truth of the maze. Because of
this, a more precise definition of our invariant is: given a turtle that has
gone between squares A and B that share an edge E, we view an invariant
violation as: turtle has not checked the given edge E bump() before
crossing it, OR turtle has checked the given wall segment E for bumped()
, which returned true, and turtle still crossed it. In other words,
the turtle must have seen bumped() return false for E some time in the
past before going from A to B. This suggests that, every time your monitor
sees a bumped() call, it will have to store it for lookup later.
- You can simplify this approach by putting a bound of how many past
bumped() calls your monitor keeps track of. For example, if your
turtle implementation always checks bumped() before moving, you only
need to keep the last bumped() call stored. Similarly, if your turtle
spins and checks four directions for bumps before moving, you only need to keep
the last four bumped() calls stored.
- Note that, geometrically, the line segment between (0,1) and (0,2) and the
line segment between (0,2) and (0,1) are the same. Also, because all walls in
the maze run parallel to the x- and y- axes, either both x- or both y-
coordinates of each wall segment will be the same. We therefore suggest you
store your line-segments in a canonical format to make it easy to compare two
line segments: dictionary order, or all line segments fulfilling ((y1==y2
&& x1 < x2) || (x1==x2 && y1 < y2)) is a good one.
- Our implementation used a fixed-size circular queue (statically declared
array) and two main helper functions: Endpoints wallBetween(Pose p1, Pose
p2) and bool bumpedInMemory(Endpoint e).
- ANDREWID_face_monitor.cpp: for any call to bumped(x1,y1,x2,y2), the
turtle shall be facing the wall segment with endpoints (x1,y1) and (x2,y2). As
a hint, note that this means there is only one valid wall segment that the
turtle can call bumped(...) for any given position and orientation. You might
consider computing this valid wall segment and comparing it to the arguments of
- ANDREWID_solved_monitor.cpp: If the turtle has solved the maze
(atEnd(x,y)==true), it shall not move or turn
- ANDREWID_atend_monitor.cpp: Turtle shall only call atEnd(x,y) if it
is at a position x,y.
- Note that "step_monitor" must be included in your system.
You get points for not violating it, but no points for design/implementation
since we gave it to you.
The number of times the turtle visits a cell has been intentionally left off
the required monitors.
- Perform a peer review:
- Your Project 10 peer review groups can be found on Canvas.
- Follow the same procedures as in past peer reviews, including creating
your own peer review checklist suitable for checking the monitor design.
- Focus on the runtime monitors for this project. Primarily
design is what matters, but including code in the scope of the review is fine
- Fix any issues that come up in peer review. Note that this is explicitly
on a rubric -- do not blow this off!
- Optionally (no credit, but permissible collaboration within your
peer review group), spot check each other's documentation paper trail (high
level design, detailed design, unit tests) for holes before you hand in.
- Create build package similar to the one for previous
projects, meeting the following requirements:
- When unpacked, a single command runs all unit tests with all compiler
warning flags and all run-time monitors enabled. ANDREWID_build.sh
- A command runs acceptance test on a maze k with all run-time monitors
enabled, where "k" is an integer 1..10: ANDREWID_run.sh k
- Writeup: Do a final check that the turtle solves the mazes,
and a final check that your testing and documentation is up to date. Include
the following in a writeup:
- Q1: Give step-by-step directions for setting up and running your release
candidate build. Generally this involves downloading a clean course virtualbox
image, creating a directory (what name, where?), expanding the tarball file
(where?) and entering the commands ANDREWID_build.sh and
ANDREWID_run.sh (from what directory?) Also say where/how we should
look to ensure that your run did not generate any monitor warnings. We
strongly suggest you do a completely clean trial run before
handing in. Even if you make one little last change without re-testing it could
break everything. If this is broken you'll need to hand back in with a late
- Q2: Did the new maze files or new invariants catch any issues with your
implementation? If so, what?
- Q3: Did you get any invariant violations? If so, briefly explain how you
know that these are due to your turtle behavior and not due to bugs in your
runtime monitors themselves. If you believe a violation is due to ROS timing
issues, make the argument here.
- Q4: What one software engineering process or practice from Projects 1-10
do you think is the most important one to apply to your own work beyond this
course, going forward?
- Q5: Any feedback about Project 10, or any projects?
- Include your design documentation package in your handin, including peer
review materials (see rubric; per hand-in checklist this will be a separate
Hand in the following:
- A release candidate build file: ANDREWID_P10.tar.gz or ANDREWID_P10.tgz
- Your collected design documentation (everything that's not code), which
should be in a single acrobat file called:
- Your writeup, which should be in a single acrobat file called
Zip the files and submit them as P10_[Andrew
ID]_[Family name]_[First name].zip.
The rubric for the project is found here.
- 10/19/2019: issued with various changes for 2019
- 11/25/2019: clarified that writeup should address both
ANDREWID_build.sh and ANDREWID_run.sh