Ausarbeitung/wiselib.tex

   1 \section{Wiselib}
   2 The \definition{Wiselib}\cite{wiselib} is a C++\index{C++} algorithm library for
   3 sensor networks, containing for example algorithms for routing, localization and
   4 time synchronization, and is strongly focused on portability and cross-platform
   5 development. In particular, it allows the user to develop applications that run
   6 on different hardware platforms without the need to change the code, and it
   7 strongly uses C++ templates to achieve that feature. Amongst the supported
   8 platforms are diverse sensor node platforms, like iSense, Contiki and TinyOS,
   9 but there are as well implementations for the diverse x86-compatible Personal
  10 Computer platforms, and the Shawn sensor network simulator.
  11
  12 \subsection{Architecture}
  13 \paragraph{Concepts and Models}
  14 Wiselib makes strong uses of \definition{concepts} and \definition{models} as
  15 central design objects. Concepts serve as an informal description of interfaces,
  16 only existent in documentation, defining expected parameters and types. Models
  17 however implement these interfaces in C++ code while fulfilling their
  18 specification. The Wiselib algorithms can in turn rely on the concepts as a
  19 generic specification, and take models as template parameters to use their
  20 functionality, so a function call will be immediately resolved to a specific
  21 model at compile time without the need for an additional function call as it is
  22 the case with virtual inheritance. Furthermore, this also allows usage on
  23 platforms which do not have support for C++, as the bytecode generated by the
  24 compiler does not include C++ specific extensions (no virtual function tables,
  25 and templates are resolved at compile time) and can be linked against any
  26 Standard C Library.
  27
  28 This makes cross-platform development easily possible. For example, to implement
  29 a routing algorithm, one can rely on the concept of a Radio to send and receive
  30 data packets, without needing to implement code specific to the used radio
  31 hardware. The users of that routing algorithm can now choose which radio model
  32 they want to use, according to their needs and the underlying hardware, provided
  33 that their radio model also implements the same Radio concept that the routing
  34 algorithm uses.
  35
  36 \begin{figure}
  37   \centering
  38   \includegraphics[width=.8\textwidth]{images/Wiselib-Arch.pdf}
  39   \caption{Wiselib architecture\label{fig:wiselib-arch}}
  40 \end{figure}
  41 Besides algorithms, and basic concepts and models, the Wiselib also consists of
  42 two other main parts: the internal interface and the external interface (see
  43 Figure \ref{fig:wiselib-arch}).
  44
  45 \paragraph{External Interface}
  46 The \definition{External Interface} provides access to the underlying \ac{OS},
  47 like iSense, Contiki, Shawn\ldots and defines concepts like a Radio or a Timer.
  48 Thus, the concepts are as generic as possible to match all supported operating
  49 systems and provide a light-weight abstraction to the underlying \ac{OS}. These
  50 concepts sometimes extend the generic concepts, for example there is a TxRadio
  51 which has the ability to set the transmission power on the radio. The models
  52 (for example an iSenseRadioModel or a ShawnTimerModel) implement these concepts
  53 on the specific operating system, and can be passed around as template
  54 parameters.
  55
  56 \paragraph{Internal Interface}
  57 The \definition{Internal Interface} defines concepts and models for data
  58 structures that can be used in algorithms. This allows to specialize for
  59 restricted platforms; for instance a wireless sensor node without dynamic memory
  60 management can use a static implementation of lists and other containers,
  61 whereas a full-grown desktop can use the dynamic implementation provided by the
  62 C++ \ac{STL}. For this purpose, the Wiselib also contains the
  63 \ignoreoutput{\ac{pSTL}}\definition{\acl{pSTL}} (\acs{pSTL}) which implements a
  64 subset of the \ac{STL} without the use of dynamic memory allocation.
  65
  66 \paragraph{Stackability}
  67 Another central design principle used in the Wiselib is
  68 \definition{stackability}, which describes the possibility to stack
  69 implementations of the same concept, thereby building a layered structure. For
  70 example, one could stack a cryptography algorithm on top of a radio model, which
  71 both implement the Radio concept. In this case, the cryptography layer doesn't
  72 have to know anything at all about the underlying implementation, as long as it
  73 can use the Radio concept of the underlying layer. And it can even provide the
  74 same interface to a possibly higher layer in order to provide transparent packet
  75 de- and encryption over the radio.
  76
  77 \subsection{Roomba Control}
  78 Even more interesting is the fact that the Wiselib includes code to control an
  79 iRobot Roomba\index{Roomba} over a serial interface, and getting access to its
  80 internal sensor data, using the \acl{ROI}\index{\acl{ROI}} mentioned earlier.
  81 For this purpose, it defines two concepts for Robot Motion:
  82
  83 \paragraph{TurnWalkMotion concept}\index{TurnWalkMotion (concept)}
  84 Concept of a simple robot that can turn and walk straight, without time
  85 awareness
  86 \begin{description}
  87   \item Types:
  88     \begin{description}
  89       \item[\code{velocity\_t}] Type for velocity measurement
  90       \item[\code{angular\_velocity\_t}] Type for angular velocity measurement
  91     \end{description}
  92   \item \todo{clearpage?} Methods:
  93     \begin{description}
  94       \item[\code{int turn(angular\_velocity\_t)}] turn the robot with a
  95         constant angular velocity
  96       \item[\code{int move (velocity\_t)}] move the robot straight with a
  97         constant velocity
  98       \item[\code{int stop()}] stop the robot
  99       \item[\code{int wait\_for\_stop()}] hold the execution until the robot has
 100         stopped
 101     \end{description}
 102 \end{description}
 103
 104 \paragraph{Odometer concept}\index{Odometer (concept)}
 105 Concept of a class tracking motions over time. Whenever the object turns, or
 106 moves, internal counters will adjust their guessing of the objects traveled
 107 distance and current orientation.
 108 \begin{description}
 109   \item Types:
 110     \begin{description}
 111       \item[\code{angle\_t}] Type for angle measurement
 112       \item[\code{distance\_t}] Type for distance measurement
 113     \end{description}
 114   \item Methods:
 115     \begin{description}
 116       \item[\code{angle\_t angle()}] return the current angle
 117       \item[\code{int reset\_angle()}] reset the angle of the object
 118       \item[\code{distance\_t distance()}] return the current distance
 119       \item[\code{int reset\_distance()}] reset the distance of the object
 120       \item[\code{int register\_state\_callback (T *obj)}] register a callback
 121         that gets called when the state changes
 122       \item[\code{int unregister\_state\_callback (int)}] unregister a
 123         previously registered callback
 124       \item[\code{int state()}] return the current state
 125     \end{description}
 126 \end{description}
 127
 128 \paragraph{Implementation}
 129
 130 \todo{cite Wisebed book chapter on Roomba code}
 131 \todo{which roomba sensors were used?}