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 and Odometer 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 8N1 (8 data bits, no parity, 1 start/stop bit), 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~\magicnumber{0x2b}, \magicnumber{0x2c}, 2+2 bytes), \emph{battery
+voltage/current/charge/capacity} (IDs~\magicnumber{0x16}, \magicnumber{0x17},
+\magicnumber{0x19}, \magicnumber{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 \magicnumber{0x13} and
+\magicnumber{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 \magicnumber{1}, so everytime \magicnumber{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
+\magicnumber{0x2b} and \magicnumber{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 covered distance and
+the turned 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