From de9ffe682cf678c56f89737bb94108bd2c720a53 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Fri, 22 Jan 2016 17:02:04 +0100 Subject: [PATCH] did some rewriting on evaluation --- marsrover/document/Makefile | 2 +- marsrover/document/evaluation.tex | 54 ++++++++++++++++++------------- marsrover/document/robot.tex | 15 ++++++--- 3 files changed, 43 insertions(+), 28 deletions(-) diff --git a/marsrover/document/Makefile b/marsrover/document/Makefile index 0a53bd5..2d4eeb0 100644 --- a/marsrover/document/Makefile +++ b/marsrover/document/Makefile @@ -21,4 +21,4 @@ all: $(DOCUMENT).pdf $(LATEX) -ini -jobname="$(basename $@)" "&$(LATEX) $<\dump" clean: - $(RM) -v $(addprefix $(DOCUMENT).,fmt aux bbl blg dvi log out toc pdf) + $(RM) -v $(addprefix $(DOCUMENT).,fmt aux bbl blg dvi log out toc pdf) *.xyc diff --git a/marsrover/document/evaluation.tex b/marsrover/document/evaluation.tex index ce62ee1..8b81815 100644 --- a/marsrover/document/evaluation.tex +++ b/marsrover/document/evaluation.tex @@ -33,14 +33,14 @@ and if they are we try to complete as many iterations as possible. 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. & @@ -66,31 +66,39 @@ and if they are we try to complete as many iterations as possible. 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. diff --git a/marsrover/document/robot.tex b/marsrover/document/robot.tex index a646737..f409a9c 100644 --- a/marsrover/document/robot.tex +++ b/marsrover/document/robot.tex @@ -42,13 +42,13 @@ limitation of the Bluetooth this is very hard or even impossible to achieve. The \emph{producer-consumer} paradigm always requires to certain parameters to be set. It could very well be the case that the \emph{Producer} produces more then the \emph{Consumer} can process. There are several strategies one could -use. For example we could send the sensor data from the \emph{Producer} all +use. For example we could send the sensor data from the \emph{Producer} all the time, even when there are no updates. Since all communication happens via Bluetooth it could be the case that the bandwidth is not high enough and reading are queued and therefore reach the \emph{Consumer} too late. Another approach would be to only send the differences in sensor values. In this way we limit the needed bandwidth and still the \emph{Producer} can send its data -immediately without having to queue a lot. To keep the \emph{Producer} as dumb +immediately without having to queue a lot. To keep the \emph{Producer} as dumb as possible we do all the interpretation of the sensor values on the \emph{Consumer}. @@ -164,7 +164,14 @@ mapping is described in \autoref{tab:mapping}. \end{table} \subsection{Domain Specific Language} -A domain-specific language (DSL) is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain~\cite{van2002domain}. The DSL is designed so that the robot is able to have multiple missions and behaviours. In addition, each of the missions shall have multiple behaviours related to it, it means one behaviour shall be used in one or more missions. The DSL is visualized in \autoref{fig:dsl} where missions are done in sequence. +A domain-specific language (DSL) is a programming language or executable +specification language that offers, through appropriate notations and +abstractions, expressive power focused on, and usually restricted to, a +particular problem domain~\cite{van2002domain}. The DSL is designed so that the +robot is able to perform multiple missions consisting of behaviours. An +implementation is a list of behaviour descriptions followed by a list of +missions referring to behaviours. This main structure of the DSL is +visualized in \autoref{fig:dsl}. The missions are performed in sequence. \begin{figure}[H] \centering @@ -202,4 +209,4 @@ left motor backward \subsection{Code Structure} The DSL is able to generate the source code for the missions and the behaviours. The generated source code contains one java class for the collection of missions and one java class for each different behaviours. Moreover, the default source code is categorized by two packages. First package contains a class implementing bluetooth communication protocol between Producer-Consumer (BTController.java), a class to collect the sensor data from Producer (SensorCollector.java), and a class to collect the sensor data from Consumer (RemoteSensors.java). -Second package mainly contains the arbitrator implementation of the robot (Marster.java), the default actions of the robot (BasicBehaviour.java), the implementation of the misssion (Mission.java), and a class to terminate the mission (ShutdownBehaviour.java). \ No newline at end of file +Second package mainly contains the arbitrator implementation of the robot (Marster.java), the default actions of the robot (BasicBehaviour.java), the implementation of the misssion (Mission.java), and a class to terminate the mission (ShutdownBehaviour.java). -- 2.20.1