czech english


21st place and Best Concept Prize, Eurobot 2003

Dana is the result of our effort devoted to the Eurobot 2003 contest. We have hopefully learnt from the past mistakes (at least some of them). This robot tries hard to be both smarter and simplier at the same time than our past bots . The result is the 21st place and Best Concept Prize.

Quick Info

Dana is a successful successor of Barbora. Thus you can find the same BLDC motors (each with 600W), motherboard with AMD K6 500MHz, 128MB RAM and 128MB CompactFlash, video input, 100Mb Ethernet and of course Linux. The navigation is based on odometry and infra sensors CN70 detecting the color of the floor under the robot. Camera is used to search for the pucks. The last sensor is a bumper to provide something as a “last hope” of catching that the more advanced sensors and algos missed.



The robot is made of three main parts: boggie, hand and puck barrier for the standing pucks.


The most interesting part is the boggie, originally developed for Barbora. The boggie is very sturdy, machined in a high quality from dural (aluminum, copper, manganese and magnesium alloy). The threads give the boggie very high stability and amazing acceleration and deceleration.
Already at that time we knew some of the disadvantages — first being the odometry. However we anticipated the use of optical mice which — in theory — should give us superior odometry taking into account even skids (acctually any translation or rotation movement). The reality was somewhat different. One reason was that our field was too shiny. Another crucial point was the exact height of the mice above the surface. Because of very high magnification the optical mouse has very short depth of focus. This year we run without the mice, nevertheless we plan their reincarnation. The result so far is very inaccurate odometry. There are several causes for the errors. First of all we do not know the exact center of rotation of the robot — there is no such thing on tracked vehicle as a center of the line connecting the contact points of the wheels with the floor. Typically is the center somewhere close to the center of gravity of the robot but the exact location can shift due to the acceleration or floor irregularities. Yet another important parameter is not well defined either — R, the distance of the point of contact of a virtual wheel with a floor and the center of rotation. Its determination is complicated by the fact that the tracks have nonzero width (about 2.5cm) and also that the point of contact with the floor has different distance to the center of rotation in the middle of the track and at the end. So it happens that the theoretical R is somewhere around 14cm but the experimentaly obtained R is 19.5cm.
The value 19.5cm is the exact middle of the diagonal which means that the robot rides most on the front and back wheels and that the small wheels in between are just a pomp. The only thing that we know exactly is the distance traveled because the tracks are made of synchronous toothed belts that touch the floor with a straight surface. One revolution of the motor therefore corresponds to 14.4mm when going straight and not skiding.
Another disadvantage has appeared over time — the track tend to make the robot go straight. This effect is reinforced by the fact that Dana cannot drive the motors with low RPM but with high torque — thanks to the principle of operation of our motor controllers we can regulate only power (PWM) and not RPM. Nor it is possible to slightly break one motor. Setting one motor to 20% and the other to 4%, the robot still goes straight forward.
The last disadvantage is merely implementation flaw — the sides of the belt pulleys have been cut off so that they do not surpass the belts (the robot would then ride on the pulleys and not on the belts). But the cut off was a bit severe and the consequences too. When one track is standing still and the other under power the tracks fall off the pulleys. So far the solution is in the software, forbidding the maneuvers causing the fall off.
The propulsive unit of the robot is made of two brushless DC motors. Between the motors and the track there is two-stage gearbox made of HTD synchronous belts. The ratio is 9:100 which is approximately 1:11. The encoders in the motors give 18 pulses/rotation. The pulleys driving the tracks have 32 teeth, a tooth is 5mm. Considering all this gives us about 0.8mm/pulse.
The motors give 1480 RPM/V. The fully charged bateries give 14V (10 NiCD cells per motor) which in turn corresponds to 5m/s (18km/h) — the speed of a running man.
In reality that means that we do not use more than 20% of the available power.


The hand is made of aluminum profiles and PCB board. It can go up/down, turn and open/close. It grabs the pucks with three segment fingers. A servo with a pulley and a string drive the fingers to open and close. The other two DOF are also handled by servos. It should be mentioned that it can lift about 0.5kg into the height of 6.5cm. The front part of the robot and the hand are shaped in such a way that the even a puck laying 12cm of the axis of the robot was picked up without course correction. You can se a prototype of the hand in action in this video.

Puck Barrier

To throw off the standing pucks — that was the job of the plexiglass puck barrier at the height of 11cm above the field. The tower of three pucks passes bellow easily while a standing puck is knocked over. The robot however cannot go too fast while hitting the puck because the puck can bounce of the ground and "jump" on the hand the wrong way.

Driving the Motors and Other Outputs

Motor Controller

We use controllers TMM from MGM ComPro fitted to accept commands through serial line. They are small, light, high-performace efficient and probably the best thing you can have if you are making airplane models. However if you are making robots…
The controllers are sensorless, meaning that they do not need any sensors attached to the motor. Instead they determine the position of the rotor by sensing the back EMF. When the motor turns slowly the generated back EMF is difficult to sense and therefore the controller cannot drive the motors in low RPM.
The controllers should send a number of revolutions since last update. A “tiny” problem is that this value is always positive (even when the motor is running backward). Another "feature" is that the value should be zero when the motor is not turning which is unfortunately not true. But thanks to the manufaturer of the motors (Mega Motor company) we have older type of the motors with built-in encoder that we use for odometry calculation.

Servo Control

The control the servos we use SOS-AT from Rotta. It has worked fine thus far. However it could be easier to interface something with I2C instead of serial line. This way we have to run more cables to the hand.

Status LED

All inputs and outputs of the EzUSB microcontroller have controll LEDs connected. This is a great feature for debugging. You can faster recognize that something is not working properly. Further the outputs that are not connected to anything can be used to signal different internal states of the EzUSB.

Brake Lights

There are six high luminosity LEDs connected using the PCF8574 to the I2C bus. The LEDs can be controlled by software. We have six additional debugging elements at our disposal. If not used for debugging they can create some nice KITT (Knight Industries Two Thousand) effect .

Front Panel LEDs

On the front panel of the robot there are another two LEDs connected along with 6 buttons through PCF8574.


Another important part of the front panel is a digital voltmeter showing the joint voltage for the electronics — not the battery voltage that can be different on different packs (the robot can use up to 4 different batery packs at the same time).

TFT panel

The top side of the robot is covered with an industrial high contras TFT panel, 18-bit color depth, 800x600 pixel resolution.


IRC (Incremental Rotating Counter)

Three opto gates inside the motor encode the rotor position. There are 6 posible states determining the absolute rotor position in one period of the rotation of the magnetic flux. The motor has 6 poles meaning that we have three periods per one mechanical rotation giving the total of 18 pulses per mechanical rotation of the motor rotor.
We use the opto gates as regular incremental encoders in computer mouse — only instead of 4 states 00 → 01 → 11 → 10 we have 6. That means that even when we miss one state change we can detect the error and recover the correct pulse count.

Sensors for the Hand Position

There are no sensors dedicated to the detection of the hand position. Therefore we have no means of feedback from the hand, we cannot detect if the hand functions properly. Even the comunication between the SOS-AT module and the computer is one-way so we do not even know if the hand is alive at all. The only feedback we can use is the color detection for the puck or Sharp GP2 used to detect the tower height.

Sensor for the Puck Presence and its Color

There are two infra CNY70 sensors to detect the color of the puck in the hand (black/white). This way we can recognize if the puck should be turned, if the puck is bonus (point for us no matter which way is up) or an evil one. Another sensor on the hand is the opto gate to detect the puck presence in the hand. Everything is connected using the PCF8591 to the I2C bus.

Sensors for the Field Color

The are another 7 CNY70 connected through another two PCF8591 to the I2C bus. These are used to localize the robot using MCL algorithm.

Accelerometers, Gyros, Compass

These advanced sensors were not integrated yet. The plan is to use 12-bit A/D convertors MAX127 a MAX128 for the I2C bus to connect MEMS accelerometers, iMEMS/Piezo gyros and permalloy compass. Using these sensors we could calculate change in position which would then be used as an input in to the MCL algorithm to calculate the current position. The advantage of the approach is that the noise of the sensors does not depend on the outer conditions of the robot (field surface etc.). Some work on this field is made by the autopilot project which is interested in building an autonomous helicopter.

Optical Mice

Last year there were 4 optical mice mounted on the robot. In theory they should provide complete odometry including skids and slides. However noone can guarantee the funtionality on the fields in La-Ferté. We still have them and two of them are mounted on the robot for further testing.

Internal Camera

The robot has a cheap color PAL CMOS camera mounted on top. Using the not-so-good image grabber on the motherboard we can use 352x288 YUV422 pictures (16 bits per pixel). Sadly, when using 25 FPS the processor is running at 100% (the grabber cannot do DMA). Therefore we have developed color thresholding algorithm using only 5% of the pixels on average which seems to be working fairly well.

External Camera

We are using 2.4GHZ wireless link to connect the external camera to the robot. The camera is placed inside one of the beacons. The picture contains more noise than that of the internal camera and sometimes the signal cuts off completely. The advantage of this camera lies in its fixed position. The reciever is connected to the same image grabber as the internal camera, which means that we cannot use the cameras simultaneously. Switching the singnals from one camera to the other takes about 2 frames (100ms).


In every corner of the robot there is a sturdy microswitch wired directly to the EzUSB. The problem with the switches is that the robot must hit something perpendicular to its front/back in order for the switches to detect it. We could not make them bigger because of the spacial restriction made for the Eurobot 2003.


The front panel contains 6 buttons that can be used to control the robot when the keyboard is missing.



The computational power of the robot is composed of several processors. The motherboard contains AMD K6-2/500, 128MB SDRAM, 128MB Flash disk, 4 UARTs, parallel port, 2 USB ports, 4 video-in, stereo audio out and several audio ins. The industrial motherboard further contains LVDS, PCI and PC-104 slot.


Microcontroller EzUSB runs on 24 MHz and contains several kB of memory. It is connected using the USB bus to the PC. It also features 24 GPIO, I2C master and 2 UARTs.


The SOS-AT module is a board with AVR controller that controls up to 8 servos (we use only three in the hand). It is connected to EzUSB using a serial line running at 9600bps.


TMM are the motor controllers to drive the BLDC motors. TMM are made by MGM ComPro. They are connected using UART (19200) to the PC.

Overview of the Electrical Connections

The estimate of the wire length inside the robot is somewhere around 15m. The connector count must have reached hundreds. You can find the interconnections on the picture as you can the bus types. Red is power, blue UARTs, green I2C and purple the rest.



EzUSB runs very simple program that continualy sends the state of all inputs (I2C and GPIO) to the PC. It can also recive commands to set the hand position using the SOS-AT, it can turn on/off the power to the hand and the motors, read and set the periphery (CNY, buttons, LEDs) connected to the I2C bus. Exept this it also counts the motor revolutions using the built-in motor IRC. The polling frequenci is 3kHz which would not be possible to do from the PC directly. Only the running sum is sent to the PC. The program downloads through the USB from the PC.

Kernel of the Operating System

The main computer on the robot runs a custom fitted Linux. The hardware abstraction is dealt with in the kernel (Daisy does it through the serial line). The implementation on the kernel level allows us to screen the user-level software from the details of the electrical layout and buses (the motor controllers sit on the UARTS while the EzUSB on the USB). The kernel sends the structure input_data to the aplication. The structure describes the complete robot state. On the other side it accepts the structure output_data that contains the commands for the hardware — servo settings, motor PWM, LEDs settings…


The userspace application is one single-threaded program that works in cycle of receiving the sensor data from the robot, analyzing it and deciding the next action and sending the appropriate commands to the hardware.
The software is divided into reusable parts that are in the lib/ directory and standalone applications in the directories v0/, v1/, v2/ etc. We also have some testing utilities such as dana-io-test to test the comunication capabilities or cvtest to test the camera setup.
basic functions for the userspace-kernel communication
functions supporting the video grabber
functions such as “go-to-place”, depending on the position suggests next action — turning, straight forward…
drawing through memory mapped framebuffer
finding regions in pictures
straight forward until a puck is found, turn it the green side up and return to the starting position – video
not finished – attempt to drive the robot according to the data about the square crossings, trying to to go parallel to the field sides
drives around a rectangle using gmcl and waipoint
(joydrive, joyride) control the robot using joystick



GMCL (genetic Monte Carlo Localization) which actually has nothing to do with genetic algorithms is used to track the current position of the robot on the field. It uses input from motor encoders and from CNYs looking at the color of the field under the robot.
GMCL works fairly well but the poor quality of the odometry sometimes causes the robot to loose track of its position. One way to further improve the algorithm is to create a better model of the motion of the robot (including some of the dynamic properties). Another way is to change to path-generating algorithm to include more "cik-cak" paths that give the MCL algorithm more and better data (more corossings) to track the position. Yet another way would be to incorporate inercial sensors such as accelerometers and gyros.

Driving (Waypoints)

The driving to a set place is implemented as a simple state machine with hysteresis that decides if to go straight or turn in place. The hysteresis makes the decision process more stable and reduces oscilations.

Image Processing – Finding of the Color Regions

A simple region finding is to threshold the image into color classes and then use floodfill to connect them. For each compute the center of gravity and weight.
We have designed a faster and relatively interesting algorithm that can do all this fast (a single pass over the image). Further it is optimized to use only about 5% of the pixel data of each image because retrieving the whole image from the framegrabber memory is so slow.


When the Eurobot international finale came Dana was not as finished as we would like her to be. We knew there was still a lot of work needed on the software. What we didn't know was that the little hand for puck manipulation is going to eventualy break down. Comparing to the rest of the robot the hand was not sturdy enough. Despite of being completely hidden inside the robot it suffered several collisions. The pucks would line up in the worst way forcing the hand out of its range. Gradually its performace deteriorated so it was no longer able to manipulate the top most puck of 3-puck tower and required frequent recalibration.
Despite the problems we managed to steal some points from our opponents using the trick only Dana was able of — drive to the opponent's 3-puck tower, pick up the topmost puck, turn in upside down and place it back on the tower. One single maneuver like this gave us +10 points advantage (opponent lost 5 points for its tower, we gained 5 points for ours). All of this contributed to the Best Concept Prize we were awarded. There is also an article on Dana at the French site.

Any questions can be directed to us through the standard web form.

Send email to the editors

Your message could not be sent
but you can also reach us at

Your message was successfully sent.

You need to turn on javascript to submit this form.