\section{Robot architecture}
\subsection{Tools}
-\emph{LeJOS}\cite{lejos_team_lejos_2015}
+\paragraph{\emph{LeJOS}~\cite{lejos_team_lejos_2015}} is an alternative
+operating system for the \textsc{lego}$^{\small\textcopyright}$ \textsc{EV3}
+bricks. By default the bricks come preinstalled with their own operating system
+in which you can write programs. The programs have to be written in a
+\textsc{C} dialect or in a graphical programming tool. \emph{LeJOS} on the
+other hand is a constantly developed toolkit to write the programs in Java.
+Because of this we can reuse Java standard libraries and program in a familiar
+language that allows enough detail for the task.
+
+\paragraph{\emph{XText}, \emph{XTend} and \emph{Antlr}} are a collection of
+tools working together to provide the functionality for writing, parsing,
+generating and validating the DSL. \emph{XText} is the format used to write the
+concrete syntax in. The \emph{XText} syntax is converted to a so called
+\emph{ecore} model which can be read by \emph{XTend} programs. \emph{XTend}
+program can do code generation and validation. All the parsing is done by the
+parser generator library \emph{Antlr}.
+
+\paragraph{\emph{eclipse}} is the integrated development environment that ties
+all the tools together. The DSL is developed in \emph{eclipse} and when the
+language infrastructure is generated you can open a new instance of
+\emph{eclipse} to write the actual DSL code in. In this way the user of the
+child-instance of \emph{eclipse} has no view on the underlying mechanisms
+generating the code and processing the data.
\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
+from following a low level paradigm called \emph{producer-consumer}. As will be
+discussed in Section~\ref{sec:mapping} the first brick, from 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.
+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
+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
+as possible we do all the interpretation of the sensor values on the
+\emph{Consumer}.
+
+All of this combined leads to the visualization of the low level architecture
+as seen in \autoref{fig:arch}
+
+\begin{figure}[H]
+ \centering
+ $\xymatrix@C=.5pc@R=1pc{
+ *+[F]{\text{front-ultra}}\ar[ddr]
+ & *+[F]{\text{color}}\ar[dd]
+ & *+[F]{\text{left-touch}}\ar[ddl]
+ & *+[F]{\text{right-touch}}\ar[ddll]
+ & *+[F]{\text{left-light}}\ar[ddrr]
+ & *+[F]{\text{right-light}}\ar[ddr]
+ & *+[F]{\text{back-ultra}}\ar[dd]
+ & *+[F]{\text{gyro}}\ar[ddl]\\\\
+ & *+[F]{\text{producer}}\ar[rrrrr]^{\text{Bluetooth}}
+ & & & & & *+[F]{\text{consumer}}\ar[ddl]\ar[dd]\ar[ddr]\\\\
+ & & & & & *+[F]{\text{left-motor}}
+ & *+[F]{\text{right-motor}}
+ & *+[F]{\text{meas-motor}}
+ }$
+ \caption{Low level robot architecture visualizing data flow}\label{fig:arch}
+\end{figure}
\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}.
+
+In the subsumption behaviour there is an arbitrator and several behaviours. A
+behaviour is a class that contains three functionalities.
+\begin{itemize}
+ \item \texttt{takeControl} is the function that is called every cycle
+ to determine which behaviour wants to be in control. The
+ execution of the function should always be very fast to make
+ sure behaviours can get control as soon as possible if they
+ need to.
+ \item \texttt{action} is the function that runs after the behaviour is
+ set to be active. The action function must be suppressible at
+ all times within a very short time period. In this way a
+ behaviour can be interrupted by a more important behaviour. When an
+ action stops it should always stop the robot in a \emph{safe} position.
+ \item \texttt{suppress} is the function that is called when a behaviour
+ becomes active while some other behaviour was active before.
+ When it is called the \texttt{action} function of the old
+ behaviour should terminate as soon as possible.
+\end{itemize}
+
+The basic architecture is visualized in \autoref{fig:sub} where the behaviour
+with the lowest number has the highest priority and thus gets control over the
+actuators when asked for.
+
+\begin{figure}[H]
+ \centering
+ $\xymatrix{
+ & *+[F]{b_n}\ar[r] & \ar[d]\\
+ & *+[F]{b_{\ldots}}\ar[rr] & & \ar[d]\\
+ & *+[F]{b_2}\ar[rrr] & & & \ar[d]\\
+ *+[F]{\text{Sensors}}\ar[uuur]\ar[uur]\ar[ur]\ar[r]
+ & *+[F]{b_1}\ar[rrrr] & & & & *+[F]{\text{actuators}}
+ }$
+ \caption{Subsumption architecture}\label{fig:sub}
+\end{figure}
+
+
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
-subsumption behaviour because in our implementation the robot can finish the
-designated task even if the behaviour does not want control anymore. For
-example when the left light sensor detects that the robot is driving of the
-planet a right turn of $90$ degrees may be initiated. This right turn will be
-completed even when the left light sensor is not detecting a dangerous value.
-The suppressed flag can take three states. \texttt{IDLE}, \texttt{IN\_ACTION}
-and \texttt{SUPPRESSED}. By default all behaviours have the \texttt{IDLE}
-state. When a behaviour is started the state will change to \texttt{IN\_ACTION}
-and when a behaviour finished the state will be reset to \texttt{IDLE}. When a
-behaviour needs to be interrupted the state is set to \texttt{SUPPRESSED} and
-since the behaviour is always monitoring the state it will shutdown as soon as
-possible and reset the state.
+use of a \texttt{suppressed} flag in every behaviour. The \texttt{suppressed}
+variable is a flag that is set when \texttt{suppress} is called and the
+\texttt{action} function will monitor said variable to be able to stop when it
+is suppressed. To be able to let the robot finish some critical actions (eg.\
+turning a specific number of degrees) we need some changes to the standard
+architecture. More concretely we change the standard \texttt{suppressed}
+boolean to a three state variable.
+
+When such a task is started and said behaviour does not ask for control the
+behaviour can still finish if it is not interrupted. For example when the left
+light sensor detects that the robot is driving of the planet a right turn of
+$90$ degrees may be initiated. This right turn will be completed even when the
+left light sensor is not detecting a dangerous value. The suppressed flag can
+take three states. \texttt{IDLE}, \texttt{IN\_ACTION} and \texttt{SUPPRESSED}.
+By default all behaviours have the \texttt{IDLE} state. When a behaviour is
+started the state will change to \texttt{IN\_ACTION} and when a behaviour
+finished the state will be reset to \texttt{IDLE}. When a behaviour needs to be
+interrupted the state is set to \texttt{SUPPRESSED} and since the behaviour is
+always monitoring the state it will shutdown as soon as possible and reset the
+state.
+
+Since the task of the robot is to perform certain missions in sequence we also
+added a special kind of behaviour to the standard architecture. This behaviour,
+from now on \emph{Shutdownbehaviour}, is a behaviour has a special
+\texttt{takeControl} function. This function returns true when the end
+condition of the mission occurs and the action will stop the arbitrator. The
+main control loop of the program will then setup a new arbitrator to perform a
+new mission.
\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}.
+For the first proposal we were required to opt for a mapping for the sensors.
+After some discussion the initial proposed mapping also became the final
+mapping of actuators and sensors because of the reasons explained below.
+
+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 & \\
& Gyro sensor & Right touch sensor\\
\bottomrule
\end{tabular}
- \caption{Proposed mapping of the sensors and actuators}\label{tab:mapping}
+ \caption{Mapping of the sensors and actuators}\label{tab:mapping}
\end{table}
+\subsection{Domain Specific Language}
+
+
+\subsection{Code Structure}
repositories / des2015.git / blobdiff