Mobile

Robotics

Graduate

Students

O.

Fuentes

J.

Karlsson

W.

Meira

R.

Rao

T.

Riopka

J.

Rosca

R.

Sarukkai

M.

Van

Wie

M.

Zaki

Staff

T.

Becker

R.

Frank

B.

Miller

Prof.

C.

M.

Brown

The

University

of

Rochester

Computer

Science

Department

Rochester

New

York

Technical

Report

June

Abstract

On

December

four

student-built

autonomous

robots

demonstrated

various

strategic

tactical

and

mechanical

approaches

to

a

delivery

task

That

event

was

preceded

by

approximately

two

years

of

history

and

two

days

of

frenzied

preparation

Our

robotics

efforts

were

based

on

materials

from

MIT

's

well-known

course

This

report

summarizes

our

experiences

from

pedagogical

goals

and

organizational

matters

through

mechanical

and

electronic

techniques

Our

intended

audience

is

future

robot-builders

and

organizers

of

robot-building

courses

We

assume

familiarity

with

material

in

Jones

and

Flynn

's

Mobile

Robotics

text

and

with

the

various

materials

available

from

MIT

over

the

internet

Sensors

This

material

is

based

on

work

generously

supported

by

the

Department

of

Computer

Science

-LRB-

Tom

LeBlanc

Chair

-RRB-

and

NSF

IIP

grant

Wagner

Meira

Jr.

is

supported

by

CNPq-Brazil

Grant

Contents

Prehistory

Getting

Started

The

Competition

Map-Maker

-LRB-

Sarukkai

Meira

Zaki

-RRB-

Map-maker

General

description

Beacons

and

Triangulation

Localization

Tower

Design

Photoresistor

Mounting

Beacon

Tracking

Line

Following

Steering

Map-Maker

Gearing

Map-Maker

Lego

Experience

Map

Algorithms

Actions

algorithm

Position

Finding

Line-Follower

-LRB-

Miller

Becker

-RRB-

Cyclops

-LRB-

Riopka

Rosca

-RRB-

Cyclops

functionality

Cyclops

sensors

The

Cyclops

Artificial

Eye

System

Linear

Scanner

Scanner

Calibration

and

Thresholds

The

Vision

Algorithm

Image

Analysis

Vision

as

a

Behavior

Skill

Learning

Skill

Acquisition

Manoever

Reversal

Photoresistor

Response

Time

Servo-multiplexing

Circuit

Behavior

as

a

Hierarchy

of

Goals

Cyclops

actuators

Meccano

Monster

-LRB-

Fuentes

Rao

Van

Wie

-RRB-

Why

Meccano

Disaster

Building

the

Board

Designing

the

Body

with

Meccano

Software

for

Compulsory

Floor

Exercises

The

Competition

Beyond

the

Minibot

A

Parts

Lists

and

Information

A.

Rug

Warrior

Jones

and

Flynn

Book

A.

From

Randy

Sargent

at

MIT

A.

Work

Area

B

Supplemental

Sensors

B.

Parts

List

B.

Break

Beam

Sensors

B.

IR

LED

Pairs

B.

Microphone

B.

Miniature

IR

Reflectance

Sensors

B.

Ultrasound

B.

Further

Ideas

C

Course

Details

C.

Goals

and

Organization

C.

Compulsory

Floor

Exercises

C.

The

Robot

Competition

Prehistory

In

-LCB-

Lambert

Wixson

Jonas

Karlsson

-LRB-

Grad

students

in

thesis

mode

-RRB-

and

Ray

Frank

ordered

some

miniboard

kits

through

connections

discovered

on

the

comp.robotics

newsgroup

Miniboards

are

scaled-down

versions

of

the

microcontroller

boards

ultimately

used

in

the

robotics

work

described

here

Wixson

and

Karlsson

produce

a

successful

autonomous

LEGO

corridor-running

robot

and

the

miniboard

was

used

later

in

real-time

applications

-LRB-

sensing

for

digital

closed-loop

control

-RRB-

Thanks

as

usual

to

student

enthusiasm

and

agitation

Brown

volunteered

in

the

Spring

of

to

be

the

statutory

organizer

and

titular

head

of

a

robot-building

seminar

to

be

held

in

the

Fall

semester

of

One

constraint

was

that

if

the

necessary

parts

could

not

be

ordered

in

kit

-LRB-

one

call

does

all

-RRB-

form

it

was

not

deemed

practical

to

pursue

the

idea

For

the

more

hardy

parts

lists

are

available

in

the

very

helpful

documentation

available

at

MIT

in

support

of

their

course

Luckily

Randy

Sargent

of

MIT

had

gone

into

the

business

of

selling

these

kits

and

so

we

proceeded

Over

the

summer

an

organizing

committee

-LRB-

Brown

Karlsson

Frank

Brad

Miller

and

Tim

Becker

-RRB-

dealt

with

the

kit-ordering

process

wrote

a

proposal

for

an

Undergraduate

version

of

the

course

made

up

lists

of

tools

and

other

support

material

deemed

needed

to

get

started

-LRB-

some

details

are

in

Section

-RRB-

The

organizers

undertook

to

assemble

robot

during

the

summer

and

assess

the

difficulties

and

to

design

a

graduate-level

seminar

based

on

the

robot-building

and

competition

conception

-LRB-

details

in

Section

C

-RRB-

Getting

Started

A

good

place

to

get

general

information

is

Of

course

the

newsgroup

comp.robotics

is

still

the

standard

place

read

and

keep

current

or

to

post

specific

inquiries

The

consumables

in

our

work

were

almost

entirely

the

electronics

parts

to

assemble

the

microcontroller

computer

Appendix

A

gives

parts

lists

and

two

different

alternatives

for

robot

kits

The

LEGO

kits

used

for

mechanical

robot

construction

can

be

recycled

The

cost

comes

to

per

student

Students

might

decide

to

buy

their

robot

or

microcontroller

once

assembled

we

might

charge

a

lab

fee

of

As

of

now

we

do

n't

have

a

fixed

plan

for

how

to

finance

this

significant

ongoing

cost

Aside

from

the

above

consumable

items

ideally

the

rest

of

the

course

equipment

is

permanent

meaning

that

students

take

responsibility

for

returning

it

with

only

reasonable

wear

and

tear

The

Competition

The

stars

of

this

report

are

the

four

robots

that

were

built

during

the

course

The

robot

descriptions

follow

along

with

algorithms

assumptions

associated

team

goals

successful

and

less

successful

ideas

and

so

on

It

is

interesting

to

note

how

the

individual

mechanical

and

software

designs

interact

to

produce

coherent

component

capabilities

and

integrated

systems

First

however

to

understand

some

of

the

design

decisions

it

helps

to

know

the

history

of

the

course

assignments

and

the

rules

governing

the

final

competition

More

course

details

are

presented

in

Appendix

C

The

course

had

three

phases

construction

robot

olympics

and

compulsory

exercises

and

the

competition

To

provide

context

for

the

reports

on

individual

robots

the

competition

rules

are

presented

here

On

December

a

robot

Federal

Express

competition

was

held

with

four

contestants

There

was

an

enthusiastic

turnout

of

locals

the

press

was

not

notified

until

after

the

event

We

had

a

re-run

for

the

press

a

week

later

attended

by

two

television

stations

the

local

paper

and

a

radio

station

The

resulting

coverage

was

responsible

and

good-natured

and

more

than

likely

good

for

business

Following

are

the

rules

and

a

diagram

of

the

arena

as

it

was

set

up

for

the

competition

In

fact

one

team

-LRB-

MAP-MAKER

-RRB-

did

use

a

IR

beacon

for

ego-location

ffl

The

spirit

of

the

competition

is

to

investigate

trades-off

between

the

following

capabilities

-LCB-

line

following

-LCB-

beacon

following

-LCB-

obstacle

avoidance

-LCB-

memory

-LRB-

learning

-RRB-

and

geometric

representations

-LCB-

other

ingenious

ideas

invented

by

contestents

ffl

Competition

takes

place

on

the

by

white

sheet

with

walls

markings

and

obstacles

added

Walls

are

sturdy

and

high

made

of

or

plywood

Interior

of

walls

painted

white

There

will

up

to

a

maximum

of

eight

physical

obstacles

inches

high

and

a

foot

square

at

unannounced

positions

on

a

square

grid

The

sides

of

obstacles

will

be

painted

grey

See

Fig.

ffl

Robot

must

not

be

tethered

to

receive

either

power

or

digital

information

it

must

be

completely

autonomous

ffl

Robot

begins

or

arrives

at

a

Pickup

Area

marked

by

an

IR

beacon

at

height

of

inches

above

floor

Robot

requests

-LRB-

via

its

beeper

-RRB-

and

within

seconds

is

given

in

its

ball-carrying

hopper

a

ping-pong

ball

ffl

Obstacles

and

Pickup

and

Delivery

areas

are

one

foot

square

placed

on

one

foot

grid

squares

These

areas

will

be

in

a

fixed

position

on

the

arena

KNOWN

in

advance

to

be

fixed

and

painted

black

soon

ffl

Between

the

pickup

and

delivery

areas

will

be

a

path

marked

in

eletrical

tape

This

path

is

UNKNOWN

in

advance

ffl

There

will

be

not

more

than

eight

obstacles

in

the

arena

whose

location

like

the

path

is

variable

and

UNKNOWN

in

advance

ffl

Over

the

pickup

area

will

be

IR

beacon

at

the

height

of

ffl

Over

the

delivery

area

will

be

IR

beacon

at

the

height

of

ffl

A

team

can

design

and

deploy

more

beacons

-LCB-

prior

to

the

competition

a

single

IR

or

visible-light

beacon

can

be

set

up

These

beacons

location

must

be

communicated

to

the

organizer

-LRB-

CB

-RRB-

before

the

arena

is

set

up

for

the

competition

their

position

can

not

depend

on

the

location

of

obstacles

for

instance

-LCB-

during

the

competition

the

robot

can

drop

beacons

or

other

navigational

aids

freely

ffl

Both

pickup

and

delivery

areas

are

black

areas

on

floor

Pickup

and

Delivery

areas

may

or

may

not

be

against

walls

We

shall

use

black

electrical

tape

to

darken

these

areas

-LRB-

as

soon

as

we

determine

that

it

will

work

-RRB-

THUS

if

you

are

over

a

big

black

area

-LRB-

bigger

than

the

tape

-RRB-

and

you

can

sense

an

IR

beacon

in

the

direction

you

've

been

heading

there

's

a

good

chance

you

're

in

the

desired

area

ffl

Robot

is

to

deliver

the

package

to

the

delivery

area

take

it

there

and

dump

it

There

will

be

separate

style

points

and

perhaps

a

separate

award

for

the

elegance

or

distance

or

accuracy

of

ejecting

the

pingpong

ball

but

as

long

as

it

gets

off

the

truck

somehow

while

the

robot

is

positioned

-LRB-

at

least

partly

-RRB-

over

the

drop-off

area

full

credit

results

ffl

The

robot

makes

its

way

back

to

pickup

area

and

repeats

-LRB-

only

we

hope

with

improved

performance

-RRB-

ffl

There

will

be

a

tape

path

guaranteed

unobstructed

between

the

pickup

and

delivery

areas

It

is

guaranteed

not

to

be

the

shortest

path

It

will

have

no

radius

of

curvature

less

than

one

foot

We

'll

try

to

be

nice

and

not

put

minimum

clearances

near

maxima

of

curvature

We

guarantee

of

clearance

on

either

side

of

the

tape

ffl

We

guarantee

at

least

a

wide

path

between

any

separated

obstacles

ffl

There

will

be

partial

scores

for

partial

performance

to

be

determined

But

the

main

score

is

how

many

packages

can

be

delivered

in

four

minutes

If

robot

functions

perfectly

four

minutes

should

be

enough

to

show

it

off

If

it

malfunctions

four

minutes

is

an

eternity

ffl

A

human

may

intervene

in

the

contest

to

rotate

-LRB-

not

translate

-RRB-

or

to

repair

-LRB-

replace

bits

that

have

fallen

off

-RRB-

the

robot

The

clock

runs

during

interventions

and

each

separate

intervention

costs

one

ping-pong

ball

Any

number

of

repairs

but

only

one

rotation

are

allowed

per

intervention

The

intent

here

is

to

minimize

robot

and

team

and

audience

frustration

caused

by

simple

mechanical

or

logical

failures

ffl

In

the

spirit

of

minimally

changing

the

rules

if

robots

A

and

B

have

each

delivered

N

balls

at

the

end

of

four

minutes

then

that

robot

farthest

along

its

way

to

delivering

N

balls

is

the

winner

This

criterion

should

apply

pairwise

to

all

robots

and

should

order

the

set

The

judge

's

-LRB-

or

judging

panel

's

-RRB-

opinion

will

be

final

Videotape

replays

may

be

needed

but

we

have

the

technology

Map-Maker

-LRB-

Sarukkai

Meira

Zaki

-RRB-

With

this

section

we

commence

descriptions

of

individual

robots

Map-maker

is

an

ambitious

robot

with

complex

internal

representations

and

sensing

capabilities

The

MAP-Making

robot

is

uniquely

distinguished

by

the

ability

to

plan

paths

determine

present

location

and

accomodate

sensor

errors

during

position

determination

Given

a

grid

model

of

the

world

positional

information

of

the

robot

is

sufficient

to

build

the

world

representation

For

instance

if

an

obstacle

is

detected

by

the

robots

front

switches

then

the

position

determining

routine

is

executed

followed

by

marking

the

appropriate

location

of

the

world

as

an

obstacle

Map-maker

General

description

We

can

divide

our

robot

into

the

following

functional

parts

Traction

the

traction

includes

the

two

back

wheels

and

the

gear

train

-LRB-

including

one

motor

-RRB-

associated

with

them

We

used

the

differential

provided

with

the

lego

set

distributing

the

power

between

the

wheels

Figure

The

eight-foot-square

arena

Black

line

marks

black

tape

path

IR

beacons

of

different

frequencies

hang

foot

over

start

and

finish

squares

and

also

over

the

south-east

corner

Shaded

squares

show

obstacles

Steering

Our

steering

is

provided

by

one

wheel

that

is

controlled

by

a

motorized

gear

train

There

are

two

lateral

sensors

that

prevent

excessive

steering

To

determine

if

the

robot

is

going

straight

we

used

an

optical

solution

with

photodiodes

we

attached

the

emitter

to

the

robot

body

and

the

receiver

to

the

steering

wheel

in

such

a

way

that

when

they

are

aligned

-LRB-

i.e.

the

receiver

is

receiving

the

emitter

's

signal

-RRB-

the

wheel

is

in

a

straight

direction

Bumper

system

We

have

four

bumpers

two

frontal

and

one

in

each

side

There

is

a

digital

switch

associated

with

each

of

them

Localization

System

The

mechanics

involved

in

the

localization

system

consists

of

the

servo

motor

that

drives

three

IR

receivers

and

is

mounted

on

a

tower

Ball

holder

The

ball

holder

consists

of

lego-built

box

with

a

motor

included

The

motor

has

a

stick

attached

to

its

axle

When

the

motor

is

activated

for

seconds

the

stick

throws

out

the

ball

Beacons

and

Triangulation

In

order

to

detect

our

exact

position

in

the

board

we

needed

three

referencial

points

It

is

known

that

the

IR

receiving

task

is

CPU

intensive

so

in

order

to

take

advantage

of

the

special

sensor

electronics

of

the

board

we

decided

to

use

only

the

two

standard

frequencies

thus

two

of

the

three

transmitters

were

constrained

to

use

the

same

frequency

This

caused

two

problems

Bimodality

detection

Detecting

two

emitters

of

the

same

frequency

causes

two

peaks

at

the

end

of

the

scanning

information

Sorting

them

out

and

dealing

with

them

required

contextdependent

information

such

as

knowledge

about

the

minimum

angle

between

beacons

-LRB-

see

later

-RRB-

Proximity

effect

if

we

are

really

near

one

beacon

usually

we

are

not

able

to

detect

the

other

not

only

because

of

the

intensity

of

the

nearest

that

is

bigger

but

also

because

the

minimum

angle

is

not

effective

in

this

case

Localization

Tower

Design

One

of

the

problems

we

realized

when

using

the

servo

motor

is

that

it

does

not

cover

the

nominal

range

of

We

guess

that

it

does

not

reach

the

final

in

each

side

In

order

to

be

able

to

perform

the

localization

we

attached

three

IR

receivers

with

the

same

angular

distance

between

consecutive

ones

-LRB-

-RRB-

We

had

various

problems

with

interference

due

to

reflections

of

the

IR

signals

transmited

from

the

reference

points

To

avoid

such

problems

we

used

aluminum

foil

around

the

receiver

collector

Another

detail

is

that

the

collector

is

taller

than

it

is

wide

being

able

to

detect

transmitters

sited

at

various

heights

without

horizontal

accuracy

loss

Photoresistor

Mounting

The

photoresistors

were

used

to

implement

line

following

Each

of

them

was

mounted

in

a

black

paper

cylinder

The

purpose

of

this

tube

is

to

avoid

external

light

interference

These

tubes

are

mounted

in

the

front

wheel

structure

with

their

entrance

standing

over

the

floor

The

calibration

was

done

manually

checking

the

readings

for

black

and

white

areas

Despite

this

we

found

that

light

variations

-LRB-

like

a

person

's

shadow

-RRB-

are

enough

alter

the

thresholds

that

distinguish

the

regions

Beacon

Tracking

We

used

our

servo

motor

to

perform

beacon

tracking

We

attached

three

IR

receivers

to

the

servo

motor

in

order

to

cover

all

the

around

the

robot

We

detect

the

position

of

a

beacon

by

positioning

the

servo

motor

in

different

angles

and

checking

the

IR

receivers

The

scanning

procedure

has

two

steps

coarse

scan

and

fine

scan

In

the

coarse

scan

we

check

angles

spaced

by

degrees

to

detect

the

regions

where

the

beacons

could

be

After

this

procedure

we

perform

the

fine

scan

where

we

check

a

degrees

angle

with

increments

of

degree

Line

Following

Our

line

following

strategy

is

simple

but

efficient

We

attached

two

photoresistors

to

our

front

wheel

in

such

way

that

if

we

are

following

the

line

the

photoresistors

will

sense

the

black

region

If

one

of

them

loses

the

line

then

we

know

that

we

are

not

only

going

out

of

the

desired

direction

but

also

to

which

side

of

the

line

allowing

us

to

take

the

correct

recovery

action

Steering

We

used

the

motors

supplied

with

the

kits

to

implement

our

steering

mechanism

These

are

high

speed

motors

and

we

needed

a

gear

train

with

a

reduction

factor

of

about

that

is

attached

to

the

front

wheel

To

avoid

damage

to

the

steering

and

robot

we

put

two

touch

sensors

in

the

front

of

the

robot

that

deactivate

the

steering

motor

when

it

tries

to

turn

more

than

allowed

The

main

problem

with

this

approach

is

the

inaccuracy

of

the

turns

Gor

reactive

tasks

like

line

following

it

works

satisfactorily

but

things

become

really

hard

when

we

talk

about

spacially

exact

actions

like

the

ones

required

in

a

mapped

environment

It

is

hard

to

measure

progress

by

timing

the

activation/deactivation

of

motors

since

their

performance

is

influenced

by

the

-LRB-

variable

-RRB-

state

of

battery

charge

Another

problem

is

that

the

gear

train

is

not

accurate

enough

to

avoid

some

slippage

when

the

motor

direction

is

reversed

Another

precision

related

problem

is

the

speed

reducing

it

to

allow

adequate

control

had

the

effect

of

slowing

down

steering

appreciably

Map-Maker

Gearing

Map-maker

has

two

gear

trains

one

for

steering

and

other

for

traction

Both

use

the

same

motor

and

have

reductions

of

and

respectively

The

gear

train

building

should

be

done

carefully

not

only

to

avoid

friction

in

the

axles

-LRB-

that

can

cause

the

train

to

block

-RRB-

but

also

to

save

space

in

the

robot

Map-Maker

Lego

Experience

The

main

lesson

from

our

lego

adventures

is

that

we

should

be

conservative

We

tried

to

build

some

structures

and

had

a

lot

of

problems

IR

receivers

Servo

Motor

Ball

Holder

Side

Bumpers

AA

Batteries

Front

Bumpers

Figure

The

MAP-Maker

Steering

one

of

the

big

problems

with

our

steering

mechanism

is

gear

slippage

Due

to

the

fact

that

the

plastic

gears

have

sloppy

tolerances

high

precision

constructions

like

the

steering

have

low

accuracy

Skirt

We

designed

a

bumper

system

that

uses

a

skirt

around

the

robot

The

main

feature

of

the

skirt

is

free

movement

in

the

horizontal

plane

Properly

attached

to

four

touch

sensors

-LRB-

front

left

right

and

back

-RRB-

it

allows

easy

handling

of

all

possible

bumping

situations

Grasp

and

Lift

We

tried

to

devise

a

pretty

complicated

grasp

and

lift

device

for

the

robot

The

idea

is

using

only

one

motor

perform

two

tasks

The

motor

power

is

shared

via

a

differential

We

start

grasping

when

this

operation

is

complete

the

differential

transmits

the

power

to

the

lift

mechanism

The

reverse

operation

is

similar

as

the

force

to

unlift

is

bigger

than

the

one

to

ungrasp

we

first

put

the

device

down

and

then

ungrasp

The

problem

in

this

case

was

gear

slippage

also

they

are

not

strong

enough

to

hold

while

the

differential

is

transferring

power

to

the

other

task

Eyes

Steering

Mechanism

Robot

Traction

Figure

The

MAP-Maker

Algorithm

MAIN

Start

at

Starting

point

START

Determine

ORIENTATION

Take

Commands

returned

by

function

FindActions

-LRB-

-RRB-

If

Obstacle

then

SCAN

to

find

present

LOCATION

Find

ORIENTATION

Mark

MAP

with

OBSTACLE

Recompute

PATH

to

goal

goto

step

until

GOAL

REACHED

Throw

BALL

The

main

algorithm

is

pretty

straightforward

The

starting

point

for

the

task

is

fixed

Our

position

determining

mechanism

is

based

on

the

angular

locations

of

three

IR

transmitters

that

had

to

be

placed

in

an

appropriate

geometric

configuration

so

as

to

enable

unique

position

detection

and

is

detailed

later

Based

on

the

quadrant

locations

of

the

IR

transmitters

the

head-on

direction

or

orientation

of

the

robot

with

respect

to

the

three

IR

transmitters

and

thus

the

board

can

be

determined

robustly

The

action

sequence

is

constrained

to

one

of

the

following

STRAIGHT

RIGHT

LEFT

BACK

The

actual

path

planning

algorithm

-LRB-

shown

in

a

later

section

-RRB-

is

basically

a

dynamic

programming

search

from

the

goal

location

to

the

start

location

of

the

map

using

the

available

action

sequences

In

our

preliminary

experiments

the

map

grid

locations

were

filled

with

distance

-LRB-

to

the

goal

-RRB-

values

and

actions

required

to

go

from

the

START

position

to

the

GOAL

position

were

then

determined

However

this

need

not

be

the

best

possible

action

sequence

an

alternate

would

be

to

use

a

dynamic

programming

approach

and

accumulating

the

penalties

of

each

reverse

action

from

the

GOAL

state

to

the

START

state

During

a

final

run

due

to

the

very

low

-LRB-

including

system

stack

-RRB-

onboard

memory

the

actual

exhaustive

dynamic

programming

search

had

to

be

abandoned

in

place

of

a

local

greedy

action

selection

mechanism

Thus

the

procedure

was

to

determine

the

present

location

find

path

and

take

the

appropriate

action

If

an

unexpected

event

such

as

the

detection

of

an

obstacle

occurs

mark

appropriate

cell

in

the

map

as

an

obstacle

and

recompute

an

alternative

path

The

idea

behind

fast

robust

determination

of

the

location

of

the

robot

was

twofold

use

a

table-lookup

-LRB-

angular

information

from

the

real

world

worked

better

than

geometrically

computed

values

for

some

ill-posed

locations

-RRB-

to

match

sensor

angles

with

stored

angles

to

get

the

k

nearest

neighbours

-LRB-

locations

-RRB-

the

important

second

aspect

was

to

cross-validate

the

K-NN

locations

with

the

neighbourhood

of

the

expected

location

At

locations

more

than

a

square

away

from

the

IR

transmitters

the

cross-validation

scheme

enabled

recovery

from

positional

errors

accumulated

due

to

friction

wheel

slippage

etc.

Finding

the

angles

accurately

could

be

expensive

however

we

reduced

the

cost

of

scanning

by

doing

two

passes

The

first

pass

is

a

coarse

scan

and

the

second

pass

is

of

fine

resolution

in

a

degree

range

of

the

maxima

detected

during

the

first

pass

Map

Algorithms

Algorithm

FindPath

The

map

is

represented

by

a

x

table

Clear

MAP

at

all

points

leaving

the

obstacle

locations

unchanged

Mark

START

and

END

locations

Starting

at

the

END

location

apply

recursively

the

following

step

ffl

Depth

at

END

ffl

Let

current

location

be

x

y

and

depth

of

recursion

DEPTH

ffl

Let

be

a

neighbor

of

x

y.

ffl

MAP

-LSB-

-RSB-

min

-LRB-

MAP

-LSB-

-RSB-

DEPTH

-RRB-

Actions

algorithm

Algorithm

FindActions

Find

-LRB-

using

the

IR

beacons

-RRB-

the

initial

ORIENTATION

of

the

robot

Assign

ORIENTATION

X

STARTx

Y

STARTy

For

each

of

the

following

moves

determine

the

value

entered

in

the

MAP

and

choose

the

action

wth

the

minimum

value

LEFT

RIGHT

BACK

STRAIGHT

Assign

X

ActionX

Y

ActionY

ORIENTATION

ActionORIENTATION

If

not

reached

END

then

goto

step

EXAMPLE

Initial

configuration

of

MAP

S

START

S.

E

END

Obstacle

E.

Filling

the

MAP

with

path

information

by

using

dynamic

programming

Algorithm

FindPath

applied

Note

that

the

path

is

given

by

following

the

sequence

abc

S

in

reverse

lkjihghi

kjih

fgh

a

step

away

from

END

b

and

so

on

j

Sg

efg

ihgfedef

hgfedcde

gfed

bcd

h

dcbabc

ij

baEab

Finding

Action

Sequences

after

applying

Algorithm

FindActions

Initial

ORIENTATION

is

to

the

RIGHT

Action

Sequence

generated

RIGHT

STRAIGHT

LEFT

STRAIGHT

Position

of

Robot

after

each

ACTION

INITIAL

position

of

ROBOT

ORIENTATION

Facing

Right

E.

RIGHT

S.

ORIENTATION

Facing

down

E.

S.

ORIENTATION

Facing

down

E.

STRAIGHT

S.

ORIENTATION

Facing

down

E.

LEFT

S.

ORIENTATION

Facing

Right

@E

STRAIGHT

S.

ORIENTATION

Facing

Right

REACHED

GOAL

Position

Finding

We

use

three

infra-red

transmitters

to

determine

the

robot

position

anywhere

on

the

grid

uniquely

Refer

to

figure

We

use

the

servo

motor

to

scan

and

get

the

three

angles

A

B

and

C

We

next

find

the

centers

of

the

three

circles

passing

through

the

points

ROBOT

GOAL

THIRD

IR

ROBOT

START

THIRD-IR

and

ROBOT

START

GOAL

These

centers

are

denoted

as

P

Q

and

S

respectively

Let

Rx

Ry

denote

the

x

and

y

co-ordinates

of

the

Robot

Let

a

similar

notation

denote

the

co-ordinates

of

the

three

centers

We

can

now

find

the

Robot

position

by

the

following

set

of

equations

-LRB-

Rx

Px

-RRB-

-LRB-

Ry

Py

-RRB-

P

-LRB-

-RRB-

-LRB-

Rx

Qx

-RRB-

-LRB-

Ry

Qy

-RRB-

-LRB-

-RRB-

-LRB-

Rx

Sx

-RRB-

-LRB-

Ry

Sy

-RRB-

-LRB-

-RRB-

Now

from

equation

and

we

get

the

following

-LRB-

Qx

Px

-RRB-

-LRB-

Qy

Py

-RRB-

-LRB-

P

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

And

similarly

from

equation

and

we

have

the

following

-LRB-

Sx

Qx

-RRB-

-LRB-

Sy

Qy

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

From

these

two

equations

we

can

easily

compute

the

two

unknowns

namely

Rx

and

Ry

However

there

is

still

the

matter

of

computing

the

radius

and

the

centers

co-ordinates

of

the

three

circles

We

'll

show

how

to

do

this

for

the

circle

passing

through

ROBOT

START

and

THIRD-IR

i.e.

the

one

centered

at

Q.

ROBOT

START

GOAL

THIRD

IR-T

Q

P

S

C

BA

Figure

Position

Finding

There

are

two

cases

to

be

dealt

with

here

In

the

first

case

the

angle

between

the

THIRD

IR

ROBOT

and

START

namely

the

angle

B

is

less

then

degrees

which

is

shown

in

figure

Recall

the

fact

that

the

angle

made

by

the

chord

THIRD

IR

START

at

the

center

of

the

circle

is

twice

B.

Therefore

when

we

drop

a

perpendicular

from

the

center

onto

the

chord

we

get

two

right

triangles

with

B

as

one

of

the

angles

We

already

know

the

length

of

the

chord

lets

call

it

AB

and

we

know

the

angle

D

We

first

find

the

radius

od

the

circle

Qr

as

follows

Qr

AB

-LRB-

B

-RRB-

-LRB-

-RRB-

Now

that

we

know

Qr

and

know

the

angle

D

B

we

know

the

hypotenuse

and

one

acute

angle

of

the

right

triangle

with

thick

lines

We

can

easily

find

Qx

and

Qy

relative

to

the

co-ordinates

of

the

THIRD

IR

say

Tx

and

Ty

We

can

then

find

the

real

co-ordinates

of

the

center

by

adding

or

subtracting

Tx

and

Ty

appropriately

The

following

equations

achieve

that

Qx

Qr

Sin

-LRB-

D

B

-RRB-

-LRB-

-RRB-

Qy

p

-LRB-

-RRB-

The

second

case

is

shown

in

figure

where

the

angle

B

is

greater

than

degrees

In

this

case

we

use

the

angle

which

must

be

less

then

degrees

Then

the

angle

made

by

the

chord

B

B

THIRD

IR

START

ROBOT

Q

D

-LRB-

Qx

Qy

-RRB-

Qx

Qy

Qr

Figure

Case

I

B

at

the

center

of

the

circle

is

twice

and

dropping

the

perpendicular

from

the

center

onto

the

chord

we

get

a

right

triangle

with

as

one

of

the

angles

From

this

information

we

can

easily

get

the

angle

of

the

thick

right

triangle

The

radius

Qr

is

calculated

as

before

and

we

can

easily

obtain

Qx

and

Qy

as

follows

Qx

Qr

Sin

-LRB-

B

D

-RRB-

-LRB-

-RRB-

Qy

-LRB-

-RRB-

In

the

beginning

we

were

planning

to

do

this

at

run

time

but

we

soon

ran

into

memory

problems

We

then

decided

to

make

a

table

of

positions

along

with

the

angles

at

that

position

We

decided

to

keep

a

minimal

sized

tables

with

entries

corresponding

to

the

positions

of

the

centers

of

the

squares

in

the

grid

To

find

our

position

the

robot

would

scan

the

grid

and

obtain

the

three

angles

We

could

then

simply

search

through

the

table

and

output

the

closest

match

However

there

was

one

additional

problem

with

this

approach

The

IR

transmitters

at

the

GOAL

and

THIRD

IR-T

both

transmitted

at

while

the

START

was

at

When

the

robot

is

close

to

the

GOAL

and

especially

in

the

top

right

squares

it

becomes

difficult

to

distinguish

the

two

transmitters

since

the

GOAL

IR

obscures

the

THIRD

IR-T

We

got

around

this

problem

by

measuring

the

angles

returned

by

the

servo

at

the

trouble

spots

and

storing

these

values

in

the

table

instead

of

the

actual

values

we

should

have

obtained

This

difficulty

could

be

solved

if

the

THIRD

IR-T

were

at

a

different

frequency

But

we

did

n't

have

time

to

hack

the

assembly

code

to

achieve

this

A

good

feature

of

our

approach

is

that

due

to

the

palcement

of

the

transmitters

we

could

uniqely

identify

which

region

we

were

in

and

that

helped

us

in

calculating

the

exact

position

of

the

robot

There

are

four

regions

Having

found

the

robot

position

correctly

we

can

also

find

the

robot

orientation

So

far

we

had

been

using

the

angle

differences

i.e.

we

actually

measure

the

absolute

angles

to

the

three

transmitters

but

our

position

finding

algorithm

uses

the

differences

between

these

We

can

get

our

Q

START

ROBOT

THIRD

IR

B

D

-LRB-

Qx

Qy

-RRB-

Qy

Qx

Qr

Figure

Case

II

B

orientation

by

taking

the

absolute

angle

we

get

and

comparing

it

to

a

fixed

reference

point

For

example

we

can

say

that

facing

the

THIRD-IR

and

GOAL

line

means

that

we

are

North

So

if

the

absolute

angle

differs

by

degrees

then

we

can

say

that

we

are

facing

north-west

Line-Follower

-LRB-

Miller

Becker

-RRB-

Line-Follower

pursued

the

strategy

of

following

the

black

line

on

the

floor

from

start

to

finish

dropping

the

ball

doing

an

open-loop

degree

turn

and

returning

to

the

start

Five

reflectance

sensors

across

the

front

gave

the

control

a

startling

robustness

and

the

final

robot

was

very

small

and

compact

It

used

a

gear-head

drive

motor

and

thus

was

very

quiet

It

was

rather

slow

but

its

no-nonsense

attitude

let

it

deliver

three

balls

in

the

alloted

four

minutes

This

robot

's

design

is

an

example

of

retrograde

evolution

starting

from

a

highly

original

design

that

involved

new

sensors

and

the

goal

of

measuring

absolute

location

One

of

the

ways

to

solve

the

problem

in

maze-walking

was

to

develop

an

absolute

positioning

system

Unfortunately

monies

not

being

available

for

a

geostationary

sattelite

or

even

for

a

gyroscope

-LRB-

inertial

guidance

-RRB-

and

having

no

expertise

in

vision

Miller

leveraged

his

prior

work

on

IR

communication

for

the

minibot

with

some

knowledge

of

history

-LRB-

This

team

had

given

some

thought

to

how

two

robots

might

use

the

IR

detectors

to

communicate

information

between

themselves

-RRB-

At

one

point

in

history

navigation

was

done

by

the

stars

specifically

the

angle

of

the

north

star

was

used

to

calculate

the

latitude

while

a

compass

and

the

position

of

the

star

with

respect

to

the

time

of

day

was

used

to

fix

the

longitude

Unfortunately

electronic

compasses

being

off

budget

expenditures

Miller

investigated

the

notion

of

using

a

pair

of

stars

for

calculating

absolute

position

with

the

possibility

of

using

dead

reckoning

and

tracking

of

a

single

star

to

update

it

as

the

robot

moved

To

do

this

the

team

built

a

primitive

astrolabe

out

of

lego

A

servo

moter

was

used

to

adjust

the

azimuth

which

would

give

the

distance

to

the

star

A

normal

motor

and

break-beam

sensor

was

used

suitably

geared

to

adjust

the

angle

of

the

astrolabe

-LRB-

henceforth

referred

to

as

-RRB-

to

the

mounting

Two

Sharp

IR

sensors

were

used

each

with

a

different

length

brass

tube

attached

These

were

used

to

limit

the

angle

of

sensitivity

of

the

sensors

to

the

emitters

-LRB-

stars

-RRB-

Each

star

was

modulated

at

a

different

frequency

and

primitive

PLLs

-LRB-

new

sensor

hardware

developed

by

Miller

and

Ray

Frank

for

this

project

-RRB-

were

used

to

register

the

frequency

being

detected

by

the

wide-angle

sensor

The

basic

idea

was

that

with

the

robot

stationary

the

astrolabe

would

be

swept

until

the

wide

angle

sensor

found

the

appropriate

signal

to

be

in

view

-LRB-

thresholded

to

eliminate

reflections

-RRB-

and

then

the

narrow-angle

sensor

would

hillclimb

until

the

star

position

was

fixed

From

the

azimuth

we

then

knew

the

distance

to

the

beacon

as

well

as

the

angle

to

the

robot

Now

we

fix

on

the

other

star

and

simple

geometry

gives

us

an

absolute

position

given

the

fixed

nature

of

the

stars

-LRB-

one

was

the

starting

beacon

the

other

was

a

separate

beacon

we

erected

at

a

sufficient

distance

off

the

floor

to

give

reliable

azimuth

information

as

well

as

reduce

the

possibility

that

both

might

be

seen

by

the

bot

at

the

same

in

a

portion

of

the

maze

-RRB-

Once

the

position

was

fixed

the

robot

could

then

use

sensors

on

its

motors

to

judge

the

delta

in

a

particular

angle

and

errors

tracking

the

star

could

be

correlated

into

a

guess

of

a

new

position

From

this

we

hoped

-LRB-

with

our

knowledge

of

the

basic

map

layout

-RRB-

we

could

map

the

maze

While

preliminary

results

were

encouraging

the

following

problems

ensued

The

line

following

strategy

of

the

robot

was

very

robust

but

caused

a

large

amount

of

angle

change

to

occur

as

it

tracked

the

line

far

greater

than

the

slew

rate

of

the

moter

on

the

astrolabe

To

increase

the

slew

rate

however

would

drastically

decrease

its

accuracy

-LRB-

currently

to

degree

but

another

degree

error

from

the

narrow

aperture

sensor

meant

we

were

pretty

much

at

the

limits

of

sensitivity

when

far

from

the

star

-RRB-

To

compensate

for

this

we

should

have

to

refix

our

position

on

the

two

stars

more

frequently

and

this

was

seen

as

slowing

down

line

following

enough

that

unless

the

maze

was

particularly

tilted

against

simple

obstacle

avoidance

strategies

-LRB-

unfortunately

it

was

n't

-RRB-

the

cost

of

absolute

positioning

swamped

performance

Additionally

it

was

unclear

the

software

needed

to

reason

about

position

while

tracking

the

star

in

addition

to

the

line

following

code

and

basic

beacon

and

astrolabe

code

would

all

fit

into

the

limited

memory

of

the

robot

Additionally

the

feedback

from

the

motors

needed

the

two

ports

for

break-beam

sensors

yet

the

astrolabe

itself

used

one

The

board

we

were

using

had

no

provision

for

counting

a

third

break-beam

so

dead

reckoning

would

have

been

difficult

without

additional

sensors

There

are

a

number

of

possible

solutions

to

this

dilemma

given

funds

Fix

the

astrolabe

position

put

the

star

on

the

robot

and

relay

information

-LRB-

using

the

IR

transmission

scheme

perhaps

-RRB-

between

the

fixed

astrolabe

and

the

robot

This

would

have

avoided

slew

rate

and

tracking

problems

but

would

have

violated

tournament

rules

since

the

robot

would

not

have

been

autonomous

and

we

would

have

needed

an

additional

cpu

board

Add

a

compass

to

the

robot

This

would

have

meant

only

one

star

would

have

been

needed

to

fix

position

This

would

not

have

solved

the

problem

of

dead

reckoning

we

still

would

need

a

third

break-beam

port

Use

inertial

guidance

for

dead

reckoning

Presumably

this

can

be

done

without

a

break-beam

or

equivalent

Since

we

do

n't

know

initial

but

do

know

the

angle

of

the

start

position

to

our

star

we

could

dispense

with

the

compass

-LRB-

since

the

inertial

system

should

give

us

any

ffi

as

well

as

offset

from

our

starting

point

-RRB-

An

accurate

enough

system

might

be

able

to

dispense

with

the

external

reference

point

as

well

e.g.

that

used

for

cruise

missiles

Use

a

different

approach

e.g.

embedding

wires

into

the

arena

and

checking

flux

changes

as

the

robot

passes

over

them

Modulating

each

wire

with

different

current

or

amplitude

changes

means

we

can

either

read

absolute

position

more

or

less

directly

or

at

least

can

distinguish

horizontal

from

vertical

grid

lines

and

count

as

in

a

very

accurate

dead

reckoning

system

Cyclops

-LRB-

Riopka

Rosca

-RRB-

Cyclops

is

a

LEGO

mobile

mini-robot

that

is

capable

of

exploring

a

planar

world

by

combining

several

high-level

behaviors

such

as

line

following

beacon

following

horizon

scanning

obstacle

detection

and

avoidance

wall

following

and

map

construction

Cyclops

can

be

taught

a

set

of

micro-skills

which

can

be

used

in

writing

its

higher-level

behaviors

Cyclops

has

the

capability

of

building

a

map

of

a

grid-world

Such

a

map

can

be

used

as

a

starting

basis

in

implementing

a

simple

task

planner

for

task

optimization

The

high

level

design

decisions

that

guided

the

implementation

of

Cyclops

were

Support

a

software

architecture

that

can

implement

well

the

tradeoff

between

reactive

and

reasoning

capabilities

Learn

a

map

of

the

competition

environment

by

creating

updating

and

using

the

necessary

information

opportunistically

Keep

track

of

the

vehicle

orientation

or

reinitialize

it

and

be

able

to

realize

if

the

orientation

is

lost

We

intensively

experimented

with

various

design

decisions

influencing

the

first

major

goal

above

The

second

and

third

goals

are

inherently

very

difficult

to

implement

Although

we

made

advances

in

this

direction

any

map

construction

facilities

were

infeasible

given

the

specific

delivery

task

and

the

amount

of

time

allowed

to

compete

However

we

experimented

and

equipped

our

robot

with

various

sensors

that

support

the

creation

and

interpretation

of

a

higher

level

representation

of

the

environment

We

outline

here

that

competition

rules

and

most

importantly

the

given

world

configuration

and

the

time

allowed

for

each

robot

may

rule

out

capabilities

that

make

a

robot

more

intelligent

This

would

be

the

case

with

a

very

simple

world

which

implicitly

favors

very

simple

architectures

Our

robot

has

been

designed

to

cope

with

a

more

complex

world

Cyclops

functionality

Cyclops

is

equipped

with

a

variety

of

sensors

and

actuators

Each

of

them

will

be

shortly

described

at

two

abstraction

levels

First

we

refer

to

the

devices

used

Secondly

we

mention

the

desired

functionality

which

is

reflected

in

the

software

The

desired

functionality

influences

every

aspect

of

the

device

the

mechanical

and

electrical

component

choices

the

sensor

or

actuator

mechanical

assembly

the

way

sensors

are

interfaced

to

a

microprocessor

board

and

the

driver

routines

used

We

start

our

description

with

the

desired

functionality

and

the

goals

pursued

Then

we

describe

the

sensors

and

actuators

used

and

the

way

they

are

interfaced

to

the

controller

board

Given

the

objectives

mentioned

before

we

defined

a

set

of

necessary

functions

our

design

has

to

support

Most

of

these

impose

constraints

on

the

sensors

and

actuators

that

will

endow

our

robot

The

discussion

on

sensors

and

actuators

will

follow

these

more

detailed

goals

ffl

Drive

forwards

and

backwards

ffl

Perform

turns

with

a

very

low

steering

radius

ffl

Control

the

steering

angle

with

a

very

high

precision

ffl

Estimate

the

distance

traversed

by

the

vehicle

regardless

of

speed

or

steering

in

any

given

time

interval

ffl

Detect

obstacles

bumped

into

when

driving

forwards

or

backwards

Detect

if

an

obstacle

is

positioned

to

the

left

right

front

or

rear

of

the

vehicle

ffl

Detect

obstacles

touched

by

the

sides

of

the

vehicle

ffl

Detect

obstacles

that

appear

at

a

given

distance

in

front

of

the

vehicle

before

bumping

into

them

ffl

Detect

a

nearby

infrared

beacon

emitting

a

modulated

IR

signal

of

a

given

frequency

ffl

Detect

side

obstacles

without

touching

them

ffl

Follow

a

black

winding

stripe

on

a

lightly

colored

floor

-LRB-

e.g

white

floor

-RRB-

regardless

of

illumination

conditions

Cyclops

sensors

Cyclops

is

equipped

with

the

following

sensors

Four

bumping

sensors

All

are

simple

microswitches

attached

to

the

vehicle

in

appropriate

mountings

-LRB-

a

-RRB-

Two

front

sensors

They

are

mounted

on

a

common

bumper

They

can

be

switched

on

either

independently

or

together

if

the

vehicle

bumps

frontally

into

an

obstacle

-LRB-

b

-RRB-

Two

rear

sensors

made

of

roller

microswitches

They

are

mounted

at

the

rear

left

and

right

corners

of

the

vehicle

Two

touch

sensors

or

side

bumpers

made

of

ALPS

switches

They

are

mounted

on

the

left

and

right

sides

respectively

close

to

the

front

corners

of

the

vehicle

and

carry

side

wings

of

the

length

of

the

vehicle

so

that

whenever

a

side

of

the

vehicle

is

pressed

against

an

obstacle

or

a

wall

at

any

angle

the

sensor

becomes

switched

on

IR

beacon

detector

It

is

made

out

of

four

Sharp

detector

packages

which

can

detect

IR

light

of

or

MHz

and

are

mounted

at

and

degrees

degrees

corresponds

to

the

direction

of

the

vehicle

axis

and

a

forward

orientation

We

have

experimented

with

equally

good

results

with

a

simpler

design

in

which

only

two

IR

detectors

are

used

They

are

mounted

at

degrees

Two

IR

side

reflectance

sensors

Each

is

a

Sharp

detector

package

similar

to

the

ones

used

in

the

IR

beacon

detector

Four

IR

reflectance

sensors

They

are

made

out

of

pairs

of

an

IR

LED

and

an

ultrasensitive

IR

phototransistor

-LRB-

Sec

B.

-RRB-

One

breakbeam

sensor

It

is

mounted

above

a

LEGO

pulley

wheel

attached

to

the

direction

axle

carrying

the

front

wheels

of

the

vehicle

One

photoresistor

It

is

mounted

in

a

black-covered

drinking

straw

tilted

forwards

in

order

to

offer

an

analog

signal

on

white/grey/black

objects

a

given

distance

away

in

front

of

the

vehicle

The

photoresistor

is

part

of

an

artificial

eye

system

used

for

obstacle

avoidance

The

entire

system

will

be

described

in

more

detail

below

Interfacing

sensors

to

the

microprocessor

board

Bumping

sensors

The

left

front

and

rear

microswitches

are

mounted

in

parallel

and

connected

to

an

analog

port

However

they

are

used

as

digital

devices

-LRB-

on/off

-RRB-

The

one

corresponding

to

the

direction

of

movement

-LRB-

front

for

forward

movement

and

rear

for

backward

movement

respectively

-RRB-

offers

information

about

obstacles

the

vehicle

has

bumped

into

Touch

sensors

are

also

connected

to

an

analog

port

although

they

have

a

digital

function

IR

beacon

detector

Each

detector

package

is

connected

to

a

high

digital

port

The

Interactive

C

software

only

supports

ports

for

reading

the

modulated

IR

light

signal

IR

side

reflectance

sensors

Each

is

connected

to

a

high

digital

port

IR

reflectance

sensors

Each

is

connected

to

an

analog

port

Breakbeam

sensor

It

is

connected

to

a

low

digital

port

This

makes

possible

to

use

the

fast

assembly

language

shaft-encoder

routines

from

Interactive

C.

Although

this

alternative

offers

more

accurate

information

in

case

high

sampling

speeds

are

needed

-LRB-

determined

by

high

rotation

rates

of

the

pulley

wheel

-RRB-

our

robot

did

not

travel

at

high

speeds

The

photoresistor

is

connected

to

an

analog

port

It

offers

an

analog

signal

that

is

decoded

into

information

on

the

grey

level

of

the

point

viewed

The

Cyclops

Artificial

Eye

System

Linear

Scanner

A

line

scan

camera

was

constructed

using

a

single

photoresistor

mounted

on

a

servo

A

single

photoresistor

was

used

in

order

to

simplify

calibration

and

photosensitivity

problems

that

might

arise

using

multiple

detectors

Early

measurements

showed

that

the

sensitivity

of

any

one

photoresistor

not

only

varied

considerably

from

one

to

the

next

but

was

also

non-linear

over

its

range

Using

only

one

photoresistor

alleviated

many

of

these

potential

difficulties

The

detector

for

the

linear

scanner

consisted

of

a

photoresistor

mounted

in

one

end

of

a

long

straw

The

straw

was

covered

with

electrical

tape

with

a

black

cone

on

the

end

opposite

the

photoresistor

to

insure

no

reflections

from

the

straw

opening

The

tube

was

then

encased

in

a

lego

structure

which

was

centered

on

an

axle

whose

axis

was

perpendicular

to

the

tube

but

parallel

-LRB-

and

connected

-RRB-

to

the

shaft

of

the

servo

The

entire

scanner

was

tilted

at

an

angle

of

approximately

degrees

to

the

horizontal

resulting

in

a

view

approximately

cm

or

1 1/4

feet

in

front

of

the

vehicle

A

fixed

angle

provided

a

way

for

the

robot

to

measure

object

distance

and

also

simplified

the

vision

algorithm

-LRB-

see

below

-RRB-

In

the

final

implementation

sample

points

were

used

each

point

separated

from

the

next

by

an

angle

of

degrees

resulting

in

a

scan

angle

of

degrees

centered

about

the

robot

and

looking

forward

Experiments

with

a

visual

test

display

indicated

that

the

field

of

view

-LRB-

i.e.

the

angle

subtended

by

the

area

from

which

light

was

detected

by

the

photoresistor

through

the

tube

-RRB-

was

approximately

degrees

This

provided

significant

directionality

and

sufficient

resolution

to

enable

accurate

enough

edge

detection

for

object

avoidance

The

location

of

the

object

edge

was

used

as

a

parameter

to

the

general

skill

learned

by

the

robot

for

object

avoidance

-LRB-

see

Skill

Learning

-RRB-

Scan

time

was

approximately

seconds

per

line

acquisition

requiring

rise

time

for

the

photoresistor

ms

per

sample

to

reduce

scanner

vibration

and

seconds

for

servo-switching

This

was

considered

to

be

a

reasonable

time

but

one

which

did

not

encourage

indiscriminate

scanner

use

Scanner

Calibration

and

Thresholds

One

of

the

main

advantages

of

using

a

single

photoresistor

for

line

acquisition

was

the

very

simple

calibration

procedure

To

calibrate

the

line

scanner

two

readings

were

required

one

with

the

photoresistor

tube

aimed

at

an

area

that

corresponded

to

the

darkest

scene

possible

under

ambient

light

and

one

with

the

tube

aimed

at

the

lightest

scene

possible

The

difference

between

these

two

readings

is

the

dynamic

range

of

the

photoresistor

Because

the

analog

value

was

small

for

light

scenes

and

large

for

black

scenes

the

following

formula

was

used

to

obtain

a

graylevel

value

graylevel

-LRB-

measuredvalue

dynamicrange

-RRB-

Graylevel

measurements

after

calibration

were

very

reasonable

The

single

photoresistor

was

calibrated

on

the

objects

for

black

and

on

the

floor

for

white

This

calibration

resulted

in

a

dynamic

range

-LRB-

as

measured

by

the

analog

output

of

the

photoresistor

-RRB-

of

up

to

levels

-LRB-

or

volts

assuming

a

full

volts

for

logic

-RRB-

in

the

ambient

light

of

the

playing

field

This

enabled

the

scanner

to

tell

reliably

the

difference

between

an

object

the

floor

and

even

the

walls

of

the

playing

field

throughout

the

playing

field

However

shadows

cast

by

the

objects

themselves

resulted

in

similar

readings

for

both

the

walls

of

the

playing

field

and

the

floor

-LRB-

in

certain

shadowed

areas

-RRB-

A

similar

observation

was

made

in

regards

to

the

colors

on

top

of

the

objects

That

is

although

the

scanner

could

theoretically

tell

the

difference

between

the

floor

walls

and

even

colors

on

top

of

the

objects

shadows

prevented

the

robot

from

taking

full

advantage

of

this

potential

capability

After

several

experiments

it

was

determined

that

a

proper

gradient

threshold

-LRB-

or

more

accurately

the

difference

in

gradient

value

required

between

two

points

such

that

an

object/floor

transition

can

be

considered

to

be

very

likely

-RRB-

could

be

obtained

by

subtracting

from

the

dynamic

range

An

automated

vision

calibration

could

have

been

developed

by

using

the

loading

area

for

black

and

the

floor

for

white

Since

the

starting

position

of

the

robot

was

known

the

entire

procedure

could

have

been

automated

In

our

implementation

the

calibration

constants

were

determined

ahead

of

time

and

hard-coded

into

the

application

-LRB-

Note

that

this

did

result

in

problems

when

the

television

crew

lights

were

on

to

film

the

arena

but

in

general

under

ambient

light

conditions

the

calibration

was

fairly

stable

-RRB-

The

Vision

Algorithm

The

vision

behavior

was

implemented

as

follows

During

regular

robot

movement

the

scanner

is

active

-LRB-

i.e.

the

photoresistor

output

is

monitored

-RRB-

and

the

scanner

is

positioned

directly

forward

The

angle

for

the

scanner

is

such

that

a

black

object

is

detected

-LRB-

i.e.

light

detected

falls

below

a

specific

threshold

-RRB-

at

an

approximate

distance

of

about

grid

square

-LRB-

or

about

cm

-RRB-

in

front

of

the

robot

The

threshold

for

this

initial

object

detection

was

selected

empirically

in

such

a

way

as

to

ensure

that

a

horizontal

scan

line

at

that

point

intersects

the

approximate

center

of

the

object

Object

detection

causes

the

robot

to

stop

and

initiate

a

single

line

scan

as

described

above

The

robot

then

uses

the

edge

information

from

the

line

scan

to

parameterize

an

object

avoidance

manoever

implemented

as

a

skill

-LRB-

described

below

-RRB-

In

all

the

scenarios

the

general

strategy

was

to

determine

where

the

floor

is

and

to

move

the

robot

in

that

direction

avoiding

object

edges

Because

of

the

constraints

on

object

location

shape

and

size

only

three

image

scenarios

are

possible

No

floor/object

transitions

only

objects

in

front

This

suggests

that

the

robot

is

oriented

almost

perpendicular

to

a

set

of

at

least

two

and

probably

three

adjacent

objects

The

reaction

in

this

case

is

to

initiate

either

a

left

turn

or

right

turn

skill

depending

on

higher

level

information

One

object

transition

two

cases

are

possible

object

to

the

left

floor

to

the

right

OR

floor

to

the

left

object

to

the

right

In

either

case

the

robot

is

again

almost

perpendicular

to

an

object

wall

The

location

of

the

single

edge

is

used

to

determine

whether

an

avoid

object

go

left

skill

or

an

avoid

object

go

right

skill

is

initiated

In

either

case

the

exact

location

of

the

edge

is

used

to

parameterize

the

skill

by

varying

how

much

the

robot

needs

to

shift

its

position

to

the

left

or

to

the

right

to

avoid

the

object

Two

object

transitions

two

cases

are

possible

floor

on

either

side

of

an

object

OR

floor

between

two

objects

In

these

two

cases

the

orientation

of

the

robot

is

no

longer

clear

-LRB-

although

due

to

the

constraints

on

the

robot

world

it

could

probably

be

calculated

-RRB-

The

goal

of

the

image

analysis

here

was

to

determine

where

a

large

enough

floor

area

for

the

robot

was

in

relation

to

the

robot

and

to

determine

which

of

the

avoid

object

go

left

or

avoid

object

go

right

skills

was

appropriate

and

lastly

parameterize

the

appropriate

skill

using

the

relevant

object

edge

Image

Analysis

One

dimensional

zero

crossings

were

used

to

localize

the

position

of

the

edges

to

eliminate

edge

ambiguities

and

to

simplify

the

vision

algorithm

Although

a

simple

thresholding

approach

with

an

ad

hoc

search

algorithm

could

have

been

implemented

the

zero-crossing

approach

seemed

more

elegant

algorithmically

and

resulted

in

a

straightforward

algorithm

implementation

The

algorithm

proceeds

as

follows

First

first

derivative

-LRB-

gradient

-RRB-

and

second

derivative

images

temporary

images

are

formed

from

padded

versions

of

the

original

input

Zero

crossings

in

the

second

derivative

image

are

used

to

locate

possible

edges

Gradient

values

at

these

locations

are

used

to

determine

the

validity

of

the

edge

transition

using

an

empirically

determined

gradient

threshold

A

thresholded

version

of

the

original

input

as

well

as

a

holding

array

for

the

object

edge

locations

are

then

generated

and

used

by

the

knowledge

source

associated

with

robot

avoidance

strategies

to

implement

the

appropriate

robot

action

-LRB-

as

described

above

-RRB-

Vision

as

a

Behavior

The

general

idea

behind

the

vision

behavior

was

to

treat

it

as

a

reactive

behavior

on

an

analogous

level

with

lower

level

reactive

behaviors

but

with

the

following

qualifications

Because

of

the

method

used

to

trigger

the

vision

capability

i.e.

real-time

monitoring

of

the

center

pixel

for

object

detection

the

time

required

for

scanning

can

be

considered

to

be

irrelevant

as

long

as

all

other

behaviors

are

temporarily

suspended

during

line

acquisition

and

analysis

-LRB-

The

vision

system

could

easily

be

replaced

by

a

real

time

system

capable

of

visual

analysis

in

a

time

frame

compatible

with

the

time

frame

of

other

reactive

behaviors

-RRB-

The

execution

of

an

avoid

object

skill

can

be

viewed

in

two

ways

First

one

could

argue

that

the

proper

way

to

perform

a

reactive

behavior

to

avoid

an

object

would

be

to

visually

servo

the

object

edge

as

the

robot

moves

around

it

similar

to

the

strategy

used

by

truck

drivers

manoevering

their

vehicle

in

reverse

On

the

other

hand

truck

drivers

are

also

capable

of

performing

rather

complicated

turns

without

visually

servoing

by

noting

the

location

of

an

obstacle

and

relying

on

experience

to

enable

them

to

manoever

around

it

And

analogously

just

as

the

poor

execution

of

a

truck

turn

can

be

interrupted

by

a

vehicle

collision

so

can

skill

execution

be

interrupted

by

lower

level

higher

priority

behaviors

such

as

bump

sensors

It

is

this

capability

that

we

intended

to

capture

in

our

skills

implementation

-LRB-

as

described

in

Section

-RRB-

Skill

Learning

Skill

Acquisition

The

development

of

control

software

for

actuators

is

often

a

time

consuming

trial

and

error

process

due

to

the

inherent

error

between

specified

actions

and

their

real

world

execution

Unforseen

externalities

and

robot

hardware

deficiencies

often

conspire

to

hinder

accurate

execution

of

preprogrammed

actions

To

facilitate

skill

learning

and

alleviate

these

difficulties

we

incorporated

a

joystick

interface

into

our

robot

and

implemented

a

method

of

actuator

learning

similar

to

that

used

for

programming

some

industrial

robots

The

joystick

control

enabled

us

to

move

the

robot

interactively

Teaching

the

robot

a

skill

involved

moving

the

robot

interactively

to

execute

the

desired

action

while

at

the

same

time

storing

the

associated

motor

and

steering

commands

and

odometric

readings

between

consecutively

different

commands

By

using

the

operator

in

the

feedback

loop

a

skill

can

be

precisely

learned

and

reproduced

each

and

every

time

since

the

actuator

commands

stored

are

exactly

those

executed

during

operator

control

The

accuracy

of

the

reproduction

is

limited

only

by

the

sampling

error

associated

with

the

encoder

used

to

measure

distance

and

of

course

relies

on

consistent

contact

between

the

odometric

wheel

and

the

floor

To

execute

such

an

action

in

normal

operation

each

set

of

actuator

commands

in

the

stored

sequence

is

simply

replayed

for

a

duration

determined

by

the

corresponding

odometric

reading

in

essence

executing

a

specific

trajectory

fragment

The

execution

of

trajectory

fragments

continues

until

the

entire

set

is

either

completed

or

interrupted

as

a

result

of

a

change

another

part

of

the

system

For

example

one

such

action

could

be

a

precise

left

turn

A

lower

level

higher

priority

process

monitoring

wheel

rotations

might

determine

that

the

robot

has

stalled

and

consequently

will

never

complete

the

specified

action

Such

a

fact

would

be

communicated

through

common

data

structures

causing

the

execution

of

the

skill

to

be

suspended

perhaps

only

temporarily

enabling

another

lower

level

reactive

behavior

to

take

over

to

try

and

correct

the

impasse

and

possibly

resume

the

skill

execution

Time

was

not

considered

in

the

implementation

of

skills

for

a

number

of

reasons

First

the

type

of

skills

we

considered

did

not

have

a

dynamic

element

to

them

that

is

the

speed

of

the

skill

implementation

was

not

a

relevant

factor

This

may

or

may

not

be

true

in

general

and

hence

our

particular

representation

may

not

be

optimal

for

all

applications

-LRB-

but

was

for

ours

-RRB-

In

our

case

the

most

important

requirement

was

that

the

robot

move

in

a

particular

trajectory

for

given

distance

Second

using

time

to

control

the

duration

of

motor

and

steer

commands

had

negative

practical

ramifications

for

accurate

replay

of

learned

skills

This

was

primarily

due

to

the

fact

that

the

instantaneous

power

level

of

the

robot

directly

affected

the

speed

of

the

robot

at

any

given

command

setting

for

motor

control

and

hence

the

time

spent

in

that

state

For

example

assume

that

during

learning

a

motor

command

is

stored

while

the

robot

power

level

is

high

Later

the

command

is

replayed

when

the

power

level

of

the

robot

is

low

The

time

stored

during

learning

will

be

shorter

because

the

robot

speed

will

have

been

greater

and

will

be

too

short

when

the

robot

replays

the

command

later

on

The

use

of

odometry

to

monitor

the

progress

of

the

action

therefore

ensures

that

power

fluctuations

and

furthermore

mechanical

irregularities

do

not

impede

action

execution

since

physical

movement

of

the

robot

is

required

to

complete

it

Skills

are

implemented

using

one

array

to

store

encoded

motor

and

steer

commands

-LRB-

both

commands

are

stored

using

a

single

integer

-RRB-

and

another

array

storing

the

distance

traversed

between

changes

in

commands

The

possible

commands

are

also

discretized

and

referred

to

by

array

index

to

reduce

the

number

of

command

permutations

and

hence

reduce

the

size

of

the

command

array

Distance

is

measured

using

a

single

wheel

encoder

on

the

front

wheel

Advantages

of

using

distance

traversed

over

time

passed

are

Duration

of

commands

does

NOT

depend

on

power

level

since

the

robot

must

physically

move

to

complete

a

command

Repeatibility

during

manoever

reversal

-LRB-

see

below

-RRB-

is

improved

The

algorithm

for

manoever

reversal

is

easy

because

both

steering

and

motor

commands

are

available

at

each

step

Skill

array

simplification

is

more

straightforward

because

distances

in

the

array

can

simply

be

added

for

identical

steering

commands

For

example

if

over

some

distance

interval

the

same

steering

command

is

used

but

the

speed

varied

for

some

reason

during

learning

the

distances

traversed

can

be

added

and

all

commands

with

the

same

steering

in

the

interval

compressed

into

one

steering

command

at

a

some

fixed

speed

This

simplification

not

only

reduces

the

size

of

the

arrays

needed

to

store

the

manoevers

but

allows

efficient

automatic

array

simplification

Primitive

manoevers

left-turn

-LRB-

-RRB-

right-turn

-LRB-

-RRB-

straight

-LRB-

-RRB-

avoid-go-left

-LRB-

-RRB-

-LRB-

a

jog

to

the

left

-RRB-

and

avoid-go-right

-LRB-

-RRB-

-LRB-

a

jog

to

the

right

-RRB-

were

all

learned

and

stored

The

manoevers

avoid-go-right

-LRB-

-RRB-

and

avoid-go-left

-LRB-

-RRB-

were

parameterized

to

allow

edge

location

from

visual

input

to

affect

the

amount

that

the

robot

shifted

to

the

right

or

to

the

left

Manoever

Reversal

Manoever

reversal

refers

to

replaying

a

set

of

trajectory

fragments

backwards

in

order

to

reset

the

robot

to

its

starting

position

This

was

found

to

be

useful

for

small

reversals

but

results

varied

in

accuracy

for

more

complicated

trajectories

More

experimentation

with

this

type

of

manoever

might

prove

very

interesting

The

idea

of

being

able

to

take

back

a

given

robot

move

precisely

might

be

extremely

useful

in

many

situations

For

example

if

a

robot

were

to

enter

a

trap

and

recognize

it

as

such

manoever

reversal

might

be

able

to

take

it

out

A

left

turn

into

an

object

could

simply

be

aborted

and

the

robot

returned

to

its

original

location

giving

it

a

chance

to

try

something

new

Photoresistor

Response

Time

A

set

of

tests

was

made

to

measure

the

approximate

rise

time

of

the

photoresistors

we

had

available

Photoresistor

rise

time

had

ramifications

for

the

speed

of

the

linear

scan

and

hence

the

time

required

for

image

acquisition

Each

photoresistor

was

tested

mounted

inside

a

scanner

tube

as

described

in

the

section

on

the

linear

scanner

Before

testing

the

photoresistor

was

calibrated

using

black

and

white

fields

under

the

same

lighting

conditions

as

the

test

Note

that

a

linear

response

was

assumed

even

though

there

was

evidence

that

the

response

of

some

-LRB-

or

all

-RRB-

of

the

photoresistors

was

not

A

simple

subroutine

was

written

to

monitor

the

derivative

of

the

calibrated

graylevel

change

over

time

A

timer

was

started

as

soon

as

a

sudden

rate

of

change

was

detected

The

time

taken

from

this

point

to

the

time

that

the

derivative

became

zero

-LRB-

i.e.

no

further

change

in

graylevel

-RRB-

was

considered

to

be

the

time

to

steady

state

This

method

was

used

for

two

reasons

First

using

a

sudden

rate

of

change

in

the

derivative

-LRB-

where

value

of

the

derivative

corresponding

to

sudden

was

determined

experimentally

-RRB-

to

start

the

timer

allowed

the

measurement

to

be

started

simply

by

turning

on

-LRB-

or

off

-RRB-

a

light

Second

going

from

total

dark

to

bright

light

-LRB-

under

calibrated

conditions

of

course

-RRB-

resulted

in

the

largest

possible

dynamic

range

presumably

giving

an

upper

bound

on

the

rise

time

measurement

Measurements

indicated

a

maximum

rate

of

change

ranging

between

and

calibrated

graylevels

per

ms

-LRB-

or

if

a

full

volts

can

be

assumed

for

logic

to

volts

per

ms

-RRB-

with

a

rise

time

ranging

between

and

ms.

Various

combinations

of

lighting

and

dynamic

range

were

experimented

with

to

obtain

a

full

range

of

values

for

most

possible

field

conditions

Servo-multiplexing

Circuit

Ray

Frank

designed

a

servo-multiplexing

circuit

to

enable

us

to

use

the

same

circuit

for

controlling

two

servos

one

for

the

steering

and

one

for

the

linear

scanner

In

normal

free-floating

mode

both

servos

are

active

i.e.

a

signal

to

any

one

servo

causes

both

to

respond

A

logical

one

on

either

control

line

suppresses

the

operation

of

the

corresponding

servo

Both

control

lines

for

the

servos

were

connected

to

the

output

of

one

of

the

motor

ports

A

signal

corresponding

to

a

motor

command

instructing

the

motor

to

turn

one

direction

selects

one

servo

while

a

command

to

turn

the

other

way

selects

the

other

servo

This

also

resulted

in

a

different

color

LED

being

turned

on

whenever

one

servo

was

active

Capacitors

were

added

in

various

locations

to

reduce

noise

in

the

circuit

since

interference

from

motor

operation

caused

both

servos

to

twitch

periodically

A

circuit

diagram

is

shown

in

Fig.

SERVO-SWITCHING

CIRCUIT

RAY

FRANK

uf

Servo

in

from

Microcontroller

Control

Servo

In

from

Controller

Control

uf

Gnd

Servo

Servo

Figure

Servo

Multiplexing

Circuit

Behavior

as

a

Hierarchy

of

Goals

Goal-driven

actions

and

behaviors

are

usually

considered

separately

From

one

perspective

one

could

think

of

a

behavior

as

differing

from

the

execution

of

some

high

level

goal

only

in

the

scope

of

the

resulting

action

For

example

in

line-following

the

robot

generates

steering

and

motor

commands

whenever

a

line

transition

alarm

is

indicated

Due

to

the

swiftness

of

the

action

and

the

nature

of

the

trigger

this

type

of

action

is

typically

called

a

reactive

behavior

The

commands

generated

compete

in

priority

with

other

commands

to

finally

execute

a

command

which

essentially

results

in

a

circular

trajectory

of

an

arc-length

determined

by

the

time

required

to

move

the

robot

to

a

position

straddling

the

opposite

side

of

the

line

One

could

interpret

this

trajectory

as

being

the

fulfillment

of

a

minor

goal

of

the

system

that

is

to

move

the

robot

from

one

side

of

the

line

to

the

other

This

micro-goal

is

simply

triggered

by

sensor

input

instead

of

a

higher

reasoning

faculty

Now

take

as

a

second

example

the

action

initiated

by

our

robot

upon

seeing

an

object

in

its

path

The

robot

stops

does

a

linear

scan

to

acquire

the

location

of

the

object

edges

and

then

generates

a

move

to

avoid

the

object

In

this

case

the

assocated

logic

uses

the

object

edge

location

to

derive

motor

and

steer

commands

from

the

stored

skill

-LRB-

see

Skill

Learning

-RRB-

The

action

corresponds

again

to

a

trajectory

albeit

a

more

complicated

one

and

can

also

be

interpreted

as

the

fulfillment

of

a

goal

in

this

case

to

avoid

the

object

As

before

this

set

of

commands

also

competes

with

other

commands

for

control

For

example

actions

initiated

by

bump

sensors

may

temporarily

interrupt

execution

of

the

skill

In

this

sense

there

is

a

layering

of

control

similar

to

the

layering

postulated

by

K.L.

Doty

based

on

temporal

considerations

However

the

use

of

execution

time

to

discriminate

between

levels

of

control

does

not

seem

very

intuitive

since

the

time

taken

to

execute

various

actions

depends

more

on

hardware

and

the

computational

resources

of

the

robot

than

on

absolute

necessity

The

time

taken

to

execute

a

particular

action

is

very

different

from

the

timeliness

of

a

particular

action

The

way

in

which

we

ensure

that

a

timely

scheduling

of

the

lower

level

task

processes

is

done

is

by

statically

describing

the

lazy

or

eager

type

of

process

to

be

created

This

is

similar

in

function

to

the

types

of

sensed

feature

refreshing

in

-LSB-

-RSB-

One

might

be

able

to

postulate

a

distinction

between

layers

that

is

based

on

scale

of

action

that

is

the

resolution

of

the

goal

In

the

case

of

line

following

or

bump

behaviors

the

robot

response

-LRB-

or

goal

-RRB-

is

rather

subtle

In

the

case

of

skills

the

robot

response

typically

has

greater

scope

involving

complicated

movement

trajectories

An

even

more

ambitious

goal

such

as

map

building

for

improved

navigation

could

be

incorporated

by

treating

exploratory

behavior

as

a

low

priority

process

That

is

when

no

other

higher

priority

processes

are

active

an

exploratory

behavior

initiates

skills

such

as

turn

left

or

turn

right

to

examine

an

area

of

interest

The

exact

nature

of

the

exploratory

behavior

could

be

determined

by

a

combination

of

sensor

information

-LRB-

e.g.

the

current

location

of

the

beacon

-RRB-

and

memory

-LRB-

e.g.

the

expected

location

of

known

objects

-RRB-

The

result

of

the

exploration

would

then

be

used

to

update

the

map

Cyclops

actuators

Driving

motor

It

transmits

power

to

the

rear

wheels

through

an

gear

reduced

box

Direction

servomotor

It

drives

directly

the

steering

axle

that

carries

the

two

front

wheels

The

overall

steering

capability

is

degrees

The

front

wheel

module

is

mounted

so

that

steering

is

straight

for

a

servo

control

value

half

way

between

the

maximum

and

minimum

possible

values

The

steering

values

practically

used

are

bounded

by

the

degrees

representing

minimum/maximum

values

Scanning

servomotor

The

commands

to

this

servomotor

are

obtained

by

multiplexing

the

drive

signal

taken

from

the

servomotor

output

of

the

controller

board

to

both

servomotors

using

a

control

signal

taken

from

a

free

DC

motor

It

orients

the

artificial

eye

to

a

set

of

fixed

front

directions

in

order

to

scan

a

horizontal

set

of

equidistant

points

The

reflection

information

obtained

during

a

scan

is

used

to

generate

high

level

information

about

the

existence

of

objects

-LRB-

obstacles

-RRB-

in

front

of

the

vehicle

Ball

eject

motor

This

DC

motor

is

used

to

drive

the

ball

eject

mechanism

used

in

the

delivery

competition

IR

emitter

It

is

activated

in

order

to

detect

side

obstacles

close

to

the

vehicle

It

can

emit

light

on

one

of

two

frequencies

or

MHz

The

IR

side

reflectance

sensors

can

be

tested

to

detect

if

a

side

obstacle

reflects

IR

light

Board

Microcontroller

Bump

Sensors

Photosensors

Infrared

Detectors

-LRB-

a

-RRB-

-LRB-

b

-RRB-

Figure

-LRB-

a

-RRB-

The

Meccano

Monster

mobile

robot

-LRB-

b

-RRB-

The

robot

in

action

Meccano

Monster

-LRB-

Fuentes

Rao

Van

Wie

-RRB-

The

winner

of

the

competition

incorporated

physical

and

algorithmic

robustness

Physical

strength

came

from

Meccano

construction

which

though

less

suited

for

rapid

prototyping

has

definite

advantages

of

durability

and

dependability

in

the

field

This

robot

was

also

extremely

fast

The

strategy

employed

by

this

team

was

to

use

the

IR

beacons

for

guidance

and

to

head

toward

them

with

reactive

obstacle-avoidance

to

get

around

barriers

The

unit

had

no

memory

of

where

the

obstacles

were

The

Meccano

Monster

-LRB-

Figure

-RRB-

is

a

purely

reactive

mobile

robot

built

with

parts

from

the

MIT

kit

and

two

store-bought

Meccano

erector

sets

It

rests

on

a

three

wheel

base

with

a

servo

motor

controlling

the

angle

of

the

front

-LRB-

steering

-RRB-

wheel

In

its

present

incarnation

its

sensors

include

four

IR

sensors

wrapped

in

tinfoil

for

directionality

two

front

two

side

and

one

back

bump

sensor

three

forward-looking

light

detectors

and

two

downward-looking

light

detectors

At

the

time

of

the

UR

minibot

competition

a

mechanical

arm

was

attached

in

the

place

of

the

forward-looking

light

sensors

Why

Meccano

Originally

we

wanted

to

build

a

walking

robot

and

do

research

into

techniques

for

learning

to

walk

Thinking

that

it

would

be

easier

to

build

a

bipedal

body

from

erector

set

pieces

than

from

LEGO

we

volunteered

to

give

up

our

LEGO

pieces

and

instead

buy

a

Meccano

kit

from

the

local

toy

store

Though

we

eventually

gave

up

on

the

walking

robot

idea

using

Meccano

for

the

robot

body

turned

out

to

be

a

good

idea

in

the

end

our

robot

was

faster

and

more

solid

than

comparable

LEGO-built

robots

Meccano

motors

seem

more

easily

adapted

to

running

a

robot

than

LEGO

gears

Our

motors

were

slower

but

more

powerful

which

meant

our

gear

train

could

be

relatively

simple

Instead

of

a

long

gear

train

we

built

a

simple

two-gear

chain

that

sufficed

for

our

drive

motor

With

a

stronger

chassis

we

could

affix

more

sensors

to

the

robot

than

other

teams

Having

the

extra

sensors

helped

our

line-following

and

wall-following

behaviors

and

improved

the

fault-tolerance

of

our

algorithms

Unfortunately

working

with

Meccano

was

not

always

pleasant

Our

original

design

was

a

long

thin

robot

that

would

never

have

navigated

the

course

we

saw

in

the

competition

and

we

spent

many

hours

reworking

the

design

to

shorten

and

strengthen

our

robot

One

would

think

that

with

all

that

metal

in

the

chassis

and

all

those

sensitive

electronic

parts

on

the

board

we

might

have

problems

with

short-circuits

And

indeed

at

one

point

shorts

became

a

problem

Disaster

We

almost

had

a

major

disaster

when

we

tried

to

turn

the

board

on

after

mounting

the

IR

detectors

first

the

board

did

n't

enter

download

mode

then

some

components

near

the

switch

began

getting

hot

and

pretty

soon

we

even

saw

a

swirl

of

smoke

rising

majestically

from

one

of

the

components

This

of

course

meant

a

short

somewhere

in

our

circuit

and

since

things

were

fine

until

IR

detectors

came

into

the

picture

we

unplugged

these

and

it

was

one

tense

moment

when

we

turned

the

board

on

again

much

to

our

relief

a

miracle

seemed

to

have

occured

and

lo

and

behold

the

board

signaled

its

willingness

to

accept

code

again

The

problem

turned

out

to

be

a

short

in

one

of

the

IR

detectors

caused

by

the

aluminum

foil

that

had

been

wrapped

around

it

for

directionality

We

fixed

the

problem

by

insulating

the

detectors

with

masking

tape

and

carefully

re-wrapping

the

foil

covers

The

problem

of

shorts

is

indeed

a

serious

hazard

to

the

board

and

some

of

the

places

these

are

most

likely

to

occur

include

ffl

Connectors

plugged

into

the

board

that

are

close

to

each

other

may

have

excess

solder

sticking

to

the

pins

and

these

may

come

in

contact

Removing

excess

solder/plugging

sensors

into

the

board

at

alternating

ports/using

tape

for

insulation

alleviates

this

problem

a

good

deal

ffl

All

sensor

connections

should

be

thoroughly

checked

and

properly

insulated

using

tape

ffl

The

underside

of

the

board

may

cause

problems

if

not

shielded

-LRB-

we

used

a

cardboard

sheet

-RRB-

ffl

Battery/sensor

connections

may

be

reversed

Building

the

Board

A

greater

part

of

the

first

week

was

spent

in

reading

relevant

parts

of

the

manual

and

reviving

faded

memories

of

diodes

transistors

resistor

packs

and

inductances

-LRB-

chapter

was

very

useful

-RRB-

While

some

teams

decided

to

sort

out

the

various

components

before

beginning

assembly

we

decided

on

a

more

direct

approach

considering

the

fact

that

we

had

three

team

members

two

team

members

worked

on

soldering

boards

in

parallel

while

one

was

in

charge

of

selecting

and

directing

the

where

and

what

of

soldering

This

gameplan

speeded

up

the

process

considerably

and

we

were

able

to

get

all

boards

soldered

within

six

hours

including

a

minute

break

Lessons

learned

The

instructions

may

not

always

be

right

for

example

when

assembling

the

infrared

transmitter

board

if

you

try

to

solder

the

LED

's

after

you

've

soldered

the

resistor

packs

-LRB-

as

instructed

in

the

manual

-RRB-

then

good

luck

We

ended

up

breaking

on

the

leads

of

a

high-power

red

LED

It

pays

to

use

common

sense

and

think

about

the

end

result

before

jumping

in

to

assemble

things

Another

case

in

point

the

cable

wiring

instructions

for

the

download

link

we

faithfully

followed

the

instructions

step

by

step

until

we

realized

that

we

had

cut

the

cable

in

vain

the

phone

cable

could

directly

be

plugged

into

the

connector

with

no

need

for

soldering

The

instructions

turned

out

to

be

outdated

Luckily

the

damage

was

undone

without

much

effort

Piggybacking

two

chips

was

tricky

our

problem

was

that

there

was

a

little

too

much

solder

on

the

connectors

making

it

hard

for

the

chip

on

the

bottom

to

slide

into

the

socket

A

little

desoldering

did

the

trick

It

helps

to

have

a

multimeter

at

your

side

to

check

the

values

of

resistors

check

connectivity

polarity

etc.

just

to

make

sure

things

are

going

where

and

how

they

should

be

Chapter

has

some

helpful

diagrams

for

visual

identification

of

parts

Some

components

may

have

gotten

damaged

in

transit

or

during

soldering

One

of

the

connectors

on

one

of

our

photoresistors

was

broken

when

examined

The

battery

plug

connector

stopped

functioning

after

soldering

-LRB-

probably

due

to

overheating

-RRB-

luckily

there

was

another

one

Apart

from

testing

individual

parts

before

soldering

the

main

assembly

consisting

of

the

microprocessor

board

the

expansion

board

and

the

LCD

display

were

tested

as

given

in

the

instructions

Everything

went

fine

until

we

came

to

the

part

where

we

needed

to

check

if

the

download

mode

was

working

correctly

Upon

pressing

the

escape

button

and

turning

on

the

board

we

were

supposed

to

see

a

flickering

of

the

yellow

LED

after

which

it

would

turn

off

However

in

our

case

it

still

stayed

on

The

required

behavior

was

however

obtained

when

pressing

the

choose

button

We

decided

to

proceed

with

tests

anyway

and

it

turned

out

that

everything

worked

as

described

we

were

able

to

download

the

pcode

use

IC

load

the

program

testbrd.c

which

checked

various

board

components

The

escape

and

choose

buttons

functioned

normally

While

we

are

not

totally

sure

why

the

choose

button

and

not

escape

button

worked

to

get

the

board

into

downloading

mode

one

guess

is

that

the

results

of

pressing

the

two

were

flipped

in

our

case

due

to

the

initial

state

Designing

the

Body

with

Meccano

Meccano

design

was

an

iterative

process

we

kept

finding

new

and

better

ways

of

shortening

our

wheel-base

attaching

sensors

and

affixing

the

steering

mechanism

to

the

body

At

least

three

times

we

completely

disassembled

our

robot

each

time

cutting

the

length

of

the

body

significantly

Our

guiding

principle

was

to

keep

the

robot

as

compact

as

possible

and

in

the

end

it

had

just

enough

room

for

its

own

sensors

effectors

batteries

and

CPU

For

steering

we

mounted

a

single

wheel

on

an

assembly

that

was

mounted

on

our

servo

The

CPU

signaled

the

servo

with

the

absolute

angle

it

wanted

-LRB-

degrees

for

straight

ahead

-RRB-

and

the

servo

responded

by

turning

the

assembly

to

that

angle

Because

the

assembly

occasionally

slipped

while

the

robot

was

in

motion

we

had

to

recalibrate

the

facing

of

the

front

wheel

continually

To

recalibrate

we

set

the

servo

angle

to

degrees

and

manually

rotated

the

steering

assembly

until

it

was

pointed

as

close

as

possible

to

straight

ahead

Meccano

motors

are

slower

and

more

powerful

than

LEGO

motors

which

meant

that

our

gear

train

could

be

simpler

and

more

efficient

that

comparable

LEGO

models

In

our

case

a

worm

gear

on

the

motor

output

shaft

directly

turned

the

gear

on

the

drive-axle

Note

that

while

the

lego-robot

manual

claims

that

using

the

worm-gear

as

part

of

a

gear

train

is

inefficient

we

found

that

it

worked

quite

well

Sensors

for

the

robot

included

five

bump

sensors

four

IR

detectors

and

two

light

sensors

The

bump

sensors

were

constructed

from

microswitches

to

which

we

attached

long

flexible

meccano

sheets

as

feelers

We

tied

the

microswitches

to

the

robot

with

twists

of

wire

The

IR

detectors

were

attached

to

a

sensor

tower

that

rose

over

the

center

of

the

robot

Neither

the

tower

nor

the

sensors

were

mobile

however

the

IR

detectors

were

omni-directional

enough

that

even

with

fixed

placements

they

covered

the

robot

's

entire

range

of

vision

In

fact

unshielded

IR

detectors

turned

out

to

be

too

omni-directional

-LCB-

when

approaching

the

beacon

all

of

them

could

sense

IR

regardless

of

the

direction

they

were

pointed

We

solved

this

problem

by

wrapping

the

IR

detectors

in

aluminum

foil

-LRB-

taking

care

to

insulate

them

with

tape

first

-LCB-

see

above

-RRB-

Originally

we

planned

to

use

an

electromagnet-driven

gate

to

drop

the

ball

at

the

destination

square

Unfortunately

our

experiments

with

electromagnets

showed

that

anything

with

enough

power

to

open

a

metal

gate

would

draw

far

too

much

power

from

our

board

Our

first

attempt

to

build

an

electromagnet

was

the

naive

method

of

wrapping

a

wire

around

a

iron

nail

a

test

of

the

mechanism

showed

that

it

indeed

opened

the

door

for

the

ball

to

slide

through

except

for

the

problem

that

the

electromagnet

was

drawing

current

close

to

Amps

enough

to

burn

the

board

many

times

over

Later

attempts

proved

somewhat

more

successful

but

eventually

we

abandoned

that

design

for

something

more

striking

the

mechanical

arm

The

arm

was

a

catapult-like

ball-throwing

device

designed

to

throw

the

ball

straight

down

like

a

football

player

spiking

the

ball

after

scoring

a

touchdown

or

a

slam

dunk

in

basketball

A

simple

degree

rotation

of

the

whole

thing

enabled

it

to

throw

the

ball

forward

We

used

a

second

motor

to

control

rotation

of

the

arm

with

various

physical

hacks

to

keep

the

arm

from

damaging

other

parts

of

the

robot

After

several

more

rounds

of

design

and

construction

we

had

a

working

-LRB-

and

crowd-pleasing

-RRB-

model

Software

for

Compulsory

Floor

Exercises

Before

the

robot

competition

came

the

Robot

Olympics

Compulsory

Floor

Exercises

where

each

team

had

to

show

a

working

robot

running

three

different

behaviors

line

following

wall

following

and

beacon

following

For

the

Olympics

we

stripped

down

to

the

barest

essentials

in

sensors

Which

sensors

we

used

are

listed

at

the

head

of

each

subsection

For

line

following

we

used

four

photoresistors

as

sensors

The

photoresistors

are

located

about

an

inch

deep

inside

paper

tubes

that

point

directly

to

the

floor

The

tubes

increased

reliability

by

minimizing

the

amount

of

ambient

light

that

the

sensors

received

Preliminary

tests

showed

that

such

an

arrangement

gave

analog

measurements

roughly

below

for

white

and

above

for

black

at

distances

of

approximately

one

inch

To

obtain

a

composite

of

the

sensory

input

we

used

the

weighted

sum

of

the

individual

sensor

readings

The

inside

sensors

were

weighted

by

a

small

constant

and

the

outside

sensors

by

a

larger

constant

The

sensors

to

the

left

were

weighted

positively

and

the

sensors

to

the

right

were

weighted

negatively

The

composite

reading

was

given

by

c

co

-LRB-

Leftoutside

Rightoutside

-RRB-

ci

-LRB-

Leftinside

Rightinside

-RRB-

-LRB-

-RRB-

where

co

ci

This

way

c

was

proportional

to

the

change

in

steering

angle

needed

to

drive

c

to

zero

which

corresponded

to

the

black

line

being

at

the

center

Finally

we

obtained

the

change

in

steering

at

time

t

using

a

PD

controller

as

follows

steering

-LRB-

t

-RRB-

-LRB-

t

-RRB-

-LRB-

c

-LRB-

t

-RRB-

c

-LRB-

t

-RRB-

-RRB-

-LRB-

-RRB-

After

tweaking

the

constants

and

adding

a

few

hacks

we

obtained

a

reasonably

good

behavior

By

making

the

robot

move

as

slowly

as

possible

we

reduced

the

possibility

of

crossing

the

line

without

seeing

it

Other

interesting

aspects

of

line

following

included

normalizations

for

DC

-LRB-

additive

-RRB-

illumination

changes

and

a

proportional

power

control

which

supplied

more

power

when

negotiating

sharper

turns

Our

idea

for

the

wall-following

exercise

was

quite

simple

try

to

keep

the

front

sensor

always

off

but

keep

the

-LRB-

relatively

longer

-RRB-

side

sensor

always

on

-LRB-

i.e.

touching

the

wall

-RRB-

We

also

decided

to

use

a

controller

that

caused

the

robot

's

steering

angle

to

increase

in

proportion

with

the

amount

of

time

the

robot

was

off

course

-LCB-

the

longer

the

robot

went

without

touching

the

wall

the

sharper

the

correction

to

the

steering

The

implementation

took

less

than

half

an

hour

but

considerable

amount

of

time

was

spent

fine

tuning

the

various

parameters

such

as

when

and

how

much

to

back-up

in

case

of

collision

rate

of

increase

in

the

steering

angle

and

so

forth

We

only

used

three

switches

for

wall

following

which

appeared

to

be

enough

for

a

robust

wall

following

behavior

The

robot

had

two

switches

at

the

front

connected

in

parallel

When

either

of

them

was

pressed

the

robot

stopped

backed

up

for

a

short

time

-LRB-

about

seconds

-RRB-

steered

to

the

left

by

a

small

amount

-LRB-

about

degrees

-RRB-

and

started

forward

again

At

the

time

of

the

Olympics

we

had

just

one

side

sensor

so

our

robot

could

only

follow

walls

on

one

side

When

the

side

sensor

was

pressed

it

meant

that

the

robot

was

successfully

following

the

wall

-LRB-

provided

the

front

switches

were

n't

pressed

-RRB-

so

it

continued

forward

in

a

straight

line

When

of

the

sensors

were

pressed

the

robot

turns

to

the

right

increasing

the

steering

angle

by

a

small

amount

each

time

though

the

loop

until

it

found

a

wall

With

this

simple

strategy

we

obtained

a

surprisingly

robust

behavior

Before

the

competition

the

robot

managed

to

circle

the

sixth

floor

hallway

several

times

without

human

assistance

The

third

compulsory

exercise

was

beacon

following

Preliminary

tests

revealed

that

the

sensors

were

quite

sensitive

to

IR

radiation

even

when

turned

in

the

opposite

direction

We

used

cones

of

aluminum

foil

to

shield

IR

radiation

from

all

directions

except

the

front

and

then

arranged

the

IR

sensors

in

a

cross

each

at

a

ninety-degree

angle

from

the

two

closest

to

it

The

readings

from

these

were

then

used

to

turn

in

the

direction

of

the

strongest

response

When

no

IR

was

received

by

any

of

the

detectors

the

robot

continued

in

the

direction

it

was

originally

going

This

of

course

meant

that

it

soon

ended

up

bumping

into

obstacles

so

we

activated

the

bump

sensors

also

during

beacon

following

so

that

the

robot

would

back

up

in

case

of

collision

hopefully

getting

back

reception

of

the

lost

IR

The

Competition

Hardware

for

the

competition

was

somewhat

more

sophisticated

than

for

the

Olympics

we

had

a

full

complement

of

bump

sensors

the

arm

and

two

downward-looking

light

sensors

to

identify

the

destination

square

We

kept

the

beacon-sensors

as

they

were

during

the

beacon

following

test

Our

priority

in

designing

an

algorithm

for

the

competition

was

to

keep

our

code

as

simple

as

possible

To

that

end

we

decided

on

a

purely

reactive

subsumption-style

program

When

of

the

bump

sensors

was

active

the

robot

followed

the

beacon-following

behavior

from

above

When

the

robot

hit

an

obstacle

however

beacon-following

was

turned

off

for

a

short

time

-LRB-

about

a

second

-RRB-

to

allow

the

robot

to

back

away

from

the

obstacle

and

move

away

from

the

problem

spot

Unfortunately

the

final

algorithm

was

n't

quite

that

simple

The

fact

that

we

had

to

find

the

destination

square

complicated

matters

as

did

the

introduction

of

several

programming

hacks

that

were

supposed

to

avoid

certain

kinds

of

traps

To

recognize

the

destination

square

we

used

the

two

downward-looking

light

sensors

They

scanned

the

floor

for

dark

tape

and

when

either

of

them

got

three

consecutive

black

readings

signaled

to

stop

the

robot

The

algorithm

took

three

readings

before

reporting

that

it

had

found

the

destination

square

in

order

to

avoid

incorrectly

identifying

the

tape

path

as

the

goal

Though

this

technique

worked

well

in

most

cases

the

algorithm

often

still

incorrectly

identified

the

source

square

as

the

destination

square

To

avoid

this

behavior

we

added

a

simple

test

if

the

robot

had

seen

the

destination

beacon

in

its

front

IR

detector

since

the

last

time

it

had

touched

a

wall

it

assumed

that

any

black

square

it

found

was

the

destination

If

it

had

n't

it

continued

looking

This

approach

resulted

in

the

robot

occasionally

passing

over

the

destination

square

without

stopping

but

in

most

cases

it

found

it

on

the

second

try

Beyond

the

Minibot

After

the

competition

having

replaced

the

robot

arm

with

an

array

of

forward-looking

light

sensors

we

developed

a

streamlined

version

of

our

algorithm

Three

arrays

are

kept

mapping

sensor

inputs

to

motor

outputs

one

for

the

various

combinations

of

bump

sensor

readings

one

for

the

various

combinations

of

light

sensor

readings

and

one

for

the

various

combinations

of

beacon

sensor

readings

If

any

bump

sensor

is

active

we

use

the

corresponding

bump

motor

code

otherwise

if

any

light

sensor

is

active

we

use

the

corresponding

light

motor

code

otherwise

if

any

beacon

sensor

is

active

we

use

the

corresponding

beacon

motor

code

The

codes

are

translated

into

steering

and

drive-motor

outputs

which

are

used

to

drive

the

robot

If

no

sensor

readings

are

reported

the

robot

continues

with

its

last

action

The

streamlined

algorithm

was

invented

for

a

research

project

we

started

after

the

course

The

idea

was

to

learn

the

motor

codes

by

driving

around

a

course

at

random

and

our

attempt

at

solving

it

involved

a

combination

of

stochastic

hill-climbing

and

reinforcement

learning

The

space

of

motor

codes

was

searched

via

stochastic

hill-climbing

and

the

resultant

motor

codes

were

scored

on

their

fitness

through

a

reinforcement

learning

type

algorithm

We

refer

the

interested

reader

to

-LSB-

-RSB-

for

more

details

In

addition

we

have

also

been

working

on

methods

for

perception-based

navigation

using

selforganizing

sensory-motor

networks

-LSB-

-RSB-

The

Cyclops

robot

has

a

complex

control

structure

that

is

reported

in

the

Spring

AAAI

Symposium

on

Instantiated

Agents

The

Meccano

Monster

was

re-programmed

and

re-instrumented

to

do

obstacle

recognition

with

a

triad

of

photo-resistors

each

looking

down

a

tube

This

gave

a

-LRB-

very

-RRB-

low-resolution

view

of

the

area

in

front

of

the

robot

The

robot

used

these

inputs

and

a

form

of

reinforcement

learning

to

learn

how

to

avoid

obstacles

-LSB-

-RSB-

Later

a

simulator

for

the

robot

world

was

built

and

a

simulated

version

of

the

robot

learned

to

find

its

way

home

from

any

position

on

the

arena

-LSB-

-RSB-

A

Parts

Lists

and

Information

The

following

is

to

set

up

the

lab

with

two

workstations

and

to

get

four

kits

one

for

assembly

over

summer

by

the

course

organizers

three

for

Fall

Grad

course

The

first

issue

is

board

kits

A.

Rug

Warrior

Jones

and

Flynn

Book

One

choice

Rug

Warrior

kits

from

AK

Peters

-LRB-

publisher

of

-LSB-

-RSB-

-RRB-

Rug

Warrior

is

a

robot

board

designed

to

support

the

examples

in

-LSB-

-RSB-

The

kit

supplies

all

the

control

and

sensor

circuitry

needed

to

construct

a

custom

designed

fully

autonomous

mobile

robot

The

microprocessor

memory

and

interface

circuits

are

assembled

and

tested

at

the

factory

so

that

kits

arrive

ready

to

connect

to

the

user

's

computer

The

assembly

manual

provides

detailed

instructions

for

installing

the

standard

sensors

and

support

circuitry

included

with

the

kit

Alternately

users

can

customize

the

board

as

desired

Diagnostic

software

included

with

the

kit

helps

builders

discover

any

errors

they

might

make

as

subsystems

are

added

Library

functions

simplify

access

to

all

sensors

and

actuators

The

self

test

code

provides

examples

of

how

to

use

the

library

functions

Interactive

C

-LRB-

IC

-RRB-

is

supplied

with

the

kit

as

the

suggested

programming

environment

Both

Macintosh

and

PC

versions

are

available

For

those

who

have

already

built

Rug

Warriors

on

their

own

the

new

software

for

Rug

Warrior

is

now

available

via

ftp

on

cherupakha.media.mit.edu

Look

for

pub/interactive-c/macintosh

RW.sea.hqx

Kit

features

include

the

following

Motorola

microcontroller

LCD

display

-LRB-

alphanumeric

characters

-RRB-

of

battery

backed

RAM

serial

port

Three

bump

switches

-LRB-

for

collision

detection

-RRB-

Two

photoresistors

for

light

detection

Two

infrared

emitters

One

Sharp

infrared

detector

Microphone

for

sound

detection

Piezoelectric

buzzer

generates

tones

of

arbitrary

frequency

Motor

driver

chip

-LRB-

-RRB-

for

control

of

two

DC

motors

Dual

shaft

encoders

allow

velocity/position

control

Four

user

controllable

LEDs

Battery

holder

hookup

wire

heat

shrink

tubing

and

extra

connector

sockets

Digital

and

analog

inputs

-LRB-

two

each

-RRB-

are

available

for

user

assignment

Access

to

bus

allows

construction

of

memory

mapped

devices

The

kit

is

available

direct

from

the

publisher

they

are

charging

A.

K.

Peters

Ltd.

kpeters@math.harvard.edu

Linden

St.

-LRB-617-RRB- 235-2210

Wellesley

MA

Fax

-LRB-617-RRB- 235-2404

A

portion

of

the

income

generated

by

sales

of

the

kits

will

be

used

to

provide

free

kits

to

high

schools

that

would

otherwise

not

be

able

to

purchase

robots

-LRB-

You

can

thank

Anita

Flynn

for

this

policy

-RRB-

A.

From

Randy

Sargent

at

MIT

Complete

Kit

A

complete

kit

that

includes

Robot

Board

kit

-LRB-

assembled

or

Unassembled

-RRB-

Notes

Motor

Batteries

-LRB-

sets

-RRB-

Sharp

IR

Sensors

Touch

Sensors

LEGO

Resources

Kit

Light

Sensors

Serial

Cable

Copy

of

IC

Cost

-LRB-

unassembled

-RRB-

ACTAS

Actuator

Assortment

-LRB-

-RRB-

Solenoid

-LRB-

-RRB-

Mabuchi

DC

Motors

-LRB-

-RRB-

Futaba

Servo

Cost

Misc

sensors

and

actuators

A.

Work

Area

Another

issue

is

a

work

area

for

electronic

and

mechanical

assembly

We

felt

we

needed

the

following

items

drill

drill

bits

hack

saw

crescent

wrench

box

wrenches

hex

wrenches

Phillips

screwdrivers

slotted

screwdrivers

hammer

champ

crimper

nut

drivers

tin

snips

groove

pliers

slip

joint

pliers

multimeter

DC

power

supplies

tool

box

power

strips

work

benches

vises

wire

cutters

needle-nose

pliers

wire

stripper

utility

knife

soldering

iron

holders

solder

desolderer

safety

goggles

-LRB-

misc

nuts

bolts

glue

etc

-RRB-

B

Supplemental

Sensors

As

was

mentioned

in

the

previous

sections

some

of

the

robots

had

some

interesting

hardware

that

was

not

included

in

the

original

parts

list

Since

our

exercise

was

meant

to

encourage

independent

thought

and

to

lead

on

to

research

the

organizers

were

not

comfortable

with

enforcing

uniformity

on

the

projects

Thus

no

reasonable

request

for

unique

hardware

was

refused

-LRB-

including

the

whole

Meccano

kit

for

instance

-RRB-

Also

Brown

ordered

several

useful-looking

sensors

during

the

semester

which

Ray

Frank

then

had

to

get

working

B.

Parts

List

We

ordered

and

received

the

following

flat

cable

VERY

FINE

wires

too

small

for

our

stripper

thus

very

hard

to

work

with

Might

be

worth

getting

smaller

stripper

since

the

wires

are

more

supple

than

the

round

cables

Slotted

optical

switches

-LRB-

for

emitter

connectors

for

detector

-RRB-

This

is

an

analog

device

As

far

as

we

can

tell

these

devices

are

worse

than

the

ones

that

came

with

the

kit

but

still

usable

The

connector

parts

have

a

V

difference

between

on

and

off

the

have

V

difference

at

best

See

Section

B.

reflective

optical

sensors

These

are

parts

with

wires

-LRB-

yellow

orange

green

-RRB-

and

a

female

connector

with

what

looks

like

leds

in

a

black

plastic

case

These

actually

turned

out

to

be

just

two

IR

LEDs

and

NO

detector

a

cataloger

's

error

See

Section

B.

electret

microphones

These

perform

reasonably

but

possibly

do

not

have

much

range

This

is

an

analog

device

The

classic

problem

with

robot-mounted

mics

is

that

local

ambient

noise

from

motors

drowns

all

other

sounds

Still

See

Section

B.

Mercury

switches

Good

for

signalling

tilts

This

is

a

digital

device

electric

motors

Seem

to

work

have

their

rotors

visible

IR

detector/transmitter

bonanza

packs

duplicating

some

we

already

had

IR

LEDs

Super

IR

Leds

IR

transmitter/receiver

pairs

Ultrasensitive

IR

sensors

miniature

optical

reflectance

sensors

Small

cheapies

See

Section

B.

ultrasound

emitter/detector

pair

for

experimentation

See

Section

B.

B.

Break

Beam

Sensors

The

connector

original

parts

seem

to

work

better

Ray

had

best

luck

wiring

them

as

shown

in

Fig.

-LRB-

Fig.

is

more

explicit

-RRB-

He

got

a

V

difference

between

broken

and

unbroken

Note

the

ohm

resistor

in

place

of

the

recommended

Likewise

the

K

resistor

works

better

than

the

supplied

For

the

connector

parts

Ray

had

best

luck

wiring

them

as

shown

in

Fig.

-LRB-

also

see

Fig.

-RRB-

He

got

a

V

difference

between

broken

and

unbroken

Note

the

ohm

resistor

in

place

of

the

recommended

Likewise

the

K

resistor

works

better

than

the

supplied

B.

IR

LED

Pairs

This

seems

to

be

a

very

unexciting

part

One

-LRB-

or

maybe

both

-RRB-

of

two

IR

LEDs

light

-LRB-

s

-RRB-

up

depending

on

where

power

is

applied

Fig.

is

what

works

-LRB-

if

you

can

call

it

that

-RRB-

Perhaps

the

resistor

would

be

better

than

as

usual

B.

Microphone

These

have

only

been

bench-tested

at

this

writing

but

seem

to

put

out

enough

voltage

to

be

detectable

If

it

is

too

low

mention

the

problem

to

a

course

organizer

and

we

'll

get

Ray

to

whip

up

some

amplifiers

They

are

analog

devices

wired

as

in

Fig.

B.

Miniature

IR

Reflectance

Sensors

These

tiny

devices

have

three

leads

and

two

open

windows

with

silver

metal

inside

them

Surprise

the

business

side

-LRB-

the

emitter

and

detector

-RRB-

are

on

the

OTHER

side

of

the

device

from

the

windows

shielded

by

a

daylight-filter

material

of

glossy

brown

or

black

glassy

stuff

On

the

bench

we

find

these

devices

to

be

sensitive

to

white

reflective

surfaces

up

to

an

inch

away

with

a

nice

smooth

response

until

the

surface

gets

close

enough

to

block

the

emission

We

find

white

and

black

ink

to

be

discriminable

so

these

devices

should

be

good

for

line-following

as

well

as

really

proximal

proximity-sensing

They

are

analog

devices

wired

as

in

Fig.

B.

Ultrasound

The

emitter

is

labeled

on

the

back

the

receiver

The

ultrasound

emitter

must

be

driven

with

a

square

-LRB-

or

sine

-RRB-

wave

of

The

receiver

synchs

with

the

transmitter

if

the

signal

is

strong

enough

The

transmitter

can

be

driven

at

other

frequencies

but

the

receiver

only

synchs

if

the

emission

is

pretty

close

to

There

are

more

TopView

E

D

K

W

C

E

Analog

Output

TopView

E

S

V

V

NPN

type

PNP

Type

Ignore

V

Analog

Output

V

W

K

W

Connector

Part

W

Parts

as

supplied

Figure

BreakBeam

sensors

-LRB-

old

and

new

-RRB-

and

wiring

diagram

Top

View

Mexico

Part

as

supplied

K

W

red

blk

E

D

W

red

blk

Figure

Physical

interpretation

of

break-beam

wiring

A

B

V

for

LED

B

Vfor

LED

A

near

leads

green

orange

yellow

Figure

Two

LEDs

Ground

Connected

To

Caseblk

Middle

Microphone

Vgreen

REDMARK

red

output

Figure

Electret

Microphone

Wiring

BACK

SIDE

-LRB-

SILVER

WINDOWS

-RRB-

IR

in

and

out

OTHER

SIDE

W

W

Figure

Miniature

IR

reflectance

sensor

wiring

specs

in

the

Electronic

Goldmine

catalog

but

they

may

not

be

too

helpful

We

were

driving

the

emitter

with

up

to

volts

at

which

power

the

range

seemed

to

be

about

feet

The

sound

bounced

off

surfaces

etc.

At

lower

powers

the

range

diminished

but

devices

still

could

be

useful

for

proximity

sensing

The

IR

beacon

output

is

a

square

wave

modulated

by

or

Hz

square

wave

So

that

should

generate

ultrasound

pulses

at

or

Hz

This

hack

has

not

been

tried

as

of

this

writing

It

is

not

hard

to

design

a

Khz

oscillator

and

there

are

probably

enough

connections

on

the

expander

board

to

make

the

ultrasound

a

reality

B.

Further

Ideas

Colored

LEDs

for

colored

light

recognition

Electronic

Goldmine

has

Polarization

filters

-LCB-

as

in

competition

way

to

recognize

beacons

at

one

of

two

orientations

Edmunds

will

have

these

Bending

sensors

-LCB-

what

's

with

ACE

or

ART

or

wherever

that

place

is

Tim

's

idea

of

stiff

whiskers

inside

long

coil

springs

Hall

Effect

Sensors

-LCB-

again

Electronic

Goldmine

has

C

Course

Details

C.

Goals

and

Organization

Seminar

in

AI

Practical

Robotics

-LRB-

hrs

-RRB-

The

mechanics

-LRB-

and

electronics

-RRB-

of

this

course

consist

of

populating

a

few

printed

circuit

boards

including

a

powerful

microcontroller

and

building

a

mechanical

device

with

sensors

and

effectors

-LRB-

by

default

a

LEGO

floor-rolling

robot

-RRB-

Intellectual

issues

are

the

design

of

the

hardware

and

the

control

of

the

final

device

to

accomplish

some

task

Plans

are

for

the

class

robots

to

take

part

in

two

competitions

of

some

sort

with

the

goal

of

research

relevance

or

publishable

results

from

the

second

competition

The

controller

is

a

powerful

device

and

the

sophistication

of

applications

are

likely

to

be

limited

only

by

the

difficulties

of

mechanical

design

and

fabrication

Programming

is

in

Interactive

C

cross-compiled

and

downloaded

from

a

Sun

or

other

workstation

One

goal

of

the

course

is

to

expose

students

to

various

basic

aspects

of

robotic

construction

and

control

but

there

is

plenty

of

time

and

opportunity

to

explore

more

advanced

aspects

of

AI

and

robotics

Finally

the

completed

microcontrollers

could

play

roles

in

future

research

projects

Texts

Mobile

Robotics

-LRB-

Jones

and

Flynn

-RRB-

-LRB-

Bookstore

-RRB-

Motorola

Reference

Manual

-LRB-

Free

from

CS

Dept

-RRB-

UR

's

version

of

MIT

's

and

AAAI

's

Handbook

-LRB-

Sold

by

CS

Dept

-RRB-

Reserve

Reading

Mobile

Robotics

Readings

-LRB-

vols

-RRB-

various

papers

on

control

learning

etc.

as

needed

Proceedings

MLC-COLT

Workshop

on

Robot

Learning

June

Course

Committee

Brown

Karlsson

Becker

Miller

Frank

Nelson

There

will

be

one

lecture

or

general

session

per

week

which

will

move

from

being

an

introduction

to

soldering

to

consideration

of

promising

research

projects

in

the

LEGO

robot

domain

Otherwise

student

time

is

spent

on

preparing

for

the

three

robot

events

in

the

course

or

in

reading

writing

and

thinking

about

mobile

robot

research

Students

will

divide

into

groups

of

people

Each

group

will

be

given

raw

materials

for

which

they

will

be

held

responsible

The

microcontroller

board

built

during

the

course

is

a

valuable

piece

of

hardware

and

may

be

useful

in

future

research

projects

The

first

robot

event

is

a

non-competitive

exercise

that

demonstrates

basic

sensor

and

effector

capabilities

and

LEGO

engineering

The

next

event

is

a

competition

which

will

be

run

twice

to

allow

time

to

do

further

debugging

and

improvements

The

third

event

is

an

individual

-LRB-

really

group

-RRB-

project

that

can

have

as

much

research

content

as

practicable

Submission

of

papers

to

the

next

AAAI

Workshop

is

a

sample

of

a

specific

goal

but

will

require

advance

planning

-LRB-

Oct

Deadline

-RRB-

Anything

is

possible

here

including

relaxing

mechanical

design

constraints

-LRB-

e.g.

ME

is

sponsoring

a

rope-climbing

event

in

the

spring

-LCB-

collaboration

could

be

possible

-RRB-

The

autonomous

constraint

can

be

relaxed

to

allow

umbilicals

for

power

and

information

allowing

quicker

movement

for

pole-balancing

or

RHET-sized

reasoning

engines

Assignments

Three

robot

events

plus

one

re-match

Weekly

written

report

one

per

individual

-LCB-

mechanical

or

electronic

construction

work

or

programming

-LCB-

tangible

results

from

individual

-LCB-

ideas

contributed

-LRB-

used

or

not

-RRB-

-LCB-

plans

for

next

week

Two

written

group

reports

one

on

the

competition

-LCB-

issues

worked

on

by

team

together

-LCB-

competing

ideas

compromises

etc.

-LCB-

interesting

facets

solutions

wrinkles

ideas

in

your

robot

one

on

the

group

project

-LCB-

TR

or

conference

paper

style

including

references

Group

interview

-LCB-

course

organizers

need

feedback

on

the

course

what

you

learned

how

course

could

be

improved

suitability

for

undergraduates

suitability

as

research

launching

pad

Grades

from

group

members

Schedule

by

Week

-LRB-

Highly

flexible

-LCB-

slippage

is

likely

-RRB-

Lecture

Organization

course

goals

choose

meeting

time

At

meeting

time

Hand

out

robot

kits

intro

to

the

microprocessor

board

soldering

demo

LEGO

robot

lore

on

the

net

Participants

assemble

and

debug

PC

boards

get

familiar

with

IC

Lecture

Lego

Engineering

sensors

and

effectors

The

Compulsory

Floor

Exercises

test

board

suite

runs

successfully

locomotion

forward

reverse

left

and

right

turns

behaviors

wall-following

with

bump

sensors

homing

on

IR

beacon

line-following

fiducial-counting

and

distance

estimation

odometry

-LRB-

-RRB-

Participants

design

robot

to

do

compulsory

floor

exercises

Lecture

Sensors

and

Effectors

continued

Subsumption

architectures

Participants

design

robot

to

do

compulsory

floor

exercises

Lecture

The

architecture

tools

and

opportunities

Participants

Demonstration

I

Compulsory

Floor

Exercises

Lecture

Assembly

Language

and

interrupt-level

programming

-LRB-

we

hope

-RRB-

Competition

I

description

Participants

Begin

Competition

I

Design

Lecture

Robot

Control

Architectures

Subsumption

Blackboards

Hierarchies

Reactive

Systems

etc.

-LRB-

some

readings

-RRB-

Participants

Continue

Competition

I

Design

Lecture

Control

-LCB-

relevant

aspects

of

open-loop

closed-loop

feed-forward

control

Participants

Continue

Competition

I

Design

Lecture

Learning

-LCB-

CMACs

nets

reinforcement

case-based

map-making

Participants

Competition

Lecture/Discussion

State

of

Art

in

Lego

Robotics

Research

Opportunities

Participants

Re-Match

Lecture

Discussion

What

further

lectures

do

we

want/need

Participants

Begin

Serious

Group

Project

Planning

Lecture

TBA

Participants

Continue

Group

Project

Work

Participants

Ditto

Lecture

TBA

Participants

Project

Demonstrations

Lecture

TBA

Participants

Project

Demonstrations

Team

Interviews

Things

that

will

be

learned

or

-LRB-

if

not

known

apriori

by

participants

-RRB-

Electrical

Engineering

Basic

soldering

techniques

Board

debugging

techniques

Sensors

Optical

Infrared

Mechanical

Gyro

GPS

Accelerometers

Mechanical

Engineering

Basic

concepts

of

mechanical

advantage

through

levers

gears

chains

Different

motor

types

motor

principles

Lego

Engineering

Stable

structures

Lego

units

for

gears

and

support

beams

Computer

Science

Subsumption

Architecture

Reactive

Systems

Machine

Learning

-LRB-

reinforcement

learning

Q-learning

neural

nets

-RRB-

Multi-tasking

parallel

implementations

Computer

Vision

-LRB-

-RRB-

Research

issues

in

the

Navigation

Domain

Research

issues

in

small

robotics

C.

Compulsory

Floor

Exercises

Due

October

The

idea

here

is

to

demonstrate

your

robot

's

ability

to

do

basic

sensory

and

motor

tasks

without

putting

the

individual

tasks

in

any

sort

of

integrated

goal-oriented

context

For

a

demonstration

of

the

various

capabilities

you

might

consider

composing

the

various

abilities

and

stepping

through

them

with

the

escape

program

as

the

testboard.c

program

in

u/minibot/ic

src

does

Note

that

CB

bought

lots

of

extra

sensors

motors

and

STUFF

outlined

in

the

piece

by

cb

and

ray

in

the

lab

notes

Lots

of

it

works

some

is

untested

Feel

free

to

request

some

of

these

pieces

if

you

think

they

'll

help

you

You

should

demonstrate

all

the

following

basic

capabilities

testboard.c

should

run

without

problems

Turn

right

Turn

left

Drive

straight

ahead

open

loop

-LRB-

of

course

you

'll

get

an

arc

but

it

should

be

approximately

straight

ahead

-RRB-

Follow

a

wall

as

in

the

rug

warrior

This

could

use

two

bump-sensing

switches

and

could

subsume

Use

interrupt-level

assembly-language

programming

to

sense

the

output

of

the

breakbeam

sensor

Use

your

breakbeam

sensing

to

implement

shaft-encoders

Monitor

left

and

right

wheel

revolutions

and

use

a

controller

to

equalize

them

to

implement

straight

ahead

driving

Can

you

drive

in

a

straighter

line

than

you

could

open-loop

Sense

the

IR

beacon

You

might

want

to

try

this

two

ways

using

the

system

call

and

following

up

the

hint

and

using

a

direct

analysis

of

the

digital

input

The

latter

saves

time

Drive

in

the

direction

of

an

IR

or

visible

beacon

Two

sensors

might

help

here

mounted

left

and

right

as

in

the

shaft

encoder

case

you

might

want

to

turn

right

if

the

left

input

is

weaker

and

vice-versa

Can

you

drive

straighter

this

way

than

in

or

You

can

rig

an

IR

beacon

from

one

of

CB

's

ultra-bright

leds

a

resistor

and

one

of

ray

's

power

supplies

Follow

a

black

stripe

on

the

white

robot

arena

using

feedback

control

For

this

you

can

make

your

own

reflectance

sensor

or

use

one

of

the

emitter-receiver

pairs

CB

ordered

In

addition

to

these

basic

tasks

there

are

plenty

of

fun

things

we

'd

like

to

try

The

more

capabilities

we

can

demonstrate

the

better

-LRB-

We

shall

get

records

of

these

things

video

or

slides

or

both

-LCB-

both

the

behavior

and

details

of

the

mechanical

wizardry

involved

-RRB-

So

the

organizers

would

like

to

encourage

you

to

volunteer

to

try

one

or

more

of

the

following

off

the

wall

ideas

These

are

in

totally

random

order

of

interest

and

difficulty

but

that

sort

of

thing

should

be

obvious

Detect

Color

I

do

n't

think

we

have

any

color

LEDs

but

they

're

easy

to

get

and

radio

shack

probably

has

some

anyway

If

you

want

to

pursue

this

talk

to

CB

and

he

'll

order

some

if

need

be

There

are

color

filters

in

the

lab

We

can

get

more

from

Edmund

Detect

Polarization

A

la

AAAI

contest

I

guess

this

takes

buying

some

polarizing

filters

Probably

not

a

big

deal

First

can

IR

detectors

detect

candles

CB

suspects

so

Buy

a

small

cylindrical

box

of

Quaker

Oats

throw

them

oats

away

feed

'em

to

the

birds

or

compost

them

Save

the

top

Cut

a

penny-sized

penny-shaped

hole

in

the

center

of

the

top

and

put

it

back

on

You

now

have

a

vortex

cannon

Light

a

candle

stand

a

few

feet

away

and

thump

the

back

of

the

box

I

mean

fire

the

vortex

cannon

at

the

candle

You

should

be

able

to

extinguish

the

flame

from

several

feet

Now

get

a

fine

maduro

cigar

preferably

from

Cuba

-LRB-

warning

illegal

-RRB-

or

the

Dominican

Republic

Uppmann

is

a

good

brand

Carefully

clip

the

end

light

it

draw

gently

several

times

and

let

a

wonderful

feeling

of

well-being

suffuse

your

entire

body

soul

and

spirit

Welcome

to

the

wonderful

world

of

cigar

smoking

Before

you

finish

the

cigar

load

the

cannon

with

smoke

Fire

it

and

you

can

see

the

vortices

So

here

's

the

idea

Mount

the

cannon

on

your

robot

and

see

if

you

can

detect

and

extinguish

candles

You

can

pre-arrange

candle

and

cannon

heights

and

orientations

so

you

do

n't

have

to

go

looking

for

or

aiming

at

candles

I

'm

wondering

just

if

you

can

detect

them

and

kill

them

I

'm

thinking

a

motor

or

the

servo

or

maybe

something

clever

with

a

rubber

band

and

trigger

can

be

used

to

fire

the

cannon

repeatedly

Can

you

fire

a

single

ping

pong

or

plastic

practice

golf

ball

from

some

computer-controlled

contraption

What

sort

of

range

and

accuracy

is

possible

How

about

multiple

balls

Can

you

pick

up

an

object

or

somehow

collect

it

and

carry

it

Object

could

be

small

styrofoam

box

a

metallic

thing

-LRB-

maybe

you

can

make

an

electromagnet

-RRB-

a

ball

Can

you

detect

things

on

the

floor

you

might

want

to

pick

up

Can

you

get

their

direction

and

range

Maybe

with

special

paint

and

lighting

can

you

detect

balls

white

or

colored

styrofoam

objects

etc.

Would

maybe

an

IR

designator

work

where

you

aim

an

IR

emitter

at

what

you

want

detected

and

the

robot

uses

the

reflection

Can

you

use

two

directional

detectors

-LRB-

say

for

IR

-RRB-

and

do

crude

stereo

by

measuring

a

vergence

angle

Maybe

one

sits

on

the

servo

and

you

thus

can

measure

the

angle

Can

you

do

IFF

-LRB-

Identify

Friend

or

Foe

-RRB-

Work

with

another

group

to

see

if

you

can

use

the

IR

detector/emitters

in

their

usual

mode

you

broadcast

Hz

and

he

broadcasts

Hz

and

you

try

to

recognize/locate

him

and

vice-versa

This

is

basic

in

all

MIT

contests

Can

MORE

information

be

broadcast

between

robots

using

the

IR

beacon

You

can

maybe

modulate

the

or

Hz

square

wave

in

different

ways

to

send

different

messages

how

accurately

can

these

messages

be

decoded

How

easy

or

possible

is

it

to

dribble

or

simply

push

a

ball

around

and

keep

it

under

control

How

about

propelling

it

on

the

ground

in

a

desired

direction

Try

out

the

idea

of

driving

the

ultrasound

generator

from

the

IR

output

port

and

detecting

it

Can

you

get

the

microphones

to

work

To

direct

robot

by

clapping

say

Odometry

since

you

have

shaft

encoders

can

you

do

quantitative

measurement

of

distance

travelled

Can

you

use

parabolic

reflectors

-LRB-

perhaps

from

flashlights

-RRB-

to

send

and/or

receive

IR

messages

You

'll

need

a

long

set

of

wires

or

a

cooperative

buddy

robot

Modulate

the

IR

emitter

and

detect

its

output

-LRB-

put

phototransistor

at

focus

of

the

receiving

antenna

-RRB-

Ultimately

in

order

to

communicate

you

'll

need

a

transmit/receive

protocol

error

correction

etc.

etc.

Maybe

one

reflector

houses

the

emitter

and

receiver

Should

be

fun

Bar-code

reader

Can

you

reliably

count

a

number

of

parallel

black

stripes

-LRB-

electrical-tape

width

say

separated

by

similar

space

-RRB-

Maybe

the

barcode

starts

with

a

double

thickness

I

'm

thinking

you

just

drive

over

the

code

and

read

it

with

reflectance

sensing

Try

the

prey-tracker

posted

on

cs.minibot

recently

Any

other

cute

idea

you

have

to

extend

our

range

of

sensing

and

effecting

capabilities

C.

The

Robot

Competition

See

Section

References

-LSB-

-RSB-

Olac

Fuentes

Rajesh

P.

N.

Rao

and

Michael

Van

Wie

Hierarchical

learning

of

reactive

behaviors

in

an

autonomous

mobile

robot

using

stochastic

hillclimbing

In

Proceedings

of

the

IEEE

International

Conference

on

Systems

Man

and

Cybernetics

Vancouver

B.C.

Canada

October

to

appear

-LSB-

-RSB-

J.

L.

Jones

and

A.

M.

Flynn

Mobile

Robots

Inspiration

to

Implementation

A.

K.

Peters

-LSB-

-RSB-

Tom

M.

Mitchell

Becoming

increasingly

reactive

In

Proceedings

of

the

AAAI

pages

-LCB-

-LSB-

-RSB-

Rajesh

P.

N.

Rao

and

Olac

Fuentes

Perceptual

homing

by

an

autonomous

mobile

robot

using

sparse

self-organizing

sensory-motor

maps

In

Proceedings

of

the

World

Congress

on

Neural

Networks

Washington

D.C.

July

to

appear