continued reading

documentation/jonas.tex

@@ -45,7 +45,7 @@ camera frames.
 In the \textbf{Head Adjustment} part all necessary head movements are covered.
 In this part of the algorithm the head is rotated by a calculated angle, which
 depends on the ball yaw angle, which was provided by the \textbf{Ball
-  Detection} part. Therefore, the ball should now be aligned in the center of
+  Detection} part. Therefore, the ball should now be aligned in the centre of
 the robots' camera frames. If the angle between the head and the rest of the
 body is now below a specified threshold, the ball is locked and the algorithm
 stops, otherwise the algorithm continues with \textbf{Body Adjustment}.
@@ -56,7 +56,7 @@ current movement. Then the robot starts to rotate around its z-axis depending
 on the current head yaw angle. To ensure that the head and body of the robot
 are aligned, like in the beginning of the whole algorithm, the head is rotated
 back into zero yaw. The algorithm continues then with another \textbf{Ball
-  Detection}, to ensure that the robot is properly centered at the ball.
+  Detection}, to ensure that the robot is properly centred at the ball.
 
 The proposed algorithm provided decent results during many test runs. It allows
 the robot to align itself to the ball fast, while some strategies are in place

documentation/perception.tex

@@ -11,8 +11,8 @@ image itself needs to be transformed into HSV colorspace, so that the regions
 of interest can be extracted into a \textit{binary mask}. The contours of the
 regions can then be identified in a mask \cite{contours}, and the areas of the
 regions can be calculated using the routines from the OpenCV library. The
-center and the radius of the region with the largest area are then determined
-and are assumed to be the center and the radius of the ball.
+centre and the radius of the region with the largest area are then determined
+and are assumed to be the centre and the radius of the ball.
 
 \begin{figure}[ht]
   \includegraphics[width=\textwidth]{\fig ball-detection}
@@ -30,13 +30,13 @@ binary mask with erosions and dilations, which allowed us to detect the ball
 even over long distances.
 
 The advantages of the presented algorithm are its speed and simplicity. The
-major downside is that the careful color calibration is required for the
+major downside is that a careful color calibration is required for the
 algorithm to function properly. If the HSV interval of the targeted color is
-too narrow, then the algorithm might miss the ball; if the interval is too
-wide, then other big red-shaded objects in the camera image will be detected as
+too narrow, the algorithm might miss the ball; if the interval is too
+wide, other big red-shaded objects in the camera image will be detected as
 the ball. A possible approach to alleviate these issues to a certain degree
 will be presented further in the section \ref{p sec field detect}. To
-conclude, we found this algorithm to be robust enough for our purposes, if the
+conclude, we found this algorithm to be robust enough for our purposes, if a
 sensible color calibration was provided.
 
 \section{Goal Detection}
@@ -64,7 +64,7 @@ contours with the largest areas are considered further (in our experiments it
 was empirically determined that $N=5$ provides good results). Furthermore, all
 convex contours are rejected, since the goal is a highly non-convex shape.
 After that, a check is performed, how many points are necessary to approximate
-the remaining contours. The motivation behind this is the following: it is
+the remaining contours. The motivation behind this is the following: It is
 clearly visible that the goal shape can be perfectly approximated by a line
 with 8 straight segments. On an image from the camera, the approximation is
 almost perfect when using only 6 line segments, and in some degenerate cases
@@ -74,7 +74,7 @@ of line segments to be approximated is probably not the goal. The preselection
 stage ends here, and the remaining candidates are passed to the scoring
 function.
 
-The scoring function calculates, how different are the properties of the
+The scoring function calculates, how different the properties of the
 candidates are from the properties, that an idealized goal contour is expected
 to have. The evaluation is happening based on two properties. The first
 property is based on the observation, that the area of the goal contour is much
@@ -90,7 +90,7 @@ scoring function can then look like the following:
 
 The contour, that minimizes the scoring function, while keeping its value under
 a certain threshold is considered the goal. If no contour scores below the
-threshold, then the algorithm assumes that no goal was found. An important note
+threshold, the algorithm assumes that no goal was found. An important note
 is that the algorithm is designed in such a way, that the preselection and
 scoring are modular, which means that the current simple scoring function can
 later be replaced by a function with a better heuristic, or even by some
@@ -104,7 +104,7 @@ Figure \ref{p figure goal-detection} demonstrates the algorithm in action. On
 the right is the binary mask with all found contours. On the left are the goal,
 and one contour that passed preselection but was rejected during scoring.
 
-One downside of this algorithm, is that in some cases the field lines
+One downside of this algorithm is that in some cases the field lines
 might appear to have the same properties, that the goal contour is expected to
 have, therefore the field lines can be mistaken for the goal. We will describe,
 how we dealt with this problem, in the section \ref{p sec field detect}.
@@ -129,7 +129,7 @@ objects on the field are properly consumed.
 Such rather simple field detection has two important applications. The first
 one is that the robot should be aware, where the field is, so that it doesn't
 try to walk away from the field. Due to time constraints, we didn't implement
-this part of the behavior. The second application of field detection is the
+this part of the behaviour. The second application of field detection is the
 improvement of the quality of goal and ball recognition. As was mentioned in
 the section on ball detection, the current algorithm might get confused, if
 there are any red objects in the robot's field of view. However, there

documentation/solintro.tex

@@ -5,29 +5,29 @@ completed, which are:
 
 \begin{enumerate}
 
-  \item Ball detection;
+  \item Ball detection
 
-  \item Goal detection;
+  \item Goal detection
 
-  \item Field detection;
+  \item Field detection
 
-  \item Turning to ball;
+  \item Turning to ball
 
-  \item Distance measurement;
+  \item Distance measurement
 
-  \item Approach planning;
+  \item Approach planning
 
-  \item Ball approach;
+  \item Ball approach
 
-  \item Goal alignment;
+  \item Goal alignment
 
-  \item Ball alignment;
+  \item Ball alignment
 
-  \item Kick.
+  \item Kick
 
 \end{enumerate}
 
 In this chapter we will give our solutions to the problems posed by each of the
 milestones, and at the end the resulting goal scoring strategy will be
 presented. We will now start with the lower level detection milestones and
-will gradually introduce higher level behaviors.
+will gradually introduce higher level behaviours.

documentation/tools.tex

@@ -56,15 +56,14 @@ to ensure their proper functioning on the robot.
 \section{Rejected Software Alternatives}
 
 Here we will briefly discuss what alternative options were available for the
-choice of the base framework, and why we decided not to use those. One
+choice of the base framework and why we decided not to use those. One
 available option was the official \textit{NAOqi C++ SDK}. Being based on the
-C++ language, this SDK can naturally be expected to have better performance and
-be more resource-efficient, than the Python-based version. We still chose the
+C++ language, this SDK can naturally be expected to have better performance and to be more resource-efficient, than the Python-based version. We still chose the
 Python SDK, because C++ is not particularly suitable for fast prototyping,
 because of the complexity of the language. It is also worth noting, that we
 never really hit the performance constraints, that couldn't have been overcome
 by refactoring our code, but in the future it might be reasonable to migrate
-some of the portions of it to C++.
+some portions of it to C++.
 
 Another big alternative is \textit{ROS} \cite{ros} (Robotic Operating System).
 ROS is a collection of software targeted at robot development, and there exists
@@ -79,7 +78,7 @@ in ROS, it should be possible in the future to incorporate our work into ROS.
 Finally, as was already mentioned in the introduction, \textit{B-Human
   Framework} is a popular choice for beginners, thanks to the quality of the
 algorithms and good documentation. However, B-Human has been in development
-over many years and is therefore a very complex system. The amount time needed
+over many years and is therefore a very complex system. The amount of time needed
 to get familiar with the code, and then to incorporate our changes would have
-been too big, for this reason we decided to use the simpler option as a
+been too big. For this reason we decided to use the simpler option as a
 starting point.