0599o(2).pdf

(134 KB) Pobierz

DQG &OLYH ´0D[µ 0D[ILHOG

3$57 (TXLSSLQJ WKH 3KX]]\%RW ZLWK 2SWLFDO 6HQVRUV

Hi there! Last month, as you no doubt recall,

we created a rather cunning program to detect

when the

PhizzyBot

collided with something and to

respond in an appropriate manner. This program

was designed to be user-friendly, such that it was

relatively easy to specify, read, and modify the

The actions and movements

discussed last month were speci-

fied using constant declarations

STOP, FORWARD, TURN_L

(“turn

left”),

and

SPIN_CW

(“spin

clockwise”).

However, the “units”

associated with these actions

were always those of time

(measured in tenths of seconds).

sequences of actions performed by the

PhizzyBot,

thereby facilitating our ability to experiment with

different sequences. This month we get

PhizzyBot

involved in measured space travel, and add to its

senses by giving it eyes

six of them.

the program, or change the

gearing on the motors to make

them slower, or reduce the di-

ameter of the

PhizzyBot’s

wheels, or …)

But let’s stick with what

we’ve got. One thing we could

do would be to create a whole

host of constant declarations as

follows:

_2cm: .EQU

_4cm: .EQU

_6cm: .EQU

_8cm: .EQU

etc.

3KL]]\% &20387(56

E\ $OYLQ %URZQ

WEIGHTS AND MEA-

SURES

Associating actions with units

of time made sense in the context

of the way we developed our pro-

gram. But when you come to

think about it, a command like

“Go forward for three seconds”

isn’t perhaps quite as useful as

being able to present an instruc-

tion in the form:

“Go forward for

fifteen centimeters.”

Similarly, the

command

“Spin clockwise for two

seconds”

doesn’t convey the

same intent as

“Spin clockwise

for ninety degrees.”

Well, perhaps

it does convey the same intent (if

you want to be pedantic), but it’s

certainly less people-friendly

when it comes to working out ex-

actly what’s going to happen.

So what we need is a tech-

nique that will allow us to replace

delay values with units like inches

and degrees. In order to do this,

Maxfield & Montrose Interactive Inc

we first need to ascertain the

relationship between time and

distance traveled. One way to

do this would be to mark out a

specific distance

say three

meters

and time how long the

PhizzyBot

takes to travel this

distance. Alternatively, you

could easily modify last month’s

program such that clicking

switch 1 will cause the

Phizzy-

Bot

to travel forwards for some

specified time

say ten sec-

onds

and measure the dis-

tance traveled.

Whichever technique you

choose to use, you should re-

peat the process a number of

times and average the results to

compensate for experimental

errors.

In the case of our

Phizzy-

Bot,

it took approximately fif-

teen seconds to travel three

meters. This equates to 5 sec-

onds per meter, or 0 5 seconds

to travel ten centimeters, or 0 1

seconds to travel two centime-

ters. As 0 1 seconds is the

smallest interval we can mea-

sure with our current program,

this means that the smallest dis-

tance we can instruct the

PhizzyBot

to travel is two cen-

timeters. (In order to achieve

finer control, we could modify

Remember that label

names cannot commence with a

number, so we can’t use

2cm,

4cm, 6cm,

and so forth, but la-

bels can start with an under-

score as shown above. So this

would allow us to specify action

sequences in the form:

FORWARD, _4cm

BACKWARD, _8cm

etc.

(We’ve omitted the labels

and

.BYTE

statements associ-

ated with these action se-

quences for clarity and space

considerations). One problem

with this technique is that it re-

quires us to create one heck of

a lot of constant declarations to

EPE Online, May 1999 - www.epemag.com - 554

&RQVWUXFWLRQDO 3URMHFW

cover every time value from 1

to 255. One alternative would

be to just create one constant

declaration (say the

_2cm

.EQU 1)

and to then use ex-

pressions to modify this in the

action sequences, for example:

FORWARD, 10 * _2cm

… which means

“Go for-

wards for (10 x 2cm = 20cm)”.

That’s right, we can use expres-

sions in these statements, as

you doubtless recall from read-

ing Appendix D from

The Offi-

cial Beboputer Microprocessor

Databook

(remember that this

appendix is provided FREE with

the

PhizzyB Simulator

– check

the simulator’s online help for

more details).

In reality we might create a

small number of constant decla-

rations to cover any “standard”

values like

_10cm, _20cm,

and

so forth, and to then modify

these with expressions as re-

quired.

So once again we could

create some constant declara-

tions along the lines of:

_15deg: .EQU

_30deg: .EQU

_45deg: .EQU

_60deg: .EQU

etc.

same two action sequences, per-

haps I should try something else

and see if that gets me out of this

jolly awkward predicament.”

Not that we’re going to tell

you how to do this, you under-

stand – we’ve got too much new

stuff to be getting on with. The

only reason we’re mentioning this

here is that we thought that you

might be desperately looking for

something to do this coming

weekend …

In fact, in this case we really

only have twelve labels to de-

clare to cover 15, 30, 45, 60,

75, 90, 105, 120, 135, 150, 165,

and 180 degree increments, be-

cause we can use these decla-

rations as assignments to both

clockwise and anticlockwise

spin commands. (And we can

always use expressions to mod-

ify these constants if we wish;

for example,

4 * _180deg

will

instruct the

PhizzyBot

to per-

form two full revolutions.)

COME INTO THE

LIGHT

But we digress … In Alan

Winstanley’s construction article

elsewhere in this issue, he de-

scribes how to use a set of six

light-dependent resistors (LDRs)

as the basis for a rudimentary op-

tical sensor for the

PhizzyBot.

For our part, we are going to

create a simple program that uti-

lizes this optical sensor to make

the

PhizzyBot

act the role of a

“MothBot”. That is, a Bot that’s

attracted to the light from a torch

(or a flashlight as they would

have it in the vernacular of the

good old US-of-A, which is where

we happen to find ourselves at

this moment in time).

NO HISTORY

There is an old saying that

those who fail to learn the

lessons of history are doomed

to repeat them (this is particu-

larly true in the case of history

courses at high school)! One of

the limitations of last month’s

program is that it had no sense

of history, which means that the

PhizzyBot

has no knowledge of

anything that’s happened before

the current time.

The end result is that the

PhizzyBot

could easily get itself

stuck in a repetitive “loop,” such

as endlessly bouncing back and

forth between two closely

spaced objects. If the program

were modified to maintain some

record of what had gone before,

then we might be able to cir-

cumvent this sort of thing.

As a simple example, if the

program had some method of

checking its last few moves, it

could essentially say,

“Hmmm, I

seem to be cycling between the

IN A SPIN

Now set the

PhizzyBot

spinning clockwise, and time

how long it takes to make ten

complete revolutions. As be-

fore, repeat the process a num-

ber of times and average the

results to compensate for exper-

imental errors.

In our case, it took our

PhizzyBot

approximately 25

seconds to complete ten revolu-

tions, which equates to 2 5 sec-

onds per revolution (360 de-

grees). Remembering that the

smallest interval we can mea-

sure with our current program is

1/10 of a second, this means

that the smallest rotation we can

instruct the

PhizzyBot

to per-

form is 14 4 degrees (which we

can “round up” to 15 degrees for

the sake of this discussion).

THE SKELETON PRO-

GRAM

As for last month, the first

thing we’re going to do is to cre-

ate a skeleton (framework) pro-

gram, which we’ll develop as we

go along. Invoke your

PhizzyB

Simulator,

activate the assem-

bler, and enter the program

shown in Listing 1.

Note that the values you as-

sign to the

_10cm, _30deg,

_60deg,

and so forth labels to

control your

PhizzyBot

may be

different to the ones shown here,

because the gearing of your mo-

Maxfield & Montrose Interactive Inc

EPE Online, May 1999 - www.epemag.com - 555

&RQVWUXFWLRQDO 3URMHFW

Listing 1

### Start of Constant Declarations

LSENSORS: .EQU $F011

# Light Sensors

MGRAPH:

.EQU $F030

# Motor bargraph disp

TGRAPH:

.EQU $F031

# Timer bargraph disp

MCONTROL: .EQU $F032

# Motor controller

DELCONST: .EQU $0C

# Delay constant

STOP:

.EQU %00000000

# Stop motors

FORWARD: .EQU %00001010

# Go forward

SPIN_CW: .EQU %00000110

# Spin clockwise

SPIN_ACW: .EQU %00001001

# Spin anticlockwise

_1sec:

.EQU 10

# Delay = 1 second

_10cm:

.EQU 5

# Delay = 10 c’meters

_30deg:

.EQU 2

# Delay = 30 degrees

_60deg:

.EQU 4

# Delay = 60 degrees

_90deg:

.EQU 6

# Delay = 90 degrees

_120deg: .EQU 8

# Delay = 120 degrees

_150deg: .EQU 10

# Delay = 150 degrees

_180deg: .EQU 12

# Delay = 180 degrees

### End of Constant Declarations

### Start of main program initialization

.ORG

$4000

# Start of program

BLDSP $4FFF

# Load stack pointer

### End of main program initialization

### Start of Main Program Body

### End of Main Program Body

### Start of Subroutines

### End of Subroutines

### Start of Temp Locations and Data Values

GOFLAG:

.BYTE $01

# Flag (0=stop, 1=go)

TVALUE:

.BYTE

# Main timer temp val

TEMPX:

.2BYTE $0000

# Temp index register

### End of Temp Locations and Data Values

.END

tors and the size of your wheels

may differ from ours (bounce

back to the In a Spin section

above for more details).

Before you do anything

else, save this skeleton program

ffexp1.asm.

Now consider

the Constant Declarations sec-

tion at the beginning of the pro-

gram. The

LSENSORS

label will

be used to associate our new

light sensor device with the in-

put port at address $F011 (so

make sure you connect the little

rascal to this port).

Next we’re going to use the

PhizzyB’s

on-board 8-bit LED

bargraph display to indicate the

value we’re driving to the motors.

Thus, we equate the

MGRAPH

la-

bel the address of this output

port, which is $F030. As for last

month, we’re also going to con-

nect the 8-bit LED bargraph dis-

play we created in Part 2 (Dec

1998) to the output port at ad-

dress $F031, and then use this to

reflect the current value in the

timer. Thus, we equate the

TGRAPH

label to the address of

this output port. Also, we’re going

to connect our motor controller

board from Part 5 (March 1999)

to the output port at address

$F032. Hence the

MCONTROL

declaration.

The

DELCONST

label, which

is used to persuade our timing

subroutine to loop around for

1/10 of a second, is assigned a

value of $0C (12 in decimal).

(We determined the value of

DELCONST

by trial and error as

discussed in Part 5).

The

STOP, FORWARD,

SPIN_CW,

and

SPIN_ACW

labels

are assigned values that can be

used to control the

PhizzyBot’s

motors so as to stop the Bot,

drive it forward, spin it clock-

wise, or spin it anticlockwise,

respectively. Ideally we would

use the multi-label approach we

introduced last month; assigning

these values directly is a “quick

and dirty” solution, but it serves

our purposes here.

The remaining constant

declarations (_1sec,

_10cm,

_30deg, _60deg,

and so forth)

have been discussed in excruci-

ating detail above. The rest of

the skeleton program consists

of two initialization statements,

the reserving of some tempo-

rary locations, and some com-

ments, all of which have been

discussed into the ground ear-

lier in these series. So, without

further ado, let’s leap into the

fray!

THE TIMER SUBROU-

TINES

In a moment we’re going to

leap into the really interesting

stuff, but before we do we need

to add the timer routines shown

in Listing 2 (add these between

the

“Start and End of subrou-

tines”

comments in the skeleton

program).

These routines are exactly

the same as last month, so we

won’t spend any time discussing

them here. The only point to

note is the test of the

GOFLAG

label at the beginning of the

Maxfield & Montrose Interactive Inc

EPE Online, May 1999 - www.epemag.com - 556

&RQVWUXFWLRQDO 3URMHFW

TIMER

routine. We really aren’t

going to have any use for the

GOFLAG label this month, but

we will leave it (and the test)

where it is, because we don’t

want to do anything to affect the

delays in the

TIMER

routine.

(Note that we pre-assigned a

value of $01 (the “go” value) to

the

GOFLAG

location when we

declared it at the bottom of List-

ing 1, so we won’t have to con-

cern ourselves with this flag

anymore.)

point between the 22k

resistor

and 10k

potentiometer will be

pulled up towards a logic 1

(+5V) value. This will be in-

verted by IC1 to present a logic

0 to the input port. Similarly, if

an LDR is illuminated, its resis-

tance will fall and the tap point

will be pulled down towards a

logic 0 (0V). This, in turn, will be

inverted by IC1 to present a

logic 1 to the input port.

The end result is that any of

the LDRs that are illuminated

will be “seen” as logic 1 values

by the

PhizzyB.

In order to test

this, assemble your program,

download the resulting

ff-

exp1.ram

file to the

PhizzyB,

and set the program running.

Assuming that you’ve calibrated

the sensors as described in

Alan’s constructional article,

then all of the LEDs on the bar-

graph display should initially be

off. Now shine a light at each of

the LDRs in turn, and ensure

that the corresponding LED

lights up.

(Note that even if you don’t

have a real

PhizzyB

and

Phizzy-

Bot,

you can still perform all of

the experiments described in

this article on the

PhizzyB Simu-

lator

by presenting the appropri-

ate values to input port $F011

and observing the results.)

When you’ve satisfied yourself

that everything is working as it

should, reset the

PhizzyB

(and/

or the

PhizzyB Simulator)

and

proceed to the next section.

BLINDED BY THE

LIGHT

Although you may not have

fully appreciated this, the way in

which we implemented last

month’s “Collision Detection”

program was based on the as-

sumption that only one mi-

croswitch would be triggered at

a time. However, in the case of

our new light sensor device, it is

more than possible for multiple

LDRs to be activated simultane-

ously (Fig.2).

This article is based on the

assumption that either one sen-

sor will be activated as shown in

Fig.2a, or two adjacent sensors

as shown in Fig.2b. However,

depending on how you construct

your sensor housing (including

the positioning of the sensors

and the lengths of the internal

A SIMPLE TEST PRO-

GRAM

Before you do anything

else, make sure that the new

light sensor device is plugged

into the

PhizzyB’s

input port at

address $F011. Also ensure that

this device is oriented on top of

the

PhizzyBot

such that the LDR

driving bit

IP0

of the input port

is pointing towards the front of

the Bot (Fig.1).

Now, add the following

statements between the two

comments saying Start and End

of main program body in your

skeleton program:

LOOP: LDA

AND

STA

JMP

[LSENSORS]

%00111111

[MGRAPH]

[LOOP]

Listing 2

#== Start of "Main Timer" Routine

TIMER:

STA

[TVALUE]

# Store original

count

TLOOPA:

JSR

[ONETENTH]

# Call 1/10 Sec loop

LDA

[GOFLAG]

# Load flag

[TRETURN]

# Jump if flag=0

LDA

[TVALUE]

# Load count value

DECA

# Decrement it

STA

[TVALUE]

# Store it

STA

[TGRAPH]

# Store it to LEDs

JNZ

[TLOOPA]

# Loop again if !=0

TRETURN:

RTS

# Exit subroutine

#== End of "Main Timer" Routine

#== Start of "1/10 Second" Routine

ONETENTH: LDA

DELCONST

# Load count value

OTLOOPA:

DECA

# Decrement it

JNZ

[OTLOOPA]

# Loop again if !=0

OTRETURN: RTS

# Exit subroutine

#== End of "1/10 Second" Routine

All this program does is to

loop around reading from the

port connected to the light sen-

sors and writing to the 8-bit LED

bargraph display connected to

output port $F030 (label

MGRAPH)

on the

PhizzyB.

How-

ever, it is worth taking special

note of the

AND

instruction,

which is used to “mask out” the

top two (unused) input port bits

and force them to 0 values.

The way the sensor circuits

work is that if an LDR is not illu-

minated it will have a high resis-

tance, so the tap (connection)

Maxfield & Montrose Interactive Inc

EPE Online, May 1999 - www.epemag.com - 557

&RQVWUXFWLRQDO 3URMHFW

Front

Bit 5

Bit 0

Bit 4

Bit 3

Fig.1. Ensure that the LDR driving input port bit

IP0 is pointing towards the front.

with these labels follow a stan-

dard binary count sequence.

Bit 1

This should be easy enough,

but just in case you’re a little

unsure, here's a simple trick

you can use to create these

entries. Start off by entering

the first line for label

Bit 2

LS000000

(including the

.BYTE STOP, _1sec

por-

tion), then copy this line 64

times. In order to edit these 64

lines such that they reflect a bi-

nary count, commence by mak-

ing the least-significant (bit 0)

column alternate between 0 and

1, for example:

LSxxxxx0:

LSxxxxx1:

LSxxxxx0:

LSxxxxx1:

LSxxxxx0:

LSxxxxx1:

etc

(a) One sensor activated

(b) Two sensors activated

Fig.2. Multiple LDRs may be activated simultaneously.

dividing “spokes”), it might be

possible for your torch

(flashlight) beam to activate

one, two, or even

three

adjacent

sensors.

In fact we also have to con-

sider the fact that stray light

beams from external sources

may activate one or more sen-

sors (e.g. the sun shining

through a window). And it’s not

beyond the bounds of possibility

that a younger sibling may be

sabotaging your experiments by

surreptitiously shining their own

light sources at the

PhizzyBot

from behind the sofa …

“Just

wait till our mom comes home

Andrew!”

So although we’re only go-

ing to focus on the cases involv-

ing one or two (adjacent) sen-

sors, our program has to ac-

commodate the fact that any

combination of LDRs may be

illuminated. As we have six sen-

sors and each may be in one of

two states (On or Off), we actu-

Maxfield & Montrose Interactive Inc

ally have 2 = 64 different pat-

terns of 0s and 1s to deal with.

(This is one reason why we

didn’t use eight sensors, be-

cause we didn’t want to have to

contend with 2 = 256 different

patterns). But fear not, because

this isn’t going to be as tricky as

you might suspect …

Now make the bit-1 column

alternate between two 0s and

two 1s, for example:

LSxxxx00:

LSxxxx01:

LSxxxx10:

LSxxxx11:

LSxxxx00:

LSxxxx01:

etc

2 =64 EEEKKK!

The first thing we need to

do is to create 64 labels just be-

fore the

“End of Temp Locations

and Data Values”

comment in

Listing 1. Each of these labels

will commence with the charac-

ters “LS” (standing for

“light sen-

sors”)

followed by a 6-bit binary

code. Each label will also be

followed by a

.BYTE

statement

and associated values as shown

in Listing 3 (we’ll discover the

purpose of these values in the

not-so-distant future).

As we see from this listing,

the binary codes associated

Continue with the bit-2 col-

umn alternating between four 0s

and four 1s; the bit-3 column

alternating between eight 0s

and eight 1s; the bit-4 column

alternating between sixteen 0s

and sixteen 1s; and finally the

bit-5 column starting with thirty-

two 0s and ending with thirty-

two 1s (phew!).

In reality our program only

needs the first of these labels as

we’ll see. The other labels are

intended for us so that we can

see what we’re doing.

EPE Online, May 1999 - www.epemag.com - 558

Plik z chomika:

fred1144

Inne pliki z tego folderu:

0599f(2).pdf (822 KB)
0599g(2).pdf (442 KB)
0599i(2).pdf (561 KB)
0599h(2).pdf (281 KB)
0599m(2).pdf (193 KB)

0599o(2).pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: