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).

5/3/2002

Some problems have been detected in the former project :

• That's what the RCX (placed close to the tower) actually gets from the computer : (NOT CORRECT !!! LOOK AT X Comment added 11/3/2002).

The camera observed a single object, the image-refresh-rate was 10Hz. The picture shows the variations of the index in the Get_the_position_data.vi (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.

• During broadcasting from the tower, the RCXs reply with a IR-message, which is not requested by the tower, but which makes the whole transmission bulky. (NOT TRUE LOOK AT X ; comment added 11/3/2002)
• All this makes the camera-GPS only useful as some kind of absolute reference. But it MUST be combined with a real-time filter-algorithm and dead-reckoning which allows best estimation at any RCX-computing time. (This will be serious programming work, since we must deal with a sort of RCX implementation of a simplified Kalman-filter. Don't forget the hard- and firmware limitations!)
• As we want to do the job with ROBOLAB / LABVIEW for didactical reasons, we tried to get rid of the rather complicated access to generic containers. Why complicated ? In order not to get lost in such a complex ROBOLAB program, you must identify your variables by names rather than by numbers. We used the Container.ctl to do so, but everytime, during the development phase, when we had to change something more seriously around the variables, we were forced to change any of the user-Container.ctl. But, please, don't forget one single! We decided to implement a STRING access to the variable names, whose management is done at ONE single place. For this purpose we defined a LABVIEW global variable equipped with 10 (10 tasks) 1D-arrays of string. We designed a two sequence diagram for our RCX-programs. In the front panel we place as many (up to 10) variable lists as needed. In sequence 0 we send the lists to the LABVIEW global variable called variable_list.gbl.vi .

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.

11/03/2002

• A problem appeared with our new text-based variable addressing: If two different vis access global variable_list.gbl.vi, the second will obviously not start with the default values. So we added another sequence to reset the Labview global variable.

• We checked, if there is really no reply from the RCX at opcode 0xF7. Lego Mindstorms SDK 2.0 says that there is no reply. We got a bit confused, because the RCX-display shows that there is an IR-signal. The indicator disappears when opcode 0xD2 is send. As we were only interested in whether there is a reply or not, we used the LEGO camera, which is IR-sensitive. Here a picture of opcode 0x51 send and reply:

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

• The IR-transmission with opcode 0xF7 is much quicker than we thought. In fact every sent byte is received by the RCX. The brick buffers all the messages. We commited an observation-error on March 5th. The datalogging was executed at 10Hz, but the information was passed much quicker. The following test proves the high transmission speed of data.

19/03/2002

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 modulo-sub.vi  (%) which is the remainder of an integer-division. (Note the use of variable 46 and 47 in this sub.vi). 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 sub.vi 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 Note.vi 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

example: 

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 Container.vi 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 GO_sub.vi 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.

20/03/2002

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

Robolab 2.5 has no sub.vi 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].

DOWNLOAD ALL THE FILES

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

13/04/2002

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

Main Page