It has been approximately a month since the beginning of the project and by that moment we, among other things:
received the aluminium laser-cut base plate for the robot that we ordered from Metec.
received the motors and wheel connectors that we ordered online from Pololu.
made the “preliminary” wheels.
received the parts necessary for the motor control circuit board and soldered them together.
received the Bluetooth module ordered from Proto-PIC.
programmed the motor circuit board to communicate via Bluetooth and drive the motors.
October 10th was the day when we put those things together for the first time and could test the driving. The video below shows the robot base, remote-controlled via Bluetooth using an XBox joystick. Looks fun, doesn’t it?
When we ordered the motors we were afraid they would not be fast enough. Well here they look faster than we need (although this is not even half the final weight of the robot). However, we have some problems, too. Namely, it seems that our motor circuit board cannot handle the motors at low speeds normally. A lot of tuning awaits.
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.
Telliskivi Simulator
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
Lego 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!
By the “electronics part” of a robot we mean everything inside the chassis needed to drive the motors and kick the coilgun. Note that the smartphone, although itself a sophisticated electronic device, is not included. If the smartphone is the “brain” of our robot, then the electronics inside the chassis is the “spinal cord”.
One might think that there is really not much to do here – indeed, all of the “hard thinking” seems to be done in the brain, and the spinal cord is there just to switch the motors on and off. How hard could it be? Pretty complicated, in fact.
Motors
The simplest DC motor (the “brushed motor“) is a device which has two wires and a rotating shaft. If you connect the wires to a battery, the motor starts rotating – pretty simple. Here’s how that would look on a diagram:
A DC motor
However, this would not be sufficient for a robot – this configuration results in a continuously rotating motor, whence we would like to be able to switch it on and off. Thus, as a bare minimum, there must be a transistor and a flyback diode to allow such switching:
Switchable motor
This is still not enough, though – such a configuration only allows to rotate the motor in one direction. In order to allow the robot to move backwards, the polarity of the battery must be switchable, and this would require more scaffolding around it – the H-bridge. Various schemes for implementing the H bridge exist, some more complicated, some less and we’ll not delve into this topic here. In any case, this will add at least four additional transistors to the schematics. Luckily enough, there are chips providing all of this motor driving logic in a single package: motor drivers. Those would typically include an H-bridge together with some other useful functions, such as current monitoring to prevent overheating.
But that’s still not all of it. The H-bridge would let us switch motor both ways, but how do we control its speed? The trick here is to use pulse width modulation (PWM) for the input signal. I.e. instead of switching the “input pin” to “on” and simply letting the motor rotate at maximum speed, we shall switch the pin on and off with high frequency. Now, if on average the pin is “on” just half of the time, the motor would rotate approximately with half the maximum speed.
Microcontroller
As a result, we need a component that will generate the PWM signal at the necessary frequency. What could it be? Certainly not the smartphone – it has no facilities for such fine-grained control and has enough other duties to attend to. Hence, we need a microcontroller – essentially an additional full-blown CPU just to drive the motors. Now using a microcontroller means that we need a way to program and communicate with it – this will add a couple of additional compulsory components to the circuit.
Bluetooth
Are we done yet? No. Remember we mentioned that the only reasonable way to communicate with the smartphone is Bluetooth. Thus, we shall need a Bluetooth communication module. This is mounted on a separate board and will be communicating with the controller using the UART protocol.
Coilgun
Are we done yet? No. Remember the coilgun? In order to make the solenoid jerk (and thus kick the ball) we need to apply voltage to the coil in the same way as we did with the motor on the first figure above. However, this time this will not be battery voltage – the battery voltage is too low to provide sufficient current. Instead, we shall have a separate large capacitor, that will discharge into the coil. Conceptually:
Coilgun in principle
Of course, this diagram is incomplete. Once the capacitor has discharged, it has to be re-loaded again from the battery. Conceptually:
Coilgun in principle, step 2
Finally, in order to charge the capacitor to high voltages, we shall need to convert the 11V battery voltage to something higher, perhaps 100V or so. To do that, we need a voltage transformer together with a DC to AC converter to make it work (you can only increase voltage of alternative currents). Thus, omitting some more details, the coilgun requires a circuit like the following:
Coilgun
The coilgun charging/discharging algorithm is probably simple enough to be implementable without the need for a separate microcontroller, however doing it using a microcontroller is so much easier that we can use one here too.
Putting it all together
Are we done yet? Well, there are still a lot of small details (a fused power regulator, an IR ball detector, Hall rotation sensors on the motors), but in general that’s it. Here’s the high-level overview of the “spinal cord” for our robot:
Telliskivi Electronics
One possible indicator of the complexity of this assembly is its price. Although we shall discuss the budget in a later post, so far just take my word for it – the configuration presented above costs somewhere around €200 or more. This assumes two reasonable motors (€30 a piece at least) and a normal battery (also at least €30), yet is still a conservative estimate, which does not even include experimentation or burned parts.
The Robotex course requires participants to present their progress once each week. This automatically imposes an iterative approach to development – instead of working for a long time and coming up with a final design for the robot, we had three iterations – two preliminary drafts and the final one. The design was made using SolidEdge first (because Taavi was more familiar with it) and SolidWorks later (because Reiko was more familiar with it). Both programs are well-known industrial CAD packages. The former provides a student licence to anyone. With the latter, University of Tartu has a special arrangement for student licensing.
Here I must admit that my previous encounters with mechanical drafting was a long time ago, in high school, where we were supposed to manually draw various hypothetical 3D bodies on A4 paper and write labels using a strictly defined font. I recollect we even made one part manually according to that draft. I never enjoyed nor appreciated the course, and in fact never even understood the need for this whole drafting business: building things seemed so much easier without it. Well now I finally got it. It took me 14 years to understand the obvious. You draft something and then let other people manufacture according to it. Duh.
OK, back to the robot. Our first draft was that of a “brick on wheels” (note that this is using the N950, as this was before we got the N9). The dribbler and kicker are not present, but room is left for them. The electronics attachments are not present either, but are already planned to go onto the second floor.
Telliskivi - draft no. 1
In the second iteration, Taavi decided to position the camera higher up, on a tower. This would shift the weight backwards:
Telliskivi - draft no. 2
Finally, the third and the last iteration was completed by the beginning of October.
Telliskivi - final model
A couple of simplifications were introduced here. Firstly, the smartphone tower is now connected to the second floor – this makes it easier to assemble the robot. Secondly, the wheels are now directly mounted onto motor shafts. This means that the whole weight of the robot goes on those shafts and if our robot would have been too heavy, this might not have been a good solution. Fortunately, this is not a problem.
Note the pluggable electronics module box, designed by Reiko:
Electronics modules
The small box in the upper right is the Bluetooth module, the black bricks are batteries (why two? stay tuned for a later post). The big box below contains the printed circuit boards for controlling the motors and the coilgun:
Electronics module inside
Most of the details of the chassis are to be laser-cut from aluminum (first floor, tower, electronic box) and plastic (everything else). The aluminum cutting was ordered in Metec, and plastic cutting – in Tööstusplast.
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”:
Flash plugin or Javascript are turned off.
Activate both and reload to view the mindmap
We are not the first team to make a soccer robot. More like the first hundred thousandths. Two soccer-themed Robotex competitions have been held in Tallinn in the previous years, and the international RoboCup competition will soon celebrate its 15th anniversary. Consequently, the first thing a newborn Robotex team should do is study what kind of bicycles have been invented by our predecessors.
The anatomy of a typical soccer robot is, obviously, determined by the three tasks a robot must be capable of doing: moving around the field, detecting balls and shooting them into the opponent’s goal. The typical robot set up for solving these tasks is depicted below:
A typical soccer robot
Of course, just like people, all robots are different. There are lots of options to choose from for each of the parts.
Chassis
The chassis is what holds the robot parts together. There are three common approaches to chassis design.
The hacking approach: Make an ad-hoc construction from whatever parts you find in the lab.
The modern approach: Design the robot chassis using CAD software and order the parts to be manufactured via laser cutting from aluminum or plastic.
The main functional property of the chassis (besides precision and aesthetics) is its weight. A heavy robot is in general harder to make than a light one. On the other hand, if two robots happen to collide, the lighter one will suffer most.
Wheels
Although it is possible to have a soccer robot with legs (in fact, the international Robocup competition has separate leagues for two-legged and four-legged robots), wheels provide the most efficient way for a robot to move around the field. There are two main types of wheeled robots in Robotex.
Differential-drive robots. This is the most straightforward type. Two wheels driven by two motors allow to drive straight, follow a path or turn on the spot.
Omni-wheeled robots. Those use three or four omni wheels which allow the robot to drive sideways, drive while turning, and do all kinds of fancy kinematics. There are drawbacks, though. Omniwheels are harder to control, they introduce a lot of vibration to robot’s movement and they can be somewhat “slower” because some of them will drag during driving.
Kicker and Dribbler
Dribbler
The “dribbler” is a rotating shaft covered with rubber. As soon as the shaft touches the ball, it makes the ball rotate in the direction of the robot, thus keeping it nearby. The dribbler can be long or short. If the dribbler is long, it will be easier for the robot to “grab” the ball yet it will introduce the danger of robot grabbing more than one ball at a time, which is in violation of Robotex rules. If the dribbler is short, the robot will have to drive exactly towards the ball.
The “kicker” is a device for kicking the ball away from the robot after it has been “picked up” by the dribbler. Although in principle one can come up with numerous ways of implementing the kicker (mechanical, pneumatical), the dominant solution uses the “coilgun” principle. The idea is to use a metal bar inside a solenoid (coil). When large current is passed through the coil, magnetic field will pull the bar forward, thus producing a “kick”. Once the current stops, a spring will pull the bar back into original position.
Coilgun
Of course, having a coilgun and a dribbler is not always necessary. There have been successful teams at Robotex, whose robot would simply ram the balls with its body. There have also been peaceful robots who did not plan to shoot any balls at all, and instead spent time protecting their own goal.
Vision system
Although some brave teams dare to make a soccer robot without a camera, the majority of soccer robots observe the field using a camera. The baseline solution here is an arbitrary webcam, capable of providing around 30fps at the resolution of 640×480, mounted in front of the robot. Those teams who believe this is not good enough, have the following options:
If the frames seem blurry due to excessive vibration, the Playstation 3 Eye camera, capable of producing 120 fps, might help.
Mounting multiple cameras will increase field of view. This, however, means multiple CPUs to handle the vision processing.
Finally, using a hyperbolic mirror it is possible to observe the reflection of the whole field via a single camera.
Several other sensors may be mounted on the robot to help. A gyroscope can tell the direction towards the opponent’s goal. A proximity sensor will warn about collisions. An IR receiver can sense the beacon signals from the goals (there are special beacons set up which radiate a particular signal). Finally, a combination of an IR led with a light sensor can be used to sense when the ball is in the dribbler.
The Brain
Finally, the brain of the robot should be fast enough to be able to process the frames from the camera and sensors, make decisions, send commands to the wheels and activate the kicker when necessary. The most common choice here is a laptop, preferably a small one, such as the Asus EeePC. Alternatives include setting up a bare motherboard from a desktop computer, or using a smaller board, such as Pandaboard or Beagleboard. All those cases result in the brainpower of a single- or dual-core 1-2GHz processor, which are typically enough for a robot with a single camera.
Among all the subjects in the University of Tartu, to which a typical technically-minded student can be exposed to, the “Robotex course” (or “Robotics practice”, as it is formally called) might easily be the most demanding and the most exciting one. The aim of the course is to make a team and build a robot to compete in the upcoming Robotex competition. The theme of the competition varies from year to year, although for the last several years it has been fixed to “soccer”. The robot has to shoot as many balls from the field to the opponent robot’s goal.
The course starts in September, the competition is at the end of November, and most participants typically come having no clue about robotics whatsoever. As a result, the overall learning curve is enormously steep, the amount of work required from each team member is an order of magnitude greater than in any regular university course, and the value of teamwork is paramount. The final weeks before the contest hold a promise of numerous sleepless nights, they say.
This blog belongs to one of such teams – team codenamed “Telliskivi” (“The Brick”, in Estonian, which is supposed to highlight the simplicity of the original robot design). There are four of us here:
Andreas, a first year Computer Engineering student,
Konstantin, a PhD student in Computer Science,
Reiko, a master’s student in Computer Engineering,
and Taavi, a master’s student in Machine Engineering
We hope that our fine mix of expertise in various fields will help us make a great robot for the upcoming competition.
In the following posts we’ll gradually tell you about our progress, the problems we have on the way and the solutions we come up with. Stay tuned, feel free to comment.
