Robo-soccer Version 2

improved Robo-Soccer1

LAB-JOURNAL : last update 13/04/2002 bug-fixed !!

Make two semi-autonomous LEGO-Mindstorms robots play soccer in a given field of about 1.20 m x 1.60 m. The robots get their positionings from a global positioning system (overhead camera, image analysis executed by a computer, IR communication).


Some problems have been detected in the former project :

The camera observed a single object, the image-refresh-rate was 10Hz. The picture shows the variations of the index in the (Have a look at Robo-soccer Journal at date 18/2/2001).Obviously the communication does not work too quick ! The real sampling rate is less than 1Hz and some data don't arrive at the good moment.

Labview / Robolab first executes sequence 0, then sequence 1.

Let's have a look at the Heading and target task, where we carefully use our variables.

Note that Robolab 2.5 is based on firmware2, which allows the use of 16 local variables (number 32..47) in every task, thus 160 local variables !!! But, pay attention, for Robolab uses some of them (especially 46 and 47) in different sub.vis (like wait_for_rotation and so on). Out of the tasks you don't have access to these variables. They are extremely volatile. This might be a problem during debugging.

Note also that indirect addressing is only allowed by Robolab for variables 0..20

Datalogging with container values is only permitted with containers 0,1 and 2 (red, blue and yellow).

Datalogging needs global variables 23..29.

Here one of the custom-RCX-container access sub.vis :

We highly recommend the book Labview for everyone Graphical Programming Made Even Easier by Lisa K. Wells and Jeffrey Travis, USA, 1997 and the Labview tutorial site.


RESULT: There is NO reply when opcode 0xF7 is sent.


This week we worked on implementing new dead-reckoning features to the soccer-player. There are different ways to do so, of course, but we opted for our revisited direction-master with the tachometer for velocity measurement and the LEGO rotation-sensor for angle reading.

The tachometer is very sensitive and is suitable for way-integration. The values are averaged at a certain rythm. In a parallel task the current position is computed through integration. Later the current robot-location will be updated by the Camera-GPS-positionings. Thus we have reliable coordinates between two Camera-GPS-messages, what missed in the former project. Note that the way-integration is done in two dimensions obeying to the formulas:

posx' = posx + v.Dt.cos(q), where q is the current bearing

posy' = posy + v.Dt.sin(q)

There was a discussion whether we had to average the bearing too, but finally we agreed that bearing-variations are insignificant during forward or backward motion, while during rotation the robot speed is zero, so the position does not change.

The former project showed that the current bearing is the most fragile information, since the Camera-GPS-data is uncertain during turning phases. Now the angle is extracted from the rotation-sensor readings. To prevent overflow-problems (range -32768, 32767), the rotation-sensor is always reset at 0. The declination from the real bearing will be fixed later through the Camera-GPS values, if it is made sure the robot is not turning.

Here now some screen-shots of the Robolab 2.5 files:

At start the robot moves a bit forward in order to let the program fix the sign of the tachovalues. The sensor must be no_type and raw_mode. We explained the function at the Hanoi-project.

Note the implementing of the new Sine and Cosine-functions. These functions only work with values between 0 and 90. So the correct signs have to be considered. This is done through fixing the quadrant. Note also the  (%) which is the remainder of an integer-division. (Note the use of variable 46 and 47 in this Way-integration has intensively been explained at honeybee and robot navigation and autonomous navigator.

Note that the rotation-sensor is always reset without display. We used this in the subsumption-compass.

Here is the test of the odometry-implementation. The RCX plays the British and the German hymns then moves successively to location [100, 50], [10,60] and [0,0]. The sequence 0 is the standard variable reset. (The music has been composed through the Robolab 2.5 piano-function. The New may be found in the Robolab/Engine/Rcx1/Music.llb library.)

Take care of correct constants!

We changed the subsumption architecture implementation in such a way that now it is possible to influence also the motor-power of the driving motors according to the task-priority.

The motor-commands are encoded following the system:

Command = drive_command * 256 + left_motor_power * 16 + right_motor_power


command_right = 3, left_motor_power = 7, right_motor_power = 7

Bitwise this is equivalent to : 0011  0111  0111 = 887

To extract the original commands:

1. drive_command: integer-divide by 256 ==> 887 div 256 = 3

2. left_motor: mask the HI-byte by operating the bitwise AND-function

(0011 0111 0111) AND (1111 1111) = 0000 0111 0111 = 119,

then integer-divide by 16 ==> 119 div 16 = 7

3. right_motor: extract the four lower bits through AND-function ...

Note the use of variable 47 in all the set_comm_xx.vis.

Note the RCXWhile E which is not originally present in Robolab 2.5.

There is some confusion about naming this controller (P- or I-). In the present project the robot does no longer turn proportionnally to the course deviation in a direct way, but it rotates as long as a course deviation is notified, without caring of its magnitude. This is possible since we have a reliable real-time bearing information through the rotation-sensor. Only the rotation speed is controlled proportionnaly to the deviation. Well calibrated there is no overshooting anymore.

Remark that the robot is stopped through notifying to the bumper_command, which has the highest access priority. This assures, the course_correcting task has no access to the motors.The bumper_command will of course belong to a future bumper-task.

A less drastic stop could be done with the float-command. Note that may only be used with static targets like goal and so on. If the soccer-player is following a moving target, the target-coordinates need to be updated in the while loop. The beep must dispappear in that case, for it operates a 1-second wait.


Now the implementation of the Camera-GPS update task. Note that the program must be run with from the former project.

Robolab 2.5 has no accessing the motorstatus. But from LEGO Mindstorms SDK we know there must be a possibility. So we designed this small vi. We need this program to get knowledge about the robot's motion. Checking the tachometer could have been another solution, since at rotation we should have zero-speed. Because of the subsumption architecture and extreme multi-tasking, we have to consider the time delay between motor-orders and execution. So, the information from the motor_command-variable is useless here.

(The SDK says: the read-only motor status is source 3, the number range is 0-2, the values are 8-bit wide fields, formatted as:

bit 0-2 == power setting

bit 3    == direction (1 == FWD, 0 == RWD)

bit 4-5 == remote command overlay marker

bit 6    == brake/float (1 == brake, 0 == float)

bit 7    == on/off (1 == on, 0 == off)

when bit 7 is set (the motor is on), bit 6 is ignored)

We need to know whether both driving motors have the same direction. The 3d bits of both left and right motor-stati are masked through bitwise AND 4 (b'1000'). They are substracted. If the result is 0, they are identical.

Important note:

There must be some serious tests to make sure the Camera-GPS coordinates-dimension corresponds to odometry. Adjust the way-integration parameter accordingly!!! For example, if the camera is displaced to a higher position, it will survey a larger surface, but pixel [80, 80] will no longer be location [80cm, 80cm].


This completes the project. Now it is up to the user to add game strategy and to make his soccer-player win the game. 


We fixed a bug: of course decimal 8 = b'1000'. So we changed the accordingly. Here to download the patch.

RetourMain Page