development. In particular, it allows the user to develop applications that run
on different hardware platforms without the need to change the code, and it
strongly uses C++ templates to achieve that feature. Amongst the supported
-platforms are diverse sensor node platforms, like iSense, Contiki and TinyOS,
-but there are as well implementations for the diverse x86-compatible Personal
-Computer platforms, and the Shawn sensor network simulator.
+platforms are diverse sensor node platforms, like iSense\footnote{see
+\url{http://www.coalesenses.com/index.php?page=isense-hardware}},
+Contiki\footnote{\url{http://www.sics.se/contiki/about-contiki.html}}, and
+TinyOS\footnote{\url{http://www.tinyos.net/}}, but there is as well support for
+the diverse x86-compatible Personal Computer platforms, and the Shawn sensor
+network simulator\footnote{\url{http://shawn.sourceforge.net}}.
\subsection{Architecture}
\label{sec:wiselib:arch}
functionality, so a function call will be immediately resolved to a specific
model at compile time without the need for an additional function call as it is
the case with virtual inheritance. Furthermore, this also allows usage on
-platforms which do not have support for C++, as the bytecode generated by the
+platforms which do not support C++, as the byte code generated by the
compiler does not include C++ specific extensions (no virtual function tables,
and templates are resolved at compile time) and can be linked against any
Standard C Library.
This makes cross-platform development easily possible. For example, to implement
-a routing algorithm, one can rely on the concept of a Radio to send and receive
+a routing algorithm, one can rely on the concept of a radio to send and receive
data packets, without needing to implement code specific to the used radio
hardware. The users of that routing algorithm can now choose which radio model
they want to use, according to their needs and the underlying hardware, provided
-that their radio model also implements the same Radio concept that the routing
-algorithm uses.
+that their radio model also implements the same radio concept used by the
+routing algorithm.
\begin{figure}
\centering
\paragraph{External Interface}
The \definition{External Interface} provides access to the underlying \ac{OS},
-like iSense, Contiki, Shawn\ldots and defines concepts like a Radio or a Timer.
+like iSense, Contiki, Shawn, etc. and defines concepts like a radio or a timer.
Thus, the concepts are as generic as possible to match all supported operating
systems and provide a light-weight abstraction to the underlying \ac{OS}. These
-concepts sometimes extend the generic concepts, for example there is a TxRadio
+concepts sometimes extend the generic concepts. As an example there is a
+concept \concept{TxRadio}
which has the ability to set the transmission power on the radio. The models
-(for example an iSenseRadioModel or a ShawnTimerModel) implement these concepts
+(for example an \class{iSenseRadioModel} or a \class{ShawnTimerModel}) implement
+these concepts
on the specific operating system, and can be passed around as template
parameters.
\paragraph{Internal Interface}
The \definition{Internal Interface} defines concepts and models for data
-structures that can be used in algorithms. This allows to specialize for
-restricted platforms; for instance a wireless sensor node without dynamic memory
+structures that can be used in algorithms. This allows the specialization for
+platforms with more restricted resources; for instance a wireless sensor node
+without dynamic memory
management can use a static implementation of lists and other containers,
-whereas a full-grown desktop can use the dynamic implementation provided by the
+whereas a full-grown desktop machine can use the dynamic implementation provided
+by the
C++ \ac{STL}. For this purpose, the Wiselib also contains the
\acused{pSTL}\definition{pico Standard Template Library} (\acs{pSTL}) which
implements a subset of the \ac{STL} without the use of dynamic memory
\end{description}
\paragraph{ControlledMotion model}
-On top of the \concept{TurnWalkMotion} and \concept{Odometer} concepts builds
-the \class{ControlledMotion} model. It takes implementations of each of these
+The \class{ControlledMotion} model builds on top of the \concept{TurnWalkMotion}
+and \concept{Odometer} concepts. It takes implementations of each of these
concepts as template parameters and extends the simple turn-and-walk paradigm by
-a temporal dimension, which let the robot stop after a specific time interval.
+a temporal dimension, which makes the robot stop after a specific time interval.
In particular, it provides the following methods:
\begin{description}\item
\begin{description} % to match with the indentation level above
The class first registers a callback function at the given Odometer instance,
and then uses its distance and angle values to control the robot over the
-TurnWalkMotion instance. Everytime the state of the robot changes (i.~e. new
-data from its sensors are received), it compares the new actual values with the
+TurnWalkMotion instance. Every time the state of the robot changes (i.~e. new
+data from its sensors is received), it compares the new actual values with the
target values given by the user through the functions above, and if the actual
values exceed the target values, the robot is stopped.
particular, it manages the serial communication with the Roomba and translates
the function calls \fnfont{turn()}, \fnfont{move()} and \fnfont{stop()} of the
TurnWalkMotion concept to the according parameters for the \ac{ROI} \cmd{Drive}
-command, reads a subset of the Roomba's sensors and presents the sensor data to
-the user, and, while implementing the Odometer concept, calculates the covered
-distance and angle from the Roomba's right and left wheel rotations.
+command. It also reads a subset of the Roomba's sensors and presents the sensor
+data to the user. Finally, while implementing the Odometer concept, it
+calculates the covered distance and angle from the Roomba's right and left wheel
+rotations.
The sensor data is read from the Roomba using the \cmd{Stream} command on the
\ac{ROI}, which results in a sensor data packet (see Section
3 header/checksum bytes. There has currently been no success yet in
communicating at the higher speed of 115,200 baud.
-Also there has been research to use the distance and angle values that the
+Also research has been done to use the distance and angle values that the
Roomba itself provides (sensor packet~IDs \magicvalue{0x13} and
\magicvalue{0x14}). However, according to the \ac{ROI} Specification these
values are integer values, and the value is reset to zero every time it is read.
By using the \cmd{Stream} command on the \ac{ROI} and therefore reading these
values every 15~ms, the Roomba cannot move fast enough to increment these values
-to \magicvalue{1}, so everytime \magicvalue{0} is read. It is obvious that
+to \magicvalue{1}, so every time \magicvalue{0} is read. It is obvious that
these sensor values are not suited for such rapid evaluations, and can only be
used for larger distances and angles. Nevertheless, since the Wiselib Roomba
control needs to keep track of the Roomba's current position and orientation as
working with the Roomba's wheel encoder counts (sensor packet~IDs
\magicvalue{0x2b} and \magicvalue{0x2c}) has proven itself quite acceptable.
After a few test runs, the number of encoder counts per~mm for straight
-walks turned out as $2.27$, and for turning on the spot, $2.27 \times 115 =
+walks turned out to be $2.27$, and for turning on the spot, $2.27 \times 115 =
261.05$ encoder counts per radian, which is the number of encoder counts per~mm
-multiplicated with half the Roomba's wheelbase. So when new sensor data is read
+multiplied by half the Roomba's wheelbase. So when new sensor data is read
each 15~ms, the RoombaModel implementation calculates the \concept{Odometer}
distance and angle from these values.
projects / bachelor-thesis / written-stuff.git / blobdiff