Architectures for Controlling an Intelligent Autonomous Vehicle
Download 1.23 Mb.
|
- Navigate this page:
- Chapter 5
- 5.0 I ntroduction
- 5.1 Architecture Developed
- Plan-then-Execute Behaviour
- Topological Path Planner
- SUbsumption Interface w i th Topological Planner
- E x per i ment al Resu l ts
4.3 Experiments Performed and Their Results Ford was placed in a series of varied environments containing differing sets of obstacles to ascertain the proficiency with which this mobile vehicle could locate a 39
Figure 4.6 The features of Ford's performance during these experiments deserve further comment. I have split this commentary into two sections, discussion of the performance of the vehicle, and discussion of the performance of the architecture. 40
Two difficulties which arose during the experiments conducted for this chapter resulted from sensory limitations in the present Marvin vehicles.
These two problems with the sensory abilities of the Marvin vehicles have reinforced my own conclusion that a combination of bumper bars and computer vision will improve AI sensing abilities. 4.3.2 Comments on the Performance of Subsumption The second and more important commentary concerns the performance of the subsumption architecture. The specific implementation of this architecture for this project under the conditions available in the Essex Brooker Laboratory may have contributed to these problems, but they may also in part be symptomatic of this architecture. a. The IA V tends to oscillate between behaviours, which hampers the smooth achievement of goals. I feel this is a general fault with the subsumption architecture. Brooks added a combination feature to the AFSMs in the second version of the subsumption architecture (Brooks 1991a), which his reported results suggest may have alleviated this problem.
41 includes a hierarchy of behaviours, and I found that I could not achieve the two differing aims. This deficiency arose because the two lowest level behaviours for obstacle avoidance prevented the vehicle from making contact with an obstacle. I did not find a way of reordering the layers in the subsumption architecture. In spite of these two problems, on most occasions, the architecture enabled the integration of several different behaviours so that an environment-based goal could be achieved. 4.4 Future Work In the future I would like to further test subsumption architecture to determine of rigid hierarchies are an inherent feature of subsumption, or if the architecture can be modified to include a flexible hierarchy. If the latter is possible, I would like to investigate possible ways of reordering the behaviours, possibly using the output of a non-linear planner to determine which behaviours should be used where or when in the hierarchy. Another possible approach would be to use some form of learning function to ascertain when differing hierarchies of behaviours should be used. 4.5 Summary In summary, this chapter has shown an implementation of the sUbsumption architecture on a Marvin mobile vehicle. Although successful, this implementation has highlighted some minor problems with the sensory abilities of the departmental vehicles. The other and more major point is that the software implementation of the subsumption architecture enabled the vehicle to avoid obstacles and achieve its goal of reaching an infra red sensor on most occasions. The only unanswered question is whether the subsumption architecture is capable of reordering behaviours. As I have previously stated, I would like to investigate this question in the future. 42
Cornbinina: Subsurnption and Plan-then-Execute lAY Architectures Contents 5.0 Introduction 5.1 Architecture Developed 5.2 Implementation Details Mixing 'C' with PROLOG Plan-then-Execute Behaviour Topological Path Planner Subsumption Interface With Non-Linear Planner 5.3 Experimental Results 5.4 Future Work 5.5 Summary 5.0 Introduction Several false starts and whole scale redesigns preceded the development of the architecture which is the subject of this chapter. The fIrst section of the chapter details my chain of thought and the decisions that I made in designing the architecture, then provides an exposition of the fInal architecture, which combines subsumption with a plan-then-execute architecture. The next two sections describe the implementation of this architecture and the results of testing that implementation. Along with the tabulated results, I also have discussed the features of the architecture that I observed, 43
5.1 Architecture Developed My inspiration for the design of this architecture arose from four observations. First, I have noted that most IA V architectures currently under development fall into one of two categories: a. reaction based and sUbsumption architectures, which can cope with rapidly changing and uncertain environments, but which have trouble reordering priorities of behaviours to plan strategies for handling different tasks; and, b. plan-then-execute architectures, which experience difficulty adjusting to change, but which appear better suited to tasks that require a sequence of events for completion (such as finding a topological path to a destination or compiling a plan of operations to travel from Colchester to London). Second, I noted that the inputs to the behaviour or planning phases of IA V architectures also generally fall into two categories:
44 Third, the actions that an IA V will likely perform likewise cluster into two categories: a. well-learned or regularly performed tasks, such as moving around a room without hitting obstacles, picking up and putting down objects, or turning on a tap; and,
to an unusual destination or cooking a new recipe. The 'a' point of the third observation includes the tasks best performed by reaction based or subsumption architectures, the 'a' type of architectures which rely on the 'a' type of input. Similarly, the 'b' point of the third observation includes the tasks best performed by plan-then-execute architectures, the 'b' type of architectures which rely on the 'b' type of input. Fourth, I noted that no inherent features of either general set of architectures implied that the two varieties would not be capable of operating jointly, and thus I strove to develop a combined architecture which would exhibit the strengths and abilities of both the reaction-based and plan-then-execute architectures. Figure 5.1 displays the architecture that I developed. This architecture uses subsumption as a method of controlling the operation of vehicle and of achieving goals located in the line of sight of the IA V's sensors. To accomplish tasks requiring observation of elements of the environment located beyond the vehicle's line of sight, the architecture uses a non-linear planner working on a topological, landmark-based map to plan paths to achieve its goals. The subsumption element of this architecture operates similarly to the architecture described in the pervious chapter. The major difference in operation is from the addition of the plan-then-execute element which enables the achievement of goals which are currently out of the vehicle's line of sight. The plan-then-execute element designs a path for moving between a series of landmarks to enable the vehicle to achieve its overall objective. The planner passes the ID number of the fIrst beacon to be reached to the find beacon module of the architecture. The execute phase of the architecture then monitors the success or failure of reaching this landmark. If the vehicle passes the landmark, the plan-the-execute module sends the ID number of the next beacon to be found to the find beacon module. If the vehicle fails to locate a 45
landmarks. Stepper Motors Figure 5.1 Plan then Execute Module 1---------- 1 _ 1 Topological: 1 Mapping : 1 rE - - _.J r<- -IoE--- : Planner 1 : Module 1 -----r----I ------ 1 1 All Sensors 1 1- 1 _ . 1 1 xecuuon 1 1 r<----------------~-- : Controller 1 -----r----I V All Sensors ~ (Infra Red Beacon Number) fraRed ensor d 46 E S.2 Implementation Details This section details the testing of the combined architecture. The subsumption element of the architecture uses a modified copy of the work completed for the previous chapter. These modifications enabled the subsumption element to interface with plan-then-execute element. Implementing the plan-then-execute element proved more problematic. I originally had hoped to incorporate a standard plan-then-execute architecture, including world modelling, topological planning, and plan execution phases; however, even after the modification of its ultrasound sensors, Ford still encountered difficulty detecting basic features of its environment. The limitations of Ford's sensors and the short time available for this research prevented the full implementation of the second of these modules. Consequently, in these experiments, Ford used a much diluted adaptation of the world modelling behaviour, drawing information about the world via a terminal. The next four subsections detail the implementation. The first of the subsections describes my findings on the mixing of the programming languages 'C' and PROLOG. The following three subsections describe the developments and modifications required for the subsumption interface, the plan-then-execute module, and the topological planner to produce the combined architecture. S.2.1 Mixing 'e' with PROLOG PROLOG is ideally suited for implementing modules which require the use of redo abilities to find solutions, functions performed by planners. For this reason, I initially sought to determine if PROLOG could facilitate all, or at least part, of the implementation of this architecture. Experiments soon suggested that PROLOG on its own did not permit the full implementation of the combined architecture. In any mobile vehicle application, the world is constantly changing. As a result, variables which have been assigned in PROLOG can suddenly become negated, producing inconsistencies. I then sought to integrate 'C' with PROLOG. The plan-then-execute element of the final architecture uses 'C' to implement the sense and execute phases, 47
The planner assumes the information it receives about the state of the world remains constant during the development of the plan. The planner then passes its plan on to the execute phase, which again uses 'C' to respond to changes in the environment. 5.2.2 Plan-then-Execute Behaviour The plan-then-execute behaviour controls the operation of the non-linear planner, disseminates output to the subsumption architecture, and monitors the achievement of these steps. If a goal is not achieved, then re-planning occurs. Figure 5.2 outlines this module in pseudo code. This section of code was implemented in 'C', and Appendix J contains a listing of the program. initalise_the_description_oCthe_ world create_plan REPEAT get_next_step_oCplan pass_next_step_to_find_infra_red_module get_responce_from_terminal IF infra_red_becon_is_reached THEN modify _ world ELSE modify _ world create_plan ENDIF UNTIL no_more_steps_in_plan Figure 5.2 5.2.3 Topological Path Planner The topological path planner was written in PROLOG. This program is an adjusted version of the path planning software in the PROLOG to 'C' interface example programs provided with SICStus PROLOG. The adjustments to the original program include code to select the shortest path to a given destination, rather than all paths, and also a modification to enable the input of a limited amount of world state information about the temporary or permanent blockage of paths on the topological map. The 48 planner draws topological map information from a series of PROLOG clauses which describe connected points on a topological map provided by the researcher for an experiment Figure 5.3 shows an example of both the topological map and the PROLOG clauses used to represent the map. Appendix K lists the program for the planner. 
This translates into the PROLOG clauses listed bellow. connected( 4,5). connected( 6,5). connected(3,4 ). connected( 4,2). connected( 1,2). Figure 5.3 49
Figure 5.4 50
Download 1.23 Mb. Share with your friends:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
