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{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}
+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
+\subsubsection{Discussion}
+%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.
repositories / des2015.git / blobdiff