\section{Development Plan \& Evaluation}
\subsection{Development Plan}
The development plan is written following the spiral software development model
in which all requirements are divided into small iterations. Each of the
iterations will have an implementation phase, a testing phase, an analysis
phase, and a design phase. Furthermore, each of the iterations will have goals
and results. The iterations and their deliverables are listed in
\autoref{tab:devit}. The schedule for finishing iterations are listed in
\autoref{tab:deadli}. On the 6th of January the must-have should be finished
and if they are we try to complete as many iterations as possible.
\begin{table}[H]
	\centering
	\begin{tabu} to \linewidth{llX}
		\toprule
		Deadline & Iterations\\
		\midrule
		9 Dec 2015 & 1--2\\
		16 Dec 2015 & 3--5\\
		23 Dec 2015 & 6--9\\
		6 Jan 2015 & 10--11\\
		13 Jan 2015 & Demo\\
		\bottomrule
	\end{tabu}
	\caption{Deadlines}\label{tab:deadli}
\end{table}
\begin{table}[H]
	\centering
	\begin{tabu} to \linewidth{rlXX}
		\toprule
		It. & Req. & Description & Deliverables\\
		\midrule
		1 & NR1 & Create a DSL for MarsRover's missions to use available
			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
			motor actions: forward, backward, measure rock, measure lake and
			wait. & Code
			generation for motors\\
		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
			treshholds manually. & Code generation for sensors and threshhold
			constants.\\
		6 & CR1 & Create functionality to keep the MarsRover in the planet. &
			A generatable behaviour to stay on the planet.\\
		7 & MR3 & Create functionality for not bumping into rocks. & A
			generatable behaviour to not bump into rocks.\\
		8 & MR1 & Create functionality to find lakes. & A generatable mission
			to find lakes.\\
		9 & MR6 & Create functionality to perform missions in sequence. & A
			generatable main program that performs missions.\\
		10 & MR2, MR4& Create functionality to find rocks. & A generatable
			mission to find rocks.\\
		11 & MR5 & Create functionality to push rocks and detect when the
			robots is pushing. & A generatable behaviour for pushing.\\
		12 & MR7 & Create functionality to find the parking space. & A
			generatable behaviour that can find the parking space.\\
		13 & MR8, ER1 & Create functionality to map the environment and to
			localize. & A generatable behaviour that can map while
			performing.\\
		14 & ER2 & Create functionality to play sounds. & Add a generatable
			function for playing sounds.\\
		15 & NR3, NR4 & Create functionality to calibrate the sensor
			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.\\
		\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.
