+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}