Architectures for Controlling an Intelligent Autonomous Vehicle
Download 1.23 Mb.
|
- Navigate this page:
- Chapter 4
- 4.0. Introduction
- 4.1 . 1 Sensor Deta i ls
- 4 . 1.2 Hardware Modification
- 4.2 Subsumptio n Software Developed
- 4.2.1 Refle x Mod u le
- 4 . 2 . 4 Find I n fra R e d Beacon
- 4.2.5 Implementa t ion De t ails
3.4 Future Work This simplicity of this vehicle is very attractive, and has inspired several ideas for future development. The first two points below have high priority and are likely to be completed. 1. The development of a command language and compiler to enable faster and more efficient production of code for the vehicle
4. Introduction of learning (andlor some form of evaluation) through genetic algorithms so the vehicle could self describe its own control code or engage in some form of internal learning. At present, only two of these vehicles have been constructed. Production of more vehicles with the enhanced sensory capacity would be necessary to complete the last two goals. 3.5 Summary This chapter shows how a simple mobile vehicle with a reactive control architecture can successfully perform a single task, such as obstacle avoidance. This simple and extremely cheap hardware can be rapidly developed for mobile vehicle 30
31
An Implementation of a Subsumptjon lAY Architecture Contents 4.0. Introduction 4.1. The Hardware Sensor Details Hardware Modification Details 4.2. Subsumption Software Developed Reflex Module Obstacle A voidance Module Wall Following Module Find Infra Red Beacon Implementation Details 4.3. Experiments Performed and Their Results Comments of the Performance of the Vehicle Comments on the Performance of Subsumption 4.4. Future Work 4.5. Summary 4.0. Introduction architecture developed by Brooks (1986) on one of the departmental Marvin vehicles. This chapter details an implementation and re-evaluation of the subsumption The chapter first includes a brief deSCription of the Marvin autonomous vehicle, Ford, used as the base vehicle in both this and the following chapter. This description 32
4.1 The Hardware The Marvin vehicles, developed in the Computer Science Department at the University of Essex, are mid-sized mobile vehicles built as platforms for a MC68030 based VME computer system. Figure 4.1 pictures Ford, the vehicle used for the majority of these experiments. 
Figure 4.1 33
4.1.1 Sensor Details The Essex Marvin vehicles currently have four types of sensory equipment which read input from the environment:
Each has an arc of approximately 20 degrees of sight, providing a total of around 80 degrees of coverage. The sensors have a sensitivity in which one ultra-sound step equals 1.66 centimetres.
When combined with software, this sensor both differentiates between any number of infra-red beacons placed in its environment, and detects the angle of each beacon from the vehicle's centre line. Reading have a potential five degree error.
The software developed at Essex for the Marvin vehicles relies primarily on input from the ultra sound sensors for obstacle avoidance and wall recognition. The infra red bearings facilitate pursuit of higher level goals, such as locating beacons. The cameras will similarly expand the capacity for task performance in future projects. 34
The Marvin vehicles experienced difficulty in consistently avoiding obstacles during the initial implementation of the subsumption architecture. I speculated that the vehicles lacked sufficient data from the ultra sound sensors to interpret their environments, and elected to attach an additional ultra sound controller board to one of the vehicles (Ford). The new board doubled both the number of sensors and the scope of the input coverage. Figure 4.2 details the positioning of these new sensors, and Appendix E indicates the address of this board in the vehicle's memory map. 14cm 1 8cm 14cm 8cm 1 13451 12 1 61 1 1 1 11 1, 71 1 1 1 1 1 14cm 7cm 22 cm _____ 8 _ ( Numbers 1 to 8 are the positions of the ultra sound transmit and receive pairs) Figure 4.2 This positioning necessitated a ten degree dead area between each pair of ultra sound sensors to stop interference or cross readings. This gave the vehicle virtually full coverage of the front half of its operating environment. A single ultra sound sensor provided some data about the space to its rear. Even with these modifications, the ultra sound sensors still only provided incomplete information about the environment. The use of another type of sensor, such as vision, as the primary source of information, will likely improve the results of future research. 35
a ensor Figure 4.3 The next four sub-sections detail the individual AFSMs, to which I will subsequently refer as modules. 4.2.1 Reflex Module Upon receiving an input from one of the vehicle's bumper bars, this module suppresses all other control of the vehicle's motors and causes the vehicle first to stop, and then to move approximately 10 em in a direction away from the object with which it made contact. The software then removes the suppression, enabling other behaviours to take back control of the motors. This operation positions the vehicle so that it can rotate freely to any orientation required. This software is implemented in 'C', using a modified version of the standard bumper interrupt handling routines I. IThis process has also been implemented using a three layer neural network model, using the PDP software developed by 1. McClelland, et. al. (1989). The PDP approach was not used in the final project as it requires more processing while offering no advantages over the procedural approach. 36
This unit, which gathers input from the ultrasound sensors, avoids obstacles in a reactive manner. This module suppresses the output of other modules when the vehicle moves within a close proximity of an object. One example of such a reaction follows: Input: The vehicle's front-left ultra sound sensor detects an obstacle at a distance of one metre. Output: The unit slows the rotation of the vehicle's front-right wheel in correlation to the distance between the sensor and the object, while keeping the speed of the left wheel constant, causing the vehicle to veer right. When the sensors no longer detect a nearby object, the software lifts the suppression, and control reverts to the higher level unit. This module is currently implemented in 'C' in a procedural style. 4.2.3 Wall Following Module I implemented a wall following module as two separate functions. The ftrst function created an ego-centric map of the vehicle's immediate vicinity. The second function enabled the vehicle to follow a wall by using this map. Originally, I tested two different geometric wall recognition routines, developed in conjunction with Steve Brains, a mathematics graduate (detailed in Appendix I). When Ford operated with these geometric routines, it successfully followed walls only 50 percent of the time. After checking the ultra sound readings, measuring the distances to the wall, and calculating the expected results, I concluded that the inaccuracy and unreliability of ultra sound sensors contributed to the high number of failures. Instead, I implemented the wall following module using a far more simple and reactionary method, described in Figure 4.4. 37
REPEAT IF going_to_an_object THEN corect_to _parallel_course IF going_away _from_object THEN corect_to_parallel_course IF parallel_to_object THEN go_straight UNTIL object NOT medium_distant REMOVE_SUPPRESION ENDIF Figure 4.4 This third algorithm causes the vehicle to follow the walls of obstacles while keeping a constant distance away from them. Unlike the previous two algorithms, which require three correct ultrasound readings at any point in time, this algorithm requires only two correct readings. Using the third algorithm, Ford successfully followed walls in 70 percent of trials. This algorithm provided a sufficient degree of efficiency for the continuation of trials for this project, though it would likely generate better results if implemented on a vehicle with enhanced sensory capacity. 4.2.4 Find Infra Red Beacon This module, the highest in the hierarchy of the implemented modules, directs the vehicle to find a given infra red beacon. This module controls the vehicle if no other module in the hierarchy is active. The slow scan speed of the infra red sensor slows the operation of this module. As a result, the current bearings quickly become out of date. Reducing the speed of the vehicle's movement to one-fifth of its maximum speed allowed the sensors to hold a reasonable level of accuracy. The speed reduction permitted this module to perform correctly and guide the vehicle directly and smoothly to its goal. 38
Each module was initially implemented as a separate unit in an integrated processes, with operating system priority increasing as the hierarchy was ascended. This implementation method proved problematic, as the time taken by the operating system's tasks caused the scheduler to starve important behaviours, such as obstacle avoidance, of processor time - with predictable repercussions. A second strategy of implementing all of the individual processes in a hierarchy of IF statements proved more successful. This hierarchy is shown in a section of pseudo-code listed in Figure 4.5. REPEAT IF obstacle is close THEN aviod_obstacle ELSE IF obstacle is distant THEN follow _ wall ELSE IF no_obstacal THEN follow _infra_red_becon ENDIF ENDIF ENDIF UNTIL Figure 4.5 This second implementation strategy using IF statements generated a more predictable performance than its predecessor. This approach worked because only a small amount of processing time was required for each of the modules, although parallel execution would be required if the processing time of any of these modules was increased. Appendix G lists the code for the second implementation strategy. Download 1.23 Mb. Share with your friends:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||