sensors and actuators. & \texttt{TaskDSL.xtext}\\
2 & ER3 & Implement diagnostic functions that print on the \emph{LCD}.
& A \emph{LCD} class that prints to the \emph{LCD} screen.\\
- 3 & - & Implement functions in the code generation for basic motor the
+ 3 & -- & Implement functions in the code generation for basic motor the
motor actions: forward, backward, measure rock, measure lake and
wait. & Code
generation for motors\\
- 4 & - & Implement functions in the code generation for communicating
+ 4 & -- & Implement functions in the code generation for communicating
the sensors from the slave to the master. & Functions in the master
program to read the slave's sensors.\\
- 5 & - & Create functionality for sensor values and determine the
+ 5 & -- & Create functionality for sensor values and determine the
treshholds manually. & Code generation for sensors and threshhold
constants.\\
6 & CR1 & Create functionality to keep the MarsRover in the planet. &
treshholds. & A generatable function to calibrate the sensors.\\
16 & NR5 & Create functionality that when the robot encounters bugs it
can restart itself. & Functionality in the main program to do so.\\
- 17 & - & Speed up the behaviour of the robot within safety limits.\\
+ 17 & -- & Speed up the behaviour of the robot within safety limits.\\
\bottomrule
\end{tabu}
\caption{Spiral model iterations}\label{tab:devit}
\end{table}
\subsection{Evaluation}
+\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
+have} requirements except \emph{MR8} in which the robot must be able to
+remember the locations of the lakes. This is because we encountered some
+problems during the development phase that lead to a shortage of time. Because
+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
+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.
+
+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, the subsumption
+architecture and the rudimentary memory, we 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}
+\paragraph{Feedback loop}
+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.
+
+\paragraph{Techniques}
+Using the combination of all tools such as DSL, XText, XTend and eclipse went
+surprisingly well. In the beginning there were some technical difficulties
+setting everything up and there was quite some overhead since the tools
+required a lot of computing power. But when everything was set up correctly it
+worked like a charm.
+
+Creating our solution was a bit difficult at the beginning due to extra works
+designing the DSL to accomodate the robot's missions and behaviours. However
+when the DSL was created appropriately the generation of different missions and
+behaviours for the robot became very easy.
+
+\paragraph{General lessons learned}
+From our experience, the most important thing in the development process was to
+work iteratively in small building blocks. Another lesson learned was the fact
+that robots are not always reliable and can behave in unexpected ways.
+
+Another lesson learned was that plans mostly take longer than expected. Our
+planning was very generous but still we did not have time to implement some
+extra functionality. If we would have more time we would have tried to make the
+robots autonomous in start up. The current robot needs to have a button pressed
+when the bricks can pair. We have experimented with autonomous pairing but we
+never got it stable but with more time we could make it stable. Another option
+is to try to get more requirements. For example the mapping and internal
+representation of the locations of the lakes. This problem is not trivial at
+all and because of the lack of time we could unfortunately not spend time on
+it.
repositories / des2015.git / blobdiff