From 8bccaab629058956e02945978df7fc500a69bd4d Mon Sep 17 00:00:00 2001 From: Natanael Adityasatria Date: Fri, 22 Jan 2016 21:52:28 +0100 Subject: [PATCH] Added the possible improvement --- marsrover/document/evaluation.tex | 29 ++++++++++++++++++++--------- marsrover/document/todo.txt | 3 --- 2 files changed, 20 insertions(+), 12 deletions(-) diff --git a/marsrover/document/evaluation.tex b/marsrover/document/evaluation.tex index 8b81815..a9aa80c 100644 --- 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 --- 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? -- 2.20.1