It takes time to design and manufacture the robot’s mechanical parts. It takes time to order, solder together and debug electronics. The third important component of robot development is the main soccer playing algorithm, i.e. the smartphone software, and it is important to start working on it as soon as possible. But how do you go about developing it while the chassis is not available? We used two tricks here.

The simulator

While making the real chassis is time-consuming, making a “virtual one” can take less than a day. So that’s what we actually started with on the very first day of the course – developing a simplistic software simulator, emulating a two-wheeled robot on a football field. The robot can “sense” the balls on the field as well as the opponent’s goal using a simulated camera. It can move around by setting the speed of its two wheels.

Such a simulated robot makes it possible to write a soccer-playing control algorithm, not unlike the one we shall be using on the real machine. The control algorithm can connect to this simulated robot via TCP/IP and send commands such as “wheels <a> <b>” (set wheel speeds). This is equivalent to the smartphone connecting to the chassis via Bluetooth and sending the same “wheels” command.

The simulator is written in Python, and the core of it is about 350 lines of code, including comments and doctests. The code is hosted on github here, and everyone is welcome to use it and contribute. It is fairly easy to add custom robot models to it, and in fact, on one of the practice sessions we managed to have a small simulated soccer match against Team Spirit. We lost, because of our attempts to introduce last-minute changes to our algorithm, which happened to break it completely. Thus, the simulator managed to simulate an actual emergency at a competition.

We would like to believe that our simulator was at least in part what motivated Team Spirit to take a go at simulator development themselves, and end up with a way more sophisticated piece of software with better physics engine (JBox2d), better visualization facilities and perhaps better modularity (albeit a more complicated architecture). It is also freely available from github, take a look.

The NXT prototype

The second trick that has been enormously helpful in the first steps of software development was to take a Lego NXT constructor kit, and hack up a two-wheeler with a simple camera mount. In fact, it was enough to take the “default” NXT robot, turn the position of the NXT brick around, and connect a couple of blocks on top of it for holding the phone.

The NXT brick can be controlled via Bluetooth. The protocol does not seem to be documented anywhere, but some peeks into the source code of the nxt-python package helped to decipher it. Thus way before the mechanics and electronics of the actual Telliskivi robot were ready, we got the opportunity to work on the smartphone code: establishing the Bluetooth connection, checking connection latency and getting the first attempts at ball detection from a camera mounted on an actual moving robot.

In fact, the N9-controlled NXT is a rather fun toy in itself!