Add moscow explanation
[des2015.git] / marsrover / document / robot.tex
1 \section{Robot architecture}
2 \subsection{Tools}
3 \emph{LeJOS}~\cite{lejos_team_lejos_2015}
4
5 \emph{XText}
6
7 \emph{eclipse}
8
9 \emph{Antlr}
10
11 \emph{Xtend}
12
13 \subsection{Design patterns}
14 \subsubsection{Producer-Consumer}
15 Ultimately we want to only program one robot. The fact that the one robot
16 contains multiple control bricks is something that needs to be abstracted away
17 from. As will be discussed in Section~\ref{sec:mapping} the first brick, from
18 now on \emph{Consumer}, has the direct control over all the motors. However the
19 second brick, from now on \emph{Producer}, controls no motors. Both the
20 \emph{Consumer} and the \emph{Producer} control $4$ sensors. Because of this
21 configuration the \emph{Producer} only needs to send its sensor data to the
22 \emph{Consumer}. There is no need to communicate anything back since the
23 \emph{Producer} can not respond in any physical way. An option could be to
24 distribute the processing power but due to the strength of the bricks and the
25 limitation of the bluetooth this is very hard or even impossible to achieve.
26
27 \subsubsection{Subsumption}
28 As the higher level architecture we use a slightly adapted version of the
29 subsumption architecture first described by Brooks~\cite{brooks_robust_1986}.
30 We use the pre-implemented architecture from the \emph{LeJOS} where with the
31 use of a \texttt{suppressed} flag in every behaviour we can start and interrupt
32 the behaviour. Our version is a little bit adapted from the original
33 subsumption behaviour because in our implementation the robot can finish the
34 designated task even if the behaviour does not want control anymore. For
35 example when the left light sensor detects that the robot is driving of the
36 planet a right turn of $90$ degrees may be initiated. This right turn will be
37 completed even when the left light sensor is not detecting a dangerous value.
38 The suppressed flag can take three states. \texttt{IDLE}, \texttt{IN\_ACTION}
39 and \texttt{SUPPRESSED}. By default all behaviours have the \texttt{IDLE}
40 state. When a behaviour is started the state will change to \texttt{IN\_ACTION}
41 and when a behaviour finished the state will be reset to \texttt{IDLE}. When a
42 behaviour needs to be interrupted the state is set to \texttt{SUPPRESSED} and
43 since the behaviour is always monitoring the state it will shutdown as soon as
44 possible and reset the state.
45
46 \subsection{Mapping of the sensors and actuators}\label{sec:mapping}
47 The actuators are all plugged into the \emph{Consumer} to achieve the maximum
48 safety in case the \emph{Bluetooth} connection fails between the
49 \emph{Consumer} and the \emph{Producer} and one of the actuators is moving.
50 All the safety-critical sensors for movement are placed on the \emph{Consumer}
51 brick too. All other sensors are placed on the \emph{Producer} brick. Any
52 increased latency on those sensors will not danger the safety. The final
53 mapping is described in \autoref{tab:mapping}.
54
55 \begin{table}[H]
56 \centering
57 \begin{tabular}{lll}
58 \toprule
59 & \emph{Consumer} & \emph{Producer}\\
60 \midrule
61 \multirow{2}{*}{Actuators} & Left motor\\
62 & Right motor & \\
63 & Measurement motor\\
64 \midrule
65 \multirow{4}{*}{Sensors} & Left light sensor & Color sensor\\
66 & Right light sensor & Front ultrasone sensor\\
67 & Back ultrasone sensor & Left touch sensor\\
68 & Gyro sensor & Right touch sensor\\
69 \bottomrule
70 \end{tabular}
71 \caption{Proposed mapping of the sensors and actuators}\label{tab:mapping}
72 \end{table}
73
74 \subsection{Domain Specific Language}
75
76
77 \subsection{Code Structure}