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 robot is able to have multiple missions and behaviours. In addition, each of the missions shall have multiple behaviours related to it, it means one behaviour shall be used in one or more missions. The DSL is visualized in \autoref{fig:dsl} where missions are done in sequence.
+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
\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).
\ No newline at end of file
+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