Work reported herein was conducted at the Artificial Intelligence Laboratory, an M.I.T. research program supported by the Advanced Research Projects Agency of the Department of Defense and was monitored by the Office of Naval Research under Contract Number N00014-70-A-0362-0002.MIT Artificial Intelligence Laboratory Vision Grou

Winston, Patrick H.

DSpace@MIT

HETERARCHY IN THE M. I. T. ROBOTbyPatrick H. WinstonFLASH #8VISION GROUPARTIFICIAL INTELLIGENCE LABORATORYMASSACHUSETTS INSTITUTE OF TECHNOLOGYWork reported herein was conducted at the ArtificialIntelligence Laboratory, an M.I.T. research program supportedby the Advanced Research Projects Agency of the Department ofDefense and was monitored by the Office of Naval Researchunder Contract Number N00014-70-A-0362-0002.IntroductionIn the early days of artificial Intelligence there wastendency to write programs conducive to the study ofparticular dimensions of intelligence. A great deal waslearned from these programs including knowledge aboutplanning, subgoal formation, heuristic measures and methods,tree search and the like.With this experience we are now at M.I.T. going intoprojects that seem to require the integration of all thesemethods and ideas into powerful, general systems. We aretackling problems like natural language comprehension androbot vision with the hope and expectation that the work willead us beyond previous efforts to exhibit particular formsof intelligence long recognized and into an understanding •those aspects of intelligence not even named as yet.Although the way to go is not at all clear, it ischaracteristic of our science to experiment as well asspeculate. It is only natural then that we are working witha real robot that in a limited way perceives, understands,and manipulates the simple objects we put in front of itseye.Now to talk of understanding an environment, even asimple environment like that of the robot, one must haveoperational measures of expertise. Otherwise one facesendless haggling about just what It means for a system tounderstand. Three particular abilities which we feel requireand demonstrate a degree. of understanding are the ability todescribe, to learn, and to copy. Figures 1, 2, and 3 willhelp explain exactly what I mean.The machine's problem in figure 1 is to build a natural,heirarchically ordered description of the scene like that ahuman would produce <1>. Note that the configuration shownis quite a complex scene containing objects of various shapeswhich relate to one another In a variety of ways. From it wewant something like this multi-level description:> The scene has seven objects.> All but one is shaped like a brick.> In the foreground there is a tower consisting ofthree objects.> The tower is in front of a bridge.> The bridge supports a wedge at one end.> The tower consists of medium sized bricks.> The bridge consists of two medium sizedbricks, carefully aligned with the longboard.Figure 1: A scene of the sort now understoodby drawing analysis programs.NEAR MISSDrawings used in teaching the machinethe notion of ARCH.ARCH NEAR MISSFigure 2:Figure 3: Configuration typical of those copiedby the M.I.T robot. Note that objectsobscure one another.Figure 2 defines the particular special kind of learningthat I have In mind for the second measure of competence <1>.One presents the machine with a sequence of samples, in thiscase both examples and near misses to the notion of ARCH.From these the machine is to create an abstract modelwith which it can later identify examples of the ARCHconcept. The model must be good enough to allow recognitionof partially obscured arches and arches differing from thosein the learning sequence by way of changes in size andorientation.The third measure of understanding and the one I want toconcentrate on here, Is the ability to copy a configurationfrom spare parts. The world as our system sees It consistsof white, plane-faced objects organized into scenes such asthe one shown in figure 3. At the moment, we work primarilywith bricks and wedges, but many of our modules are quitegeneral and deal successfully with other shapes. Unlike someother systems, ours makes no assumption that the objects arerestricted to a fixed set of sizes. Moreover the systemexpects to see partially hidden objects. Indeed it thriveson configurations where the objects are on top of or in frontof one another.For us this copying task is harder to implement than theprevious two tasks because we insist on total machine self-reliance. It does not begin with a line drawing as weusually allow In our other work. Instead we want it to makeits own drawing using a random access Image dissector camerato gather information directly from the objects themselves.Many attempts at programming for this task failed and norespectable line drawings were produced using our vidisectoruntil Thomas Binford <2> and Arnold Griffith .<3>independantly completed Important line finders.The problems associated with all three of these indexesof competence have been under attack for many years now.Some have proved unexpectedly hard, but within the last yearall three of the capabilities sketched out here have beendemonstrated. I concentrate here on the achievements leadingto the ability to copy because I think they best illustratehow this work not only confirms the need for forward-lookingideas in system organization but also contributes to thedevelopment of a theory for artificial intelligence.The Basic Robot ModulesIn order to establish a frame of reference for furtherdiscussion, I must briefly outline the sort of things that goon in the mind of our seeing robot.The first thing is the very difficult job oftransforming the array of a million or so noisy intensitysamples one gets from the camera Into the respectable linedrawing needed by other modules. Since one must fight allflavors of optical distortion and electron noise, and non-uniform camera sensitivity, it is no embarrassment that ourline finding modules rarely find all the lines in a givenscene.In any case, the drawing must be represented In themachine in a way that Is convenient for other procedures.Preparing and maintaining such a representation Is the job ofa module I will simply call the bookkeeper. This programuses essential ideas contributed by H. N. Mahabala <M>.Beyond this, the system has a module good atpartitioning the regions defined by the lines into a set ofbodies. It is the job of such a body finder to report that ascene appears to have a certain number of bodies or objectsand to indicate the regions associated with each.Other modules in turn describe various properties of theobjects. One module looks for relationships between objectscorresponding roughly to our human notions of on-top-of, in-front-of, and aligned-with. This is the job of the body-relationship-describer. Its skill is useful to a modulethat finds XYZ coordinates and another that speculates on thesize of each body. These are the body-position-finder andthe body-dimension-finder modules.There remains In a skeletal system only a structureconstruction module that plans and executes the stepsnecessary to build a copy from spare parts.Now early in this research we believed that It might bepossible to write good general programs for each of thesejobs and arrange them together under an executive programthat would use them to cause an orderly progression of datafrom intensity values on one end to arm-and-hand commands onthe other. However we cannot make such a system work, and wedo not believe that such a system has good prospects. Thereason is that the system has so much to do, the probabilityof getting through the whole job without oversight or erroris small, even with very good modules.Heterarchical OrganizationTo us the way to success therefore lies in a set ofattitudes toward system organization that has come to becalled heterarchical organization. At the moment, the termremains only vaguely defined, but it certainly includes thefollowing ideas:1. A powerful vision system must contain or have accessto lots of knowledge. Some of the knowledge is aptto be special purpose and some of it quite general.In our system, for example, we have some specialknowledge that Is useful only for bricks and somemore general knowledge that applies to almost allsimple plane-faced objects.2. A powerful system needs not only a variety of goodmethods, but also knowledge about those methodssufficient to judge when they are inappropriate.3. If a module perceives some other module has erred andhas provided false information, it must be able tocomplain and request a review. This objection mightbe that a body of unlikely shape has been proposed orperhaps that a crucial line has likely beenoverlooked.A. Communications between modules must be smooth and-natural for many reasons, not the least of which isthe fact that many programmers must cooperate in sucha large project. So far the system represents directcontributions in code from Thomas Binford, BertholdHorn, Arnold Griffith, Eugene Freuder, David Silver,and Patrick Winston. We expect this group to expandquickly now that the skeletal system is complete.Taken together, these points suggest something quitedifferent from a simple row of processes, each passing overthe data base, doing Its job, handing control to the next Inline, and retiring. Instead one must think more of anInteracting community of processes, some narrow experts,others broad generalists, and still others in the role ofcritics. As the system becomes more powerful, we expect tosee more flow of advice, complaints, and requests for help.To clarify these somewhat general and abstract remarks,I now describe two relevant parts of our system. The firstof these Is the part that judges how regions go together, thebody finder.Our general method for region conglomeration is adescendant of a program conceived and implemented by AdolfoGuzman <5>. His technique, stripped of all embellishments,Is simply to make two passes over the representation of theline drawing, the first producing local evidence from thevertex configurations and the second gathering together andweighing that evidence.The local evidence pass recognizes the 8 vertex typesIllustrated in figure 4. Of these the T, K, and L areignored, while the others each produce one or more units ofevidence for believing two adjacent regions belong to thesame body. These units of evidence are called links. Thesecond pass then observes which regions are joined by two ormore links and announces that they belong to the same body.Figure 5 shows how this scheme easily handles a simpletwo brick situation. By iterating the second conglomerationpass, it can handle much more complicated scenes. Butattempts to make it fully as good as people at this job haveled only to unsatisfying hodge-podge collections of Weakerand weaker heuristics that subtract, rather than add to thebasic elegance of the scheme. This does not discourage us,however, because part of our philosophy of approach holdsthat such general schemes without any special knowledge oraccess to advice cannot do more than a good job.To see instead how this general program can contributeto the system positively while sharing its job withspecialists, consider for a moment the K type vertex. Guzmandid not use it In his basic algorithm because without acontext, the vertex suggests two equally likely, butincompatible possibilities. Figure 6 illustrates the usualcase where two aligned bodies each contribute a pair ofadjacent regions to the set of four regions that surround allK's. But which of two pairings Is correct cannot beTARROWPEAKFORK-OTHERS-MULTIVertex types as defined by Guzman.Figure 4:Figure 5: Bodies are found through a process thatuses local vertex evidence to link regionstogether.determined locally.Of course there are many ways one might attempt toresolve the ambiguity and get solid linking evidence from theotherwise ambiguous K. But here I only want to observe thatK's are frequently resolvable through the use of a specialistfor unobscured bricks. This program's only use Is thediscovery of three adjacent parallelograms compatible with abrick Interpretation. It Is thus a region conglomerator onlyunder special, easy circumstances. But see how this specialcase program easily resolves the ambiguous K's in figure 6.Once-the supported bricks are seen, the special case programmay advise the general case program that the K's have onlyone interpretation compatible with its findings. Thus theformer ambiguity gives way to solid general evidence.This last example shows how special and general programswork together in our system to accomplish the same task. Thenext illustrates how another chain of communication extendsfrom a distinct critic through a hypothesizer and on toanother specialist.As previously mentioned, the line finder cannot andshould not be expected to find all lines. Rather, it shouldonly report the ones it is reasonably sure of for theanalysis of other programs with more knowledge. It can beexpected to occasionally miss lines such as the ones dashedin figures 7 and 8 since the Illumination gradient acrossFigure 6: K-type vertexes suggest two bodiesbut the proper pairing of regionscannot be determined locally.A common type of missing line.The heavy lines outline an regionwhich the region critic findsobjectionable.Figure 7:Figure 8: The double L missing line situation.such lines may be quite small.Presently the bookkeeper is the system's first line ofdefense against such oversights. At the moment it has littlesophistication in Its complaint mechanism. It simply objectsto concave regions. The more concavities it notices along aregion's periphery, the stronger It objects. Of courseconcavity only suggests the possiblity of missing line error.But If a region genuinely deserves to be concave, thecomplaint leads to no action and nothing Is lost.Complaints are received by proposers that have buried intheir code implicit knowledge of both our line finder and oflikely line configurations. One proposer, again aspecialist, is designed to react to a missing interior lineof a brick. Hence when the peculiar concave shape outlinedIn figure 7 Is observed, this proposer Instantly hypothesizesa line which divides the region Into two parallelograms.A more general proposer Is good at the sort of doublyconcave region heavily outlined in figure 8. Its effort Isto find a pair of L type vertexes, one of which has a linewhose extension passes through the other vertex. Thisextension is then the line proposed.Both of these proposers appeal to a line verifier whichclosely inspects a small region about the proposed line. Onecan afford enormously Involved computation here because theprogram only looks at a small portion of the scene. Should aline be considered likely, the verifier reports Its presenceback to the bookkeeper which initiated the entire chain ofevents.The PLANNER LanguageIt goes without saying that our work places heavydemands on the programming languages we use. LISP, ourfavorite for many years, is now yielding to the more adequatePLANNER of Carl Hewitt <6>. PLANNER has the features of LISPplus a number of Improvements, three of which particularlyfacilitate our effort. These are roughly the following:1. Adequate pattern matching and data management. Thishas greatly shortened program length and debuggingtime.2. Automatic backup. If a subroutine falls, all actionis unwound back to a specified point where a choicewas made. Alternative is selected, and control thenpasses forward again. This means that if one line ofreasoning leads to a dead-end, all its effects arewithdrawn and alternatives are tried.3. Goal orientation. The language allows subroutines tobe called through their purpose rather than theirname. By analogy this is like the ability to stepinto a room of strangers and to say "I need to havesome boards nailed together. Is anyone good atthat?" One need not know In advance who theappropriate people for carpentry are.We believe that our work will emphasize the need forfeatures such as these and lead to still further advances inlanguage architecture as well as contributions to an overalltheory of intelligence.ConclusionOur effort in robot research is to get at the problem oforganizing a large, highly coupled system that features manydifferent abilities and kinds of knowledge. The examples Ihave given here represent only our first attempts at breakingaway from straightforward design into arrangements that causeus to squarely face the problems of big system design. Wesoon hope to add more and more specialists and more and moremodule complaint, advice, and request channels. On theimmediate horizon are more than a dozen possibilities, amongwhich are several alternatives to our current monocularobject location scheme as well as some specialists that dealprimarily with wedge processing.REFERENCES(1) Patrick H. Winston, "Learning StructuralDescriptions from Examples," Report MAC-TR-76(Thesis)(Cambridge, Mass.: Project MAC, MIT, September1970).(2) Annette Herskovits and Thomas 0. Binford, "OnBoundary Detection," Artificial Intelligence .Laboratory Memo.No. 183 (Cambridge, Mass.: Artificial IntelligenceLaboratory, MIT, July 1970).(3) Arnold Griffith, "Computer Recognition of PrismaticSolids," Report MAC-TR-73 (Thesis)(Cambridge, Mass.: ProjectMAC, MIT, August 1970)..(4) H. N. Mahabala, "Preprocessor for Programs which-Recognize Scenes," Artificial Intelligence Laboratory Memo.No. 177 (Cambridge, Mass.: Artificial IntelligenceLaboratory, MIT, August 1969).(5) Adolfo Guzman, "Computer Recognition of Three-Dimensional Objects In a Visual Scene," Report MAC-TR-59(Thesis)(Cambridge, Mass.: Project MAC, MIT, December 1968).(6) Carl Hewitt, "Description and Theoretical Analysis(Using Schemas) of PLANNER: A Language for Proving Theoremsand Manipulating Models in a Robot," Thesis, Department ofMathematics (Cambridge, Mass.: MIT, January 1971).

Heterarchy in the M.I.T. Robot

http://dspace.mit.edu/bitstream/1721.1/40799/4/AI_WP_008.pdf

Heterarchy in the M.I.T. Robot

Abstract

Similar works

Full text

Available Versions

DSpace@MIT