\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.
-\emph{XText}
+\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}.
-\emph{eclipse}
-
-\emph{Antlr}
-
-\emph{Xtend}
+\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}
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 \emph{Consumer}, has the direct control over all the motors. However the
-second brick, from now on \emph{Producer}, controls no motors. Both the
+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}.
+
+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}
+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. 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,
+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}
+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.
& 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}
+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 MarsRover is able to have multiple behaviours and missions. In addition, each of the missions shall have multiple behaviours related to it, it means one registered behaviour can be used in multiple missions.
+
+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 behaviour may also have a StoppingExpression in its TakeAction function from Subsumption architecture. The example of the use StoppingExpression in a bahaviour is one behaviour to avoid left object can be activated if the condition (StoppingExpression) of the left touch sensor is pressed. Furthermore, the StoppingCondition can be whether the color which MarsRover are collected, the touch sensor is touched, the light sensor is activated, the distance of the MarsRover with a certain object is calculated, or if it finds one specific color.
+
+The use of the motors are defined in Action in the DSL. The combination of the motors can be used to represent a certain action, for example below code is used for the action to turn left.
+\begin{lstlisting}
+right motor forward
+left motor backward
+wait 250 ms
+\end{lstlisting}
-\subsection{Code Structure}
\ No newline at end of file
+\subsection{Code Structure}
+The DSL is able to generate the missions and behaviours's source code. The generated source code contains one java class for mission 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 MarsRover (Marster.java), LCD Print functionality (LCDPrinter.java), the default actions of the MarsRover (BasicBehaviour.java), the implementation of misssion (Mission.java), and a class to terminate the mission (ShutdownBehaviour.java).
repositories / des2015.git / blobdiff