🚀 go-pugleaf

This posting is the bulk part of an article describing an
Autonomous Wheelchair, that "lived" in 1975-1977 in the
Machine Perception Lab of Arizona State Univ, College of Engr.

I post it because the work is unknown, yet with 2 IBM PCs, linked
via serial link, and one B&W camera of 128X128 resolution, digitized
to 8 bits yet usually converted to binary image for speed of processing,
Whacky would repeatedly navigate the various-width halls, recognize
alcoves and count them, recognize the unique black baseboard patterns of
important intersections, and pivot to proceed down the next hall.
Upon reaching what should be the destination room, so presumed by
counting the number of major sonar depth changes as alcoves are passed,
Whacky looked for a large black paper disk with a pattern of up to 10
3 inch white disks, arrayed to present in binary the 3-digit room number.
If found, Whacky gutterally announced "I have found the room".

Here follows, without permission, major excerpts from the article,
written by Ron Pronk, published in the Fall 1987 PC AI magazine.
My comments are noted as [.... gas]   

G. Allen Sullivan

------------- The Wheelchair Robot----------------
		by Ron Pronk

"The question: What can and cannot an autonomous robot do? To find the
answer, you build one and test it in an actual environment, right?
Wrong, as far as most researchers are concerned. The complexity of an
autonomous robotics research project usually means that millions of
dollars are required to build either a working model or an actual robot.
Several millions of dollars are then required to test and debug the
software until--if ever--the robot operates effectively."

"For this reason, the typical way to study robotics problems is by
developing practical simulations. But even the develoment of leading-edge
robotics simulations can run up a bill in the millions of dollars. And
the bottom line is that a simulation is a poor substutite for a working
robot."

"Richard Madarasz, a professor as Arizona State University, in Tempe,
knew the bottom line and didn't like it. So three years ago,
he and group of robotics and automation undergraduate students set out to
rewrite it. Madarasz realized that most undergraduates who wish to study
artificial intelligence are forced to duplicate projects set forth in 
textbooks, which leads to an extremley [error in original GAS] limited
learnng environment. In response, Madarasz decided to conduct his robotics
class by having students attempt to design and build something--anything--
that would apply the concepts they were studying."

"The result was Whacky, a robot that you might say has dared to go where
no robot has gone before. Whacky is an autonomous, or mobile, robot
built by a group of five students, who accomplished all of their work
with a total out-of-pocket outlay of about $800. When Whacky if plugged
in, it accepts a classroom number as its destination, rolls down a
university hallway in search of the room, avoiding walls and other
obstacles, and stops when it reaches its goal."

[Deleted 2 paragraphs]

"The project began in the Fall of 1985, shortly after Madarasz joined the
ASU faculty. Madarasz's students considered several development possibilities
but decided on [Whacky (gas)] for a simple reason: The initial parts were
free. The robotics students had learned that the campus Disabled Student
Services group had several spare wheelchair parts that they were willing
to make available."

"Using these parts, the students then rebuilt a makeshift wheelchair,
strapped a borrowed PC into its lap with a seat belt, and attacked a camera,
which also was on loan. Their first purchases were for a sonar and the parts
to build a motor controller. With the hardware in place, the group began
the arduous job of software design."

[Madarasz built an aluminum frame to hold an IBM PC Portable behind the
passenger seat, and to support the DC-motor-with-potentiometer-feedback
single-sonar scanner about 4 feet off the floor, well above any seated
passenger, with the General Electric camera peering over the right shoulder.
A electric wheelchair has the advantage of robustness, builtin
drive motors and motor battery. This wheelchair also had a bent front wheel
so when moving would quiver like an old supermarket cart....preventing
much repeatability. But Whacky easily compensated for that. Read on. (gas)]

"Programming Whacky went slowly at first because the students were charting
new ground in the robotics field. At the time, most robots in operation
were for industrial applications and stressed repeatability of movements---
typically within .005  of an inch. In turn, the majority of corporations
and foundations were offering grant money for robotics projects that would
improve repeatability capabillities. Autonomous, mobile robotics research
had been pretty much neglected."

------ Key point follows------
"Repetition was nnever much of a consideration with the ASU robot. Loren
Heiny, one of the research group members, says they probably couldn't
repeat Whacky's movements within a foot. To a certain extent, Whacky's
inability to repeat tasks has been beneficial. With a mobile robot,
unlike an industrial robot, there are just too may unforeseeable variables
that could affect repeatability."

"Says Heiny:"If a mobile robot were programmed only for repeatability, its
ability would be extremely crippled. If someone were to bump against the
robot, it would be all over. The machine couldn't recover."

"But it is exactly this tupe of environment, in which variables are infinite
and occur randomly, that the group wanted to explore. According to Rob
Lovell, another group member, "The key is to provide enough sensing
capabilities so that the machine can always recover." So, for a mobile robot
to move freely, it has to be able to examine and comprehend reference points
at any time during its operations."

"The group provided these sensing capabilities using two basic techniques.
Under the first technique, the robot is controlled by a task-oriented planner
[written by Robert Cromp now at NASA GODDARD, and Neal Mazur now at Union
College (gas)] that contains a world model of the machine's environment.
The world model for Whacky was the hallways of the ASU Engineering Research
Center. With this model, the planner program executes individual tasks that
will help the robot reach its goal. For instance, to locate a given
classroom, say room 216, the plan includes such tasks as turn 90 degrees
toward the hallway, go down the hallway to an intersection and make a left
(or right), and go down to the second door on the right side (which should
be room 216)."

[ ------- some details -------------

Whacky initially oriented itself by using the sonar to locate the nearest
freespace, moving into that freespace, and again scanning for freespace,
preferrably containing 2 long opposing regions presumed to be the hallway,
and approximately pivoting the wheelchair into an orientation parallel
with and hopefully centered enough to locate the black baseboards with
the camera.

At a worst-case startup condition, Whacky was pushed into the alcove outside
the lab, an alcove about 3 feet deep by 8 feet wide, with the long side
parallel to the hallway. The sonar was thus about 2 feet from the alcove
wall/corner, and about 7 feet from the opposite wall of the hallway.
Since Whacky pivoted inaccurately, at least early on, in general the machine
was initially pushed into the alcove such that no accurate pivoting was
necessary to leave the alcove, e.g. not jammed right into a corner.
Whacky was given power for the computers, thru a long orange extension cord,
and after PC bootup, the first program run was to scan the sonar to
measure distances on about 5 degree intervals over 360 degrees. Determining
a vast difference between 2 and 7 feet, Whacky then for the first time
would move, backward or forward, as needed to leave the alcove corner.

Now out of the alcove, the sonar was rotated, again generating a polar
map of distances. Since the angle of incidence was quite shallow when
the sonar was pointed down the hallway, the measured distance was the
maximum---not the 30 feet we expected for the Polaroid sonar, but an
ASU hallway characteristic of 13 feet. Something in the ceiling tiles,
or something, would cause the sonar to indicate 13 feet when measuring
along a hallway! Detecting two approximately opposing infinite/13-feet
peaks, and having a plan of action, Whacky would pivot to face along the
necessary hall, and switch to using vision by bringing in a vision program
into the 640K byte space.
--------- return to article------------]

"The second basic technique, which helps the robot identify its location
and avoid obstacles, is the use of a landmark-based vision recognition
system. Whacky doesn't understand distances. [At least initially, the
crude optical encoders worked poorly, with motor interference giving lots
of miscounts, and even pivoting, which could have used the information,
was accomplished by just briefly driving the two motors in opposite
directions. Later on the optical encoders worked better, and were used
for moving into an intersection a known distance, so that pivoting at 
that location would face Whacky along the new hallway. (gas)]
Instead, its domain is limited to a few basic landmarks found in its
hallway world model. As Lovell explains. "It knows relative locations
of rooms, not absolute locations. With these relative locations available,
it can creat a plan to move from one room to another." At any given time,
Whacky understands its locaion according to its proximity to the
nearest room. "For example," says Heiny, "it doesn't really know that it's
25 feet down the hallway, only that it's close to Room 218 on the right."

[------ more details, using pattern recognition -----

Robb Lovell received his MSCS for conceiving and implementing a visual
grammar that recognized which intersection Whacky was approaching. The 4
major intersections of the 2nd floor were each unique, if you considered
hall widths, and offsets of corners, and doors near the intersection
that generated gaps in the black baseboards. So Robb's grammar
was used to describe the 4 expected patterns. As the movement plan
predicted an intersection should be detectable soon, since the last alcove
had been passed, the second IBM PC was activated to process in parallel
the image information, to pattern-match the angles and lengths and gaps
of an intersection undergoing perspective distortion thru a 30-degree
field-of-view lense mounted 3 feet off the floor.

As Whacky further approached the intersection, the camera often would
lose the straight lines of the normal left and right baseboards, so 
the pattern-matcher was run to compute how much further to move--blindly--
to probably be centered in the intersection, ready to pivot 90 degrees.

-------- back to article-----------]

"In fact, some of the more important accomplishments of the ASU research
group can be seen in what they could not do. One lesson in robotics
limitations occurred when the group tried to operate the sonar. 
"When we started the project," Heiny says,"the big thing in the robotics
field was the sonar range finder. People believed you could just put a
sonar on a robot and it would move around freely, mapping out rooms
and ckecking the map to a world model. With the sonar, the robot would
know where it was at all times.""

""Well, when we actually put the sonar on, we realized that it is a very
poor sensing device, because it reflectly strangely of of walls. You get
echoes and readings that are very difficult to understand.
[Imagine mapping a room using 3 or 4 very fat fluffy pillows on the end of a
yardstick, with the pillows beeping whenever ANY PART OF THEM touched 
something. (gas)] Researchers are now beginning to accept the fact that
sonar isn't as great as they initially had thought."