1 \section{Robot architecture
}
3 \emph{LeJOS
}~
\cite{lejos_team_lejos_2015
}
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 following a low level paradigm called
\emph{producer-consumer
}. As will be
18 discussed in Section~
\ref{sec:mapping
} the first brick, from now on
19 \emph{Consumer
}, has the direct control over all the motors. However the second
20 brick, from now on
\emph{Producer
}, controls no motors. Both the
21 \emph{Consumer
} and the
\emph{Producer
} control $
4$ sensors. Because of this
22 configuration the
\emph{Producer
} only needs to send its sensor data to the
23 \emph{Consumer
}. There is no need to communicate anything back since the
24 \emph{Producer
} can not respond in any physical way. An option could be to
25 distribute the processing power but due to the strength of the bricks and the
26 limitation of the Bluetooth this is very hard or even impossible to achieve.
28 The
\emph{producer-consumer
} paradigm always requires to certain parameters to
29 be set. It could very well be the case that the
\emph{Producer
} produces more
30 then the
\emph{Consumer
} can process. There are several strategies one could
31 use. For example we could send the sensor data from the
\emph{Producer
} all
32 the time, even when there are no updates. Since all communication happens via
33 Bluetooth it could be the case that the bandwidth is not high enough and
34 reading are queued and therefore reach the
\emph{Consumer
} too late. Another
35 approach would be to only send the differences in sensor values. In this way we
36 limit the needed bandwidth and still the
\emph{Producer
} can send its data
37 immediately without having to queue a lot. To keep the
\emph{Producer
} as dumb
38 as possible we do all the interpretation of the sensor values on the
41 All of this combined leads to the visualization of the low level architecture
42 as seen in
\autoref{fig:arch
}
46 $
\xymatrix@C=
.5pc@R=
1pc
{
47 *+
[F
]{\text{front-ultra
}}\ar[ddr
]
48 & *+
[F
]{\text{color}}\ar[dd
]
49 & *+
[F
]{\text{left-touch
}}\ar[ddl
]
50 & *+
[F
]{\text{right-touch
}}\ar[ddll
]
51 & *+
[F
]{\text{left-light
}}\ar[ddrr
]
52 & *+
[F
]{\text{right-light
}}\ar[ddr
]
53 & *+
[F
]{\text{back-ultra
}}\ar[dd
]
54 & *+
[F
]{\text{gyro
}}\ar[ddl
]\\\\
55 & *+
[F
]{\text{producer
}}\ar[rrrrr
]^
{\text{Bluetooth
}}
56 & & & & & *+
[F
]{\text{consumer
}}\ar[ddl
]\ar[dd
]\ar[ddr
]\\\\
57 & & & & & *+
[F
]{\text{left-motor
}}
58 & *+
[F
]{\text{right-motor
}}
59 & *+
[F
]{\text{meas-motor
}}
61 \caption{Low level robot architecture visualizing data flow
}\label{fig:arch
}
64 \subsubsection{Subsumption
}
65 As the higher level architecture we use a slightly adapted version of the
66 subsumption architecture first described by Brooks~
\cite{brooks_robust_1986
}.
68 In the subsumption behaviour there is an arbitrator and several behaviours. A
69 behaviour is a class that contains three functionalities.
71 \item \texttt{takeControl
} is the function that is called every cycle
72 to determine which behaviour wants to be in control. The
73 execution of the function should always be very fast to make
74 sure behaviours can get control as soon as possible if they
76 \item \texttt{action
} is the function that runs after the behaviour is
77 set to be active. The action function must be suppressible at
78 all times within a very short time period. In this way a
79 behaviour can be interrupted by a more important behaviour. When an
80 action stops it should always stop the robot in a
\emph{safe
} position.
81 \item \texttt{suppress
} is the function that is called when a behaviour
82 becomes active while some other behaviour was active before.
83 When it is called the
\texttt{action
} function of the old
84 behaviour should terminate as soon as possible.
87 The basic architecture is visualized in
\autoref{fig:sub
} where the behaviour
88 with the lowest number has the highest priority and thus gets control over the
89 actuators when asked for.
94 & *+
[F
]{b_n
}\ar[r
] &
\ar[d
]\\
95 & *+
[F
]{b_
{\ldots}}\ar[rr
] & &
\ar[d
]\\
96 & *+
[F
]{b_2
}\ar[rrr
] & & &
\ar[d
]\\
97 *+
[F
]{\text{Sensors
}}\ar[uuur
]\ar[uur
]\ar[ur
]\ar[r
]
98 & *+
[F
]{b_1
}\ar[rrrr
] & & & & *+
[F
]{\text{actuators
}}
100 \caption{Subsumption architecture
}\label{fig:sub
}
104 We use the pre-implemented architecture from the
\emph{LeJOS
} where with the
105 use of a
\texttt{suppressed
} flag in every behaviour. The
\texttt{suppressed
}
106 variable is a flag that is set when
\texttt{suppress
} is called and the
107 \texttt{action
} function will monitor said variable to be able to stop when it
108 is suppressed. To be able to let the robot finish some critical actions (eg.\
109 turning a specific number of degrees) we need some changes to the standard
110 architecture. More concretely we change the standard
\texttt{suppressed
}
111 boolean to a three state variable.
113 When such a task is started and said behaviour does not ask for control the
114 behaviour can still finish if it is not interrupted. For example when the left
115 light sensor detects that the robot is driving of the planet a right turn of
116 $
90$ degrees may be initiated. This right turn will be completed even when the
117 left light sensor is not detecting a dangerous value. The suppressed flag can
118 take three states.
\texttt{IDLE
},
\texttt{IN
\_ACTION} and
\texttt{SUPPRESSED
}.
119 By default all behaviours have the
\texttt{IDLE
} state. When a behaviour is
120 started the state will change to
\texttt{IN
\_ACTION} and when a behaviour
121 finished the state will be reset to
\texttt{IDLE
}. When a behaviour needs to be
122 interrupted the state is set to
\texttt{SUPPRESSED
} and since the behaviour is
123 always monitoring the state it will shutdown as soon as possible and reset the
126 Since the task of the robot is to perform certain missions in sequence we also
127 added a special kind of behaviour to the standard architecture. This behaviour,
128 from now on
\emph{Shutdownbehaviour
}, is a behaviour has a special
129 \texttt{takeControl
} function. This function returns true when the end
130 condition of the mission occurs and the action will stop the arbitrator. The
131 main control loop of the program will then setup a new arbitrator to perform a
134 \subsection{Mapping of the sensors and actuators
}\label{sec:mapping
}
135 For the first proposal we were required to opt for a mapping for the sensors.
136 After some discussion the initial proposed mapping also became the final
137 mapping of actuators and sensors because of the reasons explained below.
139 The actuators are all plugged into the
\emph{Consumer
} to achieve the maximum
140 safety in case the
\emph{Bluetooth
} connection fails between the
141 \emph{Consumer
} and the
\emph{Producer
} and one of the actuators is moving.
142 All the safety-critical sensors for movement are placed on the
\emph{Consumer
}
143 brick too. All other sensors are placed on the
\emph{Producer
} brick. Any
144 increased latency on those sensors will not danger the safety. The final
145 mapping is described in
\autoref{tab:mapping
}.
151 &
\emph{Consumer
} &
\emph{Producer
}\\
153 \multirow{2}{*
}{Actuators
} & Left motor\\
155 & Measurement motor\\
157 \multirow{4}{*
}{Sensors
} & Left light sensor & Color sensor\\
158 & Right light sensor & Front ultrasone sensor\\
159 & Back ultrasone sensor & Left touch sensor\\
160 & Gyro sensor & Right touch sensor\\
163 \caption{Mapping of the sensors and actuators
}\label{tab:mapping
}
166 \subsection{Domain Specific Language
}
169 \subsection{Code Structure
}
repositories / des2015.git / blob