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.

Lab Files:

Hints/Helpful Links:


  1. Try out the new mazefiles on your turtle (link). Notes:
  2. Spend some time verifying documentation, code style, traceability, and unit test coverage:
    1. Make sure your requirements are up-to-date and consistent with your implementation.
    2. Make sure your sequence diagrams are up-to-date and consistent with your implementation.
    3. 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.
    4. Make sure your non-statechart design documentation (e.g. flowcharts) is/are up-to-date.
    5. 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).
    6. Make sure your unit tests fulfill the transition, branch, and data coverage requirements of Projects 8-9, and that they all pass.
    7. 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 the course.
  3. 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:
    1. ANDREWID_turn_monitor.cpp: update or use as-is from previous project.
    2. 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.
    3. 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.
    4. 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).
    5. 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 bumped(...).
    6. ANDREWID_solved_monitor.cpp: If the turtle has solved the maze (atEnd(x,y)==true), it shall not move or turn
    7. ANDREWID_atend_monitor.cpp: Turtle shall only call atEnd(x,y) if it is at a position x,y.
    8. 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.
    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.
    The number of times the turtle visits a cell has been intentionally left off the required monitors.
  4. Perform a peer review:
    1. Your Project 10 peer review groups can be found on Canvas.
    2. Follow the same procedures as in past peer reviews, including creating your own peer review checklist suitable for checking the monitor design.
    3. Focus on the runtime monitors for this project. Primarily design is what matters, but including code in the scope of the review is fine too.
    4. Fix any issues that come up in peer review. Note that this is explicitly on a rubric -- do not blow this off!
    5. 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.
  5. Create build package similar to the one for previous projects, meeting the following requirements:
  6. 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:

Handin checklist:

Hand in the following:

  1. A release candidate build file: ANDREWID_P10.tar.gz or ANDREWID_P10.tgz
  2. Your collected design documentation (everything that's not code), which should be in a single acrobat file called: p10_documentation_[AndrewID]_[FamilyName]_[GivenName].pdf
  3. Your writeup, which should be in a single acrobat file called p10_writeup_[AndrewID]_[FamilyName]_[GivenName].pdf

Zip the files and submit them as P10_[Andrew ID]_[Family name]_[First name].zip.

The rubric for the project is found here.