\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 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}
+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