Project 3: Adding a robot platform to the maze

To Deliver: release 5.0 in svn repository under tags directory, email with crc card design to your grader: Md Atiqur Rahman <mrahman@email.wm.edu> (Section 1), Jianhua Sun <jsun01@email.wm.edu> (Section 2).

To Download: /home/scratch/kemper/Robot.java and /home/scratch/kemper/RobotDriver.java

Due date for submission:    Oct 18

Drop out date:                     Oct 21, at 5 AM (EARLY MORNING)

Motivation

We want to prepare the maze code base to provide an API for maze exploration algorithms that will guide a "robot" out of the maze. 

The design idea is to have a layered architecture where robot driver algorithms operate on top of an abstract robot layer that operates on the overall maze. 

The robot driver algorithms, for example, a naive random search algorithm, implement a RobotDriver interface (as given in file RobotDriver.java). They depend on a robot (a class that implements the Robot interface as given in file Robot.java) to explore a maze and find the exit. The robot interface follows from what a Lego robot may provide for as sensors to recognize distant objects (here walls) and the ability to move forward, backward and to turn on the spot.

As a first step, we want to establish the Robot platform by providing some implementation of the Robot interface that works on the maze and the maze graphics (first person and map drawer classes). To see if concept works, we want to add a manual maze exploration with a class that operates on the robot implementation (and not directly on the maze object anymore). This will replace the existing manual maze operation. Note: The RobotDriver will drive the graphics (MapDrawer and FirstPersonDrawer) without being aware of this. The robot interface implementation needs to take care of this by operating on top of the Maze class.

We also want to compare algorithms (or performance of a human driver) in terms of energy efficiency to operate the robot. So there is a some energy consumption being involved in any movement and sensor operation and the robot draws energy from its battery on its journey. 

Operating the robot needs care, hitting a wall will damage it and will cause an emergency stop. 

We need to modify the final screen to report on the length of the chosen path and the amount of energy consumed.

The only robot configuration we will consider at this point is the following:

• It has 4 distance sensors, one in each direction (forward, right, left, and backward). 
• The robot can move forward and backwards. 
• The robot can turn.
• The initial battery level is 2500.
• The energy costs are: 
• Distance sensing in one direction: 1
• Rotating by 90 degrees (left or right): 3
• Moving forward or backward one cell: 5

What to learn from this project:

- Experience in test-driven design and limitations of testing when it comes to randomized algorithms and graphics. 

- Experience in establishing a hierarchical, layered design where each layer provides functionality in form of an API (an interface) to the layer above and with the help of own code and the API of the layer below.

- Refactoring existing classes to adjust to a modified class design

- Learn to work with exceptions

Design decision

To retain a reasonably uniform design, I would like to fix the following naming conventions for classes:

The class that implements the Robot interface is named BasicRobot.java. 

The class that implements the key functionality for the manual operation of a robot is called ManualDriver.java. (You can use more classes if you like, but use this name for the one that has the responsibility to drive the robot).

Classes that implement test cases for each class have the class name followed by suffix Test, e.g. BasicRobotTest.java for the BasicRobot.java class.

Note that we will only consider a default robot configuration with 4 distance sensors, one in  each direction. However, it may be straightforward to have a class that is configurable to have more/less/other distance sensors. Provide the class with at least one constructor that has no parameters and creates a robot with the default configuration we consider. For the automated drivers in the next project, we will consider robots with only 2 distance sensors (one forward, one to the left).

To do list:

• Copy the given interface files Robot.java and RobotDriver.java from /home/scratch/kemper (accessible within CS network).
• Perform a class design with CRC cards. 
• Note: there are several possible design solutions!   
• Put your crc design in writing, simple list each class, its responsibilities and collaborators. Email this to Han Li.
• In case you have mixed source code and test code, I would like to ask you to change this. In your Eclipse project, keep source code and test code separate. Use a separate source directory src for source code, another source directory test for test code. Both should then have the same package structure, here: a falstad package. 
• Implement BasicRobot.java and BasicRobotTest.java  classes
• You can use as many additional other classes, methods as you like. You can change the existing code base to make the integration of BasicRobot.java easier. 
• WARNING: perform the following sanity test: assign the starting location (0,0) to a maze when it is built in MazeBuilder, make the rotate method print its directions before and after the rotation, print for the initial location (0,0) in which direction potential walls on top/bottom/right/left are and compare this with the graphics on display in map mode. You will recognize an inconsistency in the interpretation of directions for rotate and the CW_TOP, CW_BOT directions used in MazeBuilder. BEFORE you make changes to the existing code, think why it can work the way it is and think twice before you want to stir things up … 
• For testing: ask yourself what a correct robot implementation must be able to support. 
• Implement the Manual Robot Driver algorithm with class ManualDriver.java and make this the one that is used by MazeApplication.java. 
• You can use as many additional other classes, methods as you like. 
• For testing: ask yourself what a correct robot driver implementation distinguishes from a faulty one. Manually exercise the game and see if you can operate the robot and play the game.
• Update your subversion repository whenever you made progress and got a particular feature or method going. 
• When you have finished the project assignment, create a tag with a Release 5.0 before the drop out date (due date is recommended for your own sanity). Include your junit test cases in your release. Keep source code and test code in separate directories (src and test). 
• Send CRC design description by email to Md Atiqur (Section 1) or Jianhua (Section 2). 
• Grading
• You will receive points for the CRC design description.
• You will receive points for a release 5.0  in a separate tags directory in your subversion repository that includes source code and test code and that can be checked out by the grader. 
• You will receive points for implementing the robot and the manual robot driver classes. Code is expected to have comments, at least a statement per method (using the javadoc format with /** …. */ ). 
• You will receive points for implementing test cases for the BasicRobot class. Test cases are expected to come with a comment that specifies what is tested, what is the correct behavior and (if not obvious) why that behavior is correct.
• You will receive points if test cases perform and your code passes our own tests. We will run and evaluate your tests as well as some additional ones of our own that will test BasicRobot.java based on the interface specification. We will evaluate your tests to see if they perform a rigid test and if they achieve a reasonable coverage on the tested classes.
• You will receive points if the overall MazeApplication runs with the manual operation operating on top of the robot class works,. This includes correct operation of the maze graphics that is displayed in the first person perspective as well as the map perspective with the current location and the suggested path to the exit (based on the distance matrix).