\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
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
can make missions very complex. Possible combinations of behaviour can perform
actions such as: counting, following moving objects and grouping objects.
-\subsubsection{Discussion}
+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.
+
+\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.
+
%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.
repositories / des2015.git / blobdiff