X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;ds=sidebyside;f=marsrover%2Fdocument%2Frobot.tex;h=27efa44c5de553252c02a6f1b08da597b2b39bde;hb=HEAD;hp=4fbaf5b438ca9250722c4d72cf0cf117dc2f0dee;hpb=d685c47d4b13cc90ca44d428002773c848f9cf80;p=des2015.git diff --git a/marsrover/document/robot.tex b/marsrover/document/robot.tex index 4fbaf5b..27efa44 100644 --- a/marsrover/document/robot.tex +++ b/marsrover/document/robot.tex @@ -1,49 +1,141 @@ \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. @@ -68,10 +160,91 @@ mapping is described in \autoref{tab:mapping}. & 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}