\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~\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 +
+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 \magicnumber{0x13} and
-\magicnumber{0x14}). However, according to the \ac{ROI} Specification these
+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 \magicnumber{1}, so everytime \magicnumber{0} is read. It is obvious that
+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
-\magicnumber{0x2b} and \magicnumber{0x2c}) has proven itself quite acceptable.
+\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
projects / bachelor-thesis / written-stuff.git / blobdiff