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.
-Because of the action defined in behaviour is atomic, it makes the behaviour can be defined dinamically. It means that we can define some combination of actions to do a specific mission. The example of missions that can be supported by the DSL are the following:
-\begin{enumerate}
-\item Find lakes by color sensor
-\item Find rocks by front ultrasone sensor
-\item Push rocks
-\item Wander on the table forever
-\item Measure rocks
-\item Measure lakes
-\item Avoid rocks
-\item Avoid lakes
-\item Park in the corner of the table
-\end{enumerate}
-However the missions that cannot supported by the DSL are the following:
-\begin{enumerate}
-\item Find lakes and remember where they are after the robot found them
-\item Navigate with the map using SLAM (Simultaneous Locatization and Mapping)
-\end{enumerate}
+\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.
-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.
\ No newline at end of file
+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 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