112 lines
5.1 KiB
Markdown
112 lines
5.1 KiB
Markdown
# Toy Robot Simulator
|
|
|
|
## Problem Statement
|
|
|
|
Initial problem description taken from https://github.com/xandeep/ToyRobot.
|
|
|
|
Create a library that can read in commands of the following form:
|
|
|
|
```
|
|
PLACE X,Y,DIRECTION
|
|
MOVE
|
|
LEFT
|
|
RIGHT
|
|
REPORT
|
|
```
|
|
|
|
*The library allows for a simulation of a toy robot moving on a 6 x 6 square tabletop.*
|
|
|
|
1. There are no obstructions on the table surface.
|
|
2. The robot is free to roam around the surface of the table, but must be prevented from falling to destruction. Any movement that would result in this must be prevented, however further valid movement commands must still be allowed.
|
|
3. PLACE will put the toy robot on the table in position X,Y and facing NORTH, SOUTH, EAST or WEST.
|
|
4. (0,0) can be considered as the SOUTH WEST corner and (5,5) as the NORTH EAST corner.
|
|
5. The first valid command to the robot is a PLACE command. After that, any sequence of commands may be issued, in any order, including another PLACE command. The library should discard all commands in the sequence until a valid PLACE command has been executed.
|
|
6. The PLACE command should be discarded if it places the robot outside of the table surface.
|
|
7. Once the robot is on the table, subsequent PLACE commands could leave out the direction and only provide the coordinates. When this happens, the robot moves to the new coordinates without changing the direction.
|
|
8. MOVE will move the toy robot one unit forward in the direction it is currently facing.
|
|
9. LEFT and RIGHT will rotate the robot 90 degrees in the specified direction without changing the position of the robot.
|
|
10. REPORT will announce the X,Y and orientation of the robot.
|
|
11. A robot that is not on the table can choose to ignore the MOVE, LEFT, RIGHT and REPORT commands.
|
|
12. The library should discard all invalid commands and parameters.
|
|
|
|
### Example Input and Output:
|
|
|
|
```
|
|
a)
|
|
PLACE 0,0,NORTH
|
|
MOVE
|
|
REPORT
|
|
Output: 0,1,NORTH
|
|
```
|
|
|
|
```
|
|
b)
|
|
PLACE 0,0,NORTH
|
|
LEFT
|
|
REPORT
|
|
Output: 0,0,WEST
|
|
```
|
|
|
|
```
|
|
c)
|
|
PLACE 1,2,EAST
|
|
MOVE
|
|
MOVE
|
|
LEFT
|
|
MOVE
|
|
REPORT
|
|
Output: 3,3,NORTH
|
|
```
|
|
|
|
```
|
|
d)
|
|
PLACE 1,2,EAST
|
|
MOVE
|
|
LEFT
|
|
MOVE
|
|
PLACE 3,1
|
|
MOVE
|
|
REPORT
|
|
Output: 3,2,NORTH
|
|
```
|
|
|
|
### Design
|
|
|
|
This is a relatively simple programming problem that one might expect to find as part of an introductory tertiary programming course. It focusses mainly on data representation, state tracking and modification, constraint checking, and some text processing in a text-based environment. Error handling is de-emphasised as most invalid inputs are discarded and one may assume that initial invalid states are not considered. File handling is not required, though it has been used in this implementation for static test data.
|
|
|
|
Initial thoughts on approach included the use of a basic state machine, but movement and coordinate tracking don't lend themselves neatly to a state machine architecture, and so a more tradaitional encapsulated state was used instead.
|
|
|
|
The following additional considerations were made:
|
|
|
|
- Command-line Python was chosen as the language of choice simply due to my familiarity with it. This problem could likely be implemented in any language or environment that supports an equivalent concept of "library", including functional languages.
|
|
- The library (module in Python terminology) `toyrobot` contains just one class, `Robot`, that is aware of both its movement limits (configurable, but defaults to the 6x6 space in the original description) and can also interpret text commands. This monolithic design is appropriate given the simplicity of the problem as provided, but further separation of concerns may be desirable in a more complicated context. For instance, if the problem were to require tracking of more than one robot, it may make sense to abstract out the movement domain and command interpreter as independent entities.
|
|
- As per the spirit of the description, almost all methods are designed to "fail silently" (i.e. leave the Robot state unchanged) if they are invalid or are given invalid inputs. The one exception to this is the ``__init__`` constructor - if numerically invalid maximums are provided for movement limits then a `ValueError` exception is thrown. This ensures that a Robot instance cannot exist with an invalid initial state or configuration.
|
|
|
|
## Installation and Pre-requisites
|
|
|
|
Python version 3.10 or above is required due to the use of the `match/case` construct.
|
|
|
|
No external libraries are used, and a Python virtual environment is not necessary.
|
|
|
|
## Usage
|
|
|
|
To run the examples listed in the problem description:
|
|
|
|
```
|
|
python trexamples.py
|
|
```
|
|
|
|
## Unit Tests
|
|
|
|
A number of basic unit tests are included using the internal Python library `unittest`. These are not exhaustive, but do provide testing of the expected behaviour of the essential methods of the `Robot` class. For ease of reference these are all included in a single class, although it is worth noting that as per the `unittest` [documentation](https://docs.python.org/3/library/unittest.html) many of these should technically be in separate classes with individually specified "setup" and "takedown" code.
|
|
|
|
To run the tests, use the command:
|
|
|
|
```
|
|
python -m unittest -v trtests.py
|
|
```
|
|
|
|
### Author
|
|
|
|
Chris Davoren, 2023, cdavoren@gmail.com
|