e00a014.pdf

GENERAL

INTEREST

Invention System ( 4 )

part 4: chatting robots

By Hans Steemann and Luc Lemmens

The Robotics Invention System is an

outstanding choice for building advanced

robots. Various types of sensors can be read

out using the RCX module, and three

motors or other types of actuators can be

driven by the pulse-width modulated

outputs. However, you may sometimes want

to make a model that needs more power

than a single RCX module can provide.

Under the motto ‘strength in unity’, it turns

out that RCX modules are able to work co-

operatively.

After experimenting with the Robot-

ics Invention System for a while, you

will notice that the Lego system is

both powerful and versatile. Still, it

has its limits. Very complex robots

may prove to need more active ele-

ments than can be driven or read out

by a single RCX block. However, the

system is ﬂexible enough to be able

to encompass additional possibili-

ties, by using the combined forces of

several modules. The demonstration

robot shown in the photograph at

the head of this article is a clear

example of this. No less than three

RCX blocks work together in a single

model, in order to provided the

desired functionality. One RCX mod-

ule is built into the transport system,

while the other two modules work

together within the robot on the

basis of clearly divided responsibili-

ties. All three modules communicate

with each other regarding the

progress of their activities. This

makes it possible to use a specific

Elektor Electronics

10/2000

Lego Robotics

GENERAL

INTEREST

RCX for each separate function, with

control being passed to the next RCX

block on completion of the task. Of

course, two RCX blocks can also

carry out tasks independently of

each other, using messages to keep

track of each other’s processes. Even

for the novice robot builder, it is not

especially difficult to utilise the com-

munication functions of the system

within the standard development

environment.

Communications

The robots use the infrared trans-

ceiver that is incorporated in each

RIS for communicating with each

other. Codes that are 8 bits wide

(with numbers between 0 and 255)

can be exchanged using this inter-

face. The transmitting robot can

send a message, which will be

received by all robots that are within

the reception range. Whether the

module that receives the signal actu-

ally does anything with it depends

on the software.

The distance over which the mod-

ules can communicate with each

other depends on the settings that

are made using the configuration

screen. If the ‘long’ option is chosen

in this screen, the maximum power

level is used to send the command.

Naturally, the distance that can be

covered is a maximum in this case.

This configuration option is compa-

rable to the switch on the infrared

transmitter that is connected to the

PC. This switch relates only to the

output power of the transmitter con-

nected to the PC. The transmitter

that is used by the RCX can only be

configured using software. The

drawback of high transmission

power is that the signals may cause

interference in other systems that

use RCX modules. In addition, high

transmission power also causes the

battery to be used up more quickly,

particularly if the robots exchange a

lot of messages. You should therefore

choose the setting that best ﬁts the

desired setup.

Let’s start with message applica-

tions within the Lego development

environment.

Figure 1. The icons belonging to the message functions in the Lego software.

standard commands. This blue func-

tion block represents a function that

is integrated in the RCX, and that

can best be compared to a normal

sensor. The only difference is that it

does not have to be separately connected.

This function continuously checks whether

a message is being received. It causes a sub-

routine to be executed whenever a message

is received from another RCX. The command

RCX-message sensor watcher

RCX-message sensor watcher is an

option that is associated with the

Figure 2. This form can be combined with the Visual BASIC program. The two buttons

allow the program to be activated in the master and the slave. The result from Label1

appears at the upper right. Note that the Lego ActiveX module is linked in.

10/2000

Elektor Electronics

GENERAL

INTEREST

belonging to this function block can be used to

specify the messages to which the RCX must

respond. Click on the numbers, and enter the

lowest and highest message values. The

linked stack (the Lego term for a subroutine)

will be executed when a message

within the message value range is

received from another RCX. A mes-

sage may have a value between 0

and 255. If several RCX modules are

used, each module can be assigned

its own range. A common number

can be used for broadcasting (com-

mon messages).

Reset Message

In order to prepare a subroutine to

receive messages, it is necessary to

first activate the ‘Reset Message’

block. As long as this has not been

done, the RCX will not react to the

commands.

Table 1. The Poll function.

Poll(Source, Number)

Source and Number are used to indicate where the Poll function has to look in the RCX.

Send to RCX

The ‘Send to RCX’ block allows the

RCX to send an infrared message to

another RCX. Needless to say, at

least two RCX blocks must be used

in a project before you can make use

of the communications options.

When software is being sent from

the PC to an RCX, only one RCX at a

time may be on!

Source Number Function

0...31

Variables 0...31

0...3

Timer 0...3

0,1,2

Motor status

Bit 7: On/Off 1/0

Bit 6: Brake/Float 1/0

Bit 5: Output no. HiBit

Bit 4: Output no. LoBit

Bit 3: Direction CW/CCW 1/0

Bit 2: Power Level most signiﬁcant bit

Bit 1: Power Level

Bit 0: Powel Level least signiﬁcant bit

More possibilities with

Visual BASIC

Naturally, the features that support

communications between RCX

blocks are also available in

Spirit.OCX, so we can also utilise

them in high-level languages such

as Visual BASIC. With such lan-

guages, it is also possible to have

the PC actively participate in the

data traffic. The role of the PC does

not have to be limited to generating

code for an RCX and sending out

program blocks. As we have seen in

previous instalments, the PC can

also read out RCX registers (to query

the battery voltage, for example),

and it can even request the data

from an RCX data logging session.

Unfortunately, though, the PC cannot

send and receive messages as a sort

of pseudo-RCX. Spirit.OCX does not

have any equivalent for the message

module. All in all, this means that a

PC cannot distinguish between RCX

blocks, which means that it can only

communicate with a system that

contains only one RCX block. Also,

only one RCX module may be active

whenever program blocks are being

transferred from the PC.

Let’s ﬁrst have a brief look at how

we can use a high-level language to

develop programs that allow RCX

modules to communicate with each

other. After this, we will discuss

0,1

No function with RCX

0,1

No function with RCX

RCX program number. Number actual program in use

0,1,2

SensorValue, value measured at input,

depends on actual mode of operation

0,1,2

SensorType, tells what type of sensor the input is set-up for

0,1,2

SensorMode, tells what type of sensor the input is set-up for

0,1,2

SensorRAW i.e. the analogue value measured at the input

0,1,2

Sensor Boolean, returns the Bololean state of the input

RCX Watch. Integer where MSB=hours and LSB=minutes

Returns the PBMessage stored internally in the RCX

No function with RCX

The result of a Poll instruction that requests data or status is a 16-bit signed integer.

Examples of using Poll:

Label1.Caption = PBrickCtrrl.Poll 0, 7

Label1 takes on the value of Variable 7 in the RCX.

Label2.Caption = PBrickCtrl.Poll 8

Label2 takes on the value of the program being executed by the RCX.

Elektor Electronics

10/2000

GENERAL

INTEREST

how a PC and an RCX can ‘talk’ to

each other.

place in a separate task, in parallel

with the main task. The structure of

the program will naturally have to

take this into account. Listing 2

shows the approach that must be used.

Finally, it is naturally also possible to wait

for a message, and then to start a particular

task according to the content of the message.

From RCX to RCX

Three commands in Spirit.OCX are

important with regard to exchanging

messages between RCX modules.

Two of these (ClearPBMessage and

SendPBMessage) have equivalents

in the Lego programming environ-

ment, and the universal Poll com-

mand is used to check for successful

reception.

Poll is an exceptionally powerful

and versatile routine, which can

monitor numerous events in and

around the RCX block. Table 1

shows how it can be used. For exam-

ple, it is possible to use Poll to exam-

ine registers, to control timers, and

to monitor motor operation. It can

also be used is to see if messages

have been received. A simple BASIC

program that you can use for exper-

imenting is shown in Listing 1 .

Actually, this program incorporates

two different examples, but in prac-

tice, they can almost never work

together.

The program consists of two main

routines. The subroutine ‘Private

Sub Up_Master_Click()’ is a task that

is placed in program slot 0 of an RCX

block (RCX program 1).

After this, there has to be an RCX

that can receive the message. The

routine Private Sub Up_Slave_Click()

is provided in Visual BASIC for this

purpose. It places the code for

receiving a message in the second

RCX block, and it utilises slot 3

(SelectPrgm 3, so it can be activated

as program 4 using the grey Program

button on the RCX. This is a straight-

forward routine. When it is ﬁrst acti-

vated, it causes the RCX to make a

sound (PlaySystemSound

SWEEP_DOWN_SOUND), following

which it erases the register that may

hold a message (ClearPBMessage)

and then waits for the reception of a

message. If a message is received,

the same little tune is played again.

This is naturally only a very simple

example, but it can be easily

extended to a more meaningful appli-

cation. In this example, two tasks are

carried out in sequence. However,

since the RCX can perform several

tasks simultaneously, it is also possi-

ble to have message monitoring take

Listing 1.

Private Sub Timer1_Timer()

Rem if label <> 0, RCX has sent the message

Label1.Caption = Str(PBrickCtrl.Poll(VAR, 0))

End Sub

Private Sub Up_Slave_Click()

Rem upload the program for the Slave

With PBrickCtrl

Rem select program slot 4

.SelectPrgm 3

.BeginOfTask MAIN

Rem let’s hear the program starting

.PlaySystemSound SWEEP_DOWN_SOUND

Rem just to make sure, clear all messages

.ClearPBMessage

Rem and wait for message from another RCX

.While PBMESS, 0, EQ, CON, 0

Rem 50 ms delay

.Wait CON, MS_50

.EndWhile

Rem message received!

.PlaySystemSound SWEEP_DOWN_SOUND

.EndOfTask

End With

End Sub

Private Sub Up_master_Click()

With PBrickCtrl

.SelectPrgm 0

.BeginOfTask MAIN

.ClearPBMessage

Rem just to be safe, make var0 zero

.SetVar 0, CON, 0

Rem send message no. 11

.SendPBMessage CON, 11

Rem make variable 0 equal to 11

Rem PC detects ‘message sent’ by reading timer

.SetVar 0, CON, 11

.EndOfTask

End With

End Sub

Private Sub Form_Load()

PBrickCtrl.InitComm

End Sub

Note: this program utilises the RCXDATA.BAS module, in which the constants (MAIN,

EQ, CON etc.) are declared and initialised. Make sure that this module is linked in!

Listing 1. The basic program that can be used to analyse the sending of messages.

10/2000

Elektor Electronics

GENERAL

INTEREST

Listing 2.

coincidence; other values are also

possible in this application).

The PC uses a timer to check the

value of VAR 0 once per second. The

first few lines of the program show

how this works. The routine Private

Sub Timer1_Timer() is used for this

purpose. With this arrangement, the

PC uses the Poll command to request

the content of VAR 0 at one-second

intervals via PBrickCtrl.Poll (VAR, 0).

This is controlled by Timer1, which

has a period of one second. The con-

tent of the text string obtained in

this manner is assigned to Label1,

and then displayed on the screen

using the form.

Many readers may wonder what

this is all good for. The answer is

that the PC cannot directly receive a

message from the RCX. However,

the technique illustrated in this

example, in which the content of the

message is assigned to an auxiliary

variable, makes it possible to check

whether something has happened

inside the RCX or has been handled

by the RCX. This function can be

used to send a new task to the RCX

after it has carried out a particular

task, or to start a new session after

the RCX has been read out, for exam-

ple.

Now you can probably understand

why we earlier remarked that these

two examples are not compatible

with each other. This is because

whenever the PC requests the value

of the auxiliary variable, it would not

be possible for two or more RCX

blocks to know which of them

should send its Variable 0 value.

Every block that receives a com-

mand from the PC will send back its

own VAR 0 value, which means that

no reliable result can be obtained in

the PC.

Both of these examples are thus

intended purely to illustrate how var-

ious things work in the interplay

between the PC and the RCX or

between several RCX modules.

However, it should not be difficult to

apply these principles to an actual

robot environment.

:REM structure of a program

with parallel tasks

PBrickCtrl.BeginOfTask MAIN

PBrickCtrl.StartTask 1

PBrickCtrl.StartTask 2

PbrickCtrl.EndOfTask

:REM deﬁnition of tasks within

MAIN

PBrickCtrl.BeginOfTask 1

.........

PBrickCtrl.EndOfTask

PBrickCtrl.BeginOfTask 2

.........

PBrickCtrl.EndOfTask

(000040-4)

Listing 2. If the program is set up slightly

differently, the monitoring of message traffic can

be carried out in parallel with the main task

Between PC and RCX

We have already mentioned that the PC can-

not participate in the message traffic that can

take place between RCX blocks. The actual

problem is primarily that an RCX cannot itself

send a message to the PC. However, it is pos-

sible to use a trick to allow the PC to period-

ically ‘look at’ the RCX to see if it has any-

thing to report. Note that this trick works only

with a single RCX; it cannot be used in a sys-

tem in which several RCX modules are active

at the same time.

The trick is based on using an auxiliary vari-

able in the RCX (VAR 0 in this example). This

variable has the value ‘0’ after the routine is

started. After a message has been sent, the

variable takes on the same value as the mes-

sage. This is done by the program line ‘Set-

Var 0, CON, 11’. The number ‘11’ corre-

sponds to the content of the message, since

the instruction SendPBMessage CON, 11 is

defined in the previous line (which is just a

Figure 3. Thanks to the PBMessages that the RCX blocks can exchange with each

other, the robots can ‘chat’ with each other. In this example, R2S2 is

communicating with the robot that will be featured in the next instalment.

Elektor Electronics

10/2000

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: