Once we know the background, planning the robot becomes a matter of simple decisions. As we are strictly limited in our time (two months to build the robot from scratch) and lack previous robotics experience, simplicity becomes the first priority. Consequently, the dumbest differential drive system with a single webcam is what we shall be building. There are some details here, though.

Dribbler and kicker

In our quest for simplicity we would even consider avoiding the dribbler and the kicker, hoping to just ram the balls into the goals. Such an approach, however, seems risky, as it is not immediately clear how easy it is to control the robot with sufficient precision. Moreover, we do not know of any successful differential-drive ramming robots in Robotex. Hence we split our plan in two sequential iterations:

• Stage A: Making a differential-drive robot which is capable of ramming and trying to see whether it is possible to implement a reasonable control algorithm.
• Stage B: Adding the coilgun and dribbler to the robot and switching to a simpler “approach the ball, grab the ball, rotate towards the goal, kick” algorithm.

Smartphone

In order to make things interesting and have our robot stand out from the crowd, we decided to use a smartphone for both the brain and the camera. Nowadays smartphones pack all the necessary brainpower together with a camera in a small lightweight package. Konstantin had a Nokia N950  to spare, and it seemed to fit the bill – 1GHz processor, built-in camera, programmable using familiar C/C++ on a Linux platform.

Later on we used our choice of the phone as an excuse to ask Nokia to support us, and Nokia kindly provided us with their latest and greatest Nokia N9 model to use with the robot, yay!

Bluetooth

The choice of a smartphone for the brain, however, did not come without a complication. Namely, the only reasonable way for the phone to communicate with the chassis is Bluetooth. Why not USB, you might ask? Well, USB turns out to be an asymmetric protocol, where each device is pre-set to play a role of a “master” or a “slave”. The phone is always a “slave” and we would have a hard time making the chassis hardware play the role of a “master”. An alternative idea would be to use the phone’s headphone/microphone jack for communication, however this would require us to implement nontrivial modulation/demodulation protocols and we do not have time for that. Hence, Bluetooth it is.

Omitting some other details of the overall planning procedure, let us just show the finalized plan for our soon-to-be-made robot, which got named “Telliskivi” (“The Brick”), in honour of the simplicity of our “Stage A”: