\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}
+variable is a flag that is set when \texttt{suppress} 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.
+
+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}
-\subsection{Code Structure}
\ No newline at end of file
+\subsection{Code Structure}
repositories / des2015.git / blobdiff