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