\section{Robot architecture}
\subsection{Tools}
-\emph{LeJOS}~\cite{lejos_team_lejos_2015}
-
-\emph{XText}
-
-\emph{eclipse}
-
-\emph{Antlr}
-
-\emph{Xtend}
+\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{Producer-Consumer}
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}.
\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. The \texttt{suppressed}
-variable is a flag that is set when \texttt{suppress} is called and the
+flag that is set when the \texttt{suppress} function 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.
+is suppressed. The entire action will always finish, however when the flag is
+set all loops are terminated immediatly leaving only atomic actions which are
+executed almost always asychronously. Therefore the action will stop almost
+immediatly after suppress is called.
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,
\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 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
+ $\xymatrix{
+ & *+[F]{Mission_n} & *+[F]{Behaviour_n} \\
+ & *+[F]{Mission_{\ldots}} & *+[F]{Behaviour_3} \\
+ & *+[F]{Mission_2}\ar[r]\ar[ur]\ar[uur] & *+[F]{Behaviour_2}\\
+ *+[F]{\text{Robot}}\ar[uuur]\ar[uur]\ar[ur]\ar[r]
+ & *+[F]{Mission_1}\ar[r]\ar[ur] & *+[F]{Behaviour_1}
+ }$
+ \caption{Robot Domain Specific Language}\label{fig:dsl}
+\end{figure}
+
+As can be seen in \autoref{fig:beh}, a behaviour shall have a condition to make it take control and it shall contain one or more actions. Action is atomic and the use of the motor is defined in Action.
+
+\begin{figure}[H]
+ \centering
+ $\xymatrix{
+ & & *+[F]{Action_n} \\
+ & & *+[F]{Action_2} \\
+ & *+[F]{Actions}\ar[r]\ar[ur]\ar[uur] & *+[F]{Action_1}\\
+ *+[F]{\text{Behaviour}}\ar[ur]\ar[r]
+ & *+[F]{Take Control}\ar[r] & *+[F]{Condition}
+ }$
+ \caption{Behaviour in Domain Specific Language}\label{fig:beh}
+\end{figure}
+
+We implemented the StoppingExpression in the DSL so that every mission have a condition to stop. Once the condition is reached then the mission is accomplished.
+The combination of actions can be used to represent a robot movement, for example below code is used by the robot to turn left.
+\begin{lstlisting}
+right motor forward
+left motor backward
+\end{lstlisting}
\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).
repositories / des2015.git / blobdiff