1 \section{Robot architecture
}
3 \paragraph{\emph{LeJOS
}~
\cite{lejos_team_lejos_2015
}} is an alternative
4 operating system for the
\textsc{lego
}$^
{\small\textcopyright}$
\textsc{EV3
}
5 bricks. By default the bricks come preinstalled with their own operating system
6 in which you can write programs. The programs have to be written in a
7 \textsc{C
} dialect or in a graphical programming tool.
\emph{LeJOS
} on the
8 other hand is a constantly developed toolkit to write the programs in Java.
9 Because of this we can reuse Java standard libraries and program in a familiar
10 language that allows enough detail for the task.
12 \paragraph{\emph{XText
},
\emph{XTend
} and
\emph{Antlr
}} are a collection of
13 tools working together to provide the functionality for writing, parsing,
14 generating and validating the DSL.
\emph{XText
} is the format used to write the
15 concrete syntax in. The
\emph{XText
} syntax is converted to a so called
16 \emph{ecore
} model which can be read by
\emph{XTend
} programs.
\emph{XTend
}
17 program can do code generation and validation. All the parsing is done by the
18 parser generator library
\emph{Antlr
}.
20 \paragraph{\emph{eclipse
}} is the integrated development environment that ties
21 all the tools together. The DSL is developed in
\emph{eclipse
} and when the
22 language infrastructure is generated you can open a new instance of
23 \emph{eclipse
} to write the actual DSL code in. In this way the user of the
24 child-instance of
\emph{eclipse
} has no view on the underlying mechanisms
25 generating the code and processing the data.
27 \subsection{Design patterns
}
28 \subsubsection{Producer-Consumer
}
29 Ultimately we want to only program one robot. The fact that the one robot
30 contains multiple control bricks is something that needs to be abstracted away
31 from following a low level paradigm called
\emph{producer-consumer
}. As will be
32 discussed in Section~
\ref{sec:mapping
} the first brick, from now on
33 \emph{Consumer
}, has the direct control over all the motors. However the second
34 brick, from now on
\emph{Producer
}, controls no motors. Both the
35 \emph{Consumer
} and the
\emph{Producer
} control $
4$ sensors. Because of this
36 configuration the
\emph{Producer
} only needs to send its sensor data to the
37 \emph{Consumer
}. There is no need to communicate anything back since the
38 \emph{Producer
} can not respond in any physical way. An option could be to
39 distribute the processing power but due to the strength of the bricks and the
40 limitation of the Bluetooth this is very hard or even impossible to achieve.
42 The
\emph{producer-consumer
} paradigm always requires to certain parameters to
43 be set. It could very well be the case that the
\emph{Producer
} produces more
44 then the
\emph{Consumer
} can process. There are several strategies one could
45 use. For example we could send the sensor data from the
\emph{Producer
} all
46 the time, even when there are no updates. Since all communication happens via
47 Bluetooth it could be the case that the bandwidth is not high enough and
48 reading are queued and therefore reach the
\emph{Consumer
} too late. Another
49 approach would be to only send the differences in sensor values. In this way we
50 limit the needed bandwidth and still the
\emph{Producer
} can send its data
51 immediately without having to queue a lot. To keep the
\emph{Producer
} as dumb
52 as possible we do all the interpretation of the sensor values on the
55 All of this combined leads to the visualization of the low level architecture
56 as seen in
\autoref{fig:arch
}
60 $
\xymatrix@C=
.5pc@R=
1pc
{
61 *+
[F
]{\text{front-ultra
}}\ar[ddr
]
62 & *+
[F
]{\text{color}}\ar[dd
]
63 & *+
[F
]{\text{left-touch
}}\ar[ddl
]
64 & *+
[F
]{\text{right-touch
}}\ar[ddll
]
65 & *+
[F
]{\text{left-light
}}\ar[ddrr
]
66 & *+
[F
]{\text{right-light
}}\ar[ddr
]
67 & *+
[F
]{\text{back-ultra
}}\ar[dd
]
68 & *+
[F
]{\text{gyro
}}\ar[ddl
]\\\\
69 & *+
[F
]{\text{producer
}}\ar[rrrrr
]^
{\text{Bluetooth
}}
70 & & & & & *+
[F
]{\text{consumer
}}\ar[ddl
]\ar[dd
]\ar[ddr
]\\\\
71 & & & & & *+
[F
]{\text{left-motor
}}
72 & *+
[F
]{\text{right-motor
}}
73 & *+
[F
]{\text{meas-motor
}}
75 \caption{Low level robot architecture visualizing data flow
}\label{fig:arch
}
78 \subsubsection{Subsumption
}
79 As the higher level architecture we use a slightly adapted version of the
80 subsumption architecture first described by Brooks~
\cite{brooks_robust_1986
}.
82 In the subsumption behaviour there is an arbitrator and several behaviours. A
83 behaviour is a class that contains three functionalities.
85 \item \texttt{takeControl
} is the function that is called every cycle
86 to determine which behaviour wants to be in control. The
87 execution of the function should always be very fast to make
88 sure behaviours can get control as soon as possible if they
90 \item \texttt{action
} is the function that runs after the behaviour is
91 set to be active. The action function must be suppressible at
92 all times within a very short time period. In this way a
93 behaviour can be interrupted by a more important behaviour. When an
94 action stops it should always stop the robot in a
\emph{safe
} position.
95 \item \texttt{suppress
} is the function that is called when a behaviour
96 becomes active while some other behaviour was active before.
97 When it is called the
\texttt{action
} function of the old
98 behaviour should terminate as soon as possible.
101 The basic architecture is visualized in
\autoref{fig:sub
} where the behaviour
102 with the lowest number has the highest priority and thus gets control over the
103 actuators when asked for.
108 & *+
[F
]{b_n
}\ar[r
] &
\ar[d
]\\
109 & *+
[F
]{b_
{\ldots}}\ar[rr
] & &
\ar[d
]\\
110 & *+
[F
]{b_2
}\ar[rrr
] & & &
\ar[d
]\\
111 *+
[F
]{\text{Sensors
}}\ar[uuur
]\ar[uur
]\ar[ur
]\ar[r
]
112 & *+
[F
]{b_1
}\ar[rrrr
] & & & & *+
[F
]{\text{actuators
}}
114 \caption{Subsumption architecture
}\label{fig:sub
}
117 We use the pre-implemented architecture from the
\emph{LeJOS
} where with the
118 use of a
\texttt{suppressed
} flag in every behaviour. The
\texttt{suppressed
}
119 flag that is set when the
\texttt{suppress
} function is called and the
120 \texttt{action
} function will monitor said variable to be able to stop when it
121 is suppressed. The entire action will always finish, however when the flag is
122 set all loops are terminated immediately leaving only atomic actions which are
123 executed almost always asychronously. Therefore the action will stop almost
124 immediately after suppress is called.
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
}
167 A domain-specific language (DSL) is a programming language or executable
168 specification language that offers, through appropriate notations and
169 abstractions, expressive power focused on, and usually restricted to, a
170 particular problem domain~
\cite{van2002domain
}. The DSL for the robot is designed so that the
171 robot is able to perform multiple missions consisting of behaviours. A mission
172 is basically a set of behaviours operating following the subsumption
173 architecture assisted by a special purpose behaviour that shuts down the
174 runtime to make room for a new mission. The complete grammar of the DSL can be
175 found in
\autoref{lst:grammar
}.
177 \autoref{fig:dsl
} describes the hierarchy of the grammar. A
\emph{Robot
} is a
178 set of constants combined with a list of
\emph{Behaviour
}s and a list of
179 \emph{Mission
}s. Missions consist of a
\emph{StoppingCondition
} and a list of
180 references to
\emph{Behaviour
}. A
\emph{Behaviour
} is a literal representation
181 of our interpretation of the subsumption architecture. Thus a control predicate
182 and a sequence of
\emph{Action
}s.
184 \emph{Action
}s represent the real action the robot will perform. This can be an
185 external action such as moving motors but also an internal action such as
186 waiting or set something in memory.
187 \emph{StopppingCondition
}s are logical expression that can contain values from
188 sensors or queries on the memory. To limit the complexity of the grammar a
189 prefix notation is used for binary and unary operators.
194 & *+
[F
]{Robot - Constants
}\ar[dl
]\ar[d
]\ar[dr
]\\
195 *+
[F
]{Mission_
{\ldots}} & *+
[F
]{Mission_k
}\ar[dl
]\ar[d
]\ar[dr
]\ar[drr
] & *+
[F
]{Mission_
{\ldots}}\\
196 *+
[F
]{StoppingExpression
} & *+
[F
]{Behaviour_
{\ldots}} & *+
[F
]{Behaviour_k
}\ar[dl
]\ar[d
] & *+
[F
]{Behaviour_
{\ldots}}\\
197 & *+
[F
]{StoppingExpression
} & *+
[F
]{Action_1
}\ar[d
]\\
198 && *+
[F
]{Action_2
}\ar[d
]\\
199 && *+
[F
]{Action_
{\ldots}}\\
201 \caption{Robot Domain Specific Language
}\label{fig:dsl
}
204 To assist the user programming in the DSL small validation mechanism have been
205 added. It could happen that the user specifies a mission that contains two
206 behaviours both want control at all times. A behaviour that wants control at
207 all times can be a valid design but when there are two with that property, only
208 one will be used. To avoid such situations the IDE will warn the user when this
209 is the case. The full code for the code validation can be found in
212 \subsection{Code Structure
}
213 The complete code generation code can be found in
\autoref{lst:gen
}. The
214 following enumeration shows what is specifically generated per grammar object.
215 All generated code can not function without the library. The library is an
216 entire runtime that only needs a little amount of data plugged in to function
217 as the program of a robot.
219 The library provides an extension on the
\texttt{Behavior
} class from the
220 \emph{LeJOS
} library that offers several higher level operations such as
221 turning and measuring. All the sensor data can be queried from the
222 \texttt{SensorCollector
} class that is available in every behaviour. This class
223 provides up to date sensor data from both bricks. The special behaviour that
224 terminates the current mission is an extension on the already extended
225 \texttt{Behavior
} class and is called
\texttt{ShutdownBehaviour.java
}.
228 \item\textbf{Robot
}\\
229 A
\texttt{Constants.java
} file is created to hold the global speed and
231 \item\textbf{Mission
}
232 In the java code a mission is a list of defined behaviours plus the
233 special
\emph{ShutdownBehaviour
}. To make this simple all the missions
234 combined generate a single
\texttt{Missions.java
} file that has one
235 static function that will return a list of
\emph{Mission
}s that the
236 main program will use.
237 \item\textbf{Behaviour
}
238 For every
\emph{Behaviour
} a file is created containing the specific
239 implementation. For example for a behaviour called
\texttt{Wander
} a
240 file called
\texttt{WanderBehaviour.java
} is created that contains the
241 class
\texttt{WanderBehaviour
} which implements the
242 \texttt{BasicBehaviour
} class from the library.
243 \item\textbf{StoppingExpression
}
244 Stopping expressions are used in missions and in behaviours and are
245 converted to java boolean expressions in-line.
247 Actions are in-line converted to the respective calls to the library or
248 implemented directly.
repositories / des2015.git / blob