e00b032.pdf

GENERAL INTEREST

Invention System (5)

Final part: your own robot

By L. Lemmens

In the previous parts of this mini-course, we have devoted our attention to the

hardware elements of the Lego Robotics Invention System and the question of how

to control them using the accompanying software or a high-level programming lan-

guage, such as Visual Basic. Naturally, it’s a lot more interesting to look at a real

robot, and that is what we do in this ﬁnal part.

Describing components is of course informa-

tive, regardless of whether it is Lego blocks

or the hardware and software that are used

to build and control the models. However,

really ‘playing’ is a lot more fun. Practical

experience teaches that many people first

make something, and only after that do they

start looking at what is actually

inside the RCX block, in order to see

what else they can do besides copy-

ing the pre-cooked examples.

Nevertheless, we will employ the

Lego manual for the mechanical con-

struction of the model described here.

If we had to publish the full assembly

instructions, this article would be

much too long. The program for

the robot will be developed using

both the software in the RIS package

and Visual Basic v.6. With a few small

modiﬁcations, it is also possible to use

Visual Basic v.5. Programmers that

prefer to work in Delphi or C should

not have much trouble adapting the

source code to their development

environments. The robot in this article

is so simple that it is actually not nec-

essary to employ high-level program-

ming languages. The RIS software is

a lot simpler in this case. However, in

the earlier instalments we have men-

tioned that certain things that are

indispensable for serious applications

(such as using variables) are possible

in high-level languages, and that we

have to do without them in the Lego

environment. In addition, as you will

see, the structure of the Visual Basic

program is actually extremely similar

to that of the Lego program. For

quickly setting up and testing the

rudimentary functions of a robot, you

can thus start with the RIS environ-

ment, and then switch over to a high

level language only when you want to

add reﬁnements.

Figure 1. The program in the Robotics Invention System development environment.

Elektor Electronics

11/2000

Lego Robotics

GENERAL INTEREST

What can our robot do?

In some cases, it may be neces-

sary to adjust the setting of the

light/dark threshold to match the

table. The ‘testing tools’ of the Lego

software prove useful here, since

they allow the values that the sensor

provides for a particular surface to

be seen while the program is being

developed. Another option is to

press the ‘View’ button on the RCX

block three times in succession. The

display will then show an arrow next

to sensor input 3, along with the

sensor value.

Under ideal conditions, subroutine

‘PBrickCtrl_DownloadDone’ would be redun-

dant, but it is essential to have feedback

regarding the success of the communications

process between the PC and the RCX. If this

routine is missing, something will of course

still happen, but you cannot be sure that the

program has been properly stored in the RCX.

If everything has gone properly, the IF state-

ment triggers a happy little tune from the

RCX and a message on the PC screen

announcing that everything went as it

should. Otherwise, all that appears is an error

message on the PC.

However, what we are naturally most

interested in is the program for the RCX. Let’s

start with the structure. The program is made

up of three tasks. The first task, ‘Main’, sets

the motors in the right direction and starts

them, looks after the proper conﬁguration of

the sensors and starts two other tasks. Each

of these tasks monitors a sensor and, if nec-

essary, responds to the signals from the sen-

sor in the appropriate manner. The main task

thus only performs a certain amount of

‘housekeeping’, namely the initialisation of

the robot, and then stops. After this, the sen-

sor tasks continuously monitor whether

something has happened with the sensors,

and ensure that the Roverbot does not roll off

the edge of the table. Of course, the program

could have been written as only a single task,

since this application is not all that compli-

cated, but this structure makes everything

easier to understand and easier to adapt to

other applications.

A small warning is in order here: as your

Our robot can ride over a tabletop,

briefly touching objects before

changing directions, and turn around

if it reaches the edge of the table.

A ‘table bumper’, located at the

front of the robot, is used to detect

obstacles and the edge of the table. If

this is pressed in, the robot moves a

short distance backwards and then

changes its direction of travel. The

light sensor on the rear side looks to

see whether the robot moves too far

backwards while it is turning

around. It all sounds simple, and in

fact it is simple.

Software in Visual Basic

Listing 1 shows what this applica-

tion can look like in Visual Basic.

You can see that it contains more

than just the program code for the

RCX module. A ‘shell’ has been

placed directly around this code, so

that the Visual Basic program can

also look after sending the program

code to the Roverbot (which is

called ‘downloading’). For this pur-

pose, the InitComm method is

added to the start-up routine of the

VB program (Form Load), in order to

make communications with the

RCX possible. Once the VB program

is started, you will see a window

with a button that you can press to

send over the code. Figure 2 shows

how this appears in the Visual Basic

development environment.

Hardware

As already mentioned, we use the

Lego assembly instructions for the

Roverbot on page 10 of the Con-

structopedia, together with the

wheel sets according to the instruc-

tions on page 17. The table bumper

is mounted on the front side (see

page 90). Finally, the light sensor

must be fastened to the rear side, as

described on page 34 and further.

This is a simple model that should

not cause any problems with its con-

struction. However, it sometimes

takes a lot of searching to find the

necessary items in the large box of

parts. Pay careful attention to the ori-

entation of the motor leads. If these

are improperly connected, the motor

may turn in the wrong direction. The

switches of the table bumper are

connected to a single sensor input

for convenience. At a later stage, it

is possible to provide a separate port

for each switch, so that the robot can

distinguish between right and left.

Software in the Robotics

Invention System

In the program bank, you will ﬁnd a

program called ‘Robot2’. You can use

this as a starting point for your own

program. In contains all the program

elements that are necessary for han-

dling the table bumper. You only

have to add the light sensor (see Fig-

ure 1 ). The routine that is necessary

for this is very simple and quite sim-

ilar to that for the table bumper. The

only difference is that the robot does

turn away, but it does not turn

around.

Figure 2. The Visual Basic program is ready to upload the program code to the RCX.

11/2000

Elektor Electronics

GENERAL INTEREST

Listing 1.

Private Sub Form_Load()

PBrickCtrl.InitComm

End Sub

.BeginOfTask 1

.Loop CON, 0

.If SENVAL, SENSOR_1, EQ, CON, 1

.SetRwd OUTPUT_A

.SetRwd OUTPUT_C

.Wait CON, SEC_1

.Off OUTPUT_C

.Wait CON, SEC_1

.Off OUTPUT_A

.Else

.SetFwd OUTPUT_A

.SetFwd OUTPUT_C

.On OUTPUT_A

.On OUTPUT_C

.EndIf

.EndLoop

.EndOfTask

.BeginOfTask 2

.Loop CON, 0

.If SENVAL, SENSOR_3, LT, CON, 35

.SetFwd OUTPUT_A

.SetFwd OUTPUT_C

.Wait CON, SEC_1

.Off OUTPUT_C

.Wait CON, SEC_1

.On OUTPUT_C

.EndIf

.EndLoop

.EndOfTask

Private Sub PBrickCtrl_DownloadDone(ByVal Error-

Code As Integer, ByVal DownloadNo As Integer)

If ErrorCode = 0 Then

PBrickCtrl.PlaySystemSound SWEEP_DOWN_SOUND

MsgBox “Upload OK”, vbInformation, “Status”

Else

MsgBox “Upload failed”, vbCritical, “Status”

End If

End Sub

Private Sub Up_master_Click()

With PBrickCtrl

.SelectPrgm 3

.BeginOfTask MAIN

.SetFwd OUTPUT_A

.SetFwd OUTPUT_C

.SetPower OUTPUT_A + OUTPUT_C, CON, 3

.On OUTPUT_A

.On OUTPUT_C

.SetSensorType SENSOR_1, SWITCH_TYPE

.SetSensorType SENSOR_3, LIGHT_TYPE

.On SENSOR_1

.On SENSOR_3

.StartTask 1

.StartTask 2

.EndOfTask

End With

End Sub

Listing 1. The program listing in Visual Basic version 6.

robots become more complex, you must take

care that the various tasks do not interfere

with each other, since they are executed in

parallel. For example, it could happen that

after one task has just stopped the motors,

another task immediately resets them to max-

imum speed. In the present application, it is

nearly inconceivable for the robot to teeter on

the edge of the abyss on the front and rear

sides at the same time, but in cases where it

is possible for two sensors to be ‘operated’

nearly simultaneously, you will certainly have

to pay attention to this possibility. It is rea-

sonably simple to solve such conﬂicts by hav-

ing one task suspend the other task using a

‘StopTask’ instruction or by using sema-

phores, as discussed in Part 3, so that (for

example) only one task at a time can control

the motors. Once a task has ﬁnished its work,

it can reactivate the other task(s) or release

the blocked resources. In the present appli-

cation, however, it would not be a good solu-

tion to allow one task to completely block the

other one, since what we want is to prevent

the robot from running off the edge of the

table while it is turning around. However, a

possible option would be to activate the light

sensor task only within the IF statement of

task 1. After all, this sensor will not ﬁnd itself

looking over the edge of the table

when the robot is travelling for-

wards.

The two companion tasks are

simple and do not need further

explanation. The only fairly unusual

elements are the IF statements for

determining the sensor values. The

first argument indicates that a sen-

sor value must be compared, while

the second argument specifies the

sensor input in question. The third

argument contains the relational

operator. In the case of the switch,

this is ‘equals’ (EQ), while with the

light sensor it is ‘less than’ (LT).

After this, the final two arguments

specify that the sensor value must

be compared to a constant (CON).

Note: the symbolic names used in this

application (EQ, LT, CON, OUTPUT_A

etc.) are deﬁned in the module RCX-

Data.bas, which is linked to this pro-

ject. This module is located in the pro-

ject GetStart.vbp, which we have

already met in Part 3 of this course.

use only the software from the RIS

package instead of Visual Basic.

However, if you want to have total

control over what the program does

and to understand precisely how the

robot works, you will want to use

other programming languages.

Conclusion

In the five parts of this course, you

have been introduced to the Lego

Robotics Invention System, but this

cannot be considered to be anything

more than an introduction. You can

find an enormous amount of infor-

mation and documentation regard-

ing this system on the Internet,

including sample programs, con-

struction diagrams and so on – all

too much to name and describe. We

do hope that this series has made

you enthusiastic about this ‘toy’,

which can be used by people of all

ages. Maybe it will turn out to be the

latest of the toys that fathers buy ‘for

their children’, only to keep them for

themselves.

Both programs perform similar func-

tions, and this case it was simpler to

(000040-5)

Elektor Electronics

11/2000

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: