\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 immediately leaving only atomic actions which are
+executed almost always asychronously. Therefore the action will stop almost
+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,
+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 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]{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}
+
+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 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}.
-\subsection{Code Structure}
\ No newline at end of file
+\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