updated with bibtex'

'

diff --git a/marsrover/document/evaluation.tex b/marsrover/document/evaluation.tex
index 305da04..1554614 100644 (file)
--- a/marsrover/document/evaluation.tex
+++ b/marsrover/document/evaluation.tex
@@ -1,4 +1,5 @@
-\section{Development Plan}
+\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
@@ -70,3 +71,5 @@ and if they are we try to complete as many iterations as possible.
        \end{tabu}
        \caption{Spiral model iterations}\label{tab:devit}
 \end{table}
+
+\subsection{Evaluation}

diff --git a/marsrover/document/marsrover.bib b/marsrover/document/marsrover.bib
index 7dc3519..5e80e1b 100644 (file)
--- a/marsrover/document/marsrover.bib
+++ b/marsrover/document/marsrover.bib
@@ -19,4 +19,4 @@
        author = {LeJOS Team},
        month = nov,
        year = {2015}
-}
\ No newline at end of file
+}

diff --git a/marsrover/document/robot.tex b/marsrover/document/robot.tex
index 5140b15..092f9e9 100644 (file)
--- a/marsrover/document/robot.tex
+++ b/marsrover/document/robot.tex
@@ -1,24 +1,32 @@
 \section{Robot architecture}
 \subsection{Tools}
-\emph{LeJOS}\cite{lejos_team_lejos_2015}
+\emph{LeJOS}~\cite{lejos_team_lejos_2015}
+
+\emph{XText}
+
+\emph{eclipse}
+
+\emph{Antlr}
+
+\emph{Xtend}
 
 \subsection{Design patterns}
-\subsubsection{Leader-Follower}
+\subsubsection{Producer-Consumer}
 Ultimately we want to only program one robot. The fact that the one robot
 contains multiple control bricks is something that needs to be abstracted away
 from. As will be discussed in Section~\ref{sec:mapping} the first brick, from
-now on \textit{Leader}, has the direct control over all the motors. However the
-second brick, from now on \textit{Follower}, controls no motors. Both the
-\textit{Leader} and the \textit{Follower} control $4$ sensors. Because of this
-configuration the \textit{Follower} only needs to send its sensor data to the
-\textit{Leader}. There is no need to communicate anything back since the
-\textit{Follower} can not respond in any physical way. An option could be to
+now on \emph{Consumer}, has the direct control over all the motors. However the
+second brick, from now on \emph{Producer}, controls no motors. Both the
+\emph{Consumer} and the \emph{Producer} control $4$ sensors. Because of this
+configuration the \emph{Producer} only needs to send its sensor data to the
+\emph{Consumer}. There is no need to communicate anything back since the
+\emph{Producer} can not respond in any physical way. An option could be to
 distribute the processing power but due to the strength of the bricks and the
 limitation of the bluetooth this is very hard or even impossible to achieve.
 
 \subsubsection{Subsumption}
 As the higher level architecture we use a slightly adapted version of the
-subsumption architecture first described by Brooks\cite{brooks_robust_1986}.
+subsumption architecture first described by Brooks~\cite{brooks_robust_1986}.
 We use the pre-implemented architecture from the \emph{LeJOS} where with the
 use of a \texttt{suppressed} flag in every behaviour we can start and interrupt
 the behaviour. Our version is a little bit adapted from the original
@@ -36,18 +44,19 @@ since the behaviour is always monitoring the state it will shutdown as soon as
 possible and reset the state.
 
 \subsection{Mapping of the sensors and actuators}\label{sec:mapping}
-The actuators are all plugged into the master brick to achieve the maximum
-safety in case the \emph{Bluetooth} connection fails between the master and the
-slave and one of the actuators is moving. All the safety-critical sensors for
-movement are placed on the master brick too. All other sensors are placed on
-the slave brick. Any increased latency on those sensors will not danger the
-safety. The final mapping is described in \autoref{tab:mapping}.
+The actuators are all plugged into the \emph{Consumer} to achieve the maximum
+safety in case the \emph{Bluetooth} connection fails between the
+\emph{Consumer} and the \emph{Producer} and one of the actuators is moving.
+All the safety-critical sensors for movement are placed on the \emph{Consumer}
+brick too. All other sensors are placed on the \emph{Producer} brick. Any
+increased latency on those sensors will not danger the safety. The final
+mapping is described in \autoref{tab:mapping}.
 
 \begin{table}[H]
        \centering
        \begin{tabular}{lll}
                \toprule
-                       & Master Brick & Slave Brick\\
+                       & \emph{Consumer} & \emph{Producer}\\
                \midrule
                \multirow{2}{*}{Actuators} & Left motor\\
                        & Right motor & \\

diff --git a/marsrover/document/todo.txt b/marsrover/document/todo.txt
new file mode 100644 (file)
index 0000000..ba7cdcc
--- /dev/null
+++ b/marsrover/document/todo.txt
@@ -0,0 +1,24 @@
+               1. Requirements
+adit           Explain Moscow
+mart           Fix table
+               
+               2. Robot
+mart           Tools
+mart           Subsumption add nice graph
+mart           Sensor mapping explain that it was our proposal and now is final
+                       
+adit           DSL description
+adit           Code structure, what do we generate?
+               
+               3. Development Plan & Evaluation
+done           Development Plan
+               
+                       Evaluation
+todo                   Realisation: what features implemented
+todo                   What would we do different given more time?
+adit                   What range of missions can we support
+todo                   How flexible and extendible are we
+todo                   Evaluate development process
+mart                   Discuss the use of DSL
+mart                   Discuss the technologies(eclipse, xtext...)
+todo                   General lessons learned.