The Autonomous Mobile Robot Group

Department of Computer Science
Northwestern University

Final Projects

Ball Fetcher

Our project was to design a program that would fetch a green ball and return it to the robot’s starting position. Using the GIRL color and tracker code provided by Aaron, we implemented a plan-based system, and divided the task into 4 separate actions: find-ball, goto-ball, turn-back, and return-to-start. We assumed that there would be no obstacles between the robot’s starting point and the ball’s position. In order to retrieve the ball, we would have to somehow move to a position that would allow the robot to return the ball home. One way would have been to move the robot behind the ball and push it back. However, this would raise the problem of how to remember the ball’s position while the robot goes around it, as it would leave the robot’s view. Also, we would then have to account for obstacles around the ball. Instead, we decided to have the robot move towards the ball and “catch” it with a pair of flaps that we designed, and to push it back.

We initially built the flaps as two pieces of cardboard mounted unto the robot, braced against the sides. Unfortunately, in our initial tests the friction between the ball, carpet and flaps caused the flaps to bend excessively, allowing the ball to escape. We needed some kind of mechanism that would let the ball into a catchment area and not allow it to leave. To do so we designed a set of flaps with “doors” that were tied with strings to only open inward, with very loose hinges. The ball would open the doors and roll in. When the robot rotated, the ball would push against the doors, which would not open enough to let it out.

In the first action, find-ball, the robot would orient itself in the direction of the ball. If the ball is initially within the robot’s field of view, it would simply turn towards the direction of the ball. Otherwise, it would rotate around until it sees it. In this case it would rotate in the direction of the smallest sonar reading at the start of the program. This is based on the possibility that the object sensed is the ball being sought. Of course, this did not work very well because a) sonar is inaccurate and b) the direction of the person who presses the start switch would often be picked as the turning direction. Of course, the direction of turning was not really an issue, so we left that in because randomness seemed a little crude. The robot will rotate until the ball is horizontally centered within its field of view.
Goto-ball would then kick in, and the robot will head towards the ball. The goto-ball action just heads the robot towards the ball while keeping the ball centered in its view. However, in some of our tests we found that the doors of the flaps would not open, and instead push the ball away. To counter this, once the ball is at the bottom of the view we would accelerate slightly to catch the ball.

Then, the robot would reorient itself to return back to start. It would calculate the angular direction of the position (0,0), which is the starting point, and reorient itself to that direction. It would then enter the return-to-start action, and return to that point. Of course, it never really returned to its exact starting location, due to inaccuracies with the robot’s odometry.

Of course we had several problems aside from that. The color code tended to behave erratically, and often had to be retuned for even slightly different lighting conditions. It would also fail to detect the ball if it did not start up seeing it, so the “rotate-until-find” part does not always work. We had initially planned to expand it to be able to search for the ball if it did not find it after rotating, where it would follow a simple free-space wanderer until it saw the ball, and some how return the ball to its starting point. Unfortunately, working out the bugs and fine-tuning our program proved to be too time-consuming.

Note : I apologize for the lack of images or video for this project. There was, at one time, a video of this project in action. Unfortunately, it was lost to the mists of time before we had an opportunity to digitize it. -- Aaron

AMRG home