Architectures for Controlling an Intelligent Autonomous Vehicle

Download 1.23 Mb.

Page	3/7
Date	03.05.2017
Size	1.23 Mb.
	#17133

1 2 3 4 5 6 7

.,. ,.."..."..,.~...,..."..., .,., .,..,.,

.•. ..".,...,...,...,....,...,~...,~..,,~
7...,. 7.." -r .,...., Y'7' ;r..".T.,~~1'-r.., ~ • .,.,~ 11 ~.~.,r

."".T~.."-r..,,

Figure 2.12

20

Zimmer, Fischer & Puttkamer (1994) report on very similar work completed using connectionist methods and a Boltzman machine as its basis, though, at its foundation, this approach is another way of representing the work completed by Miller.

I have not found any instances of path planners being used with topological maps. Some researchers have used simple search algorithms on these types of maps, though the use of path planners on topological maps may be tried in future research. Future work will include efforts to redesign representations of the world which facilitate easier path planning. Maps developed to date tend to have an obsolescence problem, that is present AI methods do not equip mobile vehicles to adjust maps at the speed of change in dynamic environment. Future research will also likely focus on methods for improving the speed of map adjustment.

2.3.2 Non-Linear Planners

Sacerdoti (1975) fIrst proposed non-linear planners. Tate (1977) later

expanded on the design, and other researchers have since devised further improvements. This planning technique connects operators together to form a plan which will complete a goal. Non-Linear planners complete this task with a minimum commitment to a liner solution. An example of this process is shown in Figure 2.13.

Developed as an extension of linear planning, non-linear planners have been introduced to overcome such problems such as the Sussman anomaly. The work by Fikes and Nelssion (1971) on STRIPS is a seminal example. Many researchers in the AI community now consider non-linear planners useful for general purpose planning.

Non-linear planners offer a major advantage over path planners in that the former can schedule sequences of tasks. Nevertheless, non-linear planners have difficulty coping with rapid and unexpected changes during the execution of environmental-based tasks.

21

Goal State Initial State' Step 2 Step 1 Initial State'		Operator 1		Goal State
Goal State Initial State' Step 2 Step 1 Initial State'		Operator 1		Goal State
	a	a	c	c
	b			d

a

c

b

d

Operator 1

Step 3

a c

Initial State'

Goal State

a

Operator 2

c

b

b

d

d

Figure 2.l3

2.3.3 Hierarchical Planners

Some planners produce plans which have a hierarchy of abstraction.

Hierarchical planners can expand operators in one level of a plan into more detailed layers. Sacerdoti (1971) describes this feature for non-linear planners (though other types of planners may also use a hierarchical structure). An example such expansion follows in Figure 2.14.

Goto London

into

Goto Colchester Train Station Buy Ticket

Board Train

Travel to London

Get off Train

Figure 2.14

This feature has obvious potential uses for mobile vehicles.

22

2.3.4 Planning to Plan

This process of planning to plans encompasses efforts to equip mobile vehicles to decide how to plan, and when and where to perform planning tasks. In the previously considered example of making a journey to London, the initial level of planning produced only the outline shown above. The individual planning events of expanding these goals takes place at a later stage. Planning to a plan occurs when a step in the plan requires further planning. Although Munson (1971) completed the initial work on this subject more than two decades ago, researchers now are returning to this area (Steel 1994).

2.4 Attention

The literature on the current architectures reviewed above describes work which either has not required the sharing of resources or has been inherently parallel. While attention has not been implemented as a module, some architectures have produced a form of attention as a side effect of operation. Some recent work, including Scott (1994), has focused on this area with a view to using a multi-tasking operating system to share resources. Other researchers, like Brooks, have tried to focus a vehicle's attention on a process by introducing "hormone" values which impact the performance of all behaviours. Brooks claims this process' improves a vehicle's operation by enabling researchers to introduce a form of attention mechanism into a distributed collection of processing agents.

2.S Summary

The proposal of resolutions to the debates over the most productive strategies for improving the design of architectures, mapping systems, and planners, as well for incorporating such features as attention into the programming for intelligent mobile vehicles, lie far beyond the scope of this project. Three points raised in this chapter will be considered in more detail. These are Reaction based , Subsumption and Combination Arcitectures

23

Chapter J

An Implementation of a Reactionary lAY Architecture

Contents

3.0. Introduction

3.1. Vehicle Developed 3.2. Software Developed 3.3. Experimental Results 3.4. Future Work

3.5. Summary

3.0 Introduction

The summer leave taken by a member of staff in August caused a delay in the implementation of my work on the departmental vehicle, Ford. However, the delay

provided an opportunity for a further extension of my ideas. During two weeks of this delay, I designed and built a small mobile vehicle, shown in Figure 3.1. This vehicle is controlled by a single layer reactive control system which enables it to move around its environment with out damaging itself. The simplicity of this design permits assessment of whether a reaction-based control architecture could be operated successfully on an economical machine. The work completed at M.LT. and detailed in Brooks (1989)

provided the initial inspiration for the design of an experimental rodent-like vehicle.

24

Nevertheless, there are two major differences between this vehicle and Brooks' work. First, the MIT vehicle uses a sUbsumption control architecture; and, second, Brooks created a more complicated, six-legged vehicle. Brooks reported in a 1994 Radio 4 interview that );ASA is now considering the possibility of deploying an improved version of the .Y1.I.T. vehicles to prepare ground for the construction of a planetary station on the moon or Mars at some future time. I sought to determine how successfully this work could be completed using far simpler designs for both the vehicle and the control architecture. This chapter details the development of the mobile vehicle, shown in Figure 3.1, then of the control architecture. Finally, I discuss the results of my experiments, and elaborate on the potential future developments of such a mobile vehicle.

Figure 3.1

25

3.1 Vehicle Developed

The mobile vehicle illustrated in Figure 3.1 consists of an aluminium base plate with four 1.5 volt D.C. motors, a 4.5 volt battery pack, and a circuit board which controls its movement. Two micro switches attached to both the front and rear of the mobile vehicle provide sensory input. Extensions of these switches enable them to act as "whiskers" for the vehicle.

The control circuitry, developed in conjunction with Malcom Lear, is based around the NEC 27** range of EPROMs. The use of an EPROM as the base for a controller enables a direct mapping between the vehicle's "whisker" readings (which feed into the EPROM's address lines) and the vehicle's motor control (which feed from the EPROM's data lines).

Figure 3.2 displays the full circuit diagram for the controller. The important agents of this circuit arrangement include the following:

A clocked buffer (74HTC574 and 74HC14) in the circuit allows the output data lines to feed back into the input address lines as a way of representing the internal states of the vehicle. This enables the control architecture to remember the direction the motors are going when the vehicle makes contact with an obstacle. The additional four data output lines also can similarly represent additional internal states.

The presence of spare quad gates on the clock chip (74HCI4) allows an additional clock with a delay time of approximately one second to be supplied to address line All of the EPROM (for use by the software programmer). This clock is reset by the trailing edge of an inverted pulse from data pin D4 of the EPROM.
Four L272N dual power op-amps, connected as shown in Figure 3.2, perform the directional control of the motors. The direction of the motors is dependent on the differential between points A and B shown in the diagram. The circuit, in essence, acts as a bridge.

All unused inputs to the EPROM are pulled to Zero when not in use. The total cost of the completed hardware was under £20.

Ats

AI.

All

AI2

-L2

AI1

011

Ots

012

01.

CI()

• OIl

012

081

GI()

-L³

Figure 3.2

27

3.2 Software Developed

This section describes the software developed for testing the vehicle.

Programming is based on the placing of data in the EPROM's 8 bit memory locations. This design functions similarly to a large lookup table of all the possible combinations of inputs. As the end result of the programming is a large table of hexadecimal numbers, I will describe the developed software in the form of a set of production rules.

A simple reactive control architecture formed the basis for the design of the

test software for this vehicle. This software, shown in Figure 3.4, instructs the vehicle

to constantly move around a room, and to change direction whenever it senses an

obstacle.

IF front_ whiskers NOT pressed AND back_ whiskers NOT pressed THEN go_current_direction

IF front_ whiskers ARE pressed AND back_ whiskers NOT pressed THEN go_backwards

IF front_ whiskers NOT pressed AND back_ whiskers ARE pressed THEN go_forwards

IF front_ whiskers ARE pressed AND back_ whiskers ARE pressed THEN go_spin

Figure 3.4

As the directional output to the motors is constantly fed back into the EPROM, the software always has knowledge of the direction in which the vehicle is travelling. This feature instructs the vehicle to proceed in the same direction as long as the

whiskers do not come into contact with an obstacle. This very simple aim did not use

several of the hardware features (such as the slow clock and four additional buffered internal state bits). These additional features permit the future implementation of a more complicated program than the one that I have designed for this project.

28

3.3 Experimental Results It is extremely difficult to plot the operational results of a mobile vehicle experiment for comparison with a simulator experiment, as there is no easy manner of recording the path that the vehicle takes. For this reason, I evaluated the performance of the vehicle by running several five minute experiments, and recording which of the following three outcomes occurred: (a) the vehicle became stuck in a dead end; (b) the vehicle experienced a mechanical failure; or (c) the vehicle continued move within the room without a problem. Figure 3.5 below records the outcomes of ten experiments Appendix B lists the final hexadecimal address map for this code. This address map is about 10 times the size necessary, as the EPROM selected for this project was in excess of requirements to allow for future expansion. No	Outcome
1	Movement without problem
2	Movement without problem
3	Movement without problem
4	Movement without problem
5	Movement without problem
6	Movement without problem
7	Got stuck in dead end
8	Movement without problem
9	Movement without problem
10	Movement without problem
Figure 3.5

As expected, the system performed very well, completing its task of wandering around the room without problems on most occasions. These results could be attributed to simplicity of the software, hardware, and control architecture. On the one occasion in which the vehicle experienced an unsuccessful outcome, the vehicle

29

became stuck in a confined area and oscillated between two different reactions. This oscillation may be an inherent feature of a pure reaction-based architecture. The inclusion of an internal state in the architecture may possibly cure this problem.

A second drawback of this control architecture is the presence of only one layer of control. This means that if the vehicle avoids obstacles, it cannot perform other behaviours, such as achieving a goal, at the same time.

Download 1.23 Mb.

Share with your friends:

1 2 3 4 5 6 7