MATRIX: A force field pattern matching method for mobile robots

In this paper we describe a method for localizing and tracking a mobile robot in the type of field used for RoboCup mid-size soccer robots. Each robot carries an omnidirectional camera which provides a 360 degree view of the robot’s surroundings. The only features that we use for localizing the robot are white lines present on the green carpet. These white lines are easy to find and discriminate – they are not too dependent on the color calibration of the camera. The MATRIX method localizes a robot in a field by testing a grid of hypothetical positions for a best fit to the data. Once localized, tracking the robot from frame to frame, in real time, can be done by combining the odometric data with the MATRIX pattern matching. 1 Mobile Robots Localization Localizing mobile robots in a known environment is easier that localizing robots in a space that has to be explored and mapped first. However, if the sensors used by the robots are noisy or if the computational capabilities of the robot are limited, localizing a robot in a known environment can also be a hard problem. This is the case in the RoboCup environment, where mobile robots compete trying to be as fast, yet as precise as possible. Usually, the robots have only a partial view of the field and color calibration tends to be difficult, due to varying lightning conditions. Also, spectators sitting or standing around the field, can be mistakenly identified with the yellow and blue poles used at the corners of the field. Therefore extensive color calibration is done by all teams before a game starts. Some groups have studied methods that could avoid work even without color information, for example, for finding the ball, but they are computationally expensive and not feasible yet [8]. It would be important to be able to depend less on the color calibration of the cameras and more on certain prominent features of the field. The white lines on the green carpet are a very good example, since they are specially prominent and easy to find. Some RoboCup teams already exploit such features in order to localize the robot. Utz et al. ([9]) work with this kind of information, but map it to Hough space which provides a kind of assessment of the number of expected features visible on the field. It is a form of pattern matching, using the information available in Hough spaces for lines and circles. Nevertheless, it is very difficult to leave the localization of a mobile soccer robot alone to the vision system. If the robot gets confusing images (because, for example, another robot is obstructing the camera), then the robot loses its initial position which can be difficult to recompute again – the robot gets lost on the field. Therefore, we need a method for localizing the robot globally on the field, and another method for tracking the robot from one known position to the next [7]. Odometry is a straightforward method for disambiguating vision data. Human soccer players do not look at the field constantly, they have a “feeling” for their current position extrapolated from the last known position. They know in which direction they have moved, and for how long, and so they only need to look occasionally to the field, in order to “recalibrate” their current position. This is also the best strategy for a mobile robot, specially since odometric data tends to be much more precise than data for legged robots. Our mid-size robots can drive forward for about three meters, and the localization error after stopping is just several centimeters (just how many, depends on the velocity and direction of the robot). A combination of odometric with vision data can reduce the load on the control computer enormously. Instead of having to process each frame of a video in search of field features, it would be possible to track the robot during short periods based fully on the reported odometry, while the vision can recalibrate the odometric data periodically, for example once a second. Then only one frame every second has to be fully processed for determining the robot’s position, while the odometry is reaching the robot in a continuous stream. Of course, for finding the ball and going for it, it is important to process 30 fps, but only in order to find the orange blob inside the field. Since our localization method is so fast, we can even use it to correct the robot position in every frame. One problem with odometry data is that, in the case of omnidirectional robots, three wheels produce the desired movement, sometimes by working against each other. The wheels should not slip on the floor, and if they do, the odometry data has to be corrected to take this slippage into account. In this paper we present a method to correct the odometry data. 2 Localization in a flat featured environment A flat featured environment is one in which lines on the otherwise featureless floor provide position information. This is the case of the RoboCup environment, in which white lines on a green carpet delineate a soccer field of up to 10 meters long by 5 meters wide. We would like to localize the mobile robot using this information. Fig. ?? shows a picture of the field and the markers used. One goal box is blue, the other yellow. The poles at the four corners are painted yellow and blue. The frame captured by an omnidirectional camera is processed by our mobile robot, which tracks regions in the field using an algorithm described elsewhere (cite). The robot then looks for color transitions between green and white, and dark and white. This color transitions represent possible lines on the field, that we want to identify and track. Fig. 1 shows a cloud of points, from the perspective of the robot. The dark spots represent edges between white and green colors, or viceversa. It is easy for a human to match this cloud to a model of the field, but it has to be done automatically by the robot and in only a few milliseconds. −300 −200 −100 0 100 200 300 −200 −150 −100 −50 0 50 100 150 200 250 300 Fig. 1. A cloud of vision data points representing white lines on the field, from the perspective of the robot 2.1 Global localization If the robot does not have its initial position, we use a pattern matching approach to find the best possible hypothesis. The idea is the following. If we have the cloud of vision points, we can rotate it several times (for example 16 times) and then we can translate each rotated cloud to each of several hypothetical regions of space (see Fig. 2, left). These position hypotheses form a grid on one half of the field (Fig. 2, right). We only use one half of the field, because the other half is symmetrical. The robot can be localized on one side or the other. Additional information has to be used to disambiguate the choice (like the color of the box goals seen). Given the rotation and centering of the cloud, the quality of the match to the field is measured by computing, for each point, the distance to the nearest segment or circle in the model of the field. These distances are added for all points, are averaged, and the final number represents the quality of the match. To speed up the computation, we compute beforehand a matrix of distances of every element in a 100 by 70 grid to the segments and circles in the model. Given the cloud of points it then is easy to do a table look-up to associate each point with the distance to the nearest segment. A cloud of points has typically 500 to 700 points, so that the table lookup and averaging takes only a few microseconds. −300 −200 −100 0 100 200 300 −300 −200 −100 0 100 200 300 −300 −200 −100 0 100 200 300 −250 −200 −150 −100 −50 0 50 100 150 200 250 Fig. 2. The points on the field represent the hypothesis tested for global localization. 16 orientations are tested for each position. Fig. 3 shows the matrix of “qualities, that is, the distance vector from each point in a grid that covers the field (and also points outside the field) to the nearest model element. Ideally, we would like to compute the quadratic error associated with a least squares match of the cloud point to the model. However, the minimal distance function is not smooth: midway between two parallel line segments the distance vector changes direction suddenly. It is then difficult to provide an analytic model of the field, that does not contain “if” decisions. 2.2 Tracking the robot Tracking the robot can be done also by using pattern matching. The idea is to start from a known position and orientation of the robot. We rotate the cloud of points by the known orientation and translate the cloud to the known position. The cloud should be a good match of the model. If the robot moves, the next cloud from the camera (repositioned and reoriented as before) will almost match the model, but will have moved. The translation and rotation of the cloud with respect to the model is the translation and rotation of the robot. We need to compute the inverse transformation, in order to recenter the new cloud and make it fit the model as well as possible. The inverse transformation is computed iteratively. We start from the new cloud of points and compute the total average “force” on each point. The force on a point is the attraction that a segment or circle of the model exert on each point. The force is proportional to the distance to each line element. We add all forces acting on a point, but weighting them in a way that ensures that the nearest line elements have a greater contribution to the estimated force. If (x, y) are the coordinates of a point and the array `i, i = 1, . . . , 11. represents its distances to the 11 model elements, the weight wi for each single −400 −300 −200 −100 0 100 200 300 400 −400 −300 −200 −100 0 100 200 300 400