Added the possible improvement

diff --git a/marsrover/document/evaluation.tex b/marsrover/document/evaluation.tex
index 8b81815..a9aa80c 100644 (file)
--- a/marsrover/document/evaluation.tex
+++ b/marsrover/document/evaluation.tex
@@ -91,14 +91,25 @@ interruptible at all times. Together with the rudimentary variable storage we
 can make missions very complex. Possible combinations of behaviour can perform
 actions such as: counting, following moving objects and grouping objects.
 
+In the beginning of the running program, the user need to press any button to start 
+the program in the robot. This is because both bricks need to start the bluetooth 
+communication pairing at the same time. If we were given more time we would make 
+the bluetooth pairing automatically run from the beginning of the program without 
+waiting button press in order to limit the user involvement in the robot.
+
+The DSL can accomodate the improvement in the case of adding new sensors or actuators.
+For instance, if we want to add a new sensor, then it is easy to add new \emph{StoppingExpression}
+in the DSL. In addition, if we want to add a new actuator to the robot, we can just add
+a new action defined in the DSL and implement the use of the action in the program.
+
 \subsubsection{Discussion}
 %development process, use of dsl/technologies, general lessons
-From our experience, the most important think in the development process was
-start working from a small functionality and test it. Earlier we know something
-wrong with the program and earlier we can fix and test it again. That will be
-good for the development of the next functionality.  The difficulty in the
-development was in the testing phase. The reason is sometimes we got an error
-when running the program in robot (for example: sensor error) and it took so
-much time for loading all sensor working to test the robot. There was a time
-when the robot was crashed and need to be restarted which take some time from
-the development time.
+From our experience, the most important think in the development process was to 
+start working from a small functionality and to test it. As soon as we knew 
+something wrong with the program we can fix and test it again in order to ensure 
+the functionality worked. This would be good for the development of the next 
+functionality. The difficulty in the development was in the testing phase. The 
+reason was sometimes we got an error when running the program in the robot (for 
+example: sensor exception) and it took so much time for loading all sensors to be 
+ready for testing. Moreover, there was a time when the robot was crashed and needed 
+to be restarted which took some time from the development time.
\ No newline at end of file

diff --git a/marsrover/document/todo.txt b/marsrover/document/todo.txt
index fac2d72..e522cbd 100644 (file)
--- a/marsrover/document/todo.txt
+++ b/marsrover/document/todo.txt
@@ -1,6 +1,3 @@
-done           DSL description
-done           Code structure, what do we generate?
-               
                3. Development Plan & Evaluation
                        Evaluation
 todo                   What would we do different given more time?