control of walking l d re

CMI'-CS-84-121

Control of Walking

Local control and real time systems

Marc 1). Donner

Department of(_"un_ptller Science

Carnegie-Mell(m University

Piltsburgh, Pennsyl_ ania 15213

1 May 1984

Cop)right (C) 1984 Marc Donner

St_bmittcd t,:_Carncgic-Mcllon Uni_cr,,,it5 in partial fulfillment of the

req_i: cmcnts fi_r the degrec of Doctor uf Ph itosophy.

Ac knowledgements

The number of people who have contributed to making this work possible or to my enjoyment of the

process of doing it or both is truly stunning. By tradition, only the author of a dissertation is honored

publicly; the rest of those who made it possible are repaid simply with private gratitude. In token of my

gratitude, I mention here some of the people who have helped and hint at their contributions. The first five,

Ivan Sutherland, Raj Reddy, Marc Raibert, Mary Shaw, and Rick Dill, served on my thesis committee. The

rest are presented in no particular order at all.

Ivan Sutherland designed and constructed the walking machine and offered me the opportunity to program

it. He encouraged me when I decided to take a radical approach to the control problem. He taught me the

meaning of courage and helped me rcfind it on the many occasions when I lost it.

Raj Reddy opened my eyes to the idea that good scholarship need not be narrow, dry, or uncreative.

Marc Raibert taught me that there are no boundaries or territories in science. When the interesting idea

goes over there, follow it, even if you wander beyond the edges of your field. He also tried to instill a measure

of scientific care and discipline in my work ... and almost succeeded, despite my best efforts.

Mary Shaw spent a lot of her time discussing language design with me, patiently making the effort to

understand the half-baked ideas I was scattering about and asking the carefifl questions that helped me

understand what I was doing.

Rick Dill taught me about intellectual hoqesty and good engineering. He has never failed to recognize and

reward real achievement nor to ridicule silly pretension.

James Gosling and I spent a lot of time eating and drinking and discussing IAfe, the Universe, and

Everything. Everything included my work, and James patiently suffered a great deal of earbending by me

about OWl_,and walking.

Wes Clark took the effort to understand what I was doing and asked, in the most gentle manner imaginable,

some of the hardest questions that I had ever avoided. He supervised the writing of the first walking program

and provided the grapes that I consumed while doing so.

Chris Stephenson provided intense intellectual challenges and a great deal of stimulating argument. He

listened to me and made several important comments about the design of OWL.

To Bill Wulf I owe my understanding of what a thesis is and, most importantly, the realization that OWL

could be compiled instead of interpreted.

Peter Capek, in addition to being one of the most flnpressive programmers of my acquaintance, provided

challenge and inspiration and unfailing hospitality. A better fi'iend would be hard to come by.

To the members of HA I owe lots of things, including many improvements in my programming style and

quite a few enjoyable evenings spent reading code and drinking wine. HA included Ed Smith, James

Gosling, Bob Sidebotham, Dave Rosenthal, lvor l)urham, Mike Kazar, Mahadev Satyanarayanan (Satya),

David Nichols, and Larry Matthies, among others.

I must thank the house at 1014 [qemington for many hours of" diversion during the writing of my

dissertation. When my brain began m overheat, I could always count on remodeling projects there to provide

me with walls to tear down and other forms of useful destruction.

Finally, special thanks go to Claude Shannon for the poem included as Appendix 4 and to Fred CaJ_Jsontbr

the artwork from which the figure on the back of the title page is derived. Jim Kocher's help with videotaping

was so important and so cheerful that it cannot be forgotten. The assistance that Jim McQuade provided with

the 68000 C compiler was invaluable ... particularly the time he helped me patch a running program in order

to salvage a day's worth of data. Mike Ullner wrote the 1/O roulincs that serviced the OWl. runtime system ...

he provided some of the most reliable code I have ever dealt with. l)avid Douglas kept the nmchine

functioning, bringing it back to life after broken legs a_d other disasters that I feared were terminal. Jenise

_Iamaki kept the lab fiznctioning with a thousand difR-rent contributions. Sharon Burks, tlle CSD den

mother, was wonderful.

Finally, my fi'iends who kept me happy and sane during my time in Pittsburgh: Satish, Larry, James,

Robin, Bob, Dave, Satya, Jenise, Peg, Ed, Sarah, Carl, I.ynn, Ed, Nathaniel, Trina, and others. It wouldn't

have been worth it without you.

Table of Contents i

Table of Contents

1. Introduction 1

PART I:Machine and AnimalWalking 52. Animal walking 7

2.1. Locality of control 72.1.1. The insect nervous system 72.1.2. lnscct experiments 82.1.3. The spinal cat 92.1.4. Reflexes versus patterns 9

2.2. Rear-to-front waves 10

2.3. Why insect gaits are not discrete 152.4. Summary 15

3. Other walking work 17

3.1. Static stability 183.2. I)ynamic stability 203.3. Summary 21

4. SSA walking machine 234.1. Mechanical overview 234.2. Valve settings 26

4.2.1. Hip control 274.2.2. Knee Control 29

4.2.3. Valve Switching time 304.3. Control computers 304.4. Hydraulic system 31

4.4.1. Pumps 314.4.2. Cylinders 324.4.3. Valves 33

4.5. Summary 36

5. Walking Program 37

5.1. Responsibilities of a walking program 375.2. Inhibition and Excitation 38

5.3. Walking program structure 415.4. Row 41

5.4.1. Load 425.4.2. Recover 43

5.5. Service processes 45

ii Control of Walking

5.5.1. Sensors 46

5.5.2. Trouble 48

5.5.3. Compensator monitor 495.5.4. Gather 50

PART 1I:Programming for Robotics and Control 516. Inadequacies of existing control structures 53

6.1. Concurrency 546.1.1. Time Slicing 546.1.2. Algorithmic languages 546.1.3. Production Systems 556.1.4. Concu rrent Programming I.anguages 57

6.2. Nondetenninacy 586.2.1. Concurrent programming languages revisited 596.2.2. Guarded Commands 59

6.3. The control of temporal behavior 606.3.1. Wait fi)r event 60

6.3.2. Complete task before event 626.3.3. The nature of loops 63

6.4. Real time performance 636.4.1. Pluribus "strips" 636.4.2. TOMAL 64

6.5. Summary 65

7. OWL language 67

7.1. OWL processes 697.2. Sequences 70

7.2.l. Asserting done and and alert 7I7.2.2. When and bothwhen 72

7.3. Concurrences 737.3.1. Handling of alert 737.3.2. Concurrent while 75

7.3.3. Synchronization and Mutual Exclusion 757.4. Named Processes 76

7.4.1. Scope and Parameter passing 777.5. Data 79

7.5.1. Data types 797.5.2. Declarations 80

7.6. Discussion 81

7.6.11.Sequences and loops 817.6.2. Concurrence and alternation 81

7.6.3. Distributed implementation 817.7. OWL Compiler and Runtime System 83

7.7.1. Compiler 837.7.2. Runtime system 83

7.8. Performance 85

7.9. OWL Syntax 88

7.9.1. Walking Machine primitives in OWL 89

Table of Contents iii

PART 11I:Results and conclusions 918. Experimental Results 93 _

8.1. Local control 93

8.1.1. Walking 948.1.2. Five legged walking 94

8.2. Inhibition 968.3. Excitation 99

8.4. Comparison of OWL walking program with another walking program for the SSA 99machine

8.5. Summary 1029. l)iscussion and Conclusions 103

9.1. Di,;tributed control 103

9.2. Scaling constraints on walking strategies 1049.2.1. Why small things cannot balance 1049.2.2. Why small animals don't have to balance 1059.2.3. Prognosis for walking machines 106

9.3. Natural motions 1069.4. Conclusions 108

9.5. Programming: real time and robotic systems 1089.6. Directions for future research 109

Appendix A. Walking program code 111A.1. Overview 111A.2. walk.owl II 2A.3. Load5.owl 116A.4. Drive7.owl 117A.5. Unload3.owl 117A.6. Recover6.owl 117

A.7. waveinit.owl 120A.8. sensors.owl 125A.9. data.owl 127A.10. trouble.owl 128

A.11. comps.owl 129

Appendix B. Data 131

B.1. Description of data figures 131B.2. Data plots 134

Appendix C. OWL Primitives 143

C.1. OWI, control primitives 143C.2. Compiler dircctives and declaration keywords 144C.3. Sensor primitives 144C.4. Valve command primitives 145

C.5. 1/O primitives 147C.6. Misccllaneous primitives 148

Appendix 1).The Trojan Cockroach 149

iv Control of Walking

References 151

Introduction 1

Welcome back my friendsTo the show that never ends.

We're so glad you couM attend,Come inside, come inside.

--- Emerson. Lake, and Palmer

Chapter 1

Introduction

Complex control tasks are best programmed by decomposition into a number of asynchronous

communicating subtasks. Given such a decomposition, successft,1 implementation depends on the

availability of a suitably expressive language.

This thesis describes the results of research I conducted with the objective of designing and

constructing control programs for the SSA1 six legged walking machine. This research makes two

intimately interconnected contributions. The first is a decomposition of the walking task that exhibits

a great deal of locality of control, relies on almost no global information, and requires little

computation. The second is a programming language, OWl., specially designed to provide the real

time perfonnance and concurrency control needed to implement the walking program, qtle language

made the walking strategy much easier to develop, and the strategy provided a guide for the design of

the language.

Lift _ Place<Energize

Figure 1-1: The cycle of motion for a SSA walking machine leg. Fach line segment in the figure is labeled with the nameof the hydraulic valve setting that achieves that motion.

The walking sta'ategythat I adopted, suggested by a review of the literature on animal walking, has

each leg controlled by a separate and mostly autonomous process. Each process is responsible for

cycling its leg repetitively through the phases of stepping. These processes assert constraints on

neighboring leg processes that result in orchestration and coordination of walking behavior. There

1The SSA walking machine was designed and constructed by Dr. Ivan Sutherland of Sutherland, Sproull, and Associates,Inc. beginning in 1980 while he was a Visiting Scientist at CMU.

2 Control of Walking

are two sets of constraints, one called inhibition that helps the nlachine to maintain a reasonable

stance, and one called excitation intended to encourage the development of gaits similar to those

exhibited by insects. Experimental results confirm the effectiveness of the decomposition. It is

interesting to note that the machine can walk quite effectively without the excitation mechanism,

developing gaits quite different from insect ones as a consequence.

In walking an insect's leg repeats indefinitely a simple pattern of motions. The leg first moves

forward, above the ground, until it cannot move any further and then it moves toward the ground

until it makes contact. Once in contact with the supporting surface it drives backward until the end

of its reach, at which point it picks up off the ground and begins the cycle all over again. A similar

pattern for control of individual legs is appropriate for the walking machinc, as illustratcd in figure

1-1. There are four phases in the control of this cycle: Load, Drive, Unload, and Recover. The Load

phase moves the leg downward and finishes when the leg is in contact with thc ground and loaded.

The Drive phase moves the leg rearward, passing on to the Unload phase when the leg has moved as

far back as it can. The Unload phase raises the leg off the ground and then the Recover phase moves

the leg as far forward as it will go.

left rear _left rniddle _ .... _ -

left front

right rearright middle

right frontFigure 1-2: 'Timing diagram' of slow insect walking that illustrates the rear-to-front waves of leg recoveries. Leg 3 is at the

left rear, leg I at the left front, leg 4 is at the fight rear, and leg 6 at the right front. Time increases to the fight.The bold black segments indicate the leg recoveries and the light dotted segments show when the leg is driving.Adapted from Wilson [61].

Such simple patterns are necessary but not sufficient to provide effective walkiqg behavior. 'Ilae

relationships between the cycles of the various legs must be controlled in some way in order to

prevent, for example, all six legs from recovering at once and dropping the machine unsupported to

the ground. Research on insect walking suggests that this can be done with some very simple

communication between neighboring legs. The communication serves to help the animal to maintain

its stance and to make forward progress efficiently by developing rear-to-front waves of leg

recoveries, as illustrated in figure 1-2.

The program that I developed for the control of walking involves several independent processes,

Introduction 3

including one for each leg. Each leg process is responsible for the repetition of the

l.oad-l)rive- Unload-Recover cycle for its leg. The communication between legs is limited to

neighbors and takes the form of inhibition and excitation signals sent fi'om each leg to its neighbors.

These inhibition and excitation signals are used by the leg process in deciding when to make the

Drive-Unload transition. The transition is made when the following relation becomes true.

fz <= J'o- inhibition + excitation

Where.fz is the vertica! load on the leg. When a leg is recovering, and hence not supporting any of its

share of the machine's weight, it inhibits its neighboring legs, thus reducing their probability of

making the Drive-Unload transition. When a leg finishes recovering it removes all inhibition and

excites its forward neighbor, thus encouraging that neighbor to begin recovering sooner.

N F-k/

Legs recovering, from w830728.data

rx,.... o o .o -go

time (secorlds)

Figure 1-3: Time trace of the machine walking under the control of the OWL, walking program. There is a trace for eachleg of the machine that shows when the leg is recovering, the upper level, and when it is driving, the lowerlevel. This data shows the machine walking with a faster gait than that of figure 1-2, but the rear-to-fronttriplets of recoveries are plainly visible.

Figure 1-3 shows a trace of actual machine walking plotted in a style similar to figure 1-2. The

program was also able to walk without the rear-to-front recovery waves, with each leg deciding on its

own when to recover and when to drive. In addition, the same program could walk with ollly five

legs, with one leg 'commented' out, demonstrating the same ability to walk as an insect with a leg

amputated.

Concurrent real time programs of the sort necessary to implement the walking strategies can not be

easily expressed in traditional algorithmic languages. This is because the concept of an algorithm, a

finite sequence of simple steps that implements a computation, is not powerful enough to express

simply the concurrency that the walking program needs. The OWL language that I designed for the


purpose of implementing the walki_g program provides control constructs that are better suited for

the task than the algorithmic la_lguages, while maintaining some of the control abstraction power that

algorithmic languages pioneered.

Control of walking based on the insect strategies and implemented in the OWL language was

successful. The SSA walking machine walked under the control of an OWI, program and the

walking was as good as the mechanical and hydraulic design of the machine permitted. A quantity of

data was taken during m;_chine walking and is analyzed in this thesis, l_lleOWL walking program is

reasonably short and is comprised of a collection of simple processes that were simple to debug and

maintain.

Introduction 5

Part I

Machine and Animal Walking

This part of the thesis contains an exposition on the structure of animal walking and a description

of the algorithms derived for machine walking from animal walking algorithms. It also surveys

previous machine walking work. The importance of decentralized control is emphasized and the

techniques by which decentralized control is able to achieve coordinated motion are described.

Animal walking 7

The Centipede _s happy quite,Until the 7bad infun

,TaM"Prav which leg goes after which?'And worked her mind to such apitch,

She lay distracted in the ditchConsidering how to run.--- Mrs Edmund Craster

Chapter 2

Animal walking

The original purpose of the research described in this dissertation was to devise programs to make tile

SSA walking machine walk. Studying tile research on insect walking led me to the hypothesis that

decentralized control algorithms would be effective and computational!y efficient for programming

the SSA machine. This chapter contains a review of animal locomotion research with an emphasis on

control.

The physiology and zoology literature suggested three principles that proved to be extremely

effective guides for control strategies for machine locomotion. The first important concept, discussed

in section 2.11is that animal walking control exhibits a great deal of hierarchical structure and locality

of control. This is true both of insects and of higher animals. The second important concept is that

the fundamental behavior of an individual leg in walking is extremely repetitive. This suggested that

the control of individual legs is extremely simple. The third key idea, elaborated in section 2.2 was

that gaits are the consequence of simple interactions of low level behaviors.

2.1. Locality of control

A substantial body of research in neurophysiology suggests that there is a great deal of locality of

control in both insect and mammalian walking. Evidence for this hypothesis is gained from

examining the insect nervous system and from experiments with cats and cockroaches. This section

describes some of the more important of these results and their implications.

2.1.1. The insect nervous system

Insects control their walking very economically. In his work on cockroaches, Hoyle [21] notes that

they have approximately 105 neurons. Cockroaches are certainly an existence proof that real time

walking with a simple control system is achievable. The only question is whether, since neurons are

much more sophisticated than transistors, the mere paucity of neurons is important.


Insects like ants and cockroaches have nervous systems that are comparatively distributed, as

illustrated in figure 2-1. There is a ganglion, a small collection of neurons, associated with each leg

dlat is nearly as complex as the brain, or supraoesophogeal ganglion, located at the head. The

interconnections m the cockroach nervous system are not so rich as those in our brains. While there

is communication between the ganglia of adjacent segments and across each segment between the

ganglia associated with die legs on each side, there is little, if any, direct communication between the

head ganglion and the leg ganglia.

Leg 6 Leg 5 Leg 4

__( -- ( --Head<

() (Leg 1 Leg 2. Leg 3

Figure 2-1: A schematic view of part of the nervous system of an insect. Insects evolved from segmented wonns and theiranatomy shows considerable segmental structure. 1,5_chsegment has two ganglia, or clusters of nerves, one oneach side of the segment, represenled by eirc!es in the figure. 1Lach _,anglion is connected to its sibling ganglionin the _me segment and to the correslwmding ganglia in the adjacent segments. Ihch pair of legs is attachedto a singie segment with the three leg bearing segments adjacent llais figure shows the six ganglia and theirinterconnections from the three leg bearing segments of an insect.

This structure and the limited amount of connection between any possible global controller and the

legs suggests that the control of insect walking is distributed in nature. This turns out to be true both

for insects and for higher animals. The evidence for this conclusion comes from the results of

experiments with cats and with insects.

2.1.2. Insect experiments

The first evidence that walking behavior in insects is under local control is demonstrated when the

brain, prime candidate for the origin of central control, is removed. Physiologists studying insect

locomotion have long known that both brainless and headless insects could exhibit comparatively

normal walking behavior [48].

More compelling evidence for locality of control came from experiments in which all

communication was severed between the ganglion controlling an individual leg and the rest of the

animal. Such experiments were conducted and reported by Pringle and others [51, 52]. These

Animal walking 9

experiments showed that a great deal of the control for each leg might be physically associated with

that leg. When provided with appropriate stimulation, an isolated leg could go 01rough all the

motions of walking. In addition research showed that in intact animals stimulation of the sensors of

one leg had no effect on the behavior of the other legs.

The fact that the control is probably local does not mean that there is no input from the brain at all.

There is a definite input fi'om the brain, providing the direction that enables the animal to move

puq),)sefull;_,about its way, seeking food and so on. rl'he controi input is primarily a rhythm or rate

signal [49] that governs how fast the muscles move. In addition, information derived from the sensors

in the legs is sent to the brain and used by it in generating the rhythm. A plausible interpretation of

these results is that the details of control of"each leg are local to the leg and that the higher levels of

the nervous system can perturb the behavior of the individual legs, making them move faster or

slower as the terrain dictates.

2.1.3. The spinal cat

Studies of the walking behavior of cats provide evidence that control of walking was also localized.

In the spinal cat experiments, in which the connection between the brain and the spinal cord is

severed surgically and the body of the cat is suspended over a treadmill [37, 38, 12], it was found that

these cats exhibited apparently normal walking movements when the treadmill was run, with a wide

range of gaits achievable. Similar experiments in which the spinal cord was severed lower down,

isolating only the rear legs, produced the same results. Grillner's work [12] also r)rovided evidence

that there were separate networks of control neurons for each side of the animal, thus showing that a

great deal of the control of walking behavior was associated with the individual legs.

2.1.4. Reflexes versus patterns

At the same time as this understanding of the distribution of the control of walking and other such

processes was being developed in the neurophysiology community, a debate was raging over how

these behaviors were expressed in the nervous system. Two opposing views stimulated the debate.

One view was that the details of complex behaviors were the consequences of complete patterns of

motion that were programmed into the nervous system, while still local to the limb being controlled.

The opposing view held that complex behaviors were the result of interactions of reflexes. Reflexes

are simple nervous mechanisms involving one sensory neuron to make a decision and one motor

neuron to act on the decision. In other words, the issue was whether the atomic units of animal

behavior were complete motions or reflexes. The conclusion of this debate, summarized by Pringle

[52], is that neither provided a complete explanation by itself.


Both approaches have attractive features as models for understanding how neural systems produce

behavior. If walking is the consequence of complete motions, then it is much easier to see how phase

coordination of multiple legs is possible. On the other hand, it is more difficult to see how to adapt to

details of the terrain when walking is composed of complete motions. This state of affairs is reversed

when the model is based on reflexes. The consensus that evolved was that aspects of both models are

important to the control of locomotion and that neither was completely correct by itself.

One way of describing the resolution of the reflex versus pattern debate is to say that the overall

sequencing of a leg's behavior is governed by a simple finite state machine, corresponding to the

programming of complete motions, and that the inputs that drive the transitions fiom state to state

are derived from sensory stimuli and sometimes from time-outs that prevent deadlocks. Thus, the

overall structure of the leg's behavior is determined by something that behaves like a state machine,

but the details of motion, for example about how far down the tbot is put, can adapt to details of the

terrain.

2.2. Rear-to-front waves

Locality of control is not sufficient by itself to generate walking. Some orchestration of the

indi,idual leg behaviors is obviously necessary. This section describes the coordination and

orchestration in insect walking. Walking behavior in all segmented animals, from myriapods up

through insects, is characterized by the presence of rear-to-front waves of recoveries. For example, in

hexapod walking, a rear leg is recovered, then the middle leg in front of it is recovered, and finally the

front leg is "ecovered. This property of insect walking was first remarked upon in print in 1680 [4].

The apparent complexity of insect walking behavior has stimulated considerable research in the last

half century [51, 11, 52, 22, 23, 53, 49]. Recently workers have advanced some sophisticated

theoretical models that provide simple descriptions of most observed insect walking patterns. The

two definitive descriptive models are In papers by Hughes [24] and by Wilson [61]. To illustrate the

simplicity and power of these models, here is the model put forth by Wilson, which is slightly more

concise than, though substantially the same as, that of Hughes.

1. A wave of recoveries runs from rear to front (and no leg recovers until the one behind is

placed in a supporting position).

2. Contralateral legs of the same segment alternate in phase.

3. Recovery time is constant.

Animal walking 11

4. Frequency varies (drive time decreases as frequency increases).

5. The intervals between steps of the hindleg and the middle leg and between the middle legand foreleg are conslant, while the interval between the foreleg and hindleg steps variesinversely with frequency.

The most important conclusion is that the primitive element fi'om which insect walking is

composed is a rear-to-front wave of recoveries. This wave is of constant duration, because of rules

three and five, and the variation ill step time with walking speed comes during the drive phase, as

stated in rule four. Rule two means that the phase relationship between the two sides is fixed at 180

degrees. "Fileway in which all the varied gaits that have been observed in insects are produced is

rather elegant; they are tile consequence of the relationships specified in the model, relationships that

can be enforced by simple interactions. The only parameter is the drive time, which varies inversely

with the speed of walking. This model, and the similar mode! by Hughes, provides a simple and

unified picture of the primary structure of insect walking that agrees with observed walking behavior

and with current understanding of the neural processes underlying that behavior.

Figures 2-2 through 2-7 illustrate some of the different gaits that can be described by this model.

In these figures the horizontal lines are time histories of individual legs, in which a bold black

segment indicates that the leg in question is recovering during that int.erval., while a light dashed

segment indicates that the leg is on the ground and driving. In the first few figures, the waves of

recovery that are the building blocks of insect walking are easily visible. At the higher speeds the

waves become less and less obvious.

left rear

left middle _ -left front _ ....

right rear

right middleright front

Figure 2-2: Timing diagram for a very' slow insect gait. The rear-to-front waves of recoveries are easily visible. Only oneleg is ever recovered at a time. Time increases to the right and the bold black segments indicate the recoveries.Adapted from Wilson [61].

This observation that rear-to-front recovery waves are the atomic components of insect walking

behavior raises the question of why such patterns might evolve. Might front-to-rear recovery waves

have served equally well? There are two advantages of rear-to-front waves over front-to-rear ones.

The first advantage is that a particularly efficient foot placement strategy, called follow-the-leader, is

12 Controlof Walking

left rear _left middle _- ,_left front _ ] __ _

right rear -- -- _ __ __ I_right middle -- -- _ _right front

FiRure 2-3: A faster gait. In this one lhe drive time has been reduced to the point at which the front leg o_] one side L,;recovered at the _me time as th,2rear leg on the other side Adap'ed from Wilson [61].

left rear ----- -..........left middle --- --_ _-- __ _left front

right rear -- _ ------ _ --_right middleright front _ _ -

Figure 2-4: A further reduction of the drive time. This illustrates that the recover-drive boundaries need not be

syncllronous between the two sides. Adapted l'_om Wilson [61].

left rear _ _ ....left middle _ _ .....left front _ _

right rear _ _ _-- -right middle _ _ _ _ -right front _ -_ iiiii i

Figure 2-5: It is getting more difficult to identify the waves of recoveries in this gait. Other features of this pattern seemmore compelling. Adapted fiom Wilsoa [61l].

left rear _i,.,,,.. _ _left middle _ _ _ _ --_, -left front _ _ _ __ _ -

right rear _ _ _ _ -right middleright front _ _ _ -

Figure 2-6: "Ihe well known alternating tripods gait. Adapted from Wilson [61].

possiblewithrear-to-frontwaves.Thesecondadvantageis that thebase of mechanicalsupportand

hencethestancestabilityisbetterwithrear-to-frontthanwithfront-to-rear.

Animal walking 13

left rear ---_nwJ_ _ - ,, ---mim_-- m__ _

left middle _--- --_--- --_-- _ _

left front -- -man _ _ _ -- _ -

right rear _ -- _ -- amiD-

right middle , ,i,in 7, _ ____ ___m _

right front _-- _--- _--

l;igure 2-7: A further reduction of drive time. I)rive time is now almost the sarapeas recovery time and the gait seems to becon_posed of front-to-rear waves of overlapping recoveries. Adapted fiom Wilson [61].

Some insects, when placing a rearward leg on the ground, place the foot right at the foot position of

die leg in front of it. This is called a follow-the-leader fbot placement strategy. Follow-the-leader is

not achievable with front-to-rear recovery waves. Follow-the-leader is desirable because the insect

nervous system is so simple that it is unlikely that it can memorize a map of the nearby terrain.

Given that the terrain is not sufficiently smooth to ignore and that the insect doesn't know What the

details of the terrain are, how does it decide the best places to put its feet? It does have a little

information about the terrain, since the fizetthat are sec_rely on the ground are known to be in good

places. What it does, then, is use the front legs, where the maximum amount of sensory apparatus is

located anyway, to pick out the best footholds and then it passes these footholds back to the rearward

feet. So when the middle leg is put dt_wn in the second stride, it is placed as near as possible to the

footprint of the front leg from the first stride and, similarly, this good spot of terrain is used by the

rear leg in the third stride. Thus, a set of good foot positions is preserved with the minimum mnount

of work by the nervous system. The most that the animal has to be able to do is be able to place one

leg near another, something the sensory apparatus of insects can do. Only some insects exhibit this

follow-the-leader pattern of foot placement, but it is strong testimony to the economy of the

evolutionary process that all do exhibit rear-to-front waves.

The experimental support for the follow-the-leader explanation is somewhat equivocal and it is

worth emphasizing the other advantage of rear-to-front waves. With a rear-to-front strategy the base

of support for the animal is larger than with a front-to-rear, thus increasing its margin of stability,

because when a rear leg is recovered the front leg on the same side is still in the early part of its drive.

By contrast, in a front-to-rear strategy the recovery of the rear leg comes during a later part of drive of

the front leg so that the support is closer to the center of gravity and hence the stability is less. _Ilae

contrast between the two strategies is illustrated in figure 2-8.

Rear-to-front waves can also describe the walking of quadrupeds. In fact many quadrupeds exhibit


Front Front

Middle Middle

Rear Rear

Rear-to-front Front-to-rear

Figure 2-8: illustration of the advantage of a rear-to-front strategy over a front-to-rear strategy. I'_tch pie wedge representsthe drive phase of one leg. The foot travels down the curved arc from top to bottom, with the hip joint at thepoint of the wedge. Each labeled region within the wedges, two per wedge, is named with the initial letter ofthe name of the leg that is recovering while that leg is moving over that portior, of its drive stroke. Forexample, the middle and rear legs are much farther apart during the recovery of the front leg aaqdthus providemuch more stable support with the rear-to-front strategy than with the front-to-rear strategy. The left group ofpie wedges illustrates the rear-to-front strategy and the fight group shows the fiont-to-rear strategy. Thisillustration is computed for the gait of figure 2-4.

*,.hefollow-the-leader strategy fairly clearly. Cats, when walking slowly, place their rear feet as closely

as possible to the positions of the front feet. Casual observations by the attthor show that e'_en when

an animal is galloping the successive pairs of footprints are remarkably close together, indicating that

this strategy is never completely abandoned.

Animal walking 115

2.3. Why insect gaits are not discrete

Early work on quadruped walking [43] identified a small number of discrete gaits. The work of

Hughes [24] and of Wilson [61] shows that insect gaits, instead of being a discrete set, are actually a

continuum parameterized by speed. ]'hat is, there is a distinct gait corresponding to every possible

speed between the slowest walk and the animal's maximum speed. The question is why are insect

gaits continuous and quadruped gaits discrete? The hypothesis that I favor is that gaits are

continuous for both insects and quadrupeds such as horses and that the source of the apparent

discreteness of gaits is that the animal's motions at certain speeds excite resonances in the mechanical

system composed of its skeleton and muscles and tendons. The symmetries in the system result in

symmetries in the Icsonances and hence to the symmetries in tlte observed gaits. The animal prefers

to move at the speeds corresponding to these resonances perhaps because they result in minimum

stress in the skeleton and hence in minimum discomfort. The importance of these resonant effects is

greater in the walking behavior of larger animals because of scale differences that make dynamic

effects more important, thus horses exhibit a limited number of apparently discrete gaits while

cockroaches do not. I have not seen this hypothesis in the literature, though recent work on scaling

rules in animal skeletons [7, 1, 35] and in the dynamics of running [36] show that while inertial effects,

like these resonances, are negligible in insects, they are quite significant for larger animals.

2.4. Summary

Most of us have an almost religious conviction that behavior is centrally controlled. This belief is

probably due to our awareness that the bulk of the vertebrate nervous system is concentrated in a

single central organ, the brain. This structure is not present in invertebrates. The research surveyed

in this chapter provides arguments that insect walking depends on distributed local control. The

contribution of the survey of animal walking research to my work on machine locomotion is the

devclopment of the hypothesis that deccntralizcd control algorithms were feasible and likely to be

computationally efficient. This helped focus the design of the walking progrmn, described in

Chapter 5.

Insects achieve walking with a remarkably small nervous system. There is evidence that the control

of walking is partitioned hierarchically, with most fine details associated locally with the individual

legs. The local control is quite simple and the interactions between individual legs are quite simple as

well. This evidence suggests that walking control using strategies based on insect walking is plausible

and might bc more computationally efficient than the global strategies adopted by other researchers.


System: Cock roach MC68000

Devices: 105 106

Interconnections/device: 104 1

Decisions/scc/device: 103 107

Connections x l)ccisions/sec: 1012 1013

Steps / sec: 10 1

Throughput / step: 10ll 1013Figure 2-9: Comparison of the cockroach nervous system with a mic"ocomputcr All numbers are approximate.

The following rough aigument shows that it was plausible to attempt to control the walking

machine with a MC68000 microcomputer, the processor dlat was provided with the SSA walking

machine. A MC68000 with 512K bytes of RAM has on the order of one million transistors, while a

cockroach has one tenth that many neurons. On the other hand, each neuron may communicate with

as many as ten thousand other neurons while each transistor communicates with fewer than ten

others. So far tile computer is losing badly, but i',is in speed that the balance is redressed. A neuron

can make only about a thousand decisions per second v_hilea transistor can make ten million. If we

multiply all of these numbers together we get an estimate of the amount of throughput that each

system has. The important point is that while the neuron can make only one ten-thousandth as many

decisions per second as a transistor, it considers ten thousand times as much information while doing

so. To make the cockroach's achievement look even better, the cockroach takes 20 to 30 steps per

second at full speed, while the SSA walking machine's limit is about one per second. This

comparison is summmarized in figure 2-9. While these numbers are subject to a great deal of

criticism, the)' did suggest that it might be possible to emulate the walking control algorithms of an

insect in real time. There was certainly no disparity of a factor of, say, 106 in throughput that would

have indicated that the attempt was hopeless.

Other walking work 17

The dwarf seesfarther than the giant, whenhe has the giant _ shoulder to mount on.

--- Samuel "£ Coleridge

Chapter 3

Other walking work

This thesis is not the first research on walking mechanisms. The hope that walking machines might

provide off-road and difficult terrain mobility superior to that of wheeled vehicles has led quite a few

different groups of researchers to study machine walking. A wheeled vehicle cannot deal with

obstacles much larger than half the radius of its wheels. This is also true of tracked vehicles if you

realize that each track is a virtual wheel with radius approximately tile length of the vehicle. In

addition to that limitation, the path that a wheeled vehicle travels must be completely free of

obstructions for approximately the fifll width of the vehicle. A walking vehicle, on the other hand,

does not need a path that is anywhere near so well prepared [55]. This chapter surveys some of the

more important of such efforts to study walking.

Static and dynamic stability distinguishes the two types of walking machines that have been the the

subjects of recent research. Statically stable systems keep fi'om Pallingdown by being careful never to

get in a situation where falling is possible while dynamically stable systems keep fi'om falling down by

balancing. Statically stable machines have at least four legs and sometimes as many as eight, though

more usually six, while dynamically stable ones have from one to four legs. The key discriminator is

the use of balance in the control of body attitude by dynamically stable machines. It turns out that

insects and myriapods and other many-legged creatures all walk with statically stable gaits. Higher

animals like horses, cats, and people, all walk with dynamically stable gaits.

Two different approaches to control have been taken, closed loop and open loop. Closed loop

control relies on feeding back information about the state of the machine in servo loops, while open

loop control requires that all important information about the interaction of the machine with its

environment be computed beforehand from knowledge about the environment and about the

machine. Closed loop systems are able to adapt to the unexpected but they require a lot &expensive

sensing equipment to achieve this. Open loop systems rely on accurate information about the world

and require good models of the interaction between the system and the world if accurate planning is

to be achieved.


Since this thesis describes nay research into the control of walking, this survey will focus primarily

on the control strategies adopted by other researchers, though that may not have been the objective

of the researchers in some of tile projects. Although the SSA walking machine was designed to be

statically stable, this chapter surveys both statically and dynamically stable walking research.

3.1. Static stability

There ha_e been several projects directed at building statically stable walking machines over the

course of the last twenty or so years. If we include some of the large offshore oil drilling platforms

that move themselves by means of 'legs' or the large draglines used in strip mining, some of which

move in a similar fashion, then we can see that this field has very wide scope. The main attraction of

a statically stable walking machine is that it is safe with the power or the control computer turned off.

Ifsornething fails, one has a piece of statuary, not a piece of wreckage. For this reason, static stability

is a very attractive subject of research when there is no clear picture of what a good solution to the

control problem looks like. Early walking machine research in the modern era began with small

machines and relied on static stability.

Probably the first such machine to be controlled by computer was a fi_ur-legged statically stable one

constructed by Frank and McGhee at USC in 1966 I31]. Their approach to the contr,)l of walking in

this project was to build a hardwircd finite state machine that produced two distinct gaits. One was a

crawl, similar to the quadruped animal walk described in Mtlybridge [43] and analyzed further by

Hildebrand in [18]. The other gait was similar to a trot, with alternate diagonal pairs of legs being

used. Because there was inadequate support with this gait, the machine's feet were made large so that

it could remain stable with only two feet on the ground. The control strategy was completely open

loop; there was no load or terrain sensing and no ability to adapt to terrain variation.

By the mid 1979s researchcIs had progressed to the point that more ambitious mechanical designs

could be attempted. At Ohio State University McGhee built a small machine with six electrically

actuated legs [32]. Each leg had three degrees of freedom and was actuated by electric drill motors.

The approacil to the control of the machine's walking taken in this project was computationally

expensive. Its control strategy is centralized and open loop, with planning and modeling based on

mathematical programming methods [33]. The control progr,'un requires detailed information about

the terrain, from which it computes a plan fbr a path. This computation is expensive because it

requires detailed knowledge about the kinematics of the machine and considers a combinatoriaUy

large set of possible leg motion sequences. With the path plan and information about the machine


kinematics a schedule of motor torqucs is computed. This schedule can then be 'played back' to

make the machine walk. More recent work with the machine [34] has produced algorithms, still

centralized and requiring a terrain map, that select leg motion sequences with a simpler and less

global strategy. The most recent work [47] with the OSU machine involves algorithms that use the

follow-the-leader strategies of some insects, with foot placement controlled by an operator using a

laser to designate candidate footfalls. All of these programs rely on centr_dized control and the

provision of terrain inform_ltion, though the more recent work requires less in formation and planning

computation than the earlier work did.

Another small four legged machine, but with closed loop control, was designed and constructed by

Hirose [19] in 1980 in Japan. This machine's legs wcre pantographs with three degrees of freedom

driven from lead screws by DC scrvo motors. There were contact sensors on each foot to detect the

details of the terrain. The researchers produced a very impressive motion picture of the machine

climbing up and down stairs and over a variety of obstacles. A similar machine is described by

Taguchi et al. [59], though their report focuses mostly on analysis of gait suability and makes no

mention of sensory feedback or of how such analysis might be used in closed loop control.

Kessis has constructed a similar six legged machine in France and it is the subject of continuing

research [30]. This machine has six legs with two controlled degrees of fi'eedom each. The problem

of permitting the feet to move in the direction of the third degree of freedom in order to permit

turning is handled by making the lower legs thin and flexible and letting them bend to comply with

the terrain. Control is open loop, with the approach taken to gait control based on the analysis

performed by Bcssonov [2].

Workers in the Soviet Union have also constructed a six legged machine and have been active in

related research [2, 8]. This research is also highly analytical, with an emphasis on the kinematics of

gaits and their combinatorial analysis [3]. The most recent reports on this machine describe its legs as

having three controlled degrees of freedom plus three passive degrees of freedom at the foot. Servo

systems provide closed loop control for the joint positions and three-axis force sensors located at each

leg are also used. Other researchers in the Soviet Union have reported on some interesting work that

attempts to permit the nondeterminism that terrain adaptation requires [44].

In the last year Odctics Inc. has constructed an interesting six legged machine in California. Their

machine's legs are actuated through lead screws by small powerful electric motors and it is controlled

by seven on-board microprocessors. There is no capability provided for sensing of leg positions or


forces, so adapting to terrain is difficult. This machine demonstrates that one can construct a free

roving walking machine that is electrically actuated. Since such machines arc easier to control than

hydraulically actuated ones, this is encouraging for further work on statically stable walking

machines.

3.2. Dynamic stability

Fewer dynamically stable walking machines have been attempted than statically stable ones. A

dynamically stable system is one in which active machine behavior preserves balance under

circumstances in which the machine might otherwise fall down. This is by its very nature a closed

loop control problem. The problem of controlling a dynamic system is much harder than that of

controlling a static one for two reasons. First of all, the mechanical system must be capable of

responding fast enough to maintain balance. In the case of a statically stable machine, if some

component proves too slow, one can simply slow down the operation of the entire machine until the

bottleneck component is no longer a problem. For a dynamically stable system, however, this is not

possible since every component inust be able to deliver a minimum level of performance determined,

at root, by gravity. There is no easy way to correct for inadequacies in individual components short

of changing the acceleration due to gravit3, a probleln whose difficulty is quite well known 2 . The

second reason that dynamically stable walking systems are hard_:r to control is that debugging is

much more difficult because there is the chance that an error could result in destruction of or damage

to the machine.

The first dynamically stable walking machine was the four legged walking truck constructed at GE

by Ralph Mosher's group during the 1960s [40, 41]. This machine was not computer controlled but

rather was operated by a human driver. An extremely clever system of hydraulic servos that fed a

portion of the forces on the limbs of the machine back to the controls made it possible for a human

operator to manipulate the tour legs and make the machine walk. The human opcrator provided the

necessary sensing and closed loop control. The performance of the machine was quite impressive,

but the demands on the human operator were so high that serious fatigue made operation for longer

than fiftcen minutes at a time impossible. Mosher's conclusion was that some fonn of automated

control was needed but that portable computers powerful enough for the task were not available at

the time.

2Raibert's two dimensional hopping machine could do this because it hopped, initially, on an inclined table. The tilt of thetable could be used to change the effective acceleration due to gravity, though this turned out to be unnecessary.


Various other dynamic and pseudo-dynamic machines have been constructed in the US and

abroad. One of the most prominent is Raibert's single legged hopping machine here at CMU [54]. It

is particularly interesting because the control strategies emphasize decomposition of the task into

several parameters that can be controlled ahnost independently. The result is that the control

programs can be quite a bit simpler than consideration of the task as a whole might suggest.

Miura and Shimayama[39] designed and built a small biped that walks with a truly dynamic

strategy. It oscillates rapidly back and forth from one foot to the other and moves forward with a

motion that can be described as a "Charlie Chaplin" shuffle. Kato et. al. [27] have constructed a

biped, walking machine that uses a quasidynamic strategy. Each step of the machine is composed of a

dynamic transition from one static state to the next, with the machine statically stable while standing

on one or ff_eother of its large fiat feet. The machine is capable of walking on smooth level terrain

under the control of a 16 bit micr{momputer.

3.3. Summary

The previous approaches to control of walking machines have been more computationally

expensive than necessa_'y. The control _lgorithms developed by previous workers in walking machine

locomotion are generally centralized, open loop, and pseudo-optimal [33], :'equiring a great deal of

information about the terrain and about the machine to produce a detailed plan for motion. The

storage and computational requirements for the terrain map and for the linear programming steps are

sufficiently large that the feasibility of achieving this in real time with a contemporary portable

machine is questionable.

While there has been a considerable amount of walking machine research reported, few of the

reports give much emphasis to the control software used to make the machines function. What little

information is presented indicates that most of the control is centralized and some of it is off line,

requiring precomputation of plans because the algorithms are too expensive to compute in real time.

With the exception of some of the dynamic stability work, most of the control strategies have been

open loop.


Figure 4-1: A photograph of the author riding the walking machinc. Courtesy of the Smithsonian Magazine.

SSA walking machine 23

A human being; an ingenious assemblage ofportable plumbing.--- Christopher Morley

Chapter 4

SSA walking machine

One objective of this research was m produce control programs for the SSA walking machine. This

chapter contains a description of the machine and of its particular properties that made the walking

task tractable. The first section gives a brief description of the machine's physical attributes. The

second section describes the natural motions provided by the legs of the machine. The third section

describes the hnportant features of the control electronics. The fourth section is a short tutorial on

hydraulics. A more detailed description of the machine is given by Sutherland [58].

4.11.Mechanical overview

This section is intended mostly to give an appreciation for the massiveness of the machine. It is

large and heavy and the actuators that move it are very powerful. A consequence ot"this is that the

machine is hazardous. This danger was an important consideration in the design of the control

strategies and in the programming philosophy that is described in Chapters 5, 6, and 7. Our concern

for safety was rewarded: there were no injuries m researchers or bystanders, though we were quite

perturbed on one occasion when a young parent tried to pose her toddler between two legs of the

machine while we had it powered up.

The SSA walking machine is a six legged steel mechanism that weighs 1800 pounds, figure 4-1. Its

100-inch long steel frame is the mounting platform for an 18 horsepower Briggs and Su'atton gasoline

engine designed for service in lawn tractors, for four hydraulic pumps, for the six legs, for the 38

hydraulic valves used to control the machine's motion, and for a seat for a human driver. The

mechanical output of the engine is transferred to the shafts of four Sundstrand variable displacement

hydraulic pumps. Two pumps provide drive, moving loaded legs in the fore-aft direction. Of the

other two pumps, one powers the unloaded recovery motions and the other powers the side-to-side

motions of the knee joints. Each leg is a hydraulically actuated manipulator with three degrees of

freedom. For each leg, six hydraulic spool valves control the flow of oil to three hydraulic cylinders.

Three different types of hydraulic circuits are used for the legs. First, all legs that are moving upward


are connected in hydraulic parallel, as are those moving downward. Second, legs oil the same side of

the machine driving forward or backward are connected in series to one of the two drive pumps.

Hnally, tile lower cylindcrs on each side can be connected in a series-parallel arrangement so that

all on one side are in parallel together and the two sides are in series in such a way that motion of one

side results in compensating motion by the other side. The hydraulic circuits are described in

considerable further detail by Sutherland [58]. The hydraulic valves are controlled by a pair of

Motorola MC68000 microcomputers, while the displacements of the four pumps are controlled by

the human operator who sits on a chair mounted on the frame. This machine differs from previous

six legged machines in two important respects, its size and the matching of the natural motions of its

legs to tile natural motions of walking.

___[- I

! TopV,ew //

Knee

Hip Hydraulic cylinders \Side View

[ _

I

i ,Front View

Foot _ -.. ,-.

Figure 4-1: Three views of a leg from the v,,alking machine, qllese projections illustrate the major mechanical features ofthe leg. l'here are three hydraulic cylinders, a pair that controls the motion of the upper segment about theuniversal joint and a single cylinder that moves the lower segment in and out about the knee joint.

Figure 4-1 shows a leg of the walking machine. The piston diameter of the hydraulic cylinders is 1.5

inches and the shaft diameter is 0.625 inch. Each upper cylinder is single ended, that is, the shaR


emerges from one end of the cylinder and the other end is closed. The lower cylinder is double

cnded, with tlle shaft emerging from both ends of the cylinder.

\ /

Figure 4-2: "lhe hydraulic ellipse, qhis illuslratcs the connection of the cylinders in the Energize valve setting. A quantitya ofoil entering at the left moves the left shall up by a distance d, transferring a quantity ,8 ()foil to the top ofthe righ'_cylinder, lhis forces the right shall down by the same distance d and expels the original quantity aof oil from ,,_helower right. Since the two cyliF,ders arc anchored to fl,,c liame of the machine zt the tops, thetotal length of acttmtor between the two anchoring points remains constant, tlcnce the intersection of the twoshafts at the bottom traces out an ellipse.

The most imporLant natural motion for walking is the drive stroke, in which a loaded leg is moved

rearward. The natural motion here is a straight line stroke of the leg parallel to the desired motion of

the center of gravity of the machine. By a particular connection of the cylinders of the upper leg,

illustrated in figure 4-2, it is possible to provide this natural motion. In this connection, the upper

ports of the two cylinders are connected together and the lower ports are connected to a drive pump.

When quantity of oil ot is driven into the lower port of one cylinder, the shaft is pushed up some

distance d. An amount of oil ,8 is driven out of the upper port of the cylinder and into the upper port

of the other cylinder, driving the shaft of that cylinder down the same distance d, forcing a oil out of

the lower port of the other cylinder. Since one actuator extends by d and the other retracts by d, the

total shaft distance between the clevis joints anchoring the two cylinders to the frame remains

constant, so the locus of points traced out by the intersection between the two upper cylinders is an

ellipse. The intersection is also constraincd by the universal joint at the hip to move on the surface of

a sphere. The resulting motion is almost perfectly horizontal.

The only defect in this motion is that while it isflat, it is not straight: it is actually the arc of a circle


centered on the vertical line through the hip joint. Since the desired motion of the machine is straight

line, there is a problem. This problem is corrected by permitting the lower legs to move so that the

boundary conditions established on the ground and at the knee can both be satisfied. A passive

connection between all of file loaded legs permits the motion of legs on one side to be compensated

for by the corresponding motion of other legs on the other side of the machine. This compensation is

not exact, but it makes the error negligible.

There are two important benefits from this mechanical design. The first is the good match between

the natural motions of the leg and of walking that motivated the design. The second important

benefit of this design is energy efficiency. The oil in the tops of the cylinders is under pressure from

bearing the weight of the machine, but the oil in the bottoms of the cylinders is not. Thus, driving oil

in at the low pressure end of the system results in less energy being required to move a loaded leg

than would be required if the two cylinders were controlled independently and the pump had to

drive oil from atmospheric pressure into the loaded end of the cylinder. Robotics researchers have

recently commented on the importance of a good match between the machine and task natural

motions [60].

A 12 Volt car battery on board the machine runs the starter for the engine and supplies power for

the solenoids that drive the spool valves. ,^,.nalternator driven by the engine provides recharging for

the battery, but the solenoids draw so much current that during walking there is a net 15 ampere

drain on the battery. The computer is powered by 60 Hertz line current provided either by an on

board inverter or by an umbilical.

4.2. Valve settings

Each leg is controlled by six valves. The two hip cylinders are controlled by four of these valves

and the knee cylinder is controlled by the other two. Section 4.4 contains a short tutorial on

hydraulic systems. Since each valve has three settings, the number of possible combinations is quite

large. A limited subset of the possible combinations is actually useful. This section describes these

useful settings, which number twelve in all.


4.2.1. tlip control

The natural motions of the hip joint, described in this section, are consequences of moving the

hydraulic cylinders in or out or holding them. Figure 4-3 is a table summarizing the various settings

available. A '+' in a position means that the cylinder is being lengthened, a '-' means that it is

being shortened, and a '0' means that it is not inoving. The motion named Lift shortens both

cylinders at the same time, moving the leg up. The motion named Place lengthens both cylinders,

moving the leg dewn. The motion named Ui: leaves the engine end cylinder fixed and shortens the

driver end cylinder, moving the foot upward and toward the driver's end. The motion named Down

leaves the driver end cylinder fixed and lengthens the engine end cylinder, moving the foot

downwa_'d and toward the driver's end. The name or names for each combination are noted in the

table as well. When there are two settings with the same name with one capitalized and the other not,

as in "Lift and lift", it means that both settings achieve the same motion but with slightly different

internal connections. The connections named with small letters all have the property that they can

cause the machine to develop negative pressures internally, and hence they are not used in the

walking program described in Chapter 5. One consequence of this is that the machine could only

walk in one direction, a direction that had the driver riding backwards. A different program, also

described briefly in Chapter 5, did use the small letter settings and was able to walk in the other

direction. The settings named Coast and Energize are the ones that achieve the special natural

motion that is so important to this machine's ability to walk. Energize is powered by one of the drive

pumps, while in Coast the leg is simply free to move according to the forces on it from the terrain. In

the Energize setting the direction of pumping set by the operator determines which of the two

cylinders lengthens and which shortens. What the Energize and Coast settings really do is ensure that

when one cylinder lengthens, the other shortens by the same amount.

The settings shown in figure 4-3 produce motions of the upper leg about the hip joint that are

illustrated in 4-5. The limits of motion of the hydraulic cylinders define a diamond shaped region on

the surface of the sphere defined by the hip joint, as illustrated in figure 4-4. The motion illustrated

is of the knee joint as viewed from a point to the left of the driver. It is important to note that in the

l.ift and Place settings both cylinders are being driven in parallel, which results in a nondetenninacy

in the motion of dm leg, since the cylinder with less friction will move first.


Engine End Cylinder Driver End Cylinder Pump Name

- - Rcv Lift and lift

- 0 Rcv up

- + Drive Energize and Coast (hydraulic ellipse)

0 - Rcv Up

0 0 Hold

0 + Rcv down

+ - Drive Energize and Coast (hydraulic ellipse)

+ 0 Rcv l)own

+ + Rcv Place and placeFigure 4-3: "Fableshowing all of the hip valve settings that are provided by the walking machine. A '+' indicates that the

cylinder is getting longer, a '-' that it is getting shorter, and a '0' that it is not moving. The settings named withlower case letters can produce negative pressures inside the hydraulic system, so we did not use them. Thehorizontal motion setting could be achieved either with the drive pump connected, the Energize setting, orwith it bypassed, the Coast setting. The pump column shows what pump is involved in the setting: Rcv denotesthe recovery pump and Drive denotes one of the two drive pumps. F_ch side of the machine has its own drivepump that is used to power the Energize setting. The Coast setting is not powered at all.

/

,i

"--- "74

J

JJ

JJ

.JFigure 4-4: The limits of motion for the foot as defined by the hip joint and actuators. The diamond is not actually planar,

as shown here, but lies rather on the surface of the sphere defined by motion about the hip.


Lift Up Down Place

Energize Coast Hold

Figure 4-5: ]'he natural motions of the machine. In Lift and Place the two c_linders are connected in parallel. The legmoves vertically with these settings, but since the coeflicients of friction are different in the two cylinders,exactly how the leg mo_es in the fore-aft direction is not determiued. This pennits the leg to conform to thebounda_, conditions of the ground when loading and unloading, but these settings are not good Ibr longvertical motions. The diamond represents the limits of motion of the foot: it is illustrated in figure 4-4.

4.2.2. Knee Control

There are four useful settings for the valves controlling knee cylinder. There are Right and Left,

that move the foot to the driver's right or left powered by the recovery pump. Crab is a setting that

connects the leg passively to all of the other legs that are iq Crab. Hold is a setting that prevents the

cylinder and hence the knee joint from moving. Right and Left are intended to be used to reposition

the lower leg while the upper leg is being recovered.

The Crab connection is such that when motion of the knee displaces oil from one end of the

cylinder, the displaced oil pushes the knee joints on the other side of the machine in a direction

resisting that motion. In addition, the Crab pump is connected in series with the legs in the crab

setting, thus enabling the machine to drive itself sideways. With this capability, sideways or crabwise

walking is possible, hence the name of this valve setting. Between the compensation provided by the

passive connection in crab and the flexibility of the machine, the mismatch between the knee

boundary condition and the foot boundary condition is accommodated.


4.2.3. Valve Switching time

One of the most serious limitations on walking speed and smoothness in the SSA machine is the

speed of switching of file hydraulic valves. A valve with both solenoids off switching to a setting with

one solenoid on will switch in about 100 milliseconds. A valve with a solenoid on switching to a

setting with both off will switch in about 150 milliseconds. The time for switching flora one solenoid

on to the other solenoid on is not specified, but no such transitions were used in the SSA machine.

To see how significant this is, consider the minimum amount of time it takes for a leg to move from

one end of its stroke to the other in the Energize setting. Each drive pump pumps 54 cubic inches of

oil per second at full displacement. The hydraulic cylinders have a bore of 1.5 inches and a stroke of

6 inches. The shaft diameter is .675 inch, so the amount of oil pumped by the drive pump into the

cylinders during Energize is about 2 cubic inches per inch of motion. Therefore it takes only 250

milliseconds for a full stroke motion at top speed. This isn't much different from the 150 millisecond

switching time of the valves for some of the transitions. The consequence is that precise control of leg

position was hnpossiblc. Experiments with rate prediction in an attempt to anticipate the correct

switching showed that the rates of motion were too variable to produce any significant hnprovement

in position control.

4.3. Control computers

Two microcomputers on board the machine provide control. The first machine is a Motorola

68000 development board with a 4MHz processor and 32K bytes of RAM. This computer is

interfaced to the low level I/O system of the walking machine. It is responsible for scanning the

digitized sensor values, normalizing them, and storing them in a table. It is also responsible for

accepting commands for the valves and sending them out to the control electronics that actually

switch _e valve solenoids. The second machine is a Gruss Multibus 68000 with a 8 MHz processor

and 512K bytes of RAM. 1 designed and constructed a shared memory interface between the two

computers that makes the entire memory of the small machine readable and writable by the large

machine. Each machine is connected to a Digital Equipment Corporation Vax/11-780 by a direct

9600 baud line for downloading of programs and uploading of data. In addition, each machine has a

console terminal for interaction. The walking machine has an umbilical cable containing four RS232

connections: the two host lines and the two console lines. It could operate without these lines, but

the diagnostic value of the consoles and the importance of being able to upload experimental data

drove us to run with the umbilical during the experimental phase, and there was no operational phase

for the machine.


4.4. Hydraulic system

Ivan Sutherland chose hydraulics for the actuation of this machine because he was interested in

learning about them. In addition hydraulic actuators provide a better power-to-weight ratio than

electrical ones for a machine that is this large and that is intended to be self contained. This section is

a brief exposition on the features of hydraulics and hydraulic systems that must be understood to

program the walking machine. A hydraulic system is conlposed of pumps that push the oil around,

cylinders that convert motion of oil into motion of steel rods, w_lves that control the flow of oil

between the pumps and the cylinders, and the plumbing that conducts the oil among the pumps,

cylinders, and valves. Certain constraints on the use of the system are imposed by the pumps, by the

different kinds of hydraulic cylinders, and by the valves.

4.4.1. Pumps

Hydraulic pumps convert mechanical energy from the engine to motion of pressurized oil. A

hydraulic pump has two connections, one that emits oil under pressure when the pump is pumping,

and another through which the pump is supplied with oil to pump. The pumps used in the SSA

walking machine a"e _;ariable displacement types, that is the amount of oil pumped per revolution of

the pump shaft may be varied by moving a control arm connected to a swash plate inside the pump.

The variation is symmetric about zero displacement, so the pump can pump oil both forward and

backward. The two connections or ports to each pump are identical, so that when oil is being

pumped out through one port the other port supplies the pump with oil. The hydraulic pumps are

positive displacement types, which means that the quantity of oil pumped out of one port must

exactly equal the quantity ofoil pumped into the other port.

The restriction that equal quantities of oil flow into and out of the two pmts of each pump is an

important one, since it requires that care be taken in the design of the hydraulic system to ensure that

it presents the pumps with a balanced load. A balanced load is a two port hydraulic system that emits

the same amount ofoil from one port as is pumped into the other. Ifa positive displacement pump is

forced to drive an unbalanced load, the result is a dramatic increase in operating pressure. The

pressure increases until either a relief valve is activated or something gives. The problem with driving

oil through relief valves is heat dissipation. Oil driven through a relief valve represents a lot of work

done, which results from making oil flow across a pressure drop. In hydraulic systems, however, the

fluid heats up, not the relief valve, in contrast with electrical systems where the resistors heat up and

not the electrons. Since the oil used in the hydraulic system can be damaged by excessive heat, it is

important to avoid unbalanced loads and the con,_e.quent heating of the oil. Several of the


components used in the machine do not present a balanced load and some extra mechanism had to

be added to compensate for this.

4.4.2. Cylinders

The cylinders take energy from the flow of oil and convert it back into mechanical energy. Each

cylinder is a hollow tube with holes at one or both ends that admit a steel rod. Attached to the steel

rod is a piston, which is a cylindrical object that fits snugly inside the hollow tube. There are fittings

at each end through which oil can enter and leave.

--]Figure 4-6: Single ended cylinder. Pumping oil into the right port moves the piston to the left, forcing a different quantity

of oil out of the left port.

. l////,/////A

Figure 4-7: Double ended cylinder. Pumping oil into the right port raoves the piston to the left, forcing the same quantityof oil out of the left port.

Two kinds of cylinders are used in the walking machine, single ended and double ended. Single

ended cylinders have steel rods projecting from only one end of the cylinder, while double ended

ones have rods projecting from both ends. Single ended cylinders, figure 4-6, present a problem

when working with positive displacement pumps because when one of these cylinders is moving a

different volume of oil enters at one port than is expelled at the other, the difference being the

volume of shaft that is entering or leaving the cylinder. On the other hand, double ended cylinders,

figure 4-7, while presenting a balanced load require clearance at both ends to provide room for the

shaft.

Since the pumps are positive displacement and demand a balanced load, whereas the upper

cylinders are single ended and present an unbalanced load, there is a problem. Whenever all the legs

in vertical motion are moving in the same direction there is a net imbalance: less oil is being pumped

into the legs than is being returned to the other end of the pump. In order to compensate for this


mismatch, a long single ended cylinder in the system can bc connected up in series with the others in

either the forward or the reverse direction, thus correcting the unbalanced configuration. The

compensator is not always in use because often two or more legs are moving in opposite directions so

that the load is balanced. A limitation on the use of the compensator is that when the machine is

changing the height of its stance it can change the net volume of the hydraulic system by more than

the capacity of the compensator, thus driving the compensator to the end of its travel in one direction

or the other. When this happens the compensator can be driven back toward the center by a special

pair of valve settings.

4.4.3. Valves

T A P B

Valve body

Spool

Figure 4-8: Fartsof a spool ,_alve.

The valves in a hydraulic system are the primary way that the flow of oil in the systemcan be

dynamically altered. Of course, the pump's flow rate can be changed to achieve some control, but

valves permit far greater flexibility. There are several different kinds of hydraulic valves, but since

the SSA walking machine only incorporatcs one kind, spool valves, this section will only describe

them. A spool valve is constructed from three parts, a body, a spool, and two solenoids. Figure

4-8 shows a cross section of a valve body and of a spool. The valve body is a piece of metal with a


I// ,//]/,"/////////////7

V //1

T A P B

Figure 4-9: Spool _alve with left solenoid activated. "lhe lines labeled A and T are connected, as are the lines labeled Band P.

("r ///z/z //

iT A p la

Figure 4-10: Spool valve with right solenoid activated. The lines labeled A and P are connected, as are the lines labeled Band T.

) II

iTI A P B

Figure 4-11: Spool valve with no solenoids activated. All four lines are isolated from one another.

cylindrical hole bored into it. while the spool is a matching cylindrical piece of metal that has been

turned down on a lathe leaving several sections of the original diameter, called lands. The two


solenoids are mounted on opposite ends of the body so that when one has current flowing in it the

spool moves to that end of the body. When no solenoid is turned on a spring returns the spool to a

central position.

There are four connections to the valve, labeled A, B, P, and T. Figure 4-9 shows the configuration

when the left solenoid is activated. In this configuration the line labeled A is connected to T and the

one labeled B is connected to P. Figure 4-10 shows the configuration when the right solenoid is

activated, connecting lines B and :I"together and lines A and P. Finally, figure 4-11 shows the spool

valve when neither solenoid is activated and the spring has returned the spool to the middle position,

blocking all lines.

(

A p B

Figure 4-12: A spool valve _th thin lands in the centerposition. Becauseof the narrow landsall four of the connectionsareconnected together.

Other configurations of spool valvesmay be achieved by altering the width of the lands. Figure

4-].2showsa spool valve with narrower lands in the center position with both solenoidsoff. In this

configuration all four of the lines are connected together. The other two configurations of this valve

have the same properties as the valve shown in figures 4-9 and 4-10. There are other configurations

available, but _e two illustrated here are the only ones used in the SSA walking machine.

Standard notation for these two kinds of spool valves is illusu'ated in figure 4-13. The upper

symbol shows the first valve, with all four lines isolated in the center position, while the lower symbol

shows the valve with the open center.


.._L_k

TT

Figure 4-13: Standard symbols for ;;pool valves. The upper symbol shows a center closed valve and the lower symbolshows a center open valve.

4.5. Summary

This chapter has exhibited the important properties of the walking machine from the point of view

of the programmer. The machine was big and dangerous, so issues of verification and software

reliability were extremely important. In this context, the concept of a fatal error meant more than

just the unexpected termination of a program. Control of the legs was by means of rates of motion

rather than by position. The performance of the hydraulic system severely limited the position

precision that could be achieved with the control system.

Walking Program 37

This code is made for walking ...--- (apologies to) Nancy Sinatra

Chapter 5

Walking Program

This chapter describes the OWL walking program that implements strategies suggested by those

described in Chapter 2. For a description of the OWl. language, see Chapter 7. The first section of

this chapter is a description of tile basic requirements of a walking program. The next section is a

description of the interleg communication mechanisms, called inhibition and exaltation, that are used

to satisfy those requirements. After the section on inhibition and excitation comes a brief description

of the important parts of walking program itself, which is basically the concurrent combination of a

collection of independent and interdependent processes. The processes fall into two groups: the

service processes that are responsible fi)r maintaining various pieces of system state, and the six leg

control processes. There are quite a few service processes because I chose to make each one simple

and devoted to a single task.

5.1. Responsibilities of a walking program

This section presents a simple taxonomy of machine walking to serve as a guide to the explanation

of the walking program. The two most important jobs of a walking program are stance maintenance

and purposeful progress. Stance maintenance requires that the program keep the frame of the

machine reasonably level and prevent it from falling to the ground. If the machine can move from

one place to another, that is make purposeful progress, while maintaining its stance, then it can walk.

The purposeful progress goal has three components: recover-drive cycles, rear-to-front waves, and

left-right phasing. These three components come from the animal walking described in Chapter 2.

The recover-drive cycles are required because legs have finite reach and must be periodically

recovered in order to be reused. The rear-to-front waves and the left-right phasing requirements

result from the choice of animal gaits as the model.

Here is a summary of the highest level responsibilities of the walking program.

• Stance maintenance


• Purposeful progress

o Recover-drive cycles

o Rear-to-front waves

o Left-right phasing

In the rest of this chapter I will show that each of these requirements motivates a specific

independent mechanism. The Row process associated with each leg is responsible for producing the

recover-drive cycles. The inhibition mechanism handles stance maintenance by constraining the Row

processes. The excitation mechanism, which has two parts, achieves the rear-to-front waves and the

left-right phasing, aiso by constraining the Row processes.

5.2. Inhibition and Excitation

Inhibition and excitation are information communicated by each leg to its neighbors. Each leg uses

the inhibition and excitation sent to it by its neighbors to perturb the decision threshold that governs

when the leg makes the transition from the drive phase to the unload phase.

To motivate the development of the inhibition and excitation mechanisms, consider some of the

things learned from the work on animal walking. Experiments with insects described in Chapter

2 showed that each leg of an insect goes through a simple cycle of behavior. When the leg is in

contact with the ground, it is driven rearward and when it reaches the end of its travel and begins to

bear less load, it is removed from the ground and recovered. Once it is as far forward as it can go, it is

pushed toward the ground until it makes contact, at which point the cycle begins all over again. One

of the key parts of the behavior of an individual leg is how it decides that it is free to end its drive

phase and enter the unload and recover phases. Experiments showed that an insect leg in contact

with an experimenter's tweezer would initiate recovery when the load on the leg was reduced and the

leg was at the end of its travel, but would not if the leg was still bearing load even if the leg was quite

extended. The inference drawn from this is that a leg will not unload until it is certain not to leave

the body unsupported.

The configuration of the legs at each moment determines what load is supporting and what load

permits a leg to recover. The walking program uses a mechanism I call inhibition, taking the word

from neurophysiology, to permit each leg to estimate the recovery threshold load. The technique is

for each leg that is unloading or recovering to inhibit its neighbors by subtracting a constant from

their unload decision thresholds. Figure 5-1 illustrates the flow of inhibition among the six legs.

Walking Program 39

Leg 6 Leg 5 Leg 4

Front _ T ; T _ T Rear

Leg 1 Leg 2 Leg 3

Figure 5-1: F3ow of inhibition in the walking program. Each box represents the process controlling a single leg, with thedirection of motion of the machine offto the left.. 'I'h_Js,for examp!e, leg 5 inhibits legs 6, 4, and 2 when raisedand can be inhibited in turn by those three legs. Compare th_s figure to figure 2-1 in Chapter 2.

When a leg is near the end of its travel, its decision to unload and recover is based on comparing the

vertical force on the leg with a threshold. Inhibition decreases this threshold so that the leg must be

more unloaded than usual to be permitted to begin recovery when it is being inhibited by an

unloaded neighbor. Thus, a leg with several neighbors off the ground is unlikely to be sufficiently

unloaded to overcome the ei_cts of the inhibition. The interaction of load and inhibition

discourages the machine from picking up too many legs and hence encourages the machine to

maintain a reasonable stance. With the inhibition kept large the vertical force values from the leg

sensors can be ignored and the machine can simulate walking while suspended on the jack stands in

the lab. With the inhibition kept at a moderate level, a reduction is possible in the machine's

sensitivity to transient changes in load caused by the machine's rigid structure.

Leg 6 Leg 5 Leg 4

I 1, [, I',iFront Rear

[ I- I....iLeg 1 Leg 2 Leg 3

Figure5-2: The flow of excitation signalsintended to produce rear-to-front wavesof excitations.

The inhibition mechanism permits any sequence of leg motions that maintains adequate support

for the machine. It does not, however, ensure the development of rear-to-front waves of leg

recoveries. Rear-to-front waves are encouraged in the walking program by a mechanism I call


excitation that is similar to inhibition. A leg that has finished recovering adds a constant to the

unloaded decision threshold of its fi'o_tward neighbor. When a leg does begin recovering, it removes

the excitation on it. The excitation number is added to the threshold on which die leg decides to end

drive and begin to unload and recover, thus encouraging the leg to initiate recovery sooner, while

bearing more load than otherwise permissible.

Leg 6 Leg 5 Leg 4

Front _g T Rear

I,,1 I ILeg 1 Leg 2 Leg 3

Figure 5-3: Crosswise excitation between the two rear legs. This mechanism was kept distinct from the rear-to-frontexcit_ttionso that the different parts of the walking mechanism could be tested and debugged separately.

As implemented in the walking program, there are two parts to the excitation mechanism. The first

part is the rear to fi,,mt wave excitation ill,strated in figure 5-2. The second part is excitation across

the machine between the two rear legs, illustrated in figure 5-3. Each rear leg excites its crosswise

neighbor when it reaches the hall\ray point in its drive stroke. This serves to encourage the legs to

achieve the relative 180 degree phasing daat is observed in insects. Note that the excitation does not

enforce a particular order of leg motions, it simply encourages the legs to develop a preferred order of

motions.

The interaction of the inhibition and excitation mechanisms comes in the decision to end the drive

phase and go on to the unload phase. This decision is made when the leg has made more than b,alf a

stride and when the vertical force, J'z'satisfies the relation

fz < = fo" inhibition + excitation.

Thus, there are three mechanisms in the program that are directed at three different features of the

required walking behavior.

• Inhibition - encourages good stance

• Rear to front excitation - encourages rear to front waves

• Crosswise excitation - encourages correct side-to-side phase relationship

Walking Program 41

5.3. Walking program structure

The walking program is organized as a main process that first initializes the internals of the

program and then starts up the collection of concurrent processes that develop the actual walking

behavior. During initialization file program offers a menu of parameters that can be customized for

the run. The main concurrence includes processes to keep all of the sensor tables up to date and the

six leg processes. Figure 5-4 illustrates the main components of the walking program. Each

component illustrated is a process and many of" them have numerous subproccsscs. Each leg is

controlled by an instance of the Row process. Row is responsible for the repetitive cycling of"the leg

through the four phases of the step cycle: much as a person moves an oar cyclically through the

phases of rowing. The OWI_ code for the entire program is co_]taincd in appendix A.

I Row(1) Row(6) Sensors

Row(2) I Row(5) [!Trodble

IRow(a) I [_ow(4) CompI t I

I Excite Excite Gather

lOe 0ma°]Control processes Service processes

Figure 5-4: The main elements of the walking program. "Unereare two main groups, the control processesdirectlyresponsible for making decisions ,'rod commanding ac!_ions,and the ser_;iceprocesses responsible for varioushousekeeping chores. The rear-to-front excitation signals mc generated by the individual leg processes. Thetwo processes named Excite handle the cross excitation for the two rear legs.

5.4. Row

Row is the most important single process in the walking program. Each instance of the Row

process is responsible for a single leg. Row takes the leg and moves it around and around in the

fashion illustrated in figure 5-5. The process is composed of several concurrent subprocesses, the

most important of which is the main loop that cycles the leg through the four processes that make up


Lift _ Place<

Energize

Fi_,,ure5-5: Elevation view of the motion of a knee with respect to the frame of the walking machine during walking. Theleg should repetitively Co around the loop illustrated here. Fz_ch segment is labeled with the name of thehydraulic _al_e setting that produces motion in that direction.

the step cycle. Figure 5-6 illustrates the finite state machine that describes the functioning of the Row

process.

Assuming that we start with the leg unloaded, the hip valves are switched to the Place setting.

When the leg has touched the ground and picked up load the load process terminates and the drive

process is initiated. The drive process puts the leg valve in the Energize setting, switching oil from

the appropriate drive pump into the hydraulic circuit fbr that leg. The drive process terminates when

the leg has moved t_r enough backward to constitute a reasonable step and before it moves too close

to its rearward neighbor. When the drive process has termina_,ed the unload process is initiated. This

process simply puts the leg valve in the Lift setting and then terminates when the vertical force on die

leg i_;dicates that it is no longer on the ground. This initiates the recover process. This process takes

the leg and moves it to a target position that is the beginning of the next step. The lower leg is also

recovered during this process, returning the knee joint close to the middle of its travel.

'['he four segments of the step produced by Row are handled by processes named Load, Drive,

Unload, and Recover. Of the four, Recover is the most complex. The main loop of Row starts with

the load process. This has the result that no special mechanical initialization is required. ]he walking

program can take the machine with the legs in any positions and begin walking directly, since the first

tiring that it does is load each leg. The next two sections describe the I.oad and Recover processes.

The Drive and Unload processes are quite simple, so I will let the code exhibited in Appendix

A suffice.

5.4.1. Load

Load is a process that moves its leg downward until the leg is loaded. Figure 5-7 illustrates the test

used to determine when the leg is loaded. The leg's load and position start in the shaded region and

the leg is considered to be loaded when it goes into the unshaded region. When the leg is loaded the

valve is placed in the hold setting and the process terminates. Note that since it takes at least 100

Walking Program 43

done recovering __,

loaded unloaded

,@loaded out of travelexcited

Row

Figure 5-6: Finite state machine simulated by the main subproccss in the Row process. The annotations with the mcsindicate the conditions that trigger the associated transition. The Drive state corresponds to the t'nergizeregion of figure 5-5. Unload corresponds to l.ift, Load corresponds to Place, and P,ecover corresponds to theUp-Down sequence.

milliseconds for the valve to switch from place to hold it is possible that the process after l.oad will

switch the valve to another setting before the valve has actually arrived at the Hold state. The load

threshold was low enough that the machine did not in practice overshoot into the overload area.

Tim parameters loadtok', slancebottom, stancefactor, loadbotlom, and stancetop are used in the

computation of the envelope illustrated in figure 5-7. They can be adjustcd at program initialization

time to compensate for drift in the calibration of the force sensors.

5.4.2. Recover

Recover is one of the most complex processes in the entire walking program. Its goal is to move its

leg from wherever the Unload process has left it to a target position from which the Load process will

get it. Figure 5-8 is a map of the area of motion of a leg broken up into several distinct regions

relative to the recovery target that is located at the center of the small diamond labeled Done. The

region labeled Up contains all the points from which the best way to reach the target is by means of

the Up-Down sequence illustrated in figure 5-5. The region labeled Place contains points from

which the target can be reached by setting the hip valve in the Place setting; likewise the region

labeled Lift.

The large region labeled Done might have been another region similar to _rp, although with slightly


/ \ Unreachable

o

,, -£

"_ ; Loaded o

In a hole?

Lowest

0 Force

Figure 5-7: 'rermination test fox" the Load process. The Load process terminales after the leg leaves the shaded region. If

the leg is in the :;ha(led region when Load is initiated, the usual ca:,e, they, Zc,ad mo',es it to,yard the unshaded

region, lfthe leg is in the unsimded region at the start, then Load terminated immediateb without taking any

action At the bottom is a limit to prevent overextension of the leg. On tim right is a limit that indicates

overloading of the leg. The sloped limit makes the leg act like a spring over a limited span. The leg cannot

leave the shaded region by the other two sides.

different motions. An experimental version of Recover did indeed ha,'e this stnlcture so that it

wouldn't terminate until the leg had gotten very close to the target. In practice, however, this proved

to be vnsuccessful since the valve switching time and joint velocities are so large that overshoot and

hunting were inevitable. The program was intended to walk in only one direction, so I chose to

eliminate the hunting by opening the loop, as it were, and making the frontward end of the region a

Done region. Note fl_at there is still one hunting mode available to the recover process: if the leg

starts in Place and moves down fast enough to cross completely across Done and into L/fi before the

process has time to notice, then it can get extra up-and-down cycles. While 1did observe it on a small

number of occasions, there was never more than one iteration and so I judged it not worth fixing,

though the repair would have been quite simple.

The Recover process can best be visualized in terms of the finite state machine shown in figure 5-9.

At any time the leg may enter the Done region and so the finite state machine can go to its final state

from any other state. The main concurrence of the Recover process contains two subprocesses, the

Walking Program 45

Place

Done Up

Lift

Figure 5-8: Recover target regions. The target position is at the center of the small diamond labeled Done. If the recoverprocess finds its leg position in the region labeled Up, then it places the hip valve in Up until the leg reachesthe edge of the Iegion, al which point it switches to [)own. "111cprocess is terminated when the leg reaches anypart of either of the regions labeled Done. If the recover process finds its leg in either of the regions .PlaceorL/fi, it puts the hip valve into the setting Place or I,ift until the leg moves to tile region Up or to the regionDone, from where the handling for those regions takes over.

first of which checks for the done condition and terminates the entire concurrence whenever it

becomes true and the second of which is a concurrence with three subprocesses of its own. Each of

these subprocesses is responsible for one of the three active regions.

5.5. Service processes

The processes described in this section provide the stuff functions of gathering and presenting

sensor values from the machine, sending commands down to the valves, gathering data for later

evaluation, and maintaining several hydraulic invariants.


Up Down

Start Lift Done

Place

Recover

Figure 5-9: Finite state machine describing the fu_ctioning of the recover process. Notice that this formalism is not idealfor fl_c description of the cGncurrcnt structure of this process, since the transition to Done has to be shown as atransition from eve:3' other state in the machine.

5.5.1. Sensors

The walking program includes some service processes that are responsible for periodically

propagating sensor data from the sensor computer to the control machine. The sampling and

nonnalization of sensor values is handled by a separate 68000 microcomputer that maintains a table

of sensor values, updated every ten milliseconds. There is a shared memory interface between tile

two machines that penT,its the control computer to read and write the RAM of the sensor computer.

All of the sensor values are put into global data objects that are used throughout the rest of the

walking program. Here is a list of the sensor variables, most of which are integers in the range -10000

to + 10000.

* x - an array containing the normalized knee joint position for each leg. Thenormalization is such that when the knec joint makes a right angle with the upper leg, the

value is zero. The positive values correspond to an excursion to the right when facingtoward the driver's station with the engine in back.

Walking Program 47

• y- an array containing the normalized hip jt_int horizontal position for each leg. Thenormalization is such that when the leg makes a right angle to the body the value is zero.

More positive values are toward the driver's station.

• z - an array containing the normalized hip joint vertical position for each lcg. When theleg makes a right angle with the body. the wdue is zero. More positive values are upward.

• el- This is a derived value, not a measured one. It reprcsents an estimate of the length of

the engine end hydraulic cylincicr for each leg. It is particularly useful because several ofthe valve settings shorten or lengthen only one cylinder and it is convenient to base thedoneness tests on the actuator length. 'l'he most negative value corresponds to theshortest actuator position.

• d/- This, like el, is a derived value. It represents the length of the driver end hydraulic:

cylinder for each leg:

• fx - an array containing the measured forces on the knee actuator. These values werenever used because the knee load cells were used as a supply of spares for the hip loadcells.

• _ - an array containing the measured horizontal forces on the hip actuators for each leg..These values are derived from the real load cell measurements by the sensor computer..

representing a linear combination of the engine end actuator load cell and the driver endactuator load cell.

• j_ - an array containing the measured vertical forces on the hip actu,_tors for each leg.The data were nornaalized so that a load of half the weight of the machine correspondedto + 10000.

• kneeva!ve - an array containing for each leg a character representing the actual setting oftl_eknee w_lvesas reportcd by the sensor computer.

• hipvah,e - an array containing for each leg a character representing the actual setting ofthe hip valves as reported by the sensor computer.

• rcv, crb, d123, d456 - readings of the displacements of the recovery, crab, 123 side drive,and 456 side drive pumps.

• dial- integer representing the key on the telephone keypad that is pressed.

• stick - a byte containing all of the contact closurcs for the F-4 control stick that ksmounted on the joystick of the machine.

• firststep, secondstep, thumb, trigger, cooleehat - decoded contact closures from the F-4control stick. The cooleehat variable actually contains four bits representing the direction

that the trim tab adjuster has been pushed.

• comp - The position of the compensator. This is the extra cylinder that is used to keep thehydraulic system in balance.


• comphip, compknee -compcnsator "knee:" :_nd "hip" valve settings. Because of the way

the compensator is hooked up, one can pretend that it is a seventh leg, which isconvenient at times.

5.5.2. Trouble

Two design constraints of the hydraulic system require special care in the design of the walking

program. The proccss described in this section is responsible for enforcing those constraints by

maintaining current some flags that indicate to the rest of the walking program what actions are

forbidden by the hydraulic system.

The first constraint is simply that when any cylinder is at the end of its travel it cannot be driven

beyond that point. The hydraulic system is set up so that all the legs on onc side of the machine that

are in the Drive setting simultaneously have their cylinders in series so that thc legs down and driving

will all move together at the same speed, eliminating mechanically the isometric exercise problem

that other walking machine researchers have taken considerable pains to eliminate computationally.

The consequence of this series connection is that if any leg should run out of travel, all the other legs

in series with it will be unable to move. This is probably desirable, because it prevents the movable

legs from forcing the stuck leg beyond its limits of motion and damaging it. It is more desirable, in

fact, to prevent the legs from ever running out of travel in the first place.

In orde," to provide the protection made necessary by this constraint, the walking program has a

flag named anytrouble. This variable is nonzero whenever any legs are out of travel or close to

running out of travel. Each leg may assert that it is out of travel, or close to it, by asserting its element

of the array irouble. Elements 1 through 6 are devoted to the six legs and element 8 is used by the

dea&nan process to halt all forward motion when the driver takes his finger off of the joystick trigger.

The code for the Row process takes its leg out of the Energize valve setting whenever the anylrouble

flag becomes nonzero. 'Ille TroubleServer process adds up elements 1 through 6 and eight of the

Irouble array and asserts the anytrouble flag whenever the sum is not zero.

Trouble[ 7 ] is not watched by TroubleSen'er because it is used by the compensator server to signal

that the compensator is out of travel. This has no impact on the energize decision, though it was used

in that way in an earlier implementation, and that is why this flag is located where it is.

The other hydraulic limitation is a consequence of the fact that all legs in vertical motion in the

same direction are connected in hydraulic parallel. Because hydraulic fluid is incompressible, the

Walking Program 49

pressure throughout each circuit is the same. That means 1hat when one leg is on the ground and

loaded and in Up or l.ift and another leg is unloaded and in Up or l.ift, the pressure in the system

will be zero. As a res_ilt the loaded leg will move rapidly upward and the unloaded leg will move

rapidly downward until it hits the ground with a bang. Only then will the pressure in the system

increase m the point required to support the machine. Thus, there is a constraint that when any legs

are in Up or Lift, they must all be loaded or all be unloaded. There is a similar constraint for the

settings Down and Place.

Keeping the machine in conformance with this constraint is somewhat more work. The Row

process for each leg includes a subprocess named Hydraulic that keeps track of the leg and provides

information on its status in elements of four different flag arrays. Trouble combines these arrays

together into flags that indicate what the hydraulic system will permit at any given instant, tfere is an

inventory of the flags:

plflag - Indicates that legs moving downward are loaded. This forbids any unloaded legsfrom entering downward moving settings.

• puflag - Indicates that legs moving downward are unloaded. This forbids any loaded legsfrom entedng downward moving settings.

• [iflag - Indicates that legs moving upward are loaded. This forbids any unloaded legsfrom entering upward moving settings.

• luflag - Indicates that legs moving upward are unloaded. This forbids any loaded legsfrom entering upward moving settings.

A leg that is forbidden to enter a setting by these flags may enter any permitted setting. In practice,

legs that are forbidden to enter a setting are put into the Hold setting while waiting to be permitted to

enter the desired setting.

5.5.3. Compensator monitor

The compensator is hooked into the hydraulic circuit when all the legs that are moving vertically

are moving in the same direction. When that happens the legs present an unbalanced hydraulic load

to the pumps. When the load is unbalanced, the amount of oil returning to the pump is different

from the amount being pumped out and since the hydraulic pumps are positive displacement types,

which must pump as much oil out as they pump in, this condition must be forbidden. The

compensator, which is introduced to enable the machine to function when the volume of the

hydraulic system would otherwise be suffering a net change, is a single-ended hydraulic cylinder

similar to the hip cylinders, though quite a bit longer, that is hooked into the hydraulic circuit in the

opposite direction whenever the problem condition is detected.


The only problem with the compensator is that whcq tiae machine is changing its stance

substantially the net change of volume is more than the compensator can but'fcr, thus forcing the

compensator to the end of its travel. When this happens the pressure in the system builds up until

the relief valves limit it and the oil begins to heat up. rl'o prevent overheating of the oil, the walking

program detects when the compensator is out of travel and moves it back to the center of its range.

There are valve settings that permit the compensator to bc moved in violation of the net volume

conservation rules, but all other cylinders must be stationary for tl_isto work. There is a process that

watches the compensator and when it gets close to running out of travel it taqkesover and moves the

cylinder back to the center of its operating range. This process is called compserver. It forces the rest

of the machine to halt by asserting a flag to force all other valves to halt.

5.5.4. Gather

The gather process collects detailed data during walking experiments. The data that is discussed in

Chapter 8, some of which is presented in appendix B, was collected during many tests of the walking

machine axadwalking program. The control computer has 512K bytes or' RAM, only about 100K of

which are used for the walking program. The rest of the RAbA is accessed as the global array trace

and used to hold data taken during experiments. We didn't send the data to the ho,;t Vax during the

runs because the line that we were using couldn't hemdle in real time the volume ef data we were

gathering. The data gathering processes are defined in two places, a process named gather is defined

with the main program, and a process named snapshot is defined in the lile data.owl. Gather is an

infinite loop that takes samples of each leg's variables by means of successive calls to snapshot, while

snapshot simply copies 11 key pieces of infommtion about the leg into the trace array.

Walking Program 51

Part II

Programming for Robotics and Control

In this part we examine some of the problems involved in programming robot tasks and develop

some requirements for programming languages that should be better suited to such tasks than

existing languages. The concept of an algorithm is extended to include properties of robot and

control tasks that do not fit the traditional model.

Inadequacies of existing control structures 53

And thus the whirligig of time brings in hB revenges.--- William Shakespeare

Chapter 6

Inadequacies of existing control structures

There are several ways that existing programming languages and tools fail to provide appropriate

facilities for the programming of robotics and control tasks. This chapter explores these inadequacies

and ends up with a list of requirements for a language that might be m,_re useful for robotics.

Chapter 7 contains the description of language OWl,, designed with these requirements in mind, that

was used to implement walking programs for the SSA walking machine.

Robotic and control tasks have four properties that make them different from most of the tasks for

which most existing high level languages have been designed.

o The universe that they interact with is nondeterministic. There is often no way toanticipate in advance the p_'eciseorder of external events.

n The tasks are complex but can be simplified a great deal by decomposition intoindependent asynchronous subtasks.

• External events must easily be able to affect the flow of control in the system.

• The real time behavior of the system must be controllable. Latency of time-critical tasksmust be bounded. _Ihe allocation of resources must be managed to achieve latencybounds.

This chapter starts with an exploration of the problems that traditional languages have in

expressing concurrency and handling nondetenninism, and proceeds with an examination of the

techniques for controlling real time behavior. Finally there is a review of some of the alternatives to

algorithmic programming languages and a summary of the features necessary for real time robotics

and control programming.


6.1.Concurrency

Many robotics and control tasks can be decomposed into multiple independent asynchronous

threads of control that we can call processes. 'l'hese processes are usually not totally independent;

some communication among them is required if the task is a complex one like walking. Partitioning

into processes is properly done when the communications and dependencies among the processes are

fairly sparse. In this section I consider several alternative tools and techniques for expressing

concurrent processes and compare them one with another.

6.1.1. Time Slicing

One way to implement multiple independent concurrent processes is to take some fairly traditional

timeslicing operating system and create the different processes fl'mtare needed using the multitasking

facilities provided by lbrks in the operating system. The problem with this approach is that

timesharing operating systems are designed to provide a great deal of protection because they are

intended to provide to each process the illusion that it is alone in the universe. When each process is

a truly independent program, that's fine, but when the processes are part of an integrated task like

walking, the protection is only a hindrance. It makes communication difficult and expensive. So

much state be squirreled away _hen switching between processes that the size of time slices must be

fbirly large in order to keep the overhead ratio down. The effect is to make the latency achievable

with such a system quite poor tbr real time control tasks. It is reasonable to suppose that these

systems are tuned for good interactive response time and that if one took a timeslicing system and

stripped out most of the protection and retuned it for real time latency flint it might perform well.

6.1.2. 5 Igorithmic languages

Algorithmic languages pmanit the easy expression of sequential behavior, but not of concurrent

beha,,ior. The sequential order of execution is implicit in the order of the statements in the program

text. This is a very convenient and comfortable notational tool and it saves the programmer a great

deal of effort when trying to design or understand a program. Unfortunately, algorithmic languages

usually do not provide any notation for expressing concurrent processes.

There are several ways to address this deficiency. All involve creating data structures that permit

the program to manipulate the order of execution of a collection of subprograms. "['his hnposes an

extra bookkeeping burden on the programmer, reducing the likelihood that the program will be easy

to design or implement. For a simple example of this, consider the concurrent program of figure 6-1.

Inadequacies _)fexistiqg control structures 55

CoBegin

Processl:

While true Do BeginWhile Xa Do A;While Xb Do B;While Xc Do (7;

End;

Process2:

While true Do BeginWhile Xd Do D;

While Xe !)o E;While XfDo F;End;

CoEnd;

Figure 6-1: Two processes that are intended to run concurrently and independently. A through F are names of,segmentsof code, Xa through X fare boolean expressions.

CoBegin and CoEnd indicate that the two processes Processl and Process2 are intended to execute

concurrently. This notation is from C'oncurIent Pascal [5], about which more later. One might

implement this in a simple algorithmic language with something like the code shown in figure 6-2.

There are many other ways that concurrency can be provided with a simple algorithmic language,

but since dlese languages lack the ability to specify concurrent execution of processes the techniques

will always require extra bookkeeping to be done by the programmer. This has the effect of

complicating the programs and making them harder to design, debug, and maintain.

6.1.3. Production Systems

A production system, written with a language like OPS5 [10], is a collection of condition->.action

pairs. The interpreter for a production system computes which of the Boolean conditions, or left-

hand-sides, are true and then executes the associated actions, or right-hand-sides. There is no

requirement that the programmer specify an order of execution for the productions, in fact there is

typically no mechanism for specifying order of execution simply. Production systems provide an

attractive way to specify concurrency since a large number of independent conditions can be active at

once. The drawback of using production system languages is that all of the productions in a program

are active at once so that the difficulty of writing and understanding such programs is as bad as for


ProcesslState : = hlA;Pmcess2State : = InD;

While true Do Begin

Case ProcesslState

lnA: Begin if Xa then A else t'tvcesslState:= lnB; End;InB: Begin if Xb then B else l'rocesslState := lnC; End;lnC: Begin if Xc then (" else l'rocesslState := lnA; End;Esac;

Case Process2State

lnD: Begin if Xdthen D else Process2State := lnF,; End;InE: Begin if Xe then E else t'tvcess2State := InF; End;Inl:': Begin if )fthen/;else I'rocess2State := lnE; End;Esae;

End

Fig.re 6-2: Code to implement the two concurrent processes illustrated in 6-1 by alternating between the two processes.

concurrent programs written in algorithmic languages, Production systems provide total concurrency

but they surrender the ability m specify easily several independent threads of time dependent-

behavior. Time threads can be inu'oduced by introducing explicit state variables, as illustrated in

figure 6-3 which illustrates the implementation of the two processes of figure 6-1 in a production

system language. The bookkeeping and overhead, however, are as bad as for the same task in an

algorithmic language. In addition to these software engineering concerns, most available production

system languages are interpreters and so the real-time performance is rather limited.

Production system languages provide, in a certain sense, too much concurrency. The result is a

software engineering nightmare in which the experienced prognmamer must develop a collection of

de_ices to impose serial behavior and program state on small sections of code. [!xisting production

system languages lack any real procedure abstraction, though in the concurrent programming context

it ought to be called a process abstraction. _Ilaus it is impossible to write a production system in one

place and insert its function into another production system by simply putting an utterance of its

name into the code. In a sense the OWl_, language, described in Chapter 7, could be considered to be

the imposition of a procedure or process abstraction on a production system language. Ben Hyde

drew my attention to this when he pointed out that it would not have been difficult to implement

OWL as a compiler that produced production language code [25].


(Statel = lnA) & (Xa) -> A;(Statel = lnA) & ( not Xa ) -> Statel := InB;(Statel = InB) & ( Xb ) -> B;(Statel = InB) & ( not Xb ) -> Statel := lnC;

(Statel = lnC) & ( Xc ) -> C;(Slatel = Ing) & ( not Xc ) -> Statel := InA;

(State2 = InD) & (Xd) -> D;(State2 = htD) & ( not )(d ) -> State2 : = InE;(State2 = hal:) & ( 2"e) -> E;(State2 = InE) & ( not Xe) -> State2" = InF;(State2 = Inl,) & (._f) ->F;(State2 = 1_1_)& ( not Xf) -> State2 := InD;

Figure6-3: Productionsystemimplementationofthetwoconcurrentprocessesfromfigure6-1.

6.1.4. Concurrent Programming Languages

Several languages, both real and paper, have been designed with the intent of providing some

amount of concurrent programming capability. Languages like Concurrent Pascal [5], AL [42], and

Modula [62] provide control constructs for specification of concurrent programs. Path Expressions

[6]provide a notation for specifying synchronization for concurrent programs.

Concurrent Pascal provides the CoBegin and CoEnd syntax that is exhibited in figure 6-1. The

semantics of"the language specify that all of the blocks defined within the CoBegin ... CoEnd pair are

to execute concurrently, with the concurrent block passing control on to the succeeding statement or

block after all of the processes within the concurrent block have terminated. No mechanism is

provided to permit one process to affect the flow of control within another process.

AL is a language that was designed for robotics research, with its primary focus on coordinate

transformation and manipulation. AL's concurrency control structures, CoBegin and CoEnd, are

similar to those of Concurrent Pascal, which simply provides syntax for specifying that several blocks

of code are concurrent. The example shown in figure 6-1 can be easily expressed in AL or

Concurrent Pascal languages. AL also provides 'condition monitors' that are actually simplified

condition->action pairs. A condition monitor waits on some global relation involving force or time,

though it may wait on a variable that can be set and reset by program control in some other

concurrent process.


Modula [62] also has thcilities fi_rsetting up concurrent processes, but all of file processes must be

statically defined. If several identical instances of a process are required, multiple copies of the code

must be provided. There are no facilities fi_r dynamically changing the set of active processes.

Modula provides even less ability to control concurrency than Concurrent Pascal and AL, because all

of its concurrent processes are statically defined. None of these languages provide powerful facilities,

like preemption, for controlling concurrency. What I mean by control here is the ability of some

processes to affect the execution of other processes without special communication agreed upon in

advance between the specific processes in question. The section on nondeterminacy contains a

discussion of this.

Path Expressions [6] arc a rathcr exciting notation for describing concurrent exccution of programs

because they permit the direct expression of permitted concurrency and of required scquentiality.

The expression of concurrency is achieved with simple syntactic marking. A list of procedures

separated by semicolon are to be executed sequentially, whiie a list of procedures surrounded by

curly braces { ... } may be executed concurrently. In addition, exclusion may be specified by

separating procedures in a list by commas. Path expressions were designed for the purpose of

specifying synchronization for operating system design tools, but fl_ey suggested to me that I could

design a notation for expression and control of concurrent real time programs that could easily be

impiemcnted. In many ways the OWl, language, described in detail in Ch_pter 7, provides

expressive powcr similar to that of path expressions, though with more computation power. Path

expressions are similar in power to most of the other concurrent programming notations; both lack

the ability for one process to easily affect the execution of others.

6.2. Nondeterminacy

A system that lacks detailed information about the world around it must treat that world as

unpredictable and nondetrenninistic. For example, a walking machine without a terrain map and

without any ability to peer at the ground in front of it must locatc the ground by touch. When it tries

to put a foot down on the ground, several things might happen. The ground might be fiat enough so

that the machine finds support at about the same leg extension as the last time it picked that foot up.

There might be a hole or ditch whose bottom is too deep for the foot to reach without overextending

the leg. The program controlling the machine in this case cannot know in advance which of the two

outcomes will happen; so it must be able to handle both.

When the alternatives are very simplc or the action can be postponed until the decisions are made,


the task of handling the nondeterminacy is not difficult. When the task involves several complex

concurrent subtasks, then h:mdling unpredictab}e interactions with the environment takes on some of

the character of a search. It is in situations of this sort that most of the existing systems for

programming concurrent control fail.

6.2.1. Concurrent programming languages revisited

One of the most powerfi_l constructs for enabling a program, to deal with nondeterminacy is a

grouping of concurrent activities each of which is intended to continue asynchronously as long as

some condition remains true. I call this construct the Concurrent While. It is one of the most

common constructs used in in the walking program for enabling the system to deal with

unpredictable events. The concurrent while is not easily achievable in Concurrent Pascal because the

CoBegin ... CoEnd construct has no preemption and terminates only after all of its component

subprocesses have terminated, which requires that the programmer include explicit tests of some

global condition in each subprocess. For an example of the value of this construct, consider the

recovery of a leg in the SSA walking machine. As long as the leg does not touch the ground the hip

joint should move through the recovery motions and the knee jeint should concurrently move

through its recovery motions. If the leg contacts the ground, the other processes should be

terminated, regardless of _vhere they are in their ev_Hution. If the leg finishes recovering without

touching the ground, then so much the better.

A particular virtue of the concurrent while is the fact that the scope of the termination condition is

expressed lexically; there is no need to pass process names around. Process name bookkeeping is

usually unpleasant and prone to error. In addition, when process names are first class objects 3 the.job

of ensuring that the set of processes active is in a consistent state becomes more difficult.. The

synchronization and control solutions involved are well understood, but the constraints imposed

make using them unattractive.

6.2.2. Guarded Commands

Another language design that provides some of the right semantics for the implementation of robot

tasks is Guarded Commands [9]. The language introduced two new control constructs, the do ... od

and the if ... ft. Each of the statements inside of one of these constructs is a guard->action pair,

where the guard is a Boolean condition like in a production system. When a do ... od is active,

3A first class object is one that can be created and assigned to.


statements with true guards are selected nondeterministically one at a time and executed until no

more true guards remain. When an if ... fi is active, one of the statements with a true guard is selected

nondeterministically and executed after which the if ... fi construct terminates. While the intent of

the language is to provide a total ordering on events, it is to be done without binding the order of

execution of pieces of code until execution time. This delaying of the binding of execution order is

very important to the handling of nondeterminacy with reasonably sized programs. If this were

extended to it_clude cop.currency, the language might be appropriate for robotics progrtunming.

Hoare's Communicating Sequential Processes [20] is such an extension and it might have served quite

well. However, there were a lot of features of CSI', like the elaborate input and output facilities, that

seemed too cumbersome to be implemented effectively in a real-time system and so we discarded

them. Ada tasks [13] may prove this soeculation to be false, but in the absence of an implementation

there was no opportunity to evaluate their performance.

6.3. The control of temporal behavior

There are several ways to enable a computer system's behavior to be influenced by events that

evolve in l_'al time. In dais section I will discuss them and contrast their merits and weaknesses.

There are two ways to express the interaction of a program with time. The first is to enable the

programmer to specify pauses in sequential p,ograms, to assert, in effect, 'wait here u_,til such-and-so

happens.' '[he other is to let the programme_ require that the program adhere to some external

schedule, to assert, 'get this done by the time such-and-so happeus.' In the rest of this section I will

examine these two regimes and discuss some of the design choices available in each.

6.3.1. Wait for event

There are four clearly identifiable ways to achieve the 'wait here until Boolean becomes true.' The

four mechanisms range over a spectrum from minimum resource utilization and difficult design, for

interrupts, to heavy resource utilization and simplified design, for busy waiting. The four choices are:

• Interrupts

* Prediction and anticipation

• Priorities

• Busy waiting

In the case of hardware interrupts, the Booleans are wired into the hardware of the computer

Inadequacies of existing control structures 6l

system. This mechanism provides the smallest latency, but it requires the best understanding of the

nature of the problem in order to provide the "right" l_ooleans. Traps, or software interrupts, are

slightly more flexible, but they require some code to test the Booleans and assert the traps. Both

implementation choices require substantial knowledge of the structure of the solution imbedded in

the system supporting the implementation. Systems with lots of knowledge are less flexible and

create software engineering problems.

Prediction and anticipation is a technique, provided in TOMAI. [15], whereby the programmer can

specify to the t_Jntime system some rules for predicting future events. This permits the runtime

system to set a timer for the nearest future event and then ignore all predicted events until the timer

interrupt arrives. This tcc:hnique can provide latmmies almost as good as those for interrupt based

systems, but it does require substantial analysis of the system in order to make good predictions.

Nondeterminacy is only weakly accommodated with this technique.

The third choice, assignment of priorities, is a mechanism provided in many systems to achieve a

rough bound on latency. Tasks are assigned to one of several priority levels with different quantities

of system resources assigned to each priority. Thus a bound on latency can be asserted for each

priorit_ level depending on both the resources and the load assigned to that level. Systems using

interrupts often use priorities to further o,.ganize the behavier and guarantee different latency bounds

for different devices. TOMAI. implemented a system ot' task priorities that assigned the CPU to the

highest priority task currently waiting. Priorities require less analysis of the problem than interrupts

or prediction, but they provide poorer bounds on latency as well.

Finally, busy waiting is the simplest and most expensive way to achieve control of temporal

behavior. The runtime system requires no knowledge of the system it is implementing to achieve its

best latency bound, but that latency bound is worse than that for the other mechanisms. Of course, a

properly designed concurrent programming system that used busy waiting would not hang the entire

processor while waiting on a single test but would rather keep a list of the pending I_ooleans to be

scanned repetitively. This technique is only suitable when the processor resources available are

substantia! compared to the demands of the task, since it is wasteful of CPU time.


6.3.2. Complete task before event

The 'get this done before that event' strategy is necessary when the rcsources available are restricted

enough that they must be well managed in order to achieve the real time performance goals of the

systcm. This strategy requires somc capability for analysis of the code, either mechanical or manual,

and for predictio_ of events so that the scl_eduling can be accomplished. With a schedule of events

and of the times of sections of tasks, a set of constraints can be asserted from which a schedule can be

derived. In the case that the proccssor resources are more _an adequate, the constraints can be

trivially satisfied.

No schedule works Some schedule works Any schedule works

I " I

Quantity of CPU power--_

Figure 6-4: Scheduling regions for a given task as a function of the amount of CPU throughput, available. If the CPU is

too limited, no strategy or plan will enable the schedule constraints to be met. If the CPU is sufficiently

powerful, almost any strategy will meet the schedule constraints trivially. In the intermediate region, planning

and analysis might _tisfy the constraints.

The continuum of quantit._ of compute; resources, say throughput, ranging from none to a very

large amount is broken up into three regions for every task. There is a quantity below which no

schedule will permit the satisfaction of of the task scheduling constraints. There is a quantity above

vH'dchalmost any reasonable scheduling strategy, for example round-robin, will work trivially. In the

middle is a region in which the techniques of plan based scheduling will be effective in finding some

schedule that will work. This is illustrated in figure 6-4. I believe that the region where planning

works is usually quite small. Moreover, changes in the definition of a task that starts in the marginal

region could easily make the task more difficult, perhaps moving it into the unachievable region.

The walking machine control system fell well inside the region in which round.-robin scheduling

worked, so there was no need to explore the more complex problems ot-'plan based scheduling. With

the increasing power and decreasing cost of computers, the easy scheduling region should be

accessible to most systems. Taking advantage of a multiprocessor to get into this region should be

particularly effective because breaking a system into a large number of autonomous subprocesses will

facilitate load balancing among the processors.

Inadequacies of cxisting control structures 63

6.3.3. The nature of loops

There is a fundamental difference between the way that loops are used in robotics and control

programming and the way that they are used in computational programming. Stated concisely, inner

control loops do nothing, while inner computational loops do something. A tight loop in a control

program is typically responsible for monitoring the evolution of some value, permitting the program

to proceed only after a Boolean function of that value changes. On the other hand, a tight loop in an

algorithmic program typically iterates across some data. sm.,cture, performing some computation as it

goes.

A tight loop in an algorithmic program should run as fast as possible so as to process the data

structure in the minimum amount of time. This is best done by minimizing the amount of time spent

on each iteration, including the control. In the presence of several different computations ,this

minimum is achieved by interrupting the tight loop as rarely as possible. For a control problem,

however, one wants the sharing of the processor to result in minimum latency.

6.4. Real time perfornnance

The earlier sections of this chapter bear on the design issues for a language for programming

real-time concurrent :;ystems. This section concerns some of the implementation issues that are

important enough to affect the semantics of the language. Adequate real-time performance produces

i,,tency small enough for the task at hand. Latency is the amount of time that elapses between two

successive opportunities for any specific process to receive CPU cycles and affect the behavior of the

system. This section discusses the "strips" programming discipline developed for the Pluribus project

and the TOMAI_ language developed for real time programming. Certain features of both systems

are incorporated in the implementation of the OWL languaged, described in Chapter 7.

6.4.1. Pluribus "strips"

The aim of the Pluribus project at Bolt, Beranek, and Newman [14, 45, 28] was to provide an

extremely reliable parallel processor and software to serve as the next generation of Arpanet Interface

Message Processors (IMP). In the process of writing the software for the system the workers there

developed a programming discipline, called strips, that was intended to provide good real time

performance and system reliability.

The basic idea behind strips is that every program is composed of a number of segments or strips of

64 Contn)l of Walking

code, each of which is somehow guaranteed to run to completion in less than some small amount of

CPU time. The Pluribus runtime system includes a table containing the names of all those strips that

are currently pending. A strip may put names into this table, lnsc_'ting its own namc is a way of

looping. Inserting a single different name is a way of proceeding in sequence. Inserting several

names is a way of forking several processes. One very powerful property of the strips discipline is

that it provides a bound on the latency of file system. The bound on individual strip latency was

checked by hand in the Pluribus system. In the OWI_ compiler strip latency was bounded by

requiring that each strip be a basic block, a non-looping, non-blocking stretch of inline code. Each

strip is an uninterruptable piece of code, so critical sections can be implemented easily.

The purpose of the strips discipline was to implement a highly reliable multiprocessor system, not

specifically to provide concurrency, but the strip model was also one of the best ways to implement

real or simulated concurrency. The chief defect of strips was that it was implemented as a

programming discipline and the bookkeeping was done by hand. The difficulty of doing this

bookkceping was so severe that it influenced the success of the Pluribus project as a whole.

6.4.2. TOMAL

TOMAL [15,16,17]isa ]anguagcthatprovidesallthepowcrthatisneededforrcaltimerobotics,

havingbeendesignedforrealtimemultitaskingsystemson smallprocessors.Itcontrolsprocesses,

whichmustbcstaticallydcfincdatcompilctimcina fashionsimilartoModula,by cxplicitsignals

fromprogramstotheruntimesystemactivatinganddeactivatingotherprocesses.Taskscanhave

prioritiesandthescheduicrgivestheprocessortothosetaskswithhigherprioriticsinpreferenceto

thosewithlowerpriorities.A taskthathastowaiton an eventcandeclaretotheruntimesysteman

estimateofhow longitexpectstowaitsothattheruntimesystemcancompletelydeactivatethe

processuntilthattimehaselapsed.

The underlyingimplementationof TOMAL [16]iscompiler-gcnel'atedcode-stripswhich are

essentiallythesameobjectsasthestripsofthePluribussystem.Thesearealsomuch thesameasthe

basicblocksoftheoptimizingcompilerworld.TOMAL wasthefirstsystembascdon thecodestrip

conceptthatincorporateda compilerto do the bookkeepingforthe strips.The TOMAL

programmerwasstillresponsibleformanagingtheprocessstructureofhisprogram,butthetaskwas

made considerablyeasierby bundlingup theimportantinteractionsbetweena programand the

schedulerintolanguageprimitivcs.Concernwithovcrhcadledtostrongrestrictionson process

structure:eachprocessmustbe instantiatedby itscode.ItisnotpossibleinTOMAL tocreatea

processbyhavingsomeotherprocesssimplyuttcra name.


Tomal's model of processes is more primitive than is appealing to mc because it puts a substantial

burden on the programmer. Its limitations for the walking task come with its static task structure:

separate instances of otherwise identical tasks require explicit separate copies of the code. Its notions

of priority and declaration of estimates of latency are quite in advance of any similar systems. The

decision for static structure was a choice that was carefully and consciously taken in the interest of

overhead control. One reason that they made this decision is that the implementation of reentrant

modules was rather expensive on the machines for which TOMAL was designed: microprocessors

like the lntel 8080.

6.5. Summary

This chapter has illustrated some of the ways that existing prt_gramming tools and models are not

adequate for the programming of robotics and control tasks. Algorithmic languages bind execution

order far too early, while production system languages bind it too late. Many tasks, while they cannot

be expressed as single sequential programs, can be expressed as the concurrent combination of a

moderate number of small sequential programs. While there are a lbw languages that provide the

ability to write concurrent programs, most of them lack one or more important features. Most

concurrent langqages restrict the quantity of concurrency by requiring all processes to be statically

defined at compile time. None of the available concurrent languages provides simple mechanisms

for one process to affect the flow of control of other processes, whether by suspending or terminating

them.

In view of all of this, I present here a list of features that I believe are necessary for a good robotics

control language. It is also clear that a new view of objects is needed, as pointed out by Ossher and

Reid in [46], but that issue is not addressed here. This list of requirements drove the design of the

OWI. language, which is described in Chapter 7.

o Real time performance guarantees through ways to assert bounds on latency.Performance guarantees are necessary for any program that is used to control a physicalsystem.

• Ability to control temporal behavior: for example, wait on a Boolean. This is importantfor handling asynchronous or nondeterministic behavior.

• Concurrency with lexical scoping. Without lexical scoping, the problem of managing thecode becomes much more difficult.

• Process abstraction: the ability to create process instances by uttering their names. This

frees the programmer from having to know how a function is implemented in order touse it.


• Preemption: the ability to affect the flow: of control in other processes, for example theConcurrent While. This fl'ees the programmer from a large body of complex

synchronization bookkeeping.

OWL language 67

The Owl and the Puss)_Cat went to seaIn a beautiful pea-green boat.

--- Edward Lear

Chapter 7

OWL language

OWL is a language designed as a solution to some of the inadequacies described in Chapter 6. [t was

used to implement the walking program described in Chapter 5. This chapter contains a description

of the language and of the compiler and runtime system that I designed and constructed to

implement it.

Before we dive into the details of the language, let's have a quick preview of the important features

of the language. OWL programs are collections of processes appropriately decorated with markings

that communicate the programmer's intentions about their order of execution. A process in OWl.

may be any of four mings: a primitive statement defined in the language, a named process declared

elsewhere by the programmer, a sequence, or a conc¢_rrence. The two maj¢)r execution-order

abstractions in OWI. are sequences, lists of processes to be executed serially, and concurrences, lists

&processes to be executed concurrently.

The simplest kind of combination of OWL processes is the sequence. A sequence is a list of

processes delimited by angle brackets '<' and '>'. The processes in the list are to be executed in order,

much as in traditional sequential programs. An OWL sequence is always an infinite loop. After the

last process in the list has been executed, the head of the list is restarted. Sequences are explicitly

terminated by execution of the done process, a primitive defined in the language. A sequence is a

legitimate OWL process and may appear anywhere any other kind of process may appear. Figure

7-1 shows two OWL sequences.

<A; B; C>

< A; < B; C>; D>

Figure 7-1: Two OWI_sequences. The first sequence is very simple, while the second one contains another sequence as astatement. An execution trace of the first sequence might look like A-B-C-A-B, while an execution trace of ',he

second sequence might look like A-B-C-B-C-D.


The concurrence is the only other kind of combination of OWI. processes. A concurrence is a list

of processes delimited by square brackets '[' and ']'. The processes in the list arc to bc executed

concurrently. The concurrence terminates when all of the processes inside of it have terminated.

Concurrences are also legitimate processes and may appear in other sequences and concurrences.

Figure 7-2 shows an example of a concurrence.

[A;< B; C; D >;< E; F>

1

Figure 7.2: A concurrence with three subprocesses. A is a named process, while the other two are structural subprocesses,each a sequence.

A sequence or concurrence may be assigned a name and a list of formal and local parameters. Such

a process, called a named process, may be invoked from sequences and concurrences in any place that

other kinds of processes may appear. Except for side effects like time consumption, named processes

and primitive statements provided by the language are indistinguishable.

OWL provides a mccb.anism for preemptiorJ that permits processes to terminate competing

concurrent processes. Preemption is achieved only inside of concurrences. Any subprocess of a

concurrence may request the termination of its siblings by signaling alert. Only one subprocess of a

concurrence will have its alert request acknowledged and bc permitted to continue executing. All the

other processes in the concurrence are terminated, including those requesting preemption but not

receiving any acknowledgement. A process is teraninated cleanly between statements when it is

preempted.

In Chapter 4 I mention that the walking machine is big and powerful and dangerous. The primary

reason for the inclusion of the alert mechanism was a desire fbr confidence in certain kinds of

behavior of the walking program. There are several hazards inherent in a walking strategy that

emphasizes a collection of independent processes each controlling a single leg. If some sort of

emergency arises that requires concerted behavior in order to prevent a disaster, it is desirable to

ensure that no processes with conflicting goals remain active and capable of doing damage. This

assurance requires more than cxclusion in the control of access to resources. It requires the ability to

preemptively terminate competitors and take control of their resources, which is providcd by alert in

OWL. The facilities provided in OWI_ for control of concurrent processes are necessary for

OWL language 69

implementing safe walking programs, but are not sufficient to make formal verification of safety

feasible. They ease the task of designing, understanding, testing, and debugging programs.

The alert mechanism makes it easier to say with some confidence that a program will never permit

multiple processes to rnake conflicting operations on any actuator or other machine resource. That is

not to say that any special protection is provided to ensure reasonable handling of resources, simply

that it requires less bookkeeping by the programmer to develop some confidence in the behavior of

the program.

7.1. OWL processes

The fundamental control object in OWL is a process. OWL processes are not big expensive things

like processes in traditional operating systems, they are simple inexpensive things that all live

together in a single address space. Even primitive statements like assignments are processes in OWL,

though of course there are optimizations in the compiler that take advantage of the simplicity of

assignments and other such statements.

Here is the syntax definition of all of the things that are processes:

process :: = id[ id ( actuallist ) [ sequence [ concurrence]assignment

An OWL process is one or more code strips, in the Pluribus or Tomal sense [45, 15], along with a

small amount of state information. The state associated with the process is any formal and local

parameters and the value of the alert attribute. From the point of view of its control interactions an

OWL process is quite simple, having only three distinguished moments in time. One moment is

initiation, when an instance of the process is created and becomes eligible to receive CPU time and

other resources. Another moment is termination, when the process decides that it is done and

announces that fact. Between initiation and telvaination comes the optional third moment when the

process asserts its alert signal. The alert signal is a part of the handling of control of concurrency and

will be described in greater detail in section 7.3. Figure 7-3 is an illustration of an OWL process.

An OWL process may do things during its lifetime like make computations, send commands to

actuators, or read sensors. As far as the process structure is concerned, these are side effects. A

process may be a primitive, provided by the underlying runtime system, or it may be a composite,

constructed from other OWL processes. OWL processes may be composed to make more complex

processes in two ways: sequentially and concurrently. The next two sections describe how both of

these work.


alert

/,I "initiate done

Figure7-3: An OWl, process Time increasesfrom left to fight. Between initiate and done the process is active. Duringits activetime it may assertits alelt attribute.

7.2. Sequences

The simplest way of combining several OWL processes into a larger process is the sequence. An

OWL sequence is the way that serial execution is specified.

Here is the syntax for OWL sequences:

sequence :: = < processlist >

processlist :: = process ] processlist ;process

Note that "<" and ">" ave OWI_ syntax not BNF syntax here.

An OWL sequence is a list of processes. The processes in the list are to be executed one at a time in

the order of presentation in the text of the list, starting with the first one. Each process is activated

when its predecessor tenninates. The successor to the last process in the list is the first process; thus

each sequence is an infinite loop. Each sequence has a done attribute that may be set at any time by

one of the subprocesses. The entire sequence terminates as soon as the subprocess that has set the

sequence's done attribute terminates. Each sequence has an alert attribute as well. This attribute is

unset when the sequence is first instantiated and may be set exactly once during the life of the

sequence.

Figure 7-4 illustrates the sequence whose code is < A; ,9; C >. The initiation of the composite

process causes A, the first subprocess, to be initiated. The termination of A causes the initiation of B,

and the termination of B causes the initiation of C. When C terminates it initiates A again. The entire

composite process terminates when one of the subprocesses asserts the done attribute for the

composite. In the figure this is illustrated by the dashed line from subprocess B to the done line of

the composite.

OWl. language 71

Figure 7-4: An illustration ofa _quence. The OWl, syntax for this process is < A; B; C>.

The alert signal for a sequence is asserted the first time any of the subprocesses asserts its own alert

signal. Since the subprocesses of a sequence may repeatedly be terminating and being reinstantiated,

the sequence could receive alert signals from its subprocesses many times. Only the first one is

actually passed out as the parent's own alert signal. Explanation of the handling of th_ rest is best left

for section 7.3. In essence, further alerts sent by subproccsses are ignored.

7.2.1. Asserting done and and alert

Several special primitive processes are used to assert the done and alert attributes for a process.

Each teixninates in the same activation that it is initiated, though it may delay the activation of its

Successor.

• alert( Boolean ) - This primitive process evaluates the Boolean exprcssion passed as itsargument. If the Boolean is true, then it asserts the alert signal for the parent process. Ifthe Boolean is false, no signal is asserted.

• done( Boolean ) - This primitive process evaluates its argument and asserts thetermination of its parent process if the value is true. If the _alue is false, no signal isasserted.

• both( Boolean ) - This primitive process asserts both done and alert for its parent processif the argument is true.

Here are some examples of the use of these primitives in sequences. The first example, figure 7-5,

shows a simple do-it-once process.

The second example, figure 7-6, shows a simple loop, such as one might find in a computation.

The first five instances of the done process terminate with no action. At the sixth instance the test

( i > 6 ) is true and the sequence is terminated.


< A; B; C; done( true ) >

Figure 7-5: A process that terminates after executing A followed by B followed by C exactly once.

<A;i= i+ l;done(i>6)>

Figure 7-6: A simple loop. Assuming that i is initialized elsewhere to 1, then this loop runs the process A six times.

7.2.2. _'hen and bothwhen

In early walking programs the primary use of alert and both was from inside of simple wait loops.

As a result, abbreviations for these common constructs were added as primitives. Each of these

primitives is defined as being semantically identical to a piece of OWL code. There is some

advantage to using the abbreviations because they permit the compiler to make optimizations and, in

addition, t!-myare a bit easier to type.

• _vhen(Boolean ) = = < done( Boolean ) >. This primitive waits until the boolean becomestrue, at which poi_.t it terminates, thus permitting a sequence in which it might beembedded to proceed. It is important to remember that this process does not wait in a

tight loop, but rather gets reactivated occasionally by the mn time system to recheck itsBoolean This is true for all loops in OWL.

®bothwhen( Boolean ) = -= < both( Boolean ) >. This primitive waits until the Booleanbecomes true and then asserts bolh alert and done, thus asserting the parent process's alert

attribute and permitting the parent process to proceed. See section 7.3 for more aboutalert.

Figure 7-7 illustrates the use of the when primitive. In the exmnple the process A is initiated first.

When A has tenninated, the process waits until the boolean Ready-to-proceed becomes true, at

which point B is initiated. This kind of construct is suitable for the implementation of rendezvous

and other synchroni:-ation operations.

< A; when( Ready-to-proceed); B; ... >

Figure7-7: An example using the when primitive. Execution of the sequence pauses until the BooleanReady- to-proceed becomes u'ue, at which point it resumes with B.

OWL language 73

7.3. Concurrences

Concurrences are the second and most important of the two ways of combining processes in OWL,

the first being sequences. Concurrences provide the way to express asynchronous concurrent activity

in OWL.

Here is the syntax for a concurrence:

concurrence :: = [ processlist 1

processIist :: = process lprocesslist ; process

When a concurrence is instantiated, each of the processes in the list is instantiated and proceeds

asynchronously. Each subprocess of the concurrence may terminate itself, and the entire concurrence

terminates after all of the subprocesses have terminated.

7.3.1. Handling of alert

An arbiter associated with each concurrence mediates the preemption that is signaled by the alert

attribute. The arbiter is notified by each subprocess of the concurrence as soon as that subprocess

asserts its alert attribute. The arbiter decides which subprocess asserted alert first and permits that

subprocess to proceed. All the other subprocesses in the concurrence are terminated. Figure 7-8 is

an illustration of a concurrent process. The alert signal is not propagated up by concurrences,

contrary to the behavior of sequences.

The rest of this section consists of some exmnples intended to illustrate the use of concurrences in

OWL. These examples are important because normal alternation control structures like if ... then ...

else and case are not provided in OWL.

Figure 7-9 shows how a simple if-then-else alterqation can be achieved in OWI_. The C conditional

expression (Boolean) ? exprtrue : exprraise is provided in OWL and was used occasionally in the

walking program. Alternations of the forms shown in figure 7-9 were almost never needed. If OWL

were to be developed into a production version, it is clear that an alternation construct :should

provided.

Figure 7-10 illustrates how one might implement a case statement in OWI_. Notice that the figure

shows only the form that uses the alert signal to achieve the selection. An analog to the second

example of figure 7-9 could be constructed, but in that style the test for each case would be of the

74 Control t)f Walking

/

C

Figure 7-8: Illustration of a concurrent process. Notice that it cannot signal alert. Its OWL syntax is [ A: B; C].

[< botimhen( B ); Action - 1 >;< both_hen( not B ): Action- 2 >

1

{< done( not B ); Action- 1 >;< done( B ); Action-2 >

1

Figure 7-9: Two ways to implement if-then-else. The first relys on the arbitration provided by alert, though it is clearly notnecessary for the Booleans shown in this illustration. The second relys on the fact that the loser of the twoprocesses will ternainate itself, while the other will proceed to its action. Notice that there is a potential racecc,ndition with the second implementation. If the Boolean B becomes false, say, alter the sequence containingAction-2, then the sequence containing Action-1 might aiso be terminated, resulting in neither action beingtaken. "Ibis isn't a problem in the first implementation because even if both sequences tr)' to signal alert, thearbiter guarantees that only one will be permitted to proceed.

finTn done( Casel or Case2 or ... or CaseN ), rather ungainly to code and difficult to maintain. Case

alternations of this form do appear in a few places in the OWL walking program. Their primary

function is when "search" is necessary. Several processes are started up looking for various things

and the first to find its condition satisfied signals alert, thus tmvninating all of its competitors, and

proceeds with its action.

OWL language 75

[< bothwhen( Casel ); Action- l >;< both_hen( Case2 ): Action - 2 >;< both_vhen( Case3 ); Action- 3 >;

..,

< bothwhen( CaseN ); Action- N >;

]

Figure 7-10: An example of the implementation of a case construct in OWL.

7.3.2. Concurrent while

The most common thing that the alert mechanism is used for in the walking program is a construct

that is called the concurrent while in Chapter 6. It is a process that contains one or more active

subprocesses plus a termination process. When the termination condition is satisfied, the termination

process signals alert, terminating all of the active subprocesses, and then terminates itself. This

construct is more attractive than a traditional while loop because each of the active subprocesses may

involve waiting and other latency that should not be in series with the tcnnination test. Figure

7-11 illustrates this usage. There are numerous other examples in the walking code contained in

appendix A.

[< both( Termination - test ) >;

Activity- 1;Activity- 2;Activity- 3;

]

l:igure 7-11: An example of the "concurrent while". The three busy subprocesses run concurrently until terminated by thealert a_sse:tedby the process that is watching Termination- test.

7.3.3. Synchronization and Mutual Exclusion

The role of synchronization and mutual exclusion in robot control tasks is different from their role

in operating system implementation tasks, nonetheless, both can be achieved with OWL in a

reasonably straightforward manner. The way to protect a critical rcsource and ensure that only one

process gets ownership at a time is to bundle the processes together in a concurrence and have each


precede its entry to the critical section by an alert. The semantics of alert guarantee that only one

process will bc permitted into the critical section. After that process has completed, it can terminate

and the concurrence can bc rcinstantiatcd, thus again opening the resource for contention. Notice

that this is not exactly right tbr operating system implementation, since it rcquires the termination

and reinstantiation of all the contending processes. It is also possible to create a monitor for a

resource by constructing a concurrence containing a subproccss for each potential contender and

have the subprocess that receives the acknowledgement to its 2dcrt then acknowledge the process

whose requests it is handling. If one were to use OWL for a lot of tasks of this sort, it might be better

to add some facilitics to the language for that purpose.

7.4. Named Processes

One of the most powerful features of OWL is the process abstraction capability. This enables the

programmer to give a name to the code for a process and then to create instances of the process by

simply putting inw)cations by name into other process code.

Here is the syntax for process declaration:

processdefinition :: = define idformals locals : action

aclion :: = sequence Iconcurrence

formals :: = (formallist ) I e

formallist :: = formal Iformallist, formal

formal :: = parmpassing id I parmpassing id [ literal ]

parmpassing:: = var Ivarstar I val Ivaistar I e

locals :: = , local ( locaIlist ) I e

locallisl :: = local[ localtist , local

local :: = idl id[ literaI] l id = actual

A named process establishes a scope and permits the same code to bc instantiated in multiple

processes. It is important to remember that these are not process identifiers in the traditional sense.

A process identifier is a name by _hich you may refer to an existing process after you have created it,

with operations like suspend, activate, abort and so on permitted on the process identifier. Figure

7-12 illustrates the definition and use of a named process. Note that OWL named processes are

OWL language 77

definefoo( arg ), local( i ):{ Here is the code for the process }< { It is a sequence }

i = arg; {i is local to this process, arg is the parameter }

>

and here is an example of its use:

i = 17; { The canonical random number }foo( 3 * i ); { Of course, the i inside of foo is different }.,.

Figure 7-12: An example of the definition and use of a named process. In this example, the variable name i is definedboth in the environment from whichfoo is called and inside offoo itself.

procedural, not functional, in nature. An OWI_ process communicates results to its invoking

environment with var parameters.

7.4.1. Scope and Parameter passing

Scope rules and parameter passing mechanisms are very important to a language's

comprehensibility and usability. Scope rules determine what identifiers are nmaningful within any

given procedure or process, while parameter passing rules govern how and when information is

communicated between processes.

Scope rules in OWL are simple and limited, similar to those in C or Fortran. The only identifiers

visible within a named process are its formals and locals plus whatever globals have been declared.

All processes that have been defined are considered to be globally visible, as there is no nesting of

process definition.

Parameter passing in OWL is quite a bit more complicated than for algorithmic languages because

most interprocess communication is done through formal parameters. There are four distinct

parameter passing mechanisms in OWL, two of which, value and value-result, are much like similarly

named mechanisms for algorithmic languages. The other two, called valstar and varstar, are

generalizations of the first two to the needs of concurrent processes in OWL. Note that the OWL

syntax for designating value-result parameter passing is vat, different from conventional usage in

which var is generally synonymous with passing by reference.


The first and default parameter passing mechanism is by value, denoted val. The invoked process

receives the value of the variable as seen by the invoking process at the instant of invocation. No

subsequent change to the variable that was the source of the parameter is visible to the process,

though it may alter its copy.

The second mechanism is value-result parameter passing, available with the var parameter passing

declarator. A formal passed in this manner has its value copied in at the time of instantiation of the

process and copies the local value back to the original source variable after the process terminates

successfully. Note that if the process is terminated by the action of an alert asserted by some

concurrent sibling, it does not get a chance to write its var parameters out.

[Watch( i );< ...; i = ( Expression ); ... >

lFigure 7-13: An example of a concurrent while that cannot terminate if only value and value-result parameter passing are

provided. Watch is a subprocess that signals alert when i indicates _at the concurrence should be terminated.Since the value of i is passed in at the instant of instantiation of Watch and never gets updated with latervalues from outside, Watch can never terminate the loop.

Passing by value and by value-result, while adequate for many algorithmic languages, are not

sufficient for concurrent programming. An example of the way in which these two mechanisms are

inadequate is provided in figure 7-13. This is a "concurrent while" in which the termination process

is a named process and the variable being watched is passed in as a parameter. Since the process sees

no changes to the external copy of i it cannot observe when the value that is being manipulated by the

other process achieves a terminating value.

Introduction of reference parameters could solve the invisibility problem described above, but it

introduces several difficulties. The first difficulty is that in a multiple processor environment with

message passing communication passing by reference is complex and expensive. This is because it

requires that the address spaces be merged by hardware or software. The second difficulty is that

reference parameters introduce accessing delays that are harmful to real time performance because

each access requires a round trip communication. It is often the case in control problems that it is

better to have a "pretty good" value right away rather than to pay the cost of going and getting the

"best" or most up-to-date value.

OWL language 79

The first additional parameter passing mechanism that OWl, provides is called valstar. It is similar

to wd except that each time a process or any of its structural subprocesses receives any CPU time,

which I call being activated, copies are made of all valstar parameters fi'om their sources outside the

process. The problem described earlier with the code in figure 7-13 is solved if the definition define

Watch ( varstar arg ): ... is used, for then each time that the instance of Watch was activated, it would

get the current value of its argument written into its local copy.

The other additional parameter passing mechanism is called varstar and it is the analogous

extension of var. Thus, each time a process or any of its structural subprocesses is activated the local

copies are written from the source copies just before the code begins to execute and then the source

copies are written with the local value at the end. These semantics guarantee that, in a concurrence,

the subprocess that successfully preempts its siblings gets the privilege of making the final writes to

any varstar parameters. Alert can also protect the final value of a vat parameter.

The following table shows the complete set of possible choices for parameter passing mechanisms

for OWL assuming that the only distinguishable instants in the life of an instance of a process are (1)

initiation - the first time it is activated, (2) the beginning and end of each activation, and (3)

termination - the end of the last time it is activated. Reads are done at the beginning of activations,

Writes done at the ends of activations.

Read Write l)escrip tionNever Never l.ocal variableAt initiation Never VAL parameter

Every activation Never VALSTAR parameterNever At termination (Function result- use VAR)At initiation At termination VAR parameter

Every activation At termination (not provided in OWL)Never Every activation (Achieved with VARSTAR)At initiation Every activation (Achieved with VARSTAR)

Every activation Every activation VARSTAR parameter

7.5. Data

7.5.1. Data types

The only data types provided in OWL are integers and simple linear arrays of integers. The

important data structure design and implementation issues in OWl, concern scope, parameter

passing, and how to keep shared data updated without relying unnecessarily on global variables.


The operations provided are assignment and expression evaluation, _'ith expression syntax taken

from the C progran3ming language 129].Notice that square brackets 'T' and "]" arc merloaded in

OWl. because they are used for array indexes, as in C, and for concurrent groups of OWl_ processes.

Similarly "<" and ">" are merloaded, being used to delimit sequences, much as in mathematical

notation, ancl in relational operators.

The decision not to provide any tools for data abstraction was deliberate. I felt that the control

strategies that were appropriate to the walking task did not require any more data structure power. In

addition, since the concurrem processes require a runtime system data structure more complex than

the simple stack that suffices for algorithmic languages, I was afraid that providing more complex

data structures in the language might reduce the performance of the runtime system. 1 now believe

that my concern was unfounded and that more powerful data structures could be added without

serious real time performance penalty.

7.5.2. Declarations

Data objects must be declared explicitly, either globally with a global statement or locally to a

process with a local statement. Formal parameters to processes arc equivalent to local declarations.

When an array is to be passed as a formal parmneter to a process, its size must be declared in the

definition of the process. 4 J]ere is the syntax for global data declarations:

globaideclaralion :: = global ( globallist )

globallist :: = global[ gIoballist , global

global :: = id] id[ literal]] id = literal

The syntax for formal and local data declarations is included in the syntax specification exhibited in

section on named processes.

A global declaration makes a name visible throughout the entire collection of OWL processes. A

local declaration is visible throughout the code of thc process to which it is attached. Formal

parameters obey the same scope rules as local parameters. Separate instances of the same process

have independent instances of all locals and formals.

A spcckd globai arra_, n_m<,d iracc, is defined bx tt_e l,:_nguage. It comprises all of the otherwise

4h_ the t]r_a in,p;cmeniat_or of :k,, r-ov_!_mes_stem there was a _v,a,_r__um of 100 on the si,,'e of a]} declared arrays Therewas > sli_eh_ef!Bcicnc> ad _ar'_'_agcto, i,c<pit;- khc arrays ,, 3:_]Jcr t}aar: 1] c}_:,:_cnts

OWl. language 81

unused storage at the end of the control computer's real memory. The actual size in integers is

available in the variable tracesize. Establishing addressability fbr trace is done by an invocation of

the primitive process inittrace. This array was used by the walking program for data taking during

walking experiments.

7.6. Discussion

7.6.1. Sequences and loops

A fairly controversial feature of OWI_ has been the fact that seqaences are loops by default.

Sequences might have been defined in a fairly traditional way so that they terminated after one

execution with iteration added by means of some extra syntax. An earlier design for OWl, was in fact

done that way but I chose to make looping the default for several reasons. For the kind of control

tasks that OWL is designed for, looping occurs far more often than simple do-it-once blocks. A

sequence is a loop if it is possible for a single instance to execute its code more than once. The

walking program in appendix A contains 84 sequences of which 50 arc loops of one kind or another.

The 34 nonloop sequences are all terminated by done(true), foming them to temainate

unconditionally as soon as the last subprocess in the sequence is reached. By the way, it is possible

for OWL primitives to be loops; examples of this are _'hen, both_hen, and gete.

7.6.2. Concurrence and alternation

It is important to note that OWL does not provide any special syntax for alternation constructs like

if-then-else or case but rather that they are all achieved with concurrences. This often is disturbing

intuitively because it requires lots of processes in order to achieve simple results, but OWL is

designed so that process switching is very inexpensive, so the use of concurrency for alternation is not

as expensive as it sounds. More importantly, the style of programming appropriate to robotics and

control tasks does not require things like alternation often enough for their performance to be terribly

important.

7.6.3. Distributed implementation

The OWI. language was designed for implementation on a loosely coupled, message passing

multiple processor because I was afraid that the available uniprocessor might not be adequate to the

task The existing implementations are on uniprocessors and take advantage of the simplifications

possible with a single processor. Several language design and implementation decisions must be


reevaluated for a multiprocessor imphnentation. These include the handling of shared data, the

handling of alerts, and some syntax that would permit the programlner to bind particular processes to

specific processors.

The design of the mechanisms for handling shared data is the most important part of a multiple

processor implementation. The existing design permits globals, but this can be quite expensive. A

system of caches, similar to the handling of varstar and valstar parameters in the current

implementation, could work well if updated frequently enough to sustain real time performance.

What would happen is that each machine would have a local copy of all of the globals. Processes that

want to examine a global variable would look at a local copy. When a process wrote a global, its

lnachine would send update messages out to all of the other global tables. No synchronization would

be provided in the handling of the global table for two reasons: first, any synchronization needed

could be provided by explicit OWI, code, and second, in many situations the contents of global

objects are simply sense data for which reasonable timeliness is quite adequate. Valstar and varstar

parameter passing could result in a substantial amount of message traffic and damage the

performance of processes using them. The shadow system might work well for them as well, though

the source and destinations of these links could be optimized quite a bit compared to the global

shadows.

Handling alerts is another issue that must be reexamined in any multiprocessor implementation. If

the arbiter is on one machine and the subprocesses are scattered among a bunch of others, there is a

question of how long the processes that lose the contention for the alert might continue to execute.

The semantics of alert as currently specified simply guarantee that no loser of alert will be permitted

to pass the alert point. An alternative is a fully guaranteed alert in which the process receiving the

alert is promised not only that no other sibling process has received the alert but in addition that all of

the sibling processes have been terminated. This could be expensive because it requires that the

alerting process wait a round trip time between its machine and the home of the arbiter for the

concurrence plus the longest round trip time from the arbiter to the furthest sibling process. The

semantics of the two possible designs for alert are indistinguishable in a uniprocessor

implementation, which is why the design issue was not resolved in _e implementation of the OWL

runtime system. One compromise might be to have two kinds of alert, a soft alert with the present

semantics, and a hard alert that is fully synchronized as described above.

Another capability that would have to be added in a multiprocessor implementation is a syntax for

specifying the machine on which a specific process should execute. This might be a pragmatic

OWl. language 83

solution to tile alert semantics as well, permitting one to force tile subprocesses that need a hard alert

all to reside on the same processor, thus avoiding the embarrassment of dae soft alert and eliminating

the communication penalty.

7.7. OWl, Compiler and Runtime System

This section describes tile OWI. compiler Cowl that permits programs written in OWL to be run on

Vax/Unix and MC68000 systems. It also describes the OWl. runtime system: the resource manager,

process scheduler, and other pieces tilat enable the compiled OWI. programs to run.

7.7.1. Compiler

The code generation strategy of OWL is similar to the strips discipline developed for the Pluribus

system [28] and the code-strips ofTOMAI_ [16]. Each OWl. process is decomposed into a number of

segments of code that are essentially basic blocks. The compiler puts as many OWL statements as

possible into each strip and makes each one into a D'ocedure with a machine-generated name. The

activation record for a process contains a pointer to the procedure containing the code for the

currently active block in the process. The runtime system is basically a loop that repetitively selects

one of the active processes :,nd calls the procedure at which its activation record points. The strips

are responsible for all o_"the work of managing the process's resources and activities. The copying in

and out of parameters is all done by code written into the strip at compile time and initiation of

subprocesses is done by creating activation records fbr them and linking them into the list of active

processes.

The compiler was written in C [29] and its output is C code. The parser was written using Yacc [26].

The symbol table was implemented using root insertion [57] on a binary search tree. The compiler

supports separate compilation of OWL modules.

7.7.2. Runtime system

This section contains a brief summary of the main features of the OWI. runtime system. For the

purposes of this illustration, consider the code shown in figure 7-14. The rest of this section illustrates

the actions of the runtime system when initiating a process, when activating a live process, when

handling alert, and when terminating a process.

Because of the concurrent nature of OWI. programs it is not possible to keep the state of the active


define foo:

[ { A concurrence of two processes }bar; { Suppose bar is a simple process of some sort }baz

]

define baz:

[d;e;

f1

Figure 7-14: OWl. code for the processes used to illustrate the fuHctioning of the OWl. runtime system. Bar, d, e. an(ifare simple processes of some sort.

processes on a suck. The result is that OWL keeps a list of formals and locals for each active instance

of a named process. A structural subprocess does not have its own list, but rather inherits the one

belonging to its parent.

An activation record associated with each process, named or structural, points at a procedure that

was generated in C by 'daecompiler and at a list of formal and local pa;'amcters. If the process is alive,

or eligible to receive CPU cycles, then the activation record also points at an event record that is

somewhere in the event queue. When a process initiates subprocesses it becomes suspended and its

event is not put back onto the event queue until all the subprocesses terminate. Processes that are

suspended also point at event records, but theirs are not linked into the event queue.

Suppose the runtime system were instructed to instantiate the process foo defined in figure 7-14.

An activation record is created with a pointer to the compiler generated process OO-foo0, the

procedure associated with the process, and an event is created and linked to the activation record and

linked into the event queue. When the event comes to the head of the event queue, the procedure

OO-foo0 is executed. This procedure creates activation records and events for the processes bar

and baz. At this point we have the situation illustrated in figure 7-15

Suppose we let the runtime system take another spin around the event queue. It executes the

procedure OO-bar0 for the bar process and, let's suppose, the process does not terminate, so the

event goes back onto the event queue. Next the process OO-baz0 is executed and it creates

activation records and events for the three subprocesses d, e, and f At this point we have the

situation illusu'ated in figure 7-16.

OWl. language 85

ProcessTree1

Event Queue ]

Figure 7-15: The state of the process tree and the event queue after the process foo has activated its subprocesses bar andbaz.

When a process decides to terminate, the runtime system prunes its activation record and event

from the tree and queue. When an alert is acknowledged, the 'losing' proccsses are pruned from the

u'ee by tile runtime system, while the 'winning' process is permitted to continue.

7.8.Performance

Performance measurements of process activation time the OWL system were made on both the Vax

and on the 68000 using ',he tea! time clocks available on those systems. Real time latency

measurements were made only on the 68000, primarily because it is only an interesting measure when

applied to a program that is attempting to perform a real time control task, something that I (lid not

attempt on the Vax.

The per-process activation cost of OWL processes on the 68000 is about 350 microseconds. It was

measured with a program that simply times various numbers of spins of the runtime system while it is

executing a simple loop. The cost of C procedure calls is about 42 microseconds each timed, in the

same way, so an OWl. process activation is about eight times as expensive as a C procedure call on


Process Tree

Event Queue

Figure 7-16: The state of the process tree and the event queue after the process bgz has activated the subprocesses d, e, andf.

the 68000. I believe that with some fairly simple modifications to the runtime system's data structures

I could reduce that advantage to about a fhctor of two or four.

On the Vax with a moderate load average of about 6, the cost of OWL process activations is about

220 microseconds each compared with C procedure call costs of about 50 microseconds. These

measurements were made with the same programs used for the 68000 measurements, with some small

changes made to the C measu:ement to accommodate the different real time clocks. The relatively

poor showing of the Vax against file 68000 in the procedure call measurement is probably due to the

fact that the Vax was running loaded and the 68000 was running standalone. The fact that the ratio

between the cost of OWI_ process activations and C procedure calls is different on the two machines

is probably due to the tact that the C compiler forces all pointers and integers to be 32 bits long and

since the 68000 is a 16 bit machine, there is a performance penalty for doing this. The OWI. mntime

system makes extensive use of dynamic data structures linked with pointers. This is likely the source

of the relative performance difl?rence between the Vax and 68000 versions since the same C code

produced by the OWL compiler is used on both systems and the runtime systems share almost all

their code.

OWl. language 87

My goal in implementing tile compiler and runtime system was to provide adequate real time

peribrmance for the walking program. A goal in designing the language was to make it possible to

write programs whose latency could be understood and bounded easily. This is more important than

the comparisons of activation time against procedure call time made above. After all, even if OWL

activations were faster than C procedure calls, the effort would have been wasted if the system

couldn't deliver the desired real time performance. For the OWl, walking program the latency

ranged from 22 to 28 milliseconds as measured by having the program time each run and COUl|tthe

number of spins of the event queue that were completed in each. This is four to six times faster than

the system can respond physically, given that the hydraulic valves switch in about 100 to 150

milliseconds. The sensor syslem, implemented on a separate 68000 and communicating through a

shared memory interface, produces a new set of normalized sensor values every 10 milliseconds. The

relationship between dae sensor system latency and that of the OWE system is quite dependent on the

task. For some simple monitoring tasks tlle OWL system provides smaller latency than the sensor

system, which we discovered this by examining some data taken with a low latency OWL program

and noticing that there were regularly spaced flat spots on the curves. These flat spots corresponded

to the times when the OWL system overran d'Lesensor system and read the same values twice.

Further hnprovements in the performance of the OWI. system could be achieved through several

optimizations. The present runtime system picks proce:_scs to be run fi'om the event queue in

round-robin order but with a small amount of sophistication added to the compiler the runtime

system could be made capable of deciding that a given process is blocked in some way and not l:;other

to execute its code. This could be similar to the R.E'I'ti,network facilities in the OPS systems [10],

though the implementation of these do impose restrictions on the easily implemented data structures.

A system of latency and priority declarations, similar to those in TOMAI. [16] could be added and

used by a more sophisticated runtime system. The data structures used by the existing runtime

system were designed for ease of implementation and debugging, not for efficient execution, and

could be improved quite a bit. For the 68000 implementation the use of 32 bit pointers could be

replaced by 16 bit array indices. I suspect that the implementation of the parameter passing

mechanisms would also admit a substantial improvement in efficiency.


7.9. OWL Syntax

This section describes the syntax of OWI. The syntax presented here is somewhat simplified from

that actually implemented but the omissions are just some details that were elided to avoid obscuring

the fundamentals of the language with unaesthetic details of the implementation. The manuscript

file that produced this syntax specification was derived using a text editor from the yacc [26] input file

used to produce the actual OWI_compiler.

The syntax specification of OWL uses the following conventions. Nonte_vninals are presented in an

itaiic font and terminals are presented in a bold font. Comments are processed lcxically; they are

delimited by { braces }. The symbol e represents the empty string. The characters "<" and ">"

delimit sequences and "[" and "]" delimit concurrences.

processdefinition :: - define idformals locals: action

action :"= sequence I concurrence

fi:,rmals :: = ( formailist ) I e

locals :: = , local ( locallist ) I e

sequence :: = < processlist )

Note that "<" and ">" are OWI_syntax not BNF syntax here.

concurrence :: = [ processtist ]

processlist :: = process lprocesslist ; process

process :: = id l id ( actuallist ) I sequence I concurrence I assignment

assignment :: = id = actual ] id [ actual ] = actual

formallist ::-- formal Iformallist ,formal

formal :: = parmpassing id ]parmpassing id [ literal ]

parmpassing:: = varl varstar Ival I valstar I e

localiisl :: = local[ Iocallist , local

local :: = idl id [ literal ] ]id = actual

actuallist :: = actual] actuallist, actual

globaldeclaration :: = global ( globallist )

OWl, language 89

globallist :: = global ] globallist, global

global:: = id] id[ literal]lid = literal

7.9.1. Walking Machine primitives in OWl,

Appendix C contains a list of all of the primitive processes defined for OWL. Some of"these

primitives are described in file definition of tile language, but many are specific to the task of

controlling the walking machine. The OWl. compiler and runtime system are designed to make the

addition of primitives simple. To simplify the addition of new names, d_e lexical scanner is table

driven. The code t'or the semantic actions is put in a standard auxiliary module that is linked in with

the nmtime system. Most of the primitives defined in the appendix are in fact implemented as C

compile time macros, so they can be quite efficient.

OWl_ language 91

Part III

Results and conclusions

This part presents the important experimental results of Lhe research and shows how the

hypotheses were supported.

Experimental Results 93

Truth is rarely pure, and never'simple.--- Oscar Wilde

Chapter 8

Experimental Results

This chapter describes the actual walking results obtained with the OWI. walking program and the

SSA walking machine. 'l_he first section describes experimental results supporting the hypothesis that

walking programs based on decentralized control are feasible. The second section describes

experimental results with the inhibition mechanism, while the third section describes the effects of

die excitation mechanism. The next section briefly describes a completely different walking program

developed by another member of the walking machine project. The final section is a summary of the

experimental results.

This chapter contains selected graphs of walking machine experimental data inserted when

appropriate to illustrate points. A more complete selection, covering six of the best walks, is

presented for rel_rence in Appendix B along with brief explanations of the graphs and how they were

produced.

8.1. Local control

I make three claims for distributed control in the design of walking programs. The filst is that

distributed control works, the other two are that distributed control is easier to comprehend and

program and that it is less computationally expensive than centralized control. The experimental

results presented in this section demonstrate the first point: that distributed control works. The other

two points are somewhat more speculative and are discussed later when the OWL walking program is

compared with one written in assembler language and also discussed in Chapter 9.

Two results support the effectiveness of distributed control: the ability of the OWL walking

program to produce walking at all, and the ability of the OWL walking program easily to produce

walking with fewer than six legs.


8.1.1. Walking

We perfonned many experiments with the SSA walking machine and the OWL walking program

during the time between 20 April 1983, when OWl, programs first were able to control valves on the

machine, and 16 August 1983, when the machine was retired. Selected data fl'om six of the

experiments are presented in Appendix Band are summarized in the table in figure 8-1. These six

walks demonstrate that die walking program written in OWL and relying on distributed control could

produce walking behavior in the machine. Several sessions &walking were recorded on videotape.

Experiment Excitation l)ist (m) Time (s) Steps Step size (m) Time/stepw830728 Yes 6 85 6.2 .967 13.7w830731 Yes 8 130 11.2 .714 11.6w830808a No 6 130 8.8 .666 14.4w830809 No 10.5 170 14.3 .734 11.9w830809a Yes 14 300 18.7 .748 16.0

g830816 No 7 150 11.4 .614 13.2

Figure 8-1: Summary table of six walking experiments. Distance traveled in meters, time spent traveling in seconds,average number of steps per leg, average step size, and average time per step are all shown. Note that the lastexperiment, g830816, was walking with five legs instead of six. All walking was done with the inhibitionmechanism enabled. "l]m figure notes which experimenLs were nan with and without the excilation mechanismenabled.

Figure 8-2 illustrates the cyclic behavior produced by the Row process for a leg. In addition to the

cyclic behavior, this figure shows the effects on the leg's motion of interaction with the terrain on the

elevation of the drive phase and the effects of inhibition and excitation on the length of the drive

cycle. The most extreme variation in elevation experienced by any leg in the experiments for which I

have data is about six inches.

8.1.2. Five legged walking

The five legged walking experiment was conceived as a test of distributed control. Ideally, the

locality of control in the OWL walking program should make it possible for the same walking

program to produce walking behavior without significant alteration to the code. Insects with legs

amputated are capable of walking, though their walking behavior is different in detail from that of

intact insects [23]. I created a version of the walking program in which the instance of Row for leg 5,

the middle leg on the driver's left side, was commented out. The machine was able to walk in this

condition, as illustrated by the recovery timing diagram generated from the data of that run, figure

8-3.


12 Leg 4 Hip Y vs Z angles, from w8$O809.data

25

-30 egrees)

-4

Figure 8-2: I-lipvertical angle versus horizontal angle for leg 4 for the first walk of 9 August 1983. "Ihis plot is typical andillustrates the cyclic structure of ;he leg's n:otion. The leg's motion is clockwise iri this figure. Tke vaEai,ionsin the size of the different cycles are tb.e result of interaction with the terrain and of the inhibition andexcitation n=echanisms. llae differences in the Z ,angleof the drive phase show that this leg ,sawa peak-peakelevation variation of about four inches.

--_left rear .R_n_r] r_ [-] L_.[1 N

]-l_lt!G H fLH_I] FL_YI_JIleft m__] ........H n rL_rL_ .H rt_rLJ

[]Legs re_]overing, ,_]m g830816.dataI-[_.t],, ,I_, rl I-I_XI_J-L_Jright rear

_ght middle71I1 Ill-IN I-1[1 FI 1--I I--11-11]I-Iright fron_o 40 dO 80 "100 12.0 140 160

time (seconds)

Figure 8-3: Timing diagram for the five legged walking experiment g830816. Leg five was not operated, as its instance ofRow was commented out.


8.2. Inhibition

The purpose of the inhibition mechanism was to ensurc the maintenance of reasonable stance by

the machine while walking. This means not only keeping at least three legs on the ground and not

recovering, but also making sure that the legs driving are reasonably distributed to support the

machine. Early walking experiments without the inhibition mechanism did not maintain a good

stance; the frame of the machine came into contact with the ground many times, something it should

not have done at all. After ti_e introduction of the inhibition mechanism there was a qualitative

improvement in the quality of walking. This is particularly easy to see by considering figures 8-4 and

8-6, which are graphs of the total number of legs not recovering as a function of time. Notice the

correlation between the number of legs recovering and the forward progress for the w830728

experiment, figure 8-5. l'he time from 35 to 55 seconds into the run and around 65 seconds when no

forward progress is being made is characterized by few legs recovering, while the region between 10

and 20 seconds where the machine is moving fast has three legs recovering for much of the time.

°°° t LLta3

2 Legs supporting, from w830728.data

1

o ;o "time (seconds)

Figure 8-4: Total number of legs not supporting as a function of time for the w830728 experiment.

Just having three legs on the ground is not sufficient to guarantee a reasonable stance; after all the

three legs down might be all on one side of the machine. In order to demonstrate that the machine

maintained a reasonable stance we can look at the position of the center of support. This is a vector

sum of the six foot positions weighted by the vertical force measured on the leg. If the machine's

walking were perfectly static, the center of support would be indentical to the center of gravity.

Figure 8-7 shows the computed center of support for one of the machine's walks. The center of

support moves around due to dynamic effects. If the frame of the machine had come into contact

with the ground at one end, say, the computed center of support would have moved a substantial

t:xperimental Results 97

._ 6.0

5.5

5.0 s from w830728 data ."" "',_f

"'_4.5 Forward progrre_ /_ 123 p og ess ,,'"

0_ 4.03.5 456 progress ,'" "3.0

.. ....... . .......2.5

2.0 _''_'/1.5

1.0

.5

0 10 20 3'-0- 40 50 ,.,0 70 80 90time (seconds)

Figure 8-5: Forward progress for w830728 expenment. Notice that when the machine is moving fast the number of legsrecovering shown in figure 8-4 is large and _hen it is moving slowly the numbe, -eccve,,ing is small.

_a

2 Legs supporting from wg30808a.data

1

o ,bo ,'20 " '4otime (seconds)

Figure 8-6: Total number of legs not supporting as a funelion of time for the w830808a experiment. The spike down totwo legs supporting at about 60 seconds is the result of ,sampling latency in the data taking processes.

distance from the center of gravity in the other direction. For instance, if the machine were resting

on its frame on one end and on the two end legs at the other end, the center of support would be

computed as lying about 0.8 meters from the center of the machine.


Center of support, from w830728.data

Figure 8-7: Plot of the positions taken by the center of support for the machine during a walk. An outline ofthe bottom ofthe frame of the machine plus possible positions of the six feet are drawn to the _mc scale for reference.


8.3. Excitation

The excitation mechanism was designed to encourage the machine to develop rear-to-front waves

of leg recoveries. Figure 8-9 shows a timing diagram for the leg recoveries for three minutes of

walking done with the excitation mechanism disabled. While the machine did walk effectively, there

are no coHsistent patterns of rear-to-front recoveries visible. In contrast, figure 8-10 shows three

minutes of walking recorded the same day with the excitation mechanism enabled. It is difficult for

the untrained eye to perceive the rear-to-front waves in the samples of walking with excitation. It is

possible to define a measure for the amount of structure in a particular sample of walking. First we

compute the time delay between each recovery of a leg and the subsequent recovery of its frontward

neighbor for all four pairs of rear-front neighbors and create a histogram of these delays. If we

compute the ratio between the number of counts in the five bins surrounding the mode and the the

total number of counts, we have a measure of the waviness, so to speak, of the walk. In my walking

experiments the average measure for walking with excitation was .69 while the average measure for

walking without excitation was .34. The values of the wave measure are summarized in Figure 8-8.

Experiment Excit_tion Wave numberw830809a Yes 0.74w830728 Yes 0.67w830731 Yes 0.61w830809 No 0.47

g8308i6 No 0.32w830808a No 0.23

Figure8-8: Tableof experimentswithwavenumberassociated.The expermentsare presentedin orderot decreasingwavenumber.

8.4. Comparison of OWL walking program with another walkingprogramfor file SSA machine

During the course of the research reported in this dissertation, Dr. Mike Ullner of Sutherland,

Sproull, and Associates. Incorporated was working on a completely different walking program. This

program was implemented in assembly language and involved a rather different strategy for

controlling the machine. The driver specified the sequence of leg recoveries to the program before

beginning the walk. In this section I will compare the two programs in terms of size, complexity, and

performance.


lL__LX___YI lt_E1 H_E_J]_]H H_FLJLH_-L___J]J-LrI__rLI


t ,a l

_, H, NH,HR_ H,HH HN Hrill. N_J,right fr°,_lo 40 60 80 100 120 140 160 l J80

time (seconds)

Figure 8-9: Time trace of leg recoveries for 160 seconds of walking without excitation.

, . _ Legs recovering, fro.mw830809a.data

Ikl ,k.l N , kl, %1I_1 , N.I, ,right ro_It0 40 60 80 100 120 140 160 180

time (seconds)

Figure 8-10: Time trace of leg recoveries for 160 seconds of walking with excitation.

]he OWL walking program is 1057 lines of code in 10 different modules and the OWL runtirne

system is an additional 1439 lines of C code. In addition to the OWL program and runtime system,

however, the OWL compiler is 4064 lines of C code in five modules. The OWl, walking program

compiles to 8749 lines of C code.

The assembler walking program is 3490 lines of code in 16 modules. Three of those modules,

comprising 454 lines of code, are used to provide data service to the OWL system when it is running.

Only one assembler module, totaling 88 lines, is used solely by the OWI_ server; the other two

modulcs serve both walking programs. When providing service to the OWL system, the assembler


program gathers the raw sensor data and normalizes them and takes commands from the OWL

system and sends them to the valves.

We can separate the modules of the two programs into operational and non-operational groups,

where operational means that the code is executed during walking and non-operational means that

the code is executed before walking or afterwards. If we do this, the OWI_ program is composed of

300 lines of non-operational and 757 lines of operational code. The assembler program has 396 lines

of non-operational and 3094 lines of operational code. The OWI_ program has one fourth as many

lines of operational code as the assembler language program, something that contributes to

comprehensibility, maintainability, and modifiability.

On the control 68000, which runs with an 8 MHz clock, the time around the event queue for the

OWL walking program averaged about 25 milliseconds during walking. The I/O server on the

service machine, whic_hhas a 4 MHz clock, completes a cycle in about I0 milliseconds. The

assembler program was never timed during walking, but it was almost certainly quite a bit faster than

the OWL program, l_oth systems were so much faster than the hydraulic valves that neither of us

spent much effort on improving the runtime performance once we were convinced that it was

adequate to the task.

The OWl, program and runtime system compiled to about 30K bytes of code. ! allocated another

60K for data structures, though it turned out that no more than a few percent of that was ever used.

The assembler walking program was about l lK bytes.

Very little data were taken of the assembler program walking, partly because the computer that it

ran on had so little mmnory that there was no room to put it. As a result it is difficult to compare the

walking done by the OWl. program and the assembler program.

Both programs produced walking that seemed about the same in quality, whcJe quality is made up

of daings like speed, stance stability, and jerkiness. The assembler program could walk in either

direction, which the OWL program could not do. _Fhe OWL program could only walk in the

machine's tbrward direction, which had the driver riding backward. This is because there are some

valve settings that we considered inadvisable that were necessary to walk backward. One result of

being able to walk backward is that the assembler program could turn in place better because it could

have one side walking forward and the other backward. In addition, the OWL program never was

able to walk sideways very well, something the assembler program did rather better than it walked

forward, program could.


The distributed control implemented in the OWL program was able to produce walking with five

legs without ally modification to the structure of the program. The assembler language program was

also able to produce five-legged walking, but the pattern of leg recoveries had to be specified in

advance by the operator. I believe, though without any supporting data, that tile OWl. program was

better _ble to deal with terrain variation than the assembler program.

8.5. Summary

This chapter has reviewed results of experiments intended to verify the three independent

functions of the walking program. The experiments supported the hypotheses of the design, with the

interesting discovery that the excitation mechanism and the rear-to-front waves tha_ it produced was

not necessary for effective walking. The asynchronous semi-independent process structure of the

walking program was probed by commenting out a single process instance and verifying that the

machine continued to be able to walk. Stance control with the inhibition mechanism was examined

by computing the number of legs not recovering and by computing the center of support for the

machine. The effects of the excitation mechanism on the sequencing of legs was exhibited with

timing diagrams of the machine's walking behavior with excitation enabled and disabled.

The OWL walking program was compared with an entirely different walking program written by

another member of the SSA walking machine project. The two programs implement different

algorithms, in addition to being written in radically different languages.

The implementation of the walking program as a collection of asynchronous concurrent processes

permitted the same leverage to be achieved for the designer of a complex control system as modern

abstract data types permit for the control of sequential information processing programs. In addition,

this decomposition results in a limiting of the amount of intbrmation that each process has to include

in its calculations. Supposing a global algorithm had a computation cost O(n 2) where n is the amount

of sensor data in the system. If we had a partitioning of the system into k asynchronous subprocesses

each of which examined only 1/k of the sensor data and was O(m 2) for the data that it did examine,

then the computational cost of dae partitioned system would be n2/k compared to the n2 of the

unpartitioned system. Of course, this comparison ignores the overhead cost of the system to achieve

the concurrence and it also assumes that the global and local processes rely on computations with the

same asymptotic bounds. The point of dae comparison is to suggest that there are reasonable

assumptions under which the concurrent process decomposition is computationally superior to the

global control implementation.

Discussion and Conclusions 103

Don't look back. Something may be gaining on you.--- Leroy [Satchel] Paige

Chapter 9

Discussion and Conclusions

My original hypothesis was that I could decompose the walking task into a collection of simple

concurrent processes with control and knowledge distributed among them. I argued that insect

walking had this structure, based on results from researchers studying insect walking. In addition, I

argued that this approach was better because it assumed sparse communication, which is easier to

analyze and understand, and because it permitted simple programs to express the control algorithms.

This chapter will bring the various points of the hypothesis together with those results that support

them.

9.1. Distributed control

The simplicity of the basic behavior of a si_gle leg in insect walking is striking. Except for time

scale and terrain dctails, the leg rcpcats tile very same cycle over and over again.

With that observation in mind, I decided to try to develop a distributed control algorithm for the

machine. A single process, named Row by analogy with the repetitive motions in rowing a boat, is

responsible for the cyclic behavior for each leg. The control for the cycle is a finite state machine.

The coordination of the separate legs in walking is achieved by constraints communicated among

neighboring legs. These constraints affect the Row process by perturbing a threshold controlling one

transition in the state machine.

The walking program has three responsibilities: controlling the leg cycles, maintaining good

stance, and making forward progress. The Row processes are responsible for the leg cycles, the

inhibition mechanism is responsible for stance, and the excitation mechanism is responsible for

making progress. The strategy of assigning a process to each leg to control the simple cycles of

stepping was successful. The inhibition mechanism for maintaining stance worked well. The

excitation mechanism worked but it was not necessary for the development of walking behavior; the

machine walked effectively without excitation.


In addition to processes directly responsible for walking behavior, there are processes that ensure

that consistency is maintained in the hydraulic system and others that do housekeeping chores like

getting sensor data, keeping records, and interacting with the driver.

9.2. Scaling constraints on walking strategies

This section contains an analysis that attempts to shed some light on why six legged walking has the

structure that it does and on the scaling rules that dictate that large things walk dynamically and small

things statically. Animals like ants and cockroaches walk at all times with statically stable gaits, while

animals like dogs and horses can run with dynamically stable gaits. The hexapods are generally quite

small, while the quadrupeds are generally much larger. There is little overlap in size between the

statically stable walkers and the dynamically stable walkers, though some of the largest insects do

exceed the size of some of the smallest mammals.

9.L1. Why small things cannot balance

The body of an animal standing on legs can be considered to be an inverted pendulum, to first

order, Fur the purpose of understanding the control of balance, l'he control system response time

required to balance an inverted pendulum of length l is proportional to the square root of I. The

balancing response time required for a two meter tall person is about 50 to 100 milliseconds,

assuming that the person's t'eedback control system is designed to keep the body within ten degrees of

vertical. If a five millimeter tall insect is to balance to the same criterion, it must respond in two to

four milliseconds.

Given the response time required for balance, the question is whether the insect nervous system

can respond fast enough. There is evidence that it cannot. Neuron physiology, chemistry and

behavior are remarkably similar in arthropods and mammals. Roughly speaking, neuron switching

ume is fairly large: for a simple reflex, a short path between a sensor neuron and a motor neuron, in

arthropods the minimum response time is about three milliseconds [56]. Thus, if there were a simple

reflex capable of handling balance in insects it might be able to respond fast enough. If balance

required any more complex decision making, say involving multiple legs or multiple sensors or both,

it couldn't be performed by insects. This is illustrated in figure 9-1.

I)iscussion and Conclusions 105

_re__

Figure 9-1: Time tradeofl's for dynamic balance. The abscissa i,,;animal body si'eeand the ordinate is time. llae minimumresponse time required to maintain balance is propo_tional to the square root of size. as i',lustrated. Thenervous sys',cm response is composed of lwo parts: a portion associated with tt'.e switching time of neurons andanother p,,_tion that is proportional to the distance that the signals have to .travel. Iv,sects fall in the region tothe left Gf the crossing of the two curves and hence are p_obably not capable of d_cnmnicbalance. Large,'mimals like people or horses fall to the right of the crossing and are capable of balance.

9.2.2. Why small animals don't have to balance

On the other hand, _ere is a lot of evidence that insects don't need to balance. Studies of the

scaling properties of vertebrate skeletons [50, 1] have shown that their limitations are set by the

stresses and strains imposed by the weight and size of the animals that they support. The potential

energy due to gravitation for an animal scales as the fourth power of the body size, and the limitations

of the materials from which skeletons are constructed arc such that this energy for large animals like

people and horses is significant compared to the energy necessary to damage the skeleton and hence

threaten the life of the animal. Similar study of insect nervous systems shows that they are far

stronger than weight loads dictate [7]. Speaking more intuitively, if you take an ant and drop it a

distance ten times its body height, it will walk away. If you take a person and drop him ten times his

body height, you'll probably be arrested formurder.


9.2.3. Prognosis for walking machines

It is interesting to note that no large land animal has more than four legs. For statically stable

walking, six legs is the minimum number required to permit the legs to achieve duty cycles of .5, thus

permitting the fi_steststatically stable gaits. Duty cycle is defined as the ratio of time on the ground to

total step cycle time. For dynamically stable gaits, the ability to balance makes duty cycles below .5

possible, hence permitting the animal to get by with fewer than six legs. An open question is whether

the capabilities reqt, ired to make a large six legged machine walk with static gaits wouldn't also be

adequate to make a similar machine walk dynamically. If so, there would be no point in building a

large statically stable machine.

9.3. Natural motions

A natural motion of a manipulator is one that can be achieved by varying only one of the

mechanism's degrees of freedom, as illustrated in figure 9-2. No complex behavior is required

involving coordinated motions by several actuators. A natural motion for a task is a path that some

part o[' the mechanism must take if the task is to be performed correctly. A great deal of work in

robotics has been concentrated on kinematic solutions of mechanisms and path planning because the

natural motions of manipulators and the natural motions flnposed by tasks are usually not the same.

The kinematic solutions and path planning are done in an effort to use the natural motions of the

mechanism to achieve the natural motions of tasks.

By way of an example, consider a manipulator using a rasp to shape a piece of wood as illustrated

in figure 9-3. The rasp must be scraped forward across the surface to be abraded. After each

abrasion stroke, the rasp must be returned to the starting position. The abrasion stroke is a 'natural

motion' of the rasping task because it imposes constraints on the path of the rasp but the return is not

a natural motion since it does not hnpose any such constraints.

Little attention has been paid in recent robotics research to the question of building mechanisms

with natural motions appropriate to the intended tasks. Rather, effort has been expended on

building fully general mechanisms in which there is no advantage to using the natural motions and

then using programming to achieve the task's natural motions. Fully general systems are very flexible

but the cost of this flexibility is inefficiency. The first soume of inefficiency is mechanical: when

motion is produced as the sum of the motions of multiple actuators, each actuator must be able to

overcome the forces imposed upon it by the actions of the others while moving. I.ocking joints and

relying on the structure of the mechanism to withstand motion stresses is a technique widely observed

l)iscussion and Conclusions 107

/'1

o

Figure 9-2: Natural and unnatural motions of an arm. 'llae iefl figure illustrates a natural motion for the two link, twojoint manipulator, The right figure illustrates a straight line motion that is not natural for this mechanism andsuggests the manipulator motions that are required to produce it.

Figure 9-3: Natural motions for a task. The left figure illustrates tb.e natural motion of a rasp when the task is to removematerial from the corner of the rectangular object. A rasp has the property of abrading when moved across thesurl:ace irt one direction, but not in the other. "lhe right figure suggests some of tt:e possible motions that amanipulator might use to repo_ition the rasp for the next abra,;ion stroke. "l_e manipulator illustrated infigure 9-2 does not provide the natural motion of the rasping lask as a natural motion of the manipulator; adifferent mechanism is needed if the match isdesired.

in animal limbs, and it results in superior mechanical efficiency. The second source of inefficiency is

computational. To make a mechanism conform to some path that is not a natural motion tbr the

mechanism requires the multiple evaluations of the inverse kinematic solution for the mechanism.

Feedback and dynamic control complicate this even further.

One of the key reasons why the SSA walking machine helped stimulate the development of

computationally efficient control strategies is that it provides as a natural motion of the machine the


key motion that is natural to the walking task. This key motion is the horizontal drive sta'okeof the

leg. The result is that our dlinking about control of walking could focus on higher level issues and

could ignore die leg kinematics and other details.

9.4. Conclusions

The distributed control approach to walking worked. The processes that controlled individual legs

were loosely cot_p!ed, not c_mpletely independent, but the communication between thenl was sparse.

The inhibition mechanism f_)rmaintaining stance worked. Rear-to-front waves of leg recoveries were

established with the excitati(m mechanism, though it turned out that the machine walked just as well

without the rear-to-fl'ont waves.

The OWl. language made the implementation of loosely coupled processes relatively simple. The

walking program was small enough to be easily understood and maintained because the bookkeeping

for keeping the order of execution flexible did not have to be done while writing tim walking

program. OWL should be useful for implementing real time control programs tbr other tasks that

can be decomposed into loosely coupled processes. I think that many more tasks can be decomposed

in this way than have been to date.

There is a feature of OWL dmt should have been included in the original design. The preemption

achieved by the alert mechanism is to() total for some circumstances. 1 would add an intermediate

level of preemption that would force a suspension of the concurrent siblings, not a complete

ten'nination. If I had put this capability into OWL, the handling of the hydraulic system by the

process keeping watch on the compensator and by the process keeping track of the legal

combinations of valve states would have been greatly simplified.

9.5. Programming: real time and robotic systems

In this research I designed and implemented an operating system, a compiler, a programming

language, and an application program. They were designed and implemented concurrently. As a

result, I was able to understand the relationships between decisions taken at each level and adjust the

designs as I progressed. Because of the narrow intent of the project, I was able t,a trade generality for

power in the design of the language and of the operating system. The language dispensed with

sophisticated data structures and the operating system had no file system or protection mechanisms.

OWL is extremely simple, without sacrificing any expressiveness or power. In OWL a single

Discussion and Conclusions 109

control construct, the sequence, provides the semantics of two traditional control constructs: blocks

and loops. It does this without, to my mind, any artificiality or inconvenience or baroqueness.

Similarly, the OWI. concurrence provides the semantics of the If ... Then ... Else and of the ease

constructs of traditional languages ... with CoBegin and CoEnd semantics thrown in for good

measure. There are inefficiencies in the use of concurrences in this way, but this could be fixed either

by a sufficiently clever compiler or by the introduction of an alternation primitive to the language.

I found that OWL encouraged a programming style that was quite different from that produced by

traditional sequential languages like C and Pascal, but without requiring a new set of intuitions about

programming. This style included the creation of many simple processes for situations in which I

would have written one very complex program in the past. OWl., by not requiring the programmer

to do bookkeeping of process identifiers, makes programming of systems with many concurrent

processes easy.

The mechanisms for controlling concurrency, particularly preemption with alert, were extremely

comfortable to use. This made the programming and debugging of asynchronous concurrent systems

surprisingly simple. Scope rules in modern programming languages permit programming styles that

take ad'vantage of abstract dam types and information hiding. The scope rules in OWL encouraged a

similar approach to asynchronous concurrent processes.

9.6. Directions for future research

There are darc¢ possiblc directions that this research can lead. It can lead to more walking machine

research, more real time and concurrent programming research, and more robotics and control

strategy research.

Hydraulic machines of this size with six legs don't work very well with spool valves. Servo valves

might increase the responsiveness and ease of control, but the extra capability might make such a

machine capable of dynamic stability. If this were so, then there would be no point in large statically

stable machines.

It is possible to achieve reasonable real time performance with a high level language if that

language is designed to provide the control flexibility and performance required. As the demand for

real time systems increases and the cost of computer hardware decreases and the salaries of computer

programmers increase s , the need for more sophisticated tools for implementing real time systems

5I hope.


will increase. In the future, systems may be prototyped using languages like OWI, and only after the

system is functioning will any hand optimization be done. Until tools of this sort become more

widespread system builders implementing real time systems will continue to write in assembler

language.

Control strategies based on decomposition of complex integrated tasks into collections of loosely

coupled independent processes merit further exploration. This dissertation demonstrated that the

strategy works for the walking task. I believe that there are other tasks that can be decomposed in

this way, with considerable advantage to the implementers and maintainers of the resulting systems.

Walk ing program code lI1

l(xample is always more cfficacious than precept.--- Samuel,lohnson

Appendix A

Walking program code

A.I. Overview

This appendix contains the code for the final version of the OWl. walking program. The scribe file

was generated by taking the OWL code and trimming out the history comments, making the

keywords bold and the variables italic. The program is composed of ten separate modules. The

design of the program is discussed in Chapter 5. The OWl. language is described in Chapter 7.

Walk.owl This contains the main process, the row process, plus some service processes.

Load5.owl Tt_is is the module containing the load process. The 5 in the name indicates thatthis was the fifth, and final, version of the code. This process, along with Drive7,Unload3, and Recover6, is used by the row process, it accents the name of a leg as

an argument and tenninates when the leg is le,aded acco,_ding to the definitiongiven in Chapter 5.

Drive7.owl This module contains the code for the drive process. Drive moves the leg rearwardi_ the energize setting until the leg is ready to recover.

Unload3.owl This module contains the code for the unload process. Unload lifts its leg until thevertical force indicates that the leg is unloaded.

Recover6.owl This module contains the code for the recover process. Recover repositions the leg

and foot in preparation for the next drive stroke. Recover moves the hip joint toits target position while recoverknee is responsible for returning the knee joint tothe middle of its travel.

Waveinit.owl This module contains the declarations for most of the variables that control the

properties of walking. These include parameters that control the size of steps, thedefinitions of which legs are neighbors, the loaded and unloaded threshoh:ls, andthe inhibition and excitation variables. The customize process, using many

instances of watch and update, permits the user to alter any of the parameters.

The initrow process handles the initialization befere walking, including a call tocustomize.

Sensors.owl This module contains the declarations of the sensor variables that the OWL


program uses to hold the data gathered by the sensor processor. In addition, itcontains the definitions for a process that tJpdates the sensor variables. Thesnapsensors process is used in initialization to make sure that all of the sensorwlriables contain reasonable values belbre starting the walking program.

Data.owl This module defines the processes that are used in taking data and sending it up tothe Vax ti)r archiving and analysis. The process gather, defined in walk.owl, uses

snapshot.

Trouble.owl Troubleservcr and hydraulic, defined in this module, are responsible formaintaining hydraulic system consistency. The deadman process monitors thetrigger on the joystick, enabling the energize valve setting only when the trigger isdepressed.

Comps.owl Thi_ mo,-tule contains the definition of the process responsible for getting thecompensator back to the middle when it runs uut of travel.

A.2. walk.owl

define report( rvw. co/), local( at',pn, ev, sa, ba ):{ Count free list contents as a check on the run time system }< countfl'ec( at-,pn, ev, sa, ba );

printf( "\r\n,_,l(: %4d, PN: %4d, EV: %4d, SA: %4d, BA: %4d", ar, pn, ev, sa, ba);done( true )

>

define gather:.{ Take data on the six legs }< snapshot( 1);

snapshot( 2 );snapahot( 3 );snapshot( 4 );snapshot( 5 );snapshot( 6 )

>

define monitor( leg ), local( oldstate ):< when( ( state[ &g ]! = oldstate) );

oldstate = state[ leg ];printf( "%d%c", leg, oldstate )

>

Walking program code 113

define rcm( leg ):

{ Cycle a leg through the step cycle }[ { Stop thc leg if there is trouble }

< when( ( ( apytrouble != 0 ) && ( hipvalve[ leg ] = = "E' ) ) );hhold( leg ) >;

{ Take care of the knec joint }( [ < bothwhen( ( (J_[ leg ] >= lightly ) && ( airmode = = 0 ) ) II

( ( stale[ leg ] = = 'I)') && ( airmode != 0 ) ) );kcrab(/eg );u hen( ( (fz[ leg ] ( lightly ) && ( airmode = = 0 ) )II

( ( state[ leg ] != '1)' ) && ( ain_lode != 0 ) ) );done( true ) >;

< both;_hen( ( (fz[ leg ] ( lightly ) && ( aimlode = = 0 ) ) II( ( stale[ leg ] != 'D' ) && ( ainnode != 0 ) ) ):

[ < both( ( ( j._[leg ] ) = iighto' }&& ( ainnode = = 0 ) ) II( ( state[ leg ] = = 'I)' ) && ( airmode != 0 ) ) ) >;

< bothwhen( ( state[ leg ] = = 'R' ) );recoverknee( leg, recover-x-target );done( true ) >;

< when( ( kneevalve[ leg ]! = 'H' ) );khold( leg ) > l;

done( true ) > ] >;

{ Keep the hydraulic system flags up to date }to,draulic( leg );{ Show what's happening on the console }monitor( leg );{ Main sequence in the row process }< state[ leg ] = 'L';

load leg );excite[ leg ] = 0;excite[ afmeighbor[ leg l] = excite[ aftneighbor[ leg] ] + excitation;inhibit[ crossneighbor[ leg] ] = inhibit[ crossneighbol[ leg]]" #zhibition;inhibit[ qftneighbod leg ] ] = inhibit[ aftneighbol[ leg ] 1- inhibition;inhibit[fi)reneighbor[ leg ] ] = ipd_ibit[jbreneighbo_[leg ] ]- inhibition;state[ leg I = 'D';drive( leg, drive--y-target[ leg 1,drive-x-target );inhibit[ crossneighbot[ leg ] ] -- iuhibi;[ crossneighbot[ leg I ] + inhibition;inhibit[ aftneighbot[ leg ] ] = inhibill @neighbor[ leg ] ] + inhibition;inhibit[foreneighbor[ leg ] ] = i_thibit[foreneighbor[ leg ] ] + inhibition;state[ Dg ] = 'U';unload( leg, unloaded);state[/eg ] = 'R';recovel( leg, recover-y-target[ leg ], recover-z-target, recover-x-target )>

1


define holdall:

{ Put all valves in hold }< hhold( l ); hhold( 2 ); hhold( 3 ); hhold( 4 ); hhold( 5 ); hhold( 6 );

khold( 1 ); khold( 2 ): khold( 3 ); khold( 4 ); khold( 5 ); khold( 6 );sendvalvccommands; {This makes holdall an immediate command. }

done( true )>

define nzain, local( i = 1, spins = O, tl, t2, ttot = 0 ):< initrow; { Initialize the walking parameters }

inittrouble; { lqitialize the trouble flags }holdall: { Make sure everything is stopped }hzittrace; { Initialize the table Ibr data taking }

snapsensors; { initial set of sensor data }startclock; { Make sure the real timc clock is running }

beep; { Ring the console bell }[ {The main concurrence }

< sendvalvecommands >; { Keep sending new commands to I/O processor }sensors; { Keep the sensor values up to date }

< { Report selected sensor valucs when requested }when( ( dial = = 10 ) );i=1;

< printf( "\r\nI,eg%d: Y:%6d Z:%6d H:%c K:%c FZ:%6d I:%6d",i,)_ i ], z[ i ], hipvalve[ i 1, kneevalve[ i ],fz[ i ], inhibit[ i ] );

i= i+ 1;done((i>6)) >;

_hen( ( dial != 10 ) ) >;< { Report the states of all six legs when requested }

_hen( ( dial = = 7 ) );i= 1;printf( "<" );< printf( "%d%c", i, state[ i ] );

i= i+ 1:

done( ( i > 6 ) ) >;printff ">" );when( ( dial != 7 ) ) >;

< { Keep measures of run time performance }time( tl );suspend;time( t2 );ttot = trot -F t2- ll;

spins = spins-F 1 );troubleserver, { Keep anytrouble up to date }

compserver; { Mother to service the compensator }


{The main walking control processes. Six leg rowers plus the }

{ two cross excitation processes }ro_( 1 ); { Row leg 1}

row( 2 );row( 3 );< { Excitation to leg 3 fi'om leg 4 }

when( ( excite[ 3 ] = = 0 ) && ( state[ 3 ] = = 'D' ) &&( )'f 3 ] < = ( recover-y-target[ 3 ] + drive-y-target[ 3 ] ) / 2 ) )[I( ( state[ 4 ] = = 'l)') && ( trouble[ 4 ]! = 0 ) ) ) );

excite[ 4 ] = excite[ 4 ] + crossexcita/ion;when( ( excite[ 4 ] - = 0 ) ) >;

< { Excitation to leg 4 from leg 3 }when( ( excite[ 4 ] = = 0 ) && ( state[ 4 ] = = 'D' ) &&

( y[ 4 ] ( = ( recover-y-target[ 4 ] + drive-y-target[ 4 ] ) / 2 ) )I[( ( state[ 3 ] = = 'l-Y ) && ( trouble[ 3 ] != 0 ) ) ) );

excite[ 3 ] = excite[ 3 ] + crossexcitation;when(( excite[ 3 ] = = 0)) );

row 4 ); { Row leg 4 }row(5 );row( 6 );{ More service routines }< { Report on the trouble flags when requested }

when( ( dial = = 11 ) );

printf( "\r\nTrouble: %d = %d %d %d %d %d %d %d %d",an.vtrouble, trouble[ 1 ], troub/e[ 2 ], trouble[ 3 ], trouble[ 4 ],troubie[ 5 ], trouble[ 6 ], trouUc[ 7 ], trouble[ 8 ] );

printf'( "\r\nI.l= %d I_LI:%d PL: %d PU: %d", llJlag, luflag, pIflag, puflag );printf( "\r\nairmode%d", airmode );when( ( dial != 11 ) ) );

< { Toggle the airmode flag }when( ( dial = = 9 ) );airmode = ( airmode != 0 ) ? 0 : 1;inittrouble;

printf( "airmode->%d", aitmode);when( ( dial!= 9 ) )>;

< { Start data taking }when( ( thumb!= 0 ) );when( ( thumb = = 0 ) );inittrace;

[ < bothwhen( ( thumb != 0 )II( indx >= tmcesize- 100 ) ); { Quit data taking }

printf( "\r\ngather done: %d", imtx / 11 );when( ( thumb = = 0 ) );done( true ) >;

< printf( "gathering" );gather; { Actually take data }both( true ) > ] >; { In case we run out of data space }


< { Quit the walking program }_hen( ( cooteehat != 0 ) );holdall;when( ( cooleehat = = 0 ) );both( true ) >;

deadman { The deadman switch watcher }

1;{ The main concurrence ends here }{ Now wrap up, upload any data, and exit. }printt'( "%d points taken.", indx / 11 );printf( "\r\nUpload trace dam to the vax?" );printf( "\r\nThumb to upload, hat to quit." );

[ { Clean up, upload data, etc }sensors; { Need 1/0 fi'om tile keypad and joystick }< when( ( cooleehat != 0 ) );

printR "Done." );bothwhen( ( cooleehat = = 0 ));

quit;done( true ) >;

< both_vhen( ( thumb!= 0 ) );

printf( "Sending data to the vax." );quit;tovax;done( true ) > ];

report( 8, 10 );printf( "\r\n%d spins were timed, total time was: %d", spins, trot );done( true )

>end

A.3. Load5.owl

define load( leg):< when( ( plflag = = 0 ) II( dial = = leg ) ); { OK to load or else override }

[ < both( ( (fz[ leg]> = loadtop ) II{ Max good force }( z[ leg ] < = stancebottom )II { Too far down }{ spring region }(J_[/eg ] >= ( ( ( z[ leg]- stancebottom ) * stancefactor) + !oadbottom ) ) 1[( ( ( el[ leg ] >= toolong ) II( dl[ leg ] > = toolong ) ) && (fz[ leg ] > = lightly ) ) II( ( z[ leg ] < = stancetop ) && ( ainnode != 0 ) ) I[{ Test mode }( dial = = leg ) ) ) >; { Bypass }

< when( ( ( hipvalve[ leg ] != 'P' ) && ( trouble[ 7 ] = = 0 ) ) );hplace(leg) > 1;

hhold( leg );when( ( dial!= leg) );done( true )

>end


A.4. Drive7.owl

define drive( leg, ytarget, xtarget ):< when( ( ato,trouble = : 0 ) [[( dial = = leg ) );

henergize( leg );[ _, both( ( dial = = leg )0[

( (fz[ leg ] ( = ( safeload- inhibit[ leg ] + excite[ leg ] ) ) &&( ( ){ leg ] <= ( ( recover-y-target[ leg ] + drive-y-target[ leg ] ) / 2 ) ) [[( x[ leg ] >= xtarget ) [[( x[ leg ] (: - xtarget ) ) ) )>;

< when( ( ( ( e4 leg ]4: tooshort )[[( d/[ #g] >= too/ong) [I( 3{#g ] < = ),target ) ) && ( ato,trouble = = 0 ) ) );

trouble[ leg ] = true;

printf( "%dX", leg);Mwn( ( ( e,1leg ] > tooshort ) && ( dll leg ] <.toolong ) &&

( 3{/eg ] > ),target ) && ( x[ leg ] < xtarget ) && ( x[ leg ] >- xtarget ) ) );trouble[ leg] = false;

printf( "%all)", leg ) >;< when( ( ( hipvalve[ leg ] != 'E' ) && ( anytrouble = = 0 ) ) );

henergize(leg) > ];when( ( dial!= leg ) );trouble[ leg] - false;done( true )

>end

A.5. Unload3.owl

define unload( leg, unloaded):< when( ( lujiag-- : 0)II( dial = = leg) );

[ < both( (J_[ leg ] < = unloaded ) [I( dial = = leg ) ) >;< _hen( ( ( hipvalve[ leg ] != 'L' ) && ( trouble[ 7 ] = = 0 ) ) );

hlift(/eg ) > ];hhold( leg );when( ( dial!= leg) );done( true )

>end

A.6. Recover6.owl


define reco:,erknee( leg, target ):

[ ( bothwhen( ( .x[leg ] >= target- 3000 ) && ( x[ leg ] <= target + 3000 ) );khold( leg); { Knee is done recovering }done( true ) >;

< bother'hen( ( )_[leg ] < = target- 3000 ) );

[ ( when( ( ( kneevah, e[ leg ]! = 'R' ) ) );kright( leg ) >;

< bothwhen( ( x[ leg ] > = target- 3000 ) );khold( leg );done( true ) ) ];

done( true ) >;< both,_hen( ( x[ #g ]) target + 3000 ) );

[ < when( ( ( kneevalw_[leg ] !: 'L' ) ) );kleft( #g ) );

< both_'hen( ( x[/eg ] <= target + 3000 ) );khold( leg );done( true ) ) ];

done(true) >l


define recoveff Leg, yt, zt, kt ), local( ct, dr, tO,tl ):< et = yt - zt: { Target cylinder position }

dt = - yt - zt; { Target other cylinder position }[ < both(( dial = = leg)[I { Manual bypass }

( ( el[ leg ] > = et ) && ( d/[/eg ] < =dt ) ) I[ { Overshot a bit, ok to quit }( ( et < = el[ leg ] + fi_zz ) && ( el[ leg ] < = et + fuzz ) && { On ... }( dt < = dl[ leg l + fuzz ) && ( dl[ leg,] <= dt + fuzz ) ) ) >; { ... target }

< when( ( hipvalve[/eg ] = = 'D' ) );time( tO);< time( tl ); { Delay 250 milliseconds }

dane((tl>tO+ 25)) );both_hen( (J2[ leg ] >: lightly ) ); { Stop if we hit the ground }done( true ) >;

< [ < bothwhen( ( ( el[ leg] >= et ) && ( dl[ leg ] >= dt ) && ( llflag = = 0 ) ) );{ We are in the lift region ... both cylinders are too long }[ < when( ( ( hipvalve[ leg ]! = 'L' ) && ( trouble[ 7 ] = = 0 ) ) );

hlift(leg)>;< both_rhen( ( e/[/eg ] < = et ) );

hhold( leg );done( true ) > ];

done( true ) >;< bothwhen( ( ( e/[ leg ] < = et ) && ( all[leg ] <= dt ) && ( plflag = = 0 ) ) );

{ We are in the place region ... both cylinders are too short }[ < when( ( ( hipvalve[ leg ]! = 'P' ) && ( trouble[ 7 ] = = 0 ) ) );

hplace(leg) >;< both;_hen( (dl[ leg] > = dt ) );

hhold( leg );done( true ) > ];

done( true ) >;< bothwhen( ( ( c/[ leg ] <= et ) && ( dl[ leg ] > = dt ) && ( llflag = = 0 ) ) );

{ We are in the t:p-d,)wn region }[ < when( ( ( hipvalve[ leg ] l= 'U' ) && ( trouble[ 7 ] = = 0 ) ));

hup( leg ) >;< both( ( dl[ leg ] < = art,+ fuzz ) ) > ];

hhold( leg );when( (plflag = = 0 ) );[ < when( ( ( hipvah,e[ leg ] [= 'D' ) && ( trouble[ 7 ] = : 0 ) ) );

hd_wn(leg) >;< both( ( el[ leg ] )= et- fuzz ) ) > ];

done( true ) > ] > ];hhold( leg);_hen( ( dial!-: leg) );done( true )

>end


A.7. waveinit.owi

global( recover-y-target[ 6 ], { fore-aft target fi)rhip }

recover-z-target, { up-down target for hip }recover-x-target, { in-out target for knee }drive-y-target[ 6 ], {Encrgize direction target }drive-x-target, { Crab dircction target }engine-drive, { l.cgs 3 & 4 l)rive target }engine-recover, { I.eg:_3 & 4 P,ecover target }middle-drive, { legs 2 & 5 l)rive target }middle-recover, { legs 2 & 5 Recover target }

driver-drive, { l_egs 1& 6 Drive target }driver-mcovel; { l.egs 1& 6 Recover target }airmode, { Testing in air flag }safeload, { I.eg with this much won't let machine fall }unloaded, { l.ess force than this means leg is unloaded }lightly, { Just touching the ground }loadtop, { Maximum recommended load for a leg }loadbottom, { Bottom load for good stance }stancetop, { Top position for good stance }stancebottom, { Bottom position for good stance }stanc_fTctor, { Slope of load/position curve }toolong, { Maximum extension of a cylinder }tooshort, { Minimum extension of a cylinder }

inhibit[ 7 ], { The seventh position is for 1 and 6, which have no }excite[ 7 ], { fore/aft neig:hbors to inhibit or excite. }inhibition, { llasic inhibition amount }excitation, { Basic excitation amount }crossexcitation, { I.eg 3 - [.cg 4 excitation }chr, { Place for console character input }#_pt, { Place for console integer input }afmeighbor[ 6 ], { Leg number of aft neighbor }foreneighbot[ 6 ], { l.eg number of fore neighbor }crossneighbor[ 6 ], { l.eg number of crosswise neighbor }

fuzz, { Error tolerance }minrise, { Minimum amount to raise leg during unload }

state)[6 ] { States for all six legs })

define watch( varstar parm, string, row, col ), local( last = -99999 ):{ Redisplay any parameters that change. For menu system. }< when( ( last != parm ) );

last = parm;cursor( row, col);printf( string, parm )

>


define update( var pann, dig, row,col ):{ Update selected parameter. For menu system. }( bothwhen( ( chr = = dig ) );

cursor( row, col);

getline( row, col);geti( parm );beep;cursor( row, col);

printf( .... );done( true )

>

define customize:

{ Present menu for user to modify walking parameters. }< clearscreen;

cursor( 24, 5 ):printf( "Type 'q" to continue. Single character to select parameter to modify" );[ watch( engine-recover, "1 Engine Y Recover: %8d", 1, 5 );

watch( middle-recover, "2 Middle Y Recover: %8d", 2, 5 );watch( driver-recover, "3 Driver Y Recover: %8d", 3, 5 );

watch( recover-z-target, "4 Recover Z target: %8d", 4, 5 );watch( recover-x-target, "5 Recover X target: %8d", 5, 5 );watch( engine-drive, "6 Engine Y Drive: %8d", 6, 5 );watch( middle-drive, "7 Middle Y I)rive: %8d", 7, 5 );watch( driver-drive. "8 Driver Y Drive: %8d", 8, 5 );

watch( drivc_x-target, "9 Drive X target: %8d", 9, 5 );watch( unloaded. "a Unloaded threshold: %8d", 10, 5 );walch( minrise, "b Minimum rise: %8d", 11, 5 );watch( loadtop, "c l_oad Top: %8d", 12, 5 );watct_( loadbottom, "d Load Bottom: %8d", 13, 5 );watch( stancetop, '% Stance Top: %8d", 14, 5 );watch( stancebottom, "fStance Bottom: %8d", 15, 5 );watch( safeIoad, "g Sate l.oad: %8d", 16, 5 );watch( inhibition, "h Inhibition: %8d", 17, 5 );watch( excitation, "i Excitation: %8d", 18, 5 );watch( crossexcitation, "j Cross Excitation: %8d", 19, 5 );watch(fi_zz, "k Fuzz: %8d", 20, 5 );watch( toolong, "1Too Long: %8d", 21, 5 );watch( tooshort, "m Too Short: %8d", 22, 5 );watch( lightly, "n Light I.oad: %8d", 23, 5 );


< [ ( getc(chr) );

update( el_gine-recover, '1', 1, 40 );update( middle-recover, '2', 2, 40 );update( driver-recover, 'Y, 3, 40 );update( recover-z-target, '4', 4, 40 );update( recover-x-target, '5', 5, 40 );update'( engine-drive, '6', 6, 40 ):update( middle-drive, '7', 7, 40 );update( driver-drive, '8', 8, 40 );update( drive-x--target, '9'. 9, 40 );update( unloaded, 'a', 10,40 );update( minrise, 'b', 11, 40 );update( loadtop, 'c', 12,40 );ut;_km:'(h)adbottom, 'd', 13, 40 );update( stancetop, 'e', 14, 40 );update( stancebottom, 'f', 15, 40 );update( safeload, 'g', 16, 40 );update{ inhibition, 'h', 17, 40 );updale( excitation, 'i', 18, 40 );update( crossexcitation, 'j', 19, 40 );update(fuzz, 'k', 20, 40 );update( toolong, T, 21, 40 );update( tooshort, 'm', 22, 40 );update( lightly, 'n', 23, 40 );< both( ( chr = = 'q' ) ) >;( { Rctransmit previously taken data }

botimhen( ( chr = = 's'));clearscreen;

cursor( 5, 10 );printfl "Salvage data ... ");cursor( 7, 10 );

printf( "Present value of indx: o_._,,/ou , indx );cursor( 9, 10 );

printf( "Enter indx value [ %(t ] ", indx );cursor( 9, 40 );

getline( 9, 40 );geti( inpt );indx = (inpt != 0 )? inpt" indx;tovax;

chr = 'q';done( true ) > ];

both( ( chr = = 'q') );chr = " > ];

chr = ' ",

done( true )>


define initrow, local( i = 1 ):

{ Set up all the defaults and then pennit file user to alter them. }

( recover--z-target = O;recover--x-target = O;

drive-x-target = 7500;

engine-drive = -8000;

engine-recover = O;middle-drive = -2500;

middle-recover = 2500;

driver-drive = O;

driver-recover = 8000;

airmode = O;

inittrouble;

qftneighbor[ 1 ] = 7;

aftneighbot[ 2 ] = 1;

aft,eighbor[ 3 ] = 2;

@neighbor[ 4 ] = 5;

afmeighbor[ 5 ] = 6;

afmeighbop[ 6 ] = 7;

fi_reneighbot[ 1 ] = 2;

jbmneighbot[ 2 ] = 3;

foreneighbot[ 3 ] = 7;

joreneighbor[ 4 ] = 7;

fi)reneighbor[ 5 ] = 4;

foreneighbor[ 6 ] = 5;crossneighboJ[ 1] = 6;

cmssnelghbot[ 2 ] = 5;

crossnetghbot[ 3 ] = 4;

crossnetghbol[ 4 ] = 3;

crossneighbor[ 5] = 2;

crossnet ;hbot[ 6 ] = ] ;

safeload = -1000;inhibition = O;

excitation = O;

crossexeitation = O;

fuzz = 500;


< inhibit[ i] = 0;excite[ i] -- 0;i= i+ 1;

done( ( i> 6 ) ) >;unloaded = 800;

farenoughup = 500;minrise = 2000;

lightly = 1500;loadtop = 10000;loadbottom = 3000;

stancetop = 2000;stancebottom = 0;

toolong = 8500;tooshort = -8500;

customize; { Menu for user to change parameters }{ Now initialize derived values }i= 1;< inhibit[ crossneighbolf i ] ] = inhibit[ crossneighbor[ i ] ] + inhibition;

inhibit[ aftneighbor[ i]] = inhibit[ aJh_eighbot[ i ] ] + inhibition;inhibit[ foreneighbor[ i] ] = inhibit[ fi, reneighbor[ i ] ] + inhibition;i= i+ 1;

done( ( i> 6 ) ) >;excite[ 4 ] = 500;excite[ 3 ] = 500;stancefactor = ( loadtop - loadbottom ) / ( stancetop - stancebottom );drive-y-target[ 1 ] = driver-drive;drive-y-target[ 2 ] = middle-drive;drive-y-target[ 3 ] = engine-drive;drive--y-target[4 ] = engine-drive;drip:e-y-target[ 5 ] = middle-drive;drive--y-target[ 6 ] = driver-drive;recover-y--target[ 1 ] = driver-recover;recover-y-target[ 2 ] = middle-recover;recover-y-target[ 3 ] = engine-recover,recover-y-target[ 4 ] = engine-recover,recover-y-target[ 5 ] = middle-recover;recover-y-target[ 6 ] = driver-recover;state[ 1 ] = 'H';state[ 2 ] = 'H';

state[ 3 ] = 'I-t';state[ 4 ] = 'H';

state[ 5 ] = 'H';state[ 6 ] = 'H';done( true )

>end


A.8. sensors.owl

global( x[ 6 ], { X position ... knee in-out direction }

y[ 6 ], { Y position ... hip fore-aft direction }z[ 6 ], { Z position ... hip up-down direction }e/[ 6 ], { l.ength of engine end hip actuator }d/[ 6 ], { l.ength of driver clad hip actuator }fx[ 6 ], { X force ... sideways load }55{6 ], { Y fc)l'ce... drive thrusts }fz[ 6 ], { Z force ... weight }kneeva/ve[ 6 ], { The valve settings read from the server }hipvalve[ 6 ], { 'i'he valve settings read from the server }rcv, { recovery pump displacement }crb, {crab pump displacement }d123, { 123 drive pump displaccment}d456, {456 drive pump displacement }dial, { what button of keypad is pushed }stick, { joystick handle raw data }cooleehat, { Position of joystick hat }

firststep, { tirst step of two stage switch pushed }sccothtstep, { sccoJld stcp of two stage switch pushed }thumb, { thumb button pushed }

trigger, { trigger pulled }comp, { compe_-_satordisplacemcnt}compknee, { compensator 'knee' v_dvesetting }comphip { compensator 'hip' valve setting }

)

define sensorserver( i ):{ Keep thc sensor values updated for one leg }< gctx( x[ i], i);

gety( ){ i], i );getz( z[i], i);e/[ i ] = y[ i ]- z[ i ]; { compute the engine end actuator }d/[ i ] = - 3{ i ]- _7[i ]; { compute the driver end actuator }getfx(fv[ i1, i );getfy()5{ i ], i );getfz(fz[ i l, i );getvalve( kneevalve[ i], hipvalve[ i ], i)

>


define sensors:

{ Sensors for all six legs plus touchtone keypad and joystick }

[ sensorserver( 1);_ensorserver(2 );se,sorservet( 3 );se,sorserver( 4 );se,sorserver( 5 );sensorserver( 6 );< getter( rcv); . { Recovery pump displacement }

getcrb( crb ); { Crab pump displacement }

get123( d123 ): { 123side drive pump displacement }get456( d456 ); { 456 side drive pump displacement }getdial( dial); { touchtone keypad- key pressed }getstick( stick ): { Undecodcd joystick value }

{ l)ecodedjoystick values }readstick( cooleehat, firststep, secondstep, thumb, trigger );getcomp( comp ); { Compensator position }

{ Compensator valve settings }

getcompvalves( compknee, comphip ) >l

define snapse,sors, local( i = 1 ):{This makes sure that all the sensor values have at least one valid }{dc_tasample in each. It is needed because the ,,;ensorsprocess takes }{ a little while to fire up and this sometimes causes problems. }< getter( rcv );

getcrb( erb );get123( d123 );get456( d456 );getdial( dial );getstick( stick );readstick( cooleehat, firststep, secondstep, thumb, trigger);getcomp( comp );

getcompvalves( compknee, comphip );< getx( x[i], i);

gety( y[ i], i);getz( z[ i l, i);e/[ il = y[ il-z[ il;d/[ il = -._{ i]- z[ il;

getfx(fx[ i1, i );getfy(j_I i ], i );getfz(j2[ i ], i );getvalve( kneevalve[ i ], hipvatve[ i ], i );i= i+ l;done( ( i> 6 ) ) >;

done( true )>end


A.9. data.owl

global( indx

)

define inittrace:

{ Initialize the storage for data taking. }< initfree;

indx = 1;done( true )

>

define tovax, local( i = 1 ):

-[ l'ransmit the data up to the vax. }< [ < v_hen(( ( i% 110 ) = = 1 ) );

printf( "%d>", i/11 ) >;< upprintf( "%d %d %d %d %d %d %c%d %d %d %d\n",

trace[ i], trace[ i + 1 ], trace[ i + 2 ], trace[ i + 3 ], trace[ i + 4 ], trace[ i + 5 ],trace[ i + 6 ], trace[ i + 7 ], trace[ i + 8 ], trace[ i + 9 ], trace[ i + 10 ] );

i = i + 11;both( ( i >= indx ) ) > ];

upflush; { [:lush the transmitter buffer }upprintff "%c", '\004' ); { send atD to close the file }done( true )

>

define snapshot( leg ):< time( trace[ indx ] );

trace[ indx + 1] = leg;trace[ indx + 2] = y[ leg ];t.:ace[indx + 3 ] = z[ leg ];trace[ indx + 4 ] = fz[ leg ];trace[ indx + 5 ] = fy[ leg 1;trace[ indx + 6 ] = hipvalve[ leg ];trace[ indx + 7 ] = ( leg < 4 ) ? d123 : d456;trace[ indx + 8] = rcv;trace[ indx + 9] = inhibit[ leg ];trace[ indx + 10] = excite[ leg ];indx = indx + 11;

done( true )>end


A.10. trouble.owl

global( trouble[ 8 1, {Trouble flag array ... 7 is compensator }

{ 8 is operator override }

apo,trouble, { Overall trouble flag }p/[ 8 ], { l.oaded and in Place or Down }ptflag,

pu[ 8 ], { Unloaded and in Place or Down }puflag,ll[ 8 ], { Eoaded and in Lift or Up }ltfiag,

lu[ 8 ], { Unloaded and in Lift or Up }luflag

)

define troubleserver:.

< anytrouble = trouble[ 1 ] + trouble[ 2 ] + trouble[ 3 ] +trouble[ 4 ] + trouble[ 5 ] + trouble[ 6 ] + trouble[ 8 ];

plfiag = i'/[ ] ] + p/[ 2 ] + p/[ 3 ] + p/[4 ] + p/[ 5 ] + p/[ 6];puJlag = pu[1] + pu[ 2 ] + pu[ 3 ] + pu[ 4 ] + pu[ 5 ] + pu[ 6 ];lljlag = 11ll]+ l/[2] + I/[31+ ]_4] + I/[5] + i/[6];lujlag = lu[ l ] + lu[ 2 ] + h,[ 3 ] + h,,[4 ] + lu[ 5 ] + Is,[6]

>

define &a&nan:

< ;vhen( ( trigger = = 0 ) );trouble[ 8 ] = true;when( ( trigger!= 0 ) );trouble[ 8 ] = false

>

define inittrouble, local( i = 1 ):

< < trouble[ i] = 0;p/[ i l = 0;pu[i] = 0;till] =0;lu[ i] = 0;i= i+ 1;done( ( i> 8 ) ) >;

anytrouble = 0;plflag = 0;puflag = 0;IIflag = 0;luflag = 0;done( true )

>


define hydraulic( leg ), local( Ic, ht):< when( ( hipvah,e[ leg 1! = &)ll

( ( M = = 1) && (fz[ leg ] 4,= lightly ) ) [I( ( Id = = 0 ) && ( fz[ leg ] ) lightly ) ) );

lc = hipvalve[ leg ];ld = ( fz[ leg ] >= lightly ) ? 1 : O;ll[legl =(((#=='l.')ll(Ic=-'U'))&&(Id== 1))?1:0;l.[ leg] -=(((to= ='i.' )11(le= ='U' ))&&( ld = = 0))? 1 : O;p/[ leg] = (((/c= -'P' ) II( Ic- -'I)" ))&&( ld = = 1)) ? 1:0;pu[leg] = ((( le= ='t" ) II( Ic= = 'D' ))&&( IN= = 0 ))? 1:0

>end

A.I 1. comps.owl

define compserver:[ < when( ( comp >= 9000 ) );

trouble[ 7 ] = true;lengthencomp;,_lien( ( comp <= 0 ) );

releasccomp;trouble[ 7 ] -- false );

< _hen( ( comp < = -9000 ) );trouble[ 7 ] = true;shortencomp;when( ( comp >= 0 ));relcasecomp;trouble[ 7 ] = false >

1end

Data 131

1 am not arguing with you - I am telling you.---J. et McNeil Whistler

Appendix B

Data

This appendix contains selected plots of data taken from the walking machine sensors and internal

state during various walking experiments. They are presented in chronological order. Discussion of

these data is contained in Chapter 8.

• w830728 - July 28 90 seconds of walking. Excitation and Inhibition on. S turn.

• w830731 - July 31 160 seconds of walking. Excitation and Inhibition on. An attempt at astraight walk, but 123 side was driving a bit faster than 456 due to a problem with thedrive pumps, so it curved a bit.

• _830808a - August 8 130 seconds of walking. Excitation off, Inhibition oil. Relativelystraight walk.

• _v830809- First run Augus', 9 160 seconds of walking. Excitation off, Inhibition on.

Straight walk.

• ,_'830809a - Second run August 9 300 seconds of walking. Excitation and Inhibition bothon.

• g830816 - August 16 160 seconds of walking. Excitation off. This walking was done with"gimpy", a copy of walk.owl with leg 5's instance of the Row process commented out.I=ivelegged walking.

B.I. Descril;tion of data figures

This section describes the data plots contained in t_hisappendix. The record of each "run" consists

of three plots derived from the data taken during the run.

The first plot, a sample of which is figure B-l, is a time history of all six legs. There is an

independent trace for each leg that shows when the leg was recovering and when it was driving.

When the trace is "down", the leg was on the ground. When the trace is "up", the leg was recovering.

The horizontal axis is the time scale. The excitation system was on and triplets of rear-to-front

recoveries are visible. Notice that the machine's walking doesn't always exhibit these rear-to-front


triplets; when conditions change the legs may choose to vary from the perfect rear-to-front

sequencing.

__FLI--1 ,FE_F_ Fl !-1 1left rear

,F-1 r--1 I--] Hleft middle

LJ ,n nLegs recovering, from w830728.data

M I-1 [--[ F-1 [--I I--1 1right rear

FE F_ .N n _

r_=gt_tmiddle.,_, r-1 71 F1, l-q I-1 1-71Jo _o ' 40 .do do _o ao _;otime (seconds)

Figure B-I: Sample plot of recovery values estimated from inhibition data taken during experiment run July 28, 1983.

The second plot of each set, figure B-2, shows an estimate of the forward progress of each side of

the machine. This estimate is computed by integ,'ating the horizontal joint motion of all legs that are

on the ground on each side and then taking a linear combination. In this sample you can see that

there was no forward progress on the 123 side between 35 and 50 seconds into the run while there

was progress on the 456 side during that time thus indicating that the machine turned during that

time. Between 55 and 70 seconds it turned back the other way and it ended up pointing in the same

direction as when it started, as you can see by the fact that the progress lines converge at about 85

seconds. Of course, if the machine made a complete circle, it could end up pointing in the same

direction while the progress lines would not have converged at all.

7'he third plot is the six load traces for the run. Figure B-3 shows the load plot for the same run

exhibited in the other samples in this section. Comparison of this plot with figure B-1 can show

things like legs entering drive but remaining unloaded, or becoming unloaded during drive, and so

on. It also illustrates some of the effect_sof the machine's lack of mechanical compliance.

Data 133

._ 6.0L,,

• 5.5_.o . "'/-

¢_ Forward progress from w830728.data ...... " /¢_ /4.5

123 progress ." [

_ 4.0 ........ 4_6proQre_ .... .......' / •

3.5 .___: _

3.0°

2.5 ._2.0 .'_:-_:

1.5 _,'*

1.0o _o Jo _o _o ;o do ....73 do ._o

time (seconds)

Figure B-2: Sample of progress estimates tor file two sides of the machine.

I500 pounds Leg forces, from w830728.data

......rig f/On ^^ 20 30 ^" 40 50 60 - 70 -dO 90time (seconds)

Figure B-3: Sample ofall six load traces.


B.2. Data plots

_£2_J_1 ,[--_F-1 I-1 F-1 1left rear

I-1 ,,F_ I-i F1 i--LJleft' niiddle [___I--] r-] l---i __r---] F-]_I---Ileft front

Legs recovering, from w830728.data__z___,_,r-_ _ _ _ ,I.....',7:1:i_] 7-l_1-1 FI I-i 1-1

r--t_,r--I t--1 i--i i-i I-:1- ['ight7¢nt 2o _o ,_o do do 70 8o _o

time (seconds)

-, 6.0

• ,_.5 ..F

5.0 ._Forward progress from w830728.data ..... .

4.5 123progress

OCl,4.03.5 ....... 456 progress ,--,'" ,"'....... fJ

3.0

f2.5

2.0

1.5

1.0

.5

o ,o 20 30 _o do do _o do _otime (seconds)

OW I_Primitives 135

500 pounds Leg forces, from w830728.data

t'rear

A.. 20 30 " _- 40 50 60 - fo 80 90time (seconds)

4e_mid_e J-L_] __V-__N. .r_ __H p-___

--_e_t f]7.ron, FL__H FL q_]q._[---] [_]_______ji]__]

Legs rec°verin _31"dath [--]__]--] I

!_!e_ FI__ F]__J] I-I rl []_ffii"' n n n n n ,r:-i ,isright ,rondo 40 dO 80 1_i0 ..... 120 140 i 60

time (seconds)


_11

f10

J_ 9 /---tb

6 _._ ...j ° ........

5 f ....Forward, Dro._ess from w830731 .data .'""

lz3p_-_ress " ....4 ..... 45616rogress .- ..... " .....

o..o.,• ...

1

o 20 ,_o _o _o ' _bo ,_o ,:_o ,_otime (seconds)

I500 pounds Leg forces, from w830731 .data

.....___ ....._,_ .....___._....._,.___._,rightfronL_0 40 60 80 100 120 140 160

time (seconds)

OW !. Primitives 137

___£},,_a,n r-Lr-L_S7_m H_M_r__r7N I-I.... J-l__Fi_l-l__l-IFl_rl ,rl

left middle

--£7,ootJ_--LrT__m_m-n m_n r,oO rTove,l smw O O a. a,ar--I FI I-1 I-

I"°"tri_,r7r_n H,nn, n , nn, ,right front 20 40 60 80 100 120 140time (seconds)

6.5o_6.0 J"

E_5.5Forward progress from w830808a.data .,"

_ 5.0 123progress .- "....... .... ....... ""

4.5 ...... 456 progressoel.

4,03.15 ..........

3.0 _-----_

2.5 f

2.0 f.--1.5

1.0 _¢_- ,o .;o ,70 do _o _bo _o _4otime (seconds)


I left front

500 pounds Leg forces, from w830808a.data

0 rightfront 20 40 60 80 100 120 1'40time (.seconds)

-]_l__e]__Ft_J]___I]rl rLrl_rl rl_lt__lleft front __H_I_ FLFL_I-LrU-I_FLZ-t._II_IIJ


rLmLrL mrmLm

I],.rl,.Ilrl ,"_<_'°_I1rl E1fl ,rl rl ,rll-1_171r-!r-I,nil I, ,rig I rol_ 40 60 80 100 120 140 160 180time (seconds)

OWl. Primitives 139

11.5 r ....

_o.5I. .--10.0_.

E_ 9.5 L_ 9.01. Forward progress from w8

123 progress8.5 ....... 456 progress

o_ 8.0o. 7.5

7.0 ...6.5

6.0 i_5.55.0 ""

4.5 _4.03.5 :'"3.0

2.5 L

2.01.51.0.5

o -- _o ,;o do do _bo _'2o _5o _'6o ,'8otime (seconds)

500 pounds Leg forces, from w830809.data

k-a -I .g.t fr62tO " 40 -- 60 " 80- - 16-0 - 120 ...... 140- - i60 180

] time (seconds)


__L __,_LJIHr__________,_tH--H--n-.... U_____H____£_H_n_H_H__

ec°ve TH'r°m_l H I1_J]_L_lI ligh.t rear 1l_h_'- m_H__rl_ri__iL! r]___rl_._lI-N NilRHI1I ri N11 m It NNrlrl rl ,rl__rlN I[ i]gl_t front 50 IO0 150 -- 2'00 ...... 250 3100time (seconds)

14.0 rlS.51. .--.

13.0l.

12.51.12.01.11.5_

m 1 1.01- Forward progress from w830809a.data10.5 123progress10.0 ....... 456 progiess

o 9.5 --_J9.0 ..- -J

8.5

8.07.57.06.56.05.55.04.54.03.53.02.52.01.51.0

.5 _)' b ' '0 ' ......"0 50 1 0 150 2 0 250 300

time (seconds)

OW I.. Primitives 141

[500 pounds Leg forces, from w830809a.data

ightfrorit 50 - - 100 150 200 250 300time (seconds)

__J-I._J]__l] I1 ,r-I l]_J-L__rlN_ll I] fl fl_H_l-] f-lEl_l]__ll

left middle

_,ULJ-l__r__riH rL_J_ H ,msuLegs recovering, from g830816.data

l-I_I] .FI I-1 I--I _ . rl I--LI-L_FI__Iright rear

[0°"'_'°°'_n n nn n n =,n finn ngh' ,roni_ 0 ,t_O dO 80 7100 1'120 140 1 '60time (seconds)


.._ 7.0

"_"6.0

6.5

Forward progress from g830816.data

_ 5.5 _ 123progress f ..."'" ......5.0

oO. 4.5

4.0

3.5

3.0

2.5

2.0

1.5

1.0

.5

I I- I |

o 20 ,_o _,o ao _bo _'2o 14o _so laotime (seconds)

rces, from g830816.data

_ightfro2_ - 46 " 60 80 " 1O0 - 120 "14[) 160 180time (seconds)

OWL Primitives 143

If lhere are cat-calls ...you are'sure ath'ast that the audience is still ther_

--- Cwyl Brahms & S. J. Simon

Appendix C

OWL Primitives

This appendix contains an annotated listing of all of the primitives defined for the OWI. runtime

system as implenlented for the walking task.

C.I. OWL control primitives

alert( Boolean ) Assert alert if Boolean is true, nop otherwise

alertwhen( Boolean )Semantically equivalent to < alert( Boolean ) >. Quite dangerous because it killsits siblings and then hangs.

both( Boolean ) Assert alert and done if Boolean is true. Nop otherwise.

bothwhen( Boolean )Semantically equivalent to < both( Boolean ) >.

done( Boolean ) Assert done for this process if Boolean is true. Nop otherwise.

donewhen( Boolean )Semantically equivalent to < done( Boolean ) >, done( true ). That is, it waits forBoolean to become true, then terminates the enclosing sequence.

suspend Suspend this process. In a later implementation a parameter may be passedasserting how long to suspend the process for. In the current implementation Oae

suspension is for one cycle of the event queue.

when( Boolean ) Semantically equivalent to < done( Boolean ) >


C.2. Compiler directives and declaralion keywords

debug Compiler directive. Toggles file Debug switch.

define Compiler keyword. Introduces the declaIation of an OWl. prcxzess.

end Mark the end of an owl file.

free Compiler directive. Causes compiler to report the number of items remaining inthe various fl'ee lists.

global 'Fells the compiler that global declarations are to follow.

globals Compiler directive requesting a dump of the global symbol table.

local Introduce a process's local variables.

locals Compiler directive commanding a listing of the local symbol table.

used Compiler directive commanding display of a cotint of the items in use in thevarious compiler data structures.

val Mark a formal parameter as pass-by-value.

valstar Mark a formal parameter as pass-by-value with periodic update.

var Mark a formal parameter as pass-by-value-return.

varstar Mark a formal parameter as pass-by-value-return with periodic update.

C.3. Sensor primitives

get123( VAR x ) Put the displacement of the 123 drive pump in x.

get456( VAR x ) Put the displacement of the 456 drive pump in x.

getc( VAR c ) Asynchronous character I/0. Get a character.

getcomp( VAR x )Put the position of the compensator in x.

getcrb( VAR x ) Put the displacement of the crab pump in x.

getdial( VAR x ) Put the button pressed on the dial into x.

• 0 = > No button pressed.

OWI. Primitivcs 145

• 1..9 = > Digit pressed.

• 10 = > * pressed.

• 11 = > 0 pressed.

• 12 = ) # pressed.

gctfx( VAR x, VAI_Leg )Get the x force for I_egand put it in x.

getfy( VAR x, VAI_Leg )Get the y force for Leg and put it in x.

getfz( VAR x, VAL Leg )Get the z force for Leg and put it in x.

getline Asynchronous I/O. Fill a buffer until first carriage return.

getrcv( VAR x ) Put the displacement of the recovery pump in x.

gctstick( VAR x ) Put the undecoded value of the stick buttons in x.

getvalve( VAR Hip, VAIl Knee, VAI. Leg )Read the current valve settings for Leg and put them in ttip and Knee.

getx( VAR x, VAL Leg )Get the x position for Leg and put it in x.

gety( VAR x, VAL Leg )Get the y position for Leg and put it in x.

getz( VAR x, VAL Leg )Get the z position for Leg and put it in x.

readstick( VAR Hat, VAR FirstStep, VARf SecondStcp, VAR Thumb, VAR Trigger ) Read anddecode the stick buttons into the obvious variables.

C.4. Valve command primitives

hcoast( VAI, Leg )Put Leg's hip joint in C (Coast).

hdown( VAL Leg )PUt Leg's hip joint in I) (Down).

hdown2( VAL Leg )Put Leg's hip joint in d (down).


henergize( VAI, Leg )Put leg's hip joint in E (Energize).

henergize2( VAL I,eg )Put Leg's hip joint in e (energize with recovery oil).

hhold( VAL Leg ) Put Leg's hip joint in H (Hold).

hliR( VAI, Leg ) Put Leg's hip joint in I, (Lift).

hlift2( VAL I.eg ) Put l.eg's hip joint in 1(lift).

hplace( VAL Leg )Put l.eg's hip joint in P (Place).

hplace2( VAL Leg )Put Leg's hip joint in p (place).

hup( VAL Leg ) Put Leg's hip joint in U (Up).

hup2( VAL Leg ) Put I.eg's hip joint in u (up).

kcrab( VAI. 1.eg ) Put Leg's knee joint in C (Crab).

khold( VAL I_eg ) Put Leg's knee joint in _I (Hold).

Heft( VAIl.Leg ) Put l.eg's knee joint in L (l.eft).

kright( VAI. Leg ) Put Leg's knee joint in R (Right).

lengthencomp Lengthen the compensator.

releasecomp Deactivate the compensator.

sethipvalve( VAL Leg, VAL valve )Put Leg in valve setting valve.

setkneevalve( VAL Leg, VAL valve )Put I.eg in valve setting valve.

shortencomp Shorten the compensator.

quit Signal the small 68000 that it can exit the OWL server.

sendvalvecommandsTransmit the current valve commands to the owl server.

OWl. Primitives 147

C.5. I/0 primitives

baudl200 Set the console baud rate to 1200

baud2400 Set the console baud rate to 2400

baud4800 Set the console baud rate to 4800

baud9600 Set file console baud rate to 9600

beep Sound tile console beeper

clearscreen Clear the console screen.

cursor( VAL Row, VAI. Column )Put the console cursor at ( Row, Col ).

getc( VAR c) Asynchronous tty input. This process becomes done when there is a characteravailable to put into the variable c.

geth( VAR x ) From the buffer read by getline, scan a hex integer.

geti( VAIl x ) From the buffer read by getline, scan an integer.

getline Asynchronous tty input. Gets a line of characters from the tty and puts them intoan internal buffer.

gets( VAR s ) From the buffer read by getline, scan a string. X should be an array of integers,since OWL does n¢_tyet provide character arrays.

printf( fi,rmat, output-list )C formatted print statement.

printf2( fommt, output-list )C formatted print statement. Target is host.

scant'( t'ormat, input-list )C formatted input. Does not yet work.

upflush Flush the internal buffer of the VAX receive program. For use when uploadingwith the upprintf command.

upprintff format, output-list)C formatted print statement. Receive program on vax is the target. This providesreliable uploading at baud rates up to 9600 when using the receive program. Senda _'D up to close out transmission.


C.6. Miscellaneous primitives

initffee Initialize the trace[] array and the tracesize w_riable. Tiffs array provides access toall of the memory space in the 68000 beyond the end of the space used by the

program. It may be read and written using normal array accesses. The maximumnumber of integers that may be placed in the array is available in the tracesize

variable. This process must be called before trace[] may be accessed.

false Boolean constant.

time( VAR t ) Put real time clock value into t.

trace[] Array of all the free space at the end of the 68000 memory.

tracesize Size of the trace[] array. See initfree.

true Boolean constant.

The Trojan Cock roach 149

A book that furnishes no quotations izme judice, no book - it is a pl'aything.

--- Thomas Love Peacock

Appendix D

The Trojan Cockroach

This poem was composed in honor of the walking machine by Claude Shamlon, who graciously

consented to its reproduction in this thesis.

Higgledy PiggledyIvan E. Sutherland

Built a huge cockroach - twelveHorsepower clout!

The roach, waxing vengeful forMassive roach genocide,tlcxapcdiacally

Stamped Ivan out.

References 151

References

[1] Alexander, R. McNeill.Size and Shape.Camelot Press, Southampton, 1971.

[2] Bessonov, A. 17.and Umnov N. V.The Analysis ,ffGaits in Six-Legged Vehicles According to Their Static Stability.1n First Symposium oil Theory and Practice of Robots and Manipulators, pages 1-10. 1973.

[3] Bessonov, A. P. and Umnov, N. V.Features of Kinematics of Turn of Walking Vehicles.

In Third Symposium on Theory and Practice of Robots and Manipulators, pages 87-97. 1978.

[4] Borelli, A.De motu attimalium.

unknown, Rome, 1680.

Cited by Hugt_es [22] as first recognizer of rear-front waves in insects.

[5] Brinch Hansen, P.The Programming I ,anguage Concurrent Pascal.

IEEE Transactions on Sqftware Engineering 1(2), June, 1975.

[6] Campbell, R. tt. and Haberrnann, A. N.The Specification of Process Synchronization by Path Expressions.In Lecture Notes in Computer Science Number 16, pages 89-102. 1973.

[7] Currey, J. D.Problems of Scaling in the Skeleton.In Pedley, T. J. (editor), Scale Effects in Animal Locomotion, pages 153-167. Academic Press,

1977.

[8] Devjanin, E. A. ct. al.q'he Six-l.egged Walking Robot Capable of Terrain Adaptation.In Morccki. A., Bianchi, G., Kedzior, D. (editor), ['burth Symposium on Theory and Practice of

Robots and Manipulators. Poland, 1981.

[9] Dijkstra, E. W.Guarded Commands, Nondeterminacy and Formal Derivation of Programs.In Current Trends in t'rogramming Methodology, chapter 9. Prentice-Hall, 1975.

152 Contrail of Walking

[I0] Forgy, Charles I,.OPS5 User's Manual.

Technical P,cport CM U-CS-81-135, Carnegie-Mellon Univcrsity Computcr Science

l)cpartmcnt, July, 1981.

[11] Gray, James.Croonian I.ccture: Aspects of Animal l.ocomotion.Proceedings of the Royal Sociel)' (128):28-62, 1939.Cited in Pringle, Proprioccption in Arthropods [53].

[12] Grillner, S. and Zangger, P.On the Central Generation of l_ocomotion in the [_ow Spinal Cat.

Experimental Brain Research 34:241-261, 1979.

[13] Habcmmnn, A. N. and Perry, D. E.Adafor t?xperienced Programmers.Addison-Wesley, 1983.

[14] Heart, t:. E., Ornstein, S. M., Crowther, W. R., and Barker, W. B.A new minicomputer/mtdtiprocessor for the ARPA network.In AI'71'S 1973 Conference Proceedings, pages 529-537. AFIPS, 1973.Pluribus architecture.

[15] Hcnnessy, John 1....and Kieburtz, Richard B._,IS cstemfor Producitlg _Iulti. Tasking Software for Microprocessors.Tcclmical Report # 47, SUNY Stony Brook, 1975.q'O MAI_desc rip tion.

[16] Hennessy, John L../IR eal-77me LanguageJbr Small Processors: Design, Definition, and Implementation.PhD thesis, State University of New Y(._rkat Stony Brook, August, 1977.q'OMAI, language.

[17] t lennessy, John L., and Kieburtz, Richard B.The Formal I)efinition of a Real-Time I.anguage.

Acta bfonnatica (16):309-345, 1981.TOMAI_ formal semantics.

[18] Hildebrand, M.Analysis of the Symmetrical Gaits of Tetrapods.l'blia Biotheoretica (4):9-22, 1966.

[19] Hirose, S. and Umetani, Y.The Basic Motion Regulation System for a Quadruped Walking Machine.In ASME Conference on Mechanisms. Los Angeles, 1980.

[20] Hoare, C. A. R.Communicating Sequential Processes.Communications of the ACM 21(8):666-677, 1978.

References 153

[21] Hoyle, G.

Arthropod Walking.In Herman, R. M.; Grillncr, S.; Stein, P. S. G.; and Stuart, D. G. (editor), Neural Controlof

Locomolion, pages 137-179. Plenum Press, 1976.

[22] Hughes, G. M.

The Co-ordination of Insect Movements, I. The Walking Movements of Insects.Journal of Experimental Biology (29):267-284, 1952.

[23] Hughes, G. M.The Co-ordination of Insect Mc.vements, I11.The Effect of l.imb Amputation and the Cutting

of Commissu res in the Cock roach (Blatta Orientalis).Journal of Experimenlal Biologo,(34):306-33, 1957.

[24] Hughes, George M.l.ocomotion: Terrestrial.

In R.ockstein, Morris (editor), The Physiology ofh, secta, chapter 4, pages 227-254. AcademicPress, 1965.

[25] Hyde, Benjamin.Personal communication.

1983.

[26] Johnson, Stephen C.Yacc: Yet Another Compiler Compiler.Technical P,eport, Bell Laboratories, 1978.

[27] Kato, T., Takanishi, A., Ishikawa, H., Kato, I.The Realization of the Quasi Dynamic Walking by the Biped Walking Machine.In Morecki, A., Bianchi, G., Kedzior, D. (editor), Fourlh Symposium on Theory and Practice of


[28] Katsuki, et al.Pluribus - An Operational Fault-Tolerant Multiprocessor.Proceedings of the IEEE 66(10): 1146-1159, 1978.

[29] Kernighan, Brian W. and Ritchie, Dennis M.The C I'rogramming Language.Prentice-Hall, Englewood Cliffs, New Jersey, 1978.

[30] Kessis, J. J.Walking Robot Multi-Level Architecture and Implementation.

In Morecki, A., Bianchi, G., Kedzior, D. (editor), Fourth Symposium on Theory and Practice ofRobots and Manipulators. Poland, 1981.

[31] McGhee, R. B.Finite state control of quadruped locomotion.In Proceedings of the Second International Symposium on External Control of Human

Extremities. Dubrovnik, Yugoslavia, 1966.


[32] McGhee, R. B. and Pal A. L.

AllApproach to Computer Control for I.egged Vehicles.Journal of Terramechanics 11(1):9-27, 1974.

[33] McGhee, R. B., and Orin, I). E.

A Mathematical Programming Approach to Control of Joint Positions and Torques in Leggedl_ocomotion Systems.

In Second Symposiun7 on Theory and Practice of Robots and Manipulators, pages 225-232.1976.

[34.] McGhee, R. B. and [swandhi, G. I.Adaptive l.ocomotion of a Multilegged Robot over R.ough Terrain.IEk'E Transactions on &'stems, Man, and C),bernetics 9(4): 176-182, April, 1979.

[35] McMahon, Thomas A.

Using body size to understand the structural design of animals: quadrupedal locomotion.Journal of Applied Physiology 39(4):619-627, 1975.

[36] McMahon, T. A., and Greene, P. R.Fast running tracks.ScientiJ_c American 239(6): 148-163, 1978.

[37] Miller, S." van tier Burg.,J.; and van der Meche, F. G. A.I.ocomotion in the Cat: Basic Programmes of Movement.Brair, Research (91):239-253, 1975.

Decerebrate Cat walking work here.

[38] Miller, S.: van der Burg, J.: a_ld van tier Meche, F. G. A.Coordination of Movements of the Hindlimbs and Forelimbs in Different Forms of

I.ocomotion in Nonnai and Decerebrate Cats.

Brain Research (91):217-237, 1975.

[.39] Miura, H. and Shimayama, I.Computer Control of an Unstable Mechanism.J. bbc. Eng. (17):12-13, 1980.Motion picture; paper in Japanese.

[40] Mosher, R. S.Design and Fabrication of a Full-SceIe, Limited-Motion Pedipulator.

Technical Report 65-46004-1, General Electric Company, Advanced TechnologyLaboratories, June, 1965.

[41] Mosher, R. S.Test and Evaluation of a Versatile Walking Truck.In Proceedings of Symposium on Off-Road Mobility Research, pages 359-379. 1968.

[42] Mujtaba, Shahid and Goldman, Ron.AL Users'ManuaL

Technical Report, Stanford Artificial Intelligence Laboratory, November, 1977.

R.efcrences 155

[43] Muybridge, Eadweard.Animals hi Motion.

I)ovcr Publications, New York, 1957.

First published ill 1899, Chapman and tiall, Ltd., l_ondon.

[44] Narinyani, A. S., Pyatkin, V. P., Kim, P. A., and I)emcntyev, V. N.Walking Robot: a Non-Deterministic Model of Control.unknown, 1974?

[45] Ornstcin, S. M., Crowthcr, W. R., Kraley, R. D., Bressler, A. M., and Heart, F. E.Plu ribus - A reliable multiprocessor.In A FIt'S 1975 ('utd#rence Proceedings, pages 551-559. AFIPS, 1975.Pluribus strips described.

[46] Osshcr, H. I+.and Reid, B.K.

Fable: a progr_ut_ming-language solution to IC process automation problems.In Proceedings oj'the Sigplan "83Symposium on Programming Language issues m Software

Sy.stems, pages 137-148. ACM, June, 1983.Sigplan Notices Vohlme 18, Number 6.

[47] Ozguner, F.. Tsai, S. J., McGhee R. B.An Approach to the Use of Terrain Preview Infommtion in Rough-Terrain Locomotion by a

Hexapod Walking Machine.hilernational JourmT.i_f Robotics Research ?:?, 1984.

[48] Pearson, K. G. and Iles, J. F.Nervous Mechanisms Underlying lntersegmental Co-ordination of Leg Movements During

Walking in the Cockroach.Journal of Experimental Biology 58:725-744, 71973.

[49] Pearson, K. G.Central Progra:nming and Reflex Control of Walking in the Cockroach.Journal of Experimenlal BiologoJ56:173-193, 1973.

[50] Prange, Henry D.The Scaling and Mechanics of Arthropod Exoskeletons.In Pedley, T. J. (editor), Scale l::ffecls in Animal Locomotion, pages 169-183. Academic Press,

1977.

[51] Pringle, J. W. S.Proprioception in Insects, 1I.The Action of the Companiform Sensilla on the Legs.,h)urnal of Experimental Biology (14):114-31, 1938.

[52] Dingle, J. W. S.The Reflex Mechanism of the Insect Leg.Journal of Experimental Biology (17):8-17, 1940.

[53] Pringle, J. W. S.Proprioception in Arth ropods.In Ramsay, J. R. and Wigglesworth, V. B. (editor), The Cell and the Organism, pages 256-282.

Cambridge University Prcss, 1961.


[54] Raibert, Marc H.; Brown, Benjamin, Jr.; Chepponis, Michael; Hastings, Eugene; Shreve,Stevcn E.; and Wimbcrly, Francis C.

Dynamically Stable Legged l,ocomotion.Technical Report C/VlU-RI-TR-81-9, Carnegie-Mellon University, Robotics Institute,

November, 1981.

[55] Raibert, Marc H. and Sutherland, Ivan. E.Machines That Walk.

Scientbqc American 248:44-53, January, 1983.

[56] Sejnowski, T.Personal communication to G. Hinton.

1983.

[57] Stephenson, Christopher J.

A Method For Constn_cting Binary Search Trees by Making Insertions at the root.IJCIS 9(1), 1980.

[58] Sutherland, Ivan E.A Walking Robot.Marcian Chronicles, Inc., PO Box 10209, Pittsburgh, PA 15232, 1983.

[59] Taguchi, K., Ikeda, K., and Matsumoto, S.Four-Legged Walking Machine.

In Second _b_vmposiumon Theory and Practice of Robots and Manipulators, pages 162-169.1977.

[60] Waldron, K. J. and Kinzel, G. L.

The Relationship Between Actuator Geometry and Mechanical Efficiency in Robots.In Morecki, A., Bianchi, G., Kedzior, D. (editor), Fourth ,_'mposium on Theory and Practice of


[61] Wilson, D. M.Insect Walking.Annual Review of Entomology 11:103-121, 1966.

[62] Wirth, N.

Modula: a Language for Modular Multiprogramming.Software - Practice aJld Experience 7:3-35, 1977.

control of walking l d re

Documents