From: Mart Lubbers Date: Sat, 23 Jan 2016 17:45:42 +0000 (+0100) Subject: add some evaluation stuff X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=44cc1aee6c5afc43dc4441fd0d7d91885a0f4338;p=des2015.git add some evaluation stuff --- diff --git a/marsrover/document/evaluation.tex b/marsrover/document/evaluation.tex index a9aa80c..e7be3a1 100644 --- a/marsrover/document/evaluation.tex +++ b/marsrover/document/evaluation.tex @@ -73,7 +73,7 @@ and if they are we try to complete as many iterations as possible. \end{table} \subsection{Evaluation} -\subsubsection{Realisation} +\subsubsection{Requirements realisation} %implemented features and mission range The final implementation satisfies all the \emph{must have} requirements. Besides all the most important requirements it also supports all \emph{should @@ -84,6 +84,7 @@ of that mapping and localization was not implemented. In the end of the process we had some time left which we used to implement \emph{ER2} since it was relatively simple. +\paragraph{Mission range} The range of missions the robot can support is a lot bigger then reflected by the met functional requirements. All actions specifiable in a behaviour consist of atomic operations that take very little time leading to the action being @@ -91,18 +92,47 @@ 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. +One could argue that due to the lack of control structures it is very difficult +to program complex missions. This is the case, for example if we would add a +\emph{while} construction it would increase the range of missions very much. +However, it also makes programming the robot much more difficult and will +reduce the usability. With the current structure with the subsumption +architecture and the rudimentary memory you actually can create such control +structures but it takes a little more effort. -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. +\paragraph{Flexibility} +The DSL can very easily be improved in the case of adding new sensors or +actuators. For sensors we can just add clauses in the grammar within the +\emph{StoppingExpression} that will process the values. For actuators the same +thing can be done in the \emph{Action} rule. A change in the robot's +configuration can also be handled very quickly albeit not in the DSL itself. We +specifically chose not to incorporate the hardware configuration in the DSL to +keep is a simple as possible and thus less error prone. This means that if the +hardware configuration changes the underlying library must be changed as well. +However, due to the modularity of the library this is very easy. + +\paragraph{Safety} +The DSL by design does not generate \emph{safe} code implicitly. A programmer +can make a program that can destroy the robot very easily. While safety is very +important it would limit the range of missions a lot if some basic behaviours +used in the demonstration for safety would be inherently present. + +\subsubsection{Development process} +Booting the bricks takes around a minute to complete. When the robot is +programmed launching the application takes another 30 seconds followed by +another 30 seconds waiting on the initialization of the sensors. About once +every 10 times on high battery and about every other time on low battery the +ultrasonic sensor fails to initialize. We did not have the time to investigate +this properly but the fault was hidden somewhere deep in the \emph{LeJOS} code. +When all sensors were initialized the Bluetooth connection could be commenced +by pressing a button on both bricks. Connecting via bluetooth has about the +same error rate as the ultrasonic sensor has and takes about 30 seconds. + +This very long start up led to a rough development process with long feedback +loops. After a long time we and other groups found out that applying power to +the bricks during the initialization and pairing reduced the error frequency a +lot. -\subsubsection{Discussion} %development process, use of dsl/technologies, general lessons 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 @@ -112,4 +142,4 @@ 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 +to be restarted which took some time from the development time.