management can use a static implementation of lists and other containers,
whereas a full-grown desktop can use the dynamic implementation provided by the
C++ \ac{STL}. For this purpose, the Wiselib also contains the
-\ignoreoutput{\ac{pSTL}}\definition{\acl{pSTL}} (\acs{pSTL}) which implements a
+\acused{pSTL}\definition{\acl{pSTL}} (\acs{pSTL}) which implements a
subset of the \ac{STL} without the use of dynamic memory allocation.
\paragraph{Stackability}
For this purpose, it defines two concepts for Robot Motion:
\paragraph{TurnWalkMotion concept}\index{TurnWalkMotion (concept)}
-Concept of a simple robot that can turn and walk straight, without time
-awareness
+This concept represents a simple robot that can turn on the spot and walk
+straight, without automatic stopping.
\begin{description}
\item Types:
\begin{description}
\end{description}
\paragraph{Odometer concept}\index{Odometer (concept)}
-Concept of a class tracking motions over time. Whenever the object turns, or
-moves, internal counters will adjust their guessing of the objects traveled
-distance and current orientation.
+This concept represents an Odometer which tracks motions over time.
+Whenever the object turns or moves, internal counters will adjust their
+guessing of the object's traveled distance and current orientation.
\begin{description}
\item Types:
\begin{description}
\end{description}
\end{description}
-\paragraph{Implementation}
+\paragraph{ControlledMotion class}\index{ControlledMotion (class)}
+On top of the TurnWalkMotion and Odometer concepts builds the
+\definition{ControlledMotion} model. 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.
+In particular, it provides the following methods:
+\begin{description}
+ \item[\code{int move\_distance(distance\_t, velocity\_t)}] move the robot
+ straight by a given distance with a given velocity
+ \item[\code{int turn\_about(angle\_t, angular\_velocity\_t)}] turn the robot
+ about a given angle with a given angular distance
+ \item[\code{int turn\_to(angle\_t, angular\_velocity\_t)}] turn the robot
+ to a given orientation with a given angular distance
+\end{description}
+
+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
+target values given by the user through the functions above, and if the actual
+values exceed the target values, the robot is stopped.
+
+\paragraph{Underlying Roomba Implementation}
+The actual communication with the Roomba is done in the \definition{RoombaModel}
+class. It implements the aforementioned TurnWalkMotion \index{TurnWalkMotion
+(concept)} and Odometer \index{Odometer (concept)} concepts and therewith allows
+the interaction with a ControlledMotion instance. In particular, it manages the
+serial communication with the Roomba and translates the function calls
+\code{turn()}, \code{move()} and \code{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.
+
+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
+\ref{sec:roi-stream-packet}) every 15~ms, and $66.67$ packets per second. At a
+speed of 19,200 baud in mode \ac{8N1}, the maximum size of a data packet is
+$19,200 \div (66.67 \times 9) = 32$ byte, so at the moment only the sensor
+packets \emph{encoder counts left/right} (IDs~\magicvalue{0x2b},
+\magicvalue{0x2c}, 2+2 bytes), \emph{battery voltage/current/charge/capacity}
+(IDs~\magicvalue{0x16}, \magicvalue{0x17}, \magicvalue{0x19},
+\magicvalue{0x1a}, 2+2+2+2 bytes) are streamed, which add up to 18 data bytes +
+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
+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
+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
+fast as possible to maintain a certain accuracy in movement, the distance and
+angle values as provided by the Roomba itself cannot be used. On the other hand,
+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 =
+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
+each 15~ms, the RoombaModel implementation calculates the Odometer
+\index{Odometer (concept)} distance and angle from these values.
\todo{cite Wisebed book chapter on Roomba code}
-\todo{which roomba sensors were used?}
\ No newline at end of file
projects / bachelor-thesis / written-stuff.git / blobdiff