diff --git a/documentation/jonas.tex b/documentation/jonas.tex index 7cb49fb..2c21c48 100644 --- a/documentation/jonas.tex +++ b/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 diff --git a/documentation/perception.tex b/documentation/perception.tex index 6bb008c..41b4a02 100644 --- a/documentation/perception.tex +++ b/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 diff --git a/documentation/solintro.tex b/documentation/solintro.tex index cbd57d7..9f505df 100644 --- a/documentation/solintro.tex +++ b/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. diff --git a/documentation/tools.tex b/documentation/tools.tex index 242ab5f..a6e8c0e 100644 --- a/documentation/tools.tex +++ b/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.