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}
\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.
+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 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.
+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~\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
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.
-
+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