Robot Soccer at the RoboCup Small Size League 2012
I worked on a robot for the RoboCup Small Size League (SSL), the fast-paced robot-soccer competition where small autonomous robots play soccer against one another.
My role was on the mechanical side of the UBC Thunderbots. My main project was the dribbler: the mechanism at the front of the robot that catches the ball, keeps it under control, and passes back a signal to the robot’s microcontroller when it has possession.
What Is RoboCup SSL?
RoboCup SSL is an autonomous robotic-soccer league. Two teams of small, omnidirectional robots play on the same field, using an overhead camera system to track the robots and ball. Team software turns that shared view of the field into strategy and motion commands sent wirelessly to the robots.

Each robot needs to do several things well:
- Move sideways, forward, backward, and rotate independently
- Receive and retain a moving ball
- Kick the ball along the ground or chip it over another robot
- Survive collisions, vibration, field debris, and the general chaos of a soccer match
The robots combine mechanical design, electronics, motor control, sensing, embedded systems, computer vision, artificial intelligence, wireless communication, and manufacturing. SSL robots commonly use four-wheel omnidirectional drives, a solenoid-based kicking system, and an active dribbler.
How the Robot Plays
The robot itself is one part of a larger system.
1
2
3
4
5
6
7
8
9
10
11
12
13
Overhead cameras observe the field
↓
Vision software estimates robot and ball positions
↓
Team strategy chooses an action
↓
Commands are sent to each robot
↓
Omnidirectional wheels move the robot into position
↓
Dribbler receives the ball
↓
Kicker or chipper shoots, passes, or clears it

The omnidirectional drivetrain is important because a robot can move in one direction while keeping its front pointed somewhere else. It can travel sideways while facing the ball, rotate while approaching a pass, or keep the dribbler aligned with the goal.
At the front of the robot, the dribbler receives and controls the ball. Behind it, a kicker launches the ball along the ground, while a chipper sends it into the air. In the 2012 robot, the kicking mechanism used a solenoid and plunger: energising the coil drove the plunger forward to strike the ball, while a rubber band returned it to its resting position.
The Dribbler
I designed the dribbler: the ball-handling mechanism at the front of the robot.
Its main component is a motor-driven roller. When the roller contacts the ball, friction applies backspin. That backspin makes the ball roll toward the robot, allowing it to retain possession while it moves, turns, or lines up a kick.

Catching the ball required more than spinning a roller. A fast incoming ball could bounce away if I made the mechanism too rigid. I therefore designed the dribbler to absorb impact energy without making it too large, heavy, fragile, or the need to remove many parts for servicing.
The previous year’s design had three main shortcomings: the breakbeam sensor mount could become misaligned, the shock-absorber system was too stiff to catch the ball effectively, and it lacked a way to determine the ball’s lateral position. For the 2012 robot, I focused on improving ball retention and making the possession sensor more reliable.
Designing for Ball Possession
I designed the revised dribbler around a straight roller and a moving, spring-returned assembly.
When the ball entered the dribbler, the assembly could move backward and compress springs instead of acting as a fixed surface. This reduced rebound and gave the roller more opportunity to apply backspin and pull the ball toward the robot.
I used a simplified impact analysis to guide the design. For an incoming golf ball moving at up to 810 m/s, the model suggested that a dribbler mass of about 155 g would bring the ball’s outgoing speed close to zero. I removed mass where practical and brought the assembly below that target, so that the ball and dribbler would tend to move backward together after impact rather than send the ball forward again.
I also kept the geometry within the league’s ball-coverage rule. The finished design covered about 18 percent of the ball’s planform area, leaving a small margin below the 20 percent limit.
Knowing When to Kick
I added a breakbeam sensor to determine whether the robot had possession of the ball.
I mounted an emitter and receiver across the dribbler so that the ball interrupted the beam once it reached the roller. The control software could use that interruption as a possession signal and allow the robot to kick only when the ball was in position.
The prior sensor mount relied on glue and frequently lost alignment. I replaced it with a mechanically constrained mount that used screws to clamp the sensor in place. This avoided glue, made installation more repeatable, and was designed to remain aligned through a full match.
The North American Open
Before RoboCup in Mexico City, the team hosted and competed in the 2012 Small Size League North American Open at the University of British Columbia. The event included Thunderbots, ER-Force from Germany, and ZJUNLict from China, and served as preparation for the international competition.
The mechanical work was largely complete, but electrical board testing, firmware, and some parts were not ready. The team improvised by adapting older electrical boards to the newer robots, helped by the decision to include mounting holes for the old boards. In the first match, only three of six robots could take the field, none could read the breakbeam at the microcontroller level, and the motion controller was not operating well. The result was a 10–0 loss to ZJUNLict.
The breakbeam problem was particularly frustrating. The robots could handle the ball but could not reliably recognise possession, so they did not know when to kick. Ambient infrared light from the field lighting also interfered with the sensors: a sensor that worked in the workspace did not necessarily work on the field.
That experience made the dribbler’s sensor mounting and repeatable operation much more than a theoretical design requirement.
RoboCup Mexico City
Almost immediately after the North American Open, the team flew to RoboCup 2012 in Mexico City.
The tournament began slowly. Thunderbots had to forfeit its first game against Immortals because the robots were not ready. Once three robots were operating, the team lost 1–0 to Georgia Tech’s RoboJackets. But by the match against RoboFEI, four robots were operating well: the mechanical systems, electronics, and AI came together, the robots intercepted balls and shot at goal, and the team scored. The game ended 1–1, but seeing the system work was the satisfying.
The final official match was the first time the team fielded all six robots. Thunderbots beat BRocks of Turkey and finished the group stage with one win, one tie, and two losses-13th out of 20 teams. Considering that the team had arrived with no fully working robots, that was a satisfying recovery.
The dribbler design performed better than the previous year’s version. Team members observed that it retained the ball without the previous bouncing behaviour, and the breakbeam system worked more reliably after the earlier problems at the North American Open. The design met its stated requirements, including the no-glue sensor mount, ball-contact detection, cost target, and ball-coverage constraint.
There were still failures and opportunities to improve:
- A collision bent one breakbeam mount, requiring it to be straightened.
- One dribbler shaft shifted during play, which stalled and burned out a dribbler motor.
- Some mounting-hole tolerances could make the roller gearing too tight.
- Springs could fall out during maintenance and were easy to lose.
- Higher roller speeds and different roller materials remained worth testing.
- The impact-energy dissipation system needed improvement for faster incoming balls.


The wider robot also exposed problems. Kicker heads bent after striking fixed field objects, turf accumulated inside the chassis and could slow wheels, and the kicker’s rubber-band return mechanism often needed replacement after a game.