Newsgroups: comp.robotics
Path: brunix!uunet!spool.mu.edu!sol.ctr.columbia.edu!news.kei.com!ub!acsu.buffalo.edu!lammens
From: lammens@cs.buffalo.edu (Joe Lammens)
Subject: Another robot contest report, but not from RBL-93
Message-ID: <CAszMB.MCo@acsu.buffalo.edu>
Sender: nntp@acsu.buffalo.edu
Nntp-Posting-Host: gort.cs.buffalo.edu
Organization: UB
Date: Tue, 27 Jul 1993 03:13:23 GMT
Lines: 208

Since there seems to be a lot of interest in reports from the recent 6.270
robot lab and contest in Washington DC, I thought I'd submit this report on
a similar but earlier event. I Hope I'm not wasting bandwidth with this.
Enjoy.

-----

This report summarizes my experience building a Lego robot at the Nato
Advanced Study Institute on the Biology and Technology of Intelligent
Autonomous Agents, March 1-12, 1993, Trento, Italy.

The institute consisted of many (very interesting) lectures, working
groups, and several (great) hands-on labs: 

- a subsumption lab run by Rodney Brooks and several of his students, with
several Genghises (the six-legged insect-like robots) and R-1s and R-2s
(small cylindrical robots with a 2 DOF vertically movable gripper in front)

- a Lego lab run by Tim Smithers and Miles Pebody, with Lego vehicles 1
(lots of Lego Technic parts, a 6811 controller board, and sundry sensors,
motors, etc.) and Lego vehicles 2 (roughly the same, but with a more
powerful 68331 board)

- a PDL/Lola lab run by Luc Steels and others, with two Lolas (home-grown
cylindrical robots on a synchro-drive base) and some Volksbots (similar to
Smithers' lego vehicles, but controlled by an HP palmtop computer)

- miscellaneous robots provided by participants, some very small ones, some
built on an RC car frame, etc.

The organizers deserve a lot of credit for putting all this together. It
was an excellent experience, very informative, and a lot of fun. The
preparations must have been horrendous.

We had about ten days to work on our robots, though usually only a couple
of hours per day (after the lectures). Many participants spent most of the
two free days in the labs as well. At the end of the institute there was an
informal talent show/competition where individual entries were judged by a
jury composed of (if memory serves correctly) Rodney Brooks, Leslie
Kaelbling, Luc Steels, and Tim Smithers. The scientific part of the
competition was won by my team's entry: Gogo the schizophrenic robo-ghost.
I estimate there were about 15-20 entries total.

I worked in the Lego lab, with a very international group of grad students
and young researchers that was formed by self-organization: Ann Nowe
(Belgium), Tanja Urbancic (Slovenia), Ethen Alpaydin (Turkey) and Joe
Lammens (yours truly, temporarily US but really Belgian). We all did some
of everything, but I concentrated mainly on the control program. There was
quite a bit of interaction and exchanging of advice (and parts) among
different groups in the Lego lab (encouraged by shared suffering and
frustration, as well as fun). A description of Gogo's morphology, control
program, behaviors, and performance follows. Our general strategy was an
incremental one, starting by building a solid mechanical base, testing it,
adding a simple behavior, testing it, adding more sensors/mechanical
components and behaviors, etc. That worked relatively well, although there
were many unexpected interactions both at the hardware and software levels.


				Morphology
				==========

(aka mechanical design, but I like Tim Smither's term "morphology"). The
physical shape is important, as we soon found out. The robot has to be
strong enough to be able to take a beating (running into or being hit by
uncooperative walls, huge flower pots, people, nasty things with grippers,
and other robots running around the test arena -- a large room in the
medieval castle where we were), not get stuck easily behind corners, be
able to go in a straight line, etc. We started with a rectangular frame we
found among the pile of Lego on our table, with two differentially driven
wheels (the tractor kind) in the back, and one fixed axle wheel in the
front (the same kind of tractor wheel, but with the tire removed). We could
balance the weight distribution of the robot well enough to allow the front
wheel to skid over reasonably smooth surfaces when making turns. The gear
ratio allowed a relatively high speed, I estimate about 3-4 ft/sec with
fully charged batteries. The motors on the LV-1 are only controllable in 3
steps: off, half, and full speed forward or reverse. But after a couple of
minutes the batteries would get so low that half speed didn't do anything
any more, so we ended up using only off and full speed forward or reverse
(with a brief delay when switching direction, to avoid stripping the
gears). Declining battery power was one of the unexpected things we had to
contend with. We had active IR proximity detectors on four sides (all input
ports on the LV-1 are binary), and a bumper mounted on front with two
contact switches behind it and suspended in the middle with Lego shock
absorbers.  That provided both a degree of shock absorbence and left/right
contact sensing.  We wanted to have a switchable plain white light bulb on
top, but finally settled for a non-switchable one. Lots of rubber bands
were used to give the construction some mechanical resilience. Gogo looked
somewhat like a battle ship on wheels, with a control tower near the stern
containing the cpu, power, and I/O boards, and the batteries suspended
between the rear wheels.


			      Control program
			      ===============

Although there was a "real" subsumption lab with behavior language
compilers at the institute, we thought it would be interesting to implement
a subsumption-like control program on a Lego vehicle. I like to
conceptualize things as lower level behaviors taking priority over higher
level ones (subsumption on its head). We had only 3 behaviors (or
personalities, as we liked to call them) in a strict hierarchy, from bottom
to top: obstacle avoidance (bacteria personality), sit and wait behavior
(sitting duck personality), and wander behavior (explorer personality). All
behaviors had equal access to sensor readings. The sensor readings were not
pre-processed in a separate module; we could get away with this probably
because our sensors were all binary. Each behavior was implemented as a
separate process in JTL (a Pascal-like language with multiprocessing -- the
LV-2s use a subset of C) and controlled the motors directly -- at least as
far as it was concerned. Output mediation (subsumption) was implemented
using global variables, but in a distributed fashion: process N in the
hierarchy (the bottom process being number 1) would read the output values
of process N+1, and either pass them on unchanged if N itself did not
"want" to act, or ignore them and write its own values in its set of global
output variables. In other words, this was trickle-down control. This
scheme worked well, after we discovered why it did not work at first. After
many hours of going over the code we found out why: each process would
initialize its own set of globals, and if all the processes were started
simultaneously (or in rapid succession), the lower level processes would
start reading and copying the higher level globals before they had a chance
to be initialized, resulting in random junk in the variables and very
strange behavior in the robot. The fix was easy: start the processes one by
one, from top to bottom, and wait a few msec before starting the next. All
processes would run continuously once started. Stopping the processes was a
matter of catching our little critter and hitting the stop button -- not
always an easy task since we programmed it to run away from things that
come too close, like humans chasing it.

The obstacle avoidance process would continually monitor the IR sensors and
contact switches, and scurry off in the opposite direction of where it
sensed something. For readings in the front it would back up and veer
somewhat in the opposite direction of contact, for readings on the side it
would veer in the opposite direction, and for readings in the back go
forward for a little.  There was a fixed priority among sensors (a nested
if statement), so that we never considered simultaneous readings on more
than one sensor.  Although very simplistic, this worked well in practice.
When we noticed our critter would get stuck in a corner now and then,
bouncing [from left to right, right to left]+ we added a degree of
randomness to the timer for turns, which resulted in its always getting
unstuck after a while. The sit and wait process would do nothing but now
and then stop the motors for a while, using JTL's built-in timer. The
wander process would go straight ahead and turn randomly left or right for
a randomly varied time, now and then.


				 Behaviors
				 =========

Simplistic as our design was, the behavior displayed by Gogo was quite
interesting. It would scurry around the room, bouncing off walls, people,
other robots, flower pots, etc with contact (using the switches) or without
(using the IRs). Occasionally it would follow a wall for a while, maneuver
through narrow passages between objects (a - dare I say it - emergent
behavior), even back out of dead ends, sit in the middle of the room until
approached by someone or something and scurry off, get scared by the
sunlight coming through big windows in the room (creating false readings on
the IR sensors) and go haywire, and try to escape from its creators (the
ingrate). The mechanical design was severely put to the test, and now and
then pieces would fall off and sensors would be dragged across the room
dangling from their wires. Gogo would also enter into interesting
interactions with other robots, running circles around the slow and
graceful (and somewhat snooty) Lolas, smashing into other Lego-bots, and
running from R2s. The idea for the competition was to have a light on top
that would attract a predator R2. We wanted the light switchable so Gogo
would wander around, sit still and switch on its light waiting for the R2
to catch up with it, and when it got too close, switch off the light and
scurry off again, eerily invisible to the R2. Ha! The R2 was programmed for
the purpose by Ulrich Nehmzov from Edinburgh.


				Performance
				===========

Five minutes before the actual competition we were still fixing broken
wires, trying to put a battery-powered non-switchable light on top {which
was so big it almost made the little fellow keel over), and trying to get
the latest version of the program to download (mysterious communication
problems -- aaaargh!). Some members of our group got cold feet and wanted
to withdraw at the last moment, but the rest of managed to convince them,
and we forged ahead anyway. Their twisted arms are getting better already.
The actual run was quite amusing: we had Gogo dressed up in white tissue
paper, the light on top, and all the room lights off. It moved around (a
bit slowly because of draining batteries), bumping into spectators' feet
and such, and sat and waited for the R2 to show up. The latter was
remarkably successful in tracking Gogo (untested interaction)!, and closed
in on it with its gripper opening to grab our poor little critter... Some
confusion and a robo-skirmish ensued but Gogo managed to escape unharmed.
The whole spectacle was quite well received by the audience, and we won the
jury's scientific prize (the one, for amusement value, was awarded to a
dancing Lego robot made up of two independent pieces connected through a
central hinge).


			      After thoughts
			      ==============

All in all it was great and invaluable experience. Nothing worked the way
we thought it would, but eventually we got things going. Lego is a
wonderful experimental vehicle, allowing you to experiment easily with
mechanical design as well as control strategies. Subsumption is easy and
elegant for implementing simple programs like this, and the advertised
incremental design and debug strategy actually works reasonably well, and
the results are nevertheless surprising. Kudos again to the organizers for
an excellent job and a great time.


Joe Lammens
SUNY at Buffalo
Computer Science department
