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
+set all loops are terminated immediately leaving only atomic actions which are
executed almost always asychronously. Therefore the action will stop almost
-immediatly after suppress is called.
+immediately 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,
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.
+particular problem domain~\cite{van2002domain}. The DSL for the robot is
+designed so that the robot is able to perform multiple missions consisting of
+behaviours. A mission is basically a set of behaviours operating following the
+subsumption architecture assisted by a special purpose behaviour that shuts
+down the runtime to make room for a new mission. The complete grammar of the
+DSL can be found in \autoref{lst:grammar}.
+
+\autoref{fig:dsl} describes the hierarchy of the grammar. A \emph{Robot} is a
+set of constants combined with a list of \emph{Behaviour}s and a list of
+\emph{Mission}s. Missions consist of a \emph{StoppingCondition} and a list of
+references to \emph{Behaviour}. A \emph{Behaviour} is a literal representation
+of our interpretation of the subsumption architecture. Thus a control predicate
+and a sequence of \emph{Action}s.
+
+\emph{Action}s represent the real action the robot will perform. This can be an
+external action such as moving motors but also an internal action such as
+waiting or set something in memory.
+\emph{StopppingCondition}s are logical expression that can contain values from
+sensors or queries on the memory. To limit the complexity of the grammar a
+prefix notation is used for binary and unary operators.
\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}
+ & *+[F]{Robot - Constants}\ar[dl]\ar[d]\ar[dr]\\
+ *+[F]{Mission_{\ldots}} & *+[F]{Mission_k}\ar[dl]\ar[d]\ar[dr]\ar[drr] & *+[F]{Mission_{\ldots}}\\
+ *+[F]{StoppingExpression} & *+[F]{Behaviour_{\ldots}} & *+[F]{Behaviour_k}\ar[dl]\ar[d] & *+[F]{Behaviour_{\ldots}}\\
+ & *+[F]{StoppingExpression} & *+[F]{Action_1}\ar[d]\\
+ && *+[F]{Action_2}\ar[d]\\
+ && *+[F]{Action_{\ldots}}\\
}$
\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}
+To assist the user programming in the DSL small validation mechanism have been
+added. It could happen that the user specifies a mission that contains two
+behaviours both want control at all times. A behaviour that wants control at
+all times can be a valid design but when there are two with that property, only
+one will be used. To avoid such situations the IDE will warn the user when this
+is the case. The full code for the code validation can be found in
+\autoref{lst:val}. The full DSL instance used in the demonstration can be found
+in \autoref{lst:inst}.
\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).
+The complete code generation code can be found in \autoref{lst:gen}. The
+following enumeration shows what is specifically generated per grammar object.
+All generated code can not function without the library. The library is an
+entire runtime that only needs a little amount of data plugged in to function
+as the program of a robot.
+
+The library provides an extension on the \texttt{Behavior} class from the
+\emph{LeJOS} library that offers several higher level operations such as
+turning and measuring. All the sensor data can be queried from the
+\texttt{SensorCollector} class that is available in every behaviour. This class
+provides up to date sensor data from both bricks. The special behaviour that
+terminates the current mission is an extension on the already extended
+\texttt{Behavior} class and is called \texttt{ShutdownBehaviour.java}.
+
+\begin{itemize}
+ \item\textbf{Robot}\\
+ A \texttt{Constants.java} file is created to hold the global speed and
+ acceleration values.
+ \item\textbf{Mission}
+ In the java code a mission is a list of defined behaviours plus the
+ special \emph{ShutdownBehaviour}. To make this simple all the missions
+ combined generate a single \texttt{Missions.java} file that has one
+ static function that will return a list of \emph{Mission}s that the
+ main program will use.
+ \item\textbf{Behaviour}
+ For every \emph{Behaviour} a file is created containing the specific
+ implementation. For example for a behaviour called \texttt{Wander} a
+ file called \texttt{WanderBehaviour.java} is created that contains the
+ class \texttt{WanderBehaviour} which implements the
+ \texttt{BasicBehaviour} class from the library.
+ \item\textbf{StoppingExpression}
+ Stopping expressions are used in missions and in behaviours and are
+ converted to java boolean expressions in-line.
+ \item\textbf{Action}
+ Actions are in-line converted to the respective calls to the library or
+ implemented directly.
+\end{itemize}
repositories / des2015.git / blobdiff