ICIAS2012 1569574121

Implementation of Autonomous Vehicle Navigation Algorithms Using Event-Driven Programming

Abu Bakar Sayuti Saman Patrick Sebastian Nadhira Abdul Malek Nurul Zahidah Md Hasidin
Department of Electrical and Electronic Engineering, Faculty of Engineering Universiti Teknologi PETRONAS, Seri Iskandar, 31750 Tronoh, Perak, Malaysia
Abstract - Autonomous navigation is an important feature in robotics as it provides mobile robot with the ability to traverse from one point to another point while avoiding any obstacles that lie within its path. One of the challenges is to reduce the complexity of the development of programs that can provide the pertaining artificial intelligence. The objective of this paper is to describe the implementation of autonomous navigation through the use of event-driven programming technique which was based on finite state machines (FSM). By using FSM to describe the behaviour of a navigating mobile robot, an equivalent algorithm can be developed. The algorithm can be relatively easy translated to a suitable program with event-driven programming technique. Two types of navigation, maze navigation and grid following; were implemented by persons with minimum to intermediate programming skill; exhibiting the flexibility and ease of implementation of this technique.

Personal navigation which is the awareness of the positioning of own various parts in relation to each other as well as in handling objects [1]. In maze navigation, the robots goal is to traverse from a starting point to an end point through an unknown maze of walls. It must be able to detect obstacles in front and both of its sides. It must also be able to detect an opening in the walls on its left or right. For a grid following robot, its goal is to move on the lines within a grid. The lines form many possible paths that it can take get from a starting point to an end point. Its operator may determine the starting and end points; and also which specific route it must take. FINITE STATE M ACHINE By charting the behaviours of the said robots as finite state machines (FSM), behaviour control algorithms can be subsequently developed. A state machine consists of a collection of states that represent all possible situations. As the machine runs, the states changes continuously, and the output depends on the current state and also the input [3]. FSM tools are mainly the state transition diagram (STD) and the state transition table (STT). Figure 1 shows an STD with five possible states where the transitions are based on two inputs. Table 1 is the equivalent STT for the said diagram.

INTRODUCTION Mobile robots are widely used for many different purposes in variety of fields. One feature which is important in a mobile robot is autonomous navigation. It enables the device to move from one place to another independently, without constant navigational input from its human operator. One of the most important elements in autonomous navigation is the ability of the device to sense its environment. Thus the robot is invariably equipped with various sensors to receive important information from its surrounding. For example, proximity sensors will allow the robot to detect obstacles and subsequently to decide how to avoid them. To enable the robot to follow a pre-determined route, it is equipped with line, electromagnetic or ultrasonic sensors. With this information and a suitable algorithm, a mobile robot can autonomously traverses through various types of terrain, whether on a pre-determined route or otherwise [6]. On the whole, the objective of this paper is to discuss the use of event-driven programming technique in implementing autonomous navigation using mobile robots. Two types of navigations were implemented. The first one was a maze navigation and the other was a grid following. Two different programming languages were used: C for the maze navigation and BASIC for the grid following. AUTONOMOUS VEHICLE N AVIGATION Basically, there are three types of navigation requirement scales: (1) Global navigation which determines one's position in absolute or map-referenced terms and also to be able to move to a desired destination point; (2) Local navigation which is the ability to determine one's position relative to objects in the surrounding and to interact with them; (3)

Figure 1: State Transition Diagram for Maze Navigation using 3 inputs and 4 states

Event-driven Programming Basically, an event-driven program comprised a continuous iteration that performs two tasks: (1) event selection and (2) event handling. Events refer to the possible actions that a user might perform during an application usage. While an event handler manages a particular event after an event has been

978-1-4577-1967-7/12/$26.00 2011 IEEE 1

identified. When utilising FSM in specifying and implementing an event-driven system, a state refer to the result of an event response. The event response itself can be equated to a state transition [2,7,8].
TABLE 1 STATE TRANSITION TABLE (STT) SHOWING 5 POSSIBLE STATES OF A MOBILE ROBOT WITH 2 SENSOR INPUTS Present 00 01 10 11 states\Next states Idle Forward Forward (11) Turn Left (01) Turn Right (10) Stop (00) Stop Stop Stop Stop Turn left Turn left Turn left Turn left Turn right Turn right Turn right Turn right Forward Forward Forward Forward

Case 1:

L=1 F=0 R=1

Direction: Move Forward

Case 5:

L=0 F=1 R=0

Direction: Turn Right

Case 2:

L=1 F=1 R=0

Direction: Turn Right

Case 6:

L=1 F=0 R=0

Direction: Turn Right

Case 3:

L=0 F=1 R=1

Direction: Turn Left

Case 7: L=0 F=0 R=1

Direction: Move Forward

Case 4:

Case 8: L=1 F=1 R=1

Direction: Make a U -turn Direction: Idle/Stop

An event response depends only on the current event but ignore event history. The response does not care about the sequence of past events. This concept is handy as it reduces the number of execution paths through the code, simplifies the conditions tested at each branching point, as well as simplifying the transitions between different modes of execution. Thus event-driven programming can be used to produce simple and efficient software with well understood behaviour. It produces a maintainable code without creating spaghetti code which refers to the conventional and complex if-else programming structure [2]. APPROACH AND METHOD In tackling the two applications: maze navigation and grid following; the approach carried out was divided into four steps: (1) behaviour analysis, (2) state transition diagram, (3) state transition table and (4) algorithm. Maze Navigation

L=0 F=0 R=0

Figure 2. Behaviour Analysis of Maze Navigation using 3 sensors: Front, Left and Right.

X, 1, X 0, 0, X 1, 0, 0

Idle

0, 0, 0 X, 0, 1

1, 0, 1

Turn Left

X, X, X 0, 1 ,1

Move Forward

X, X, X 1, X, 0 0, 1, 0

Turn Right

X, X, X

1, 1, 1

U-turn

There are many conditions of the surroundings to be analysed in order to determine the robots movements. Such conditions are the obstacles, or to be specific, the walls that would hinder the robot advancement. In order to obtain a smooth navigational movement, several cases of wall presence and robot response were considered [4]. Figure 2 illustrates the breakdown of all the cases identified for a maze navigator. F, L, and R denote the front, left and right sensors which detect the front, left, and right wall respectively. Value of 1 means obstacle is detected and value of 0 means no obstacle detected. There were eight cases of events and event responses. The events were classified based on all possible the sensor input combinations, while the event responses were based on the direction the robot were to take based on the inputs. An STD was constructed as shown in Figure 3 to visually describe the result of the said behaviour analysis. The 3 bits of input were derived from the left, front and right sensors respectively. By combining some of the events and responses, a total of five states were derived. A state transition table was built based on the STD as shown in Table 2.

Figure 3. State Transition Diagram for Maze Navigation using 3 inputs and 4 states TABLE 2 STATE TRANSITION TABLE OF MAZE NAVIGATION USING 3 SENSORS: FRONT, LEFT AND RIGHT. Sensors Current State Next State Left Front Right 0 0 1 Forward X 1 X Idle Idle 0 0 X Idle 1 0 0 Idle 0 0 0 Idle 0 1 1 Left 1 X 0 Right Forward 0 1 0 Right X 0 1 Forward 1 1 1 U-turn Right X X X Forward Left X X X Forward U-turn X X X Forward

From the STT, a corresponding algorithm was produced. The algorithm is discussed later in this text.

Grid Following Navigation Grid following algorithm is based on line following algorithm. Basically, in line following, the movement of the robot is limited by the guiding line. Usually there is only a single line for the robot to follow. Sometimes the line may cross itself, forming an intersection. Still the movement is limited to areas covered by a single line, drawn in a fixed pattern. In order to stay on the line, the robot needs a line detector consisting of only a pair of light detector or infra-red sensors. Figure 3 illustrates the behaviour of a line follower robot based on four possible input patterns from the sensor pair.
Input Event Response When both sensors are on black line (00), consider it at a junction of the grid. Mobile robot stops at junction. When both sensors are on white surface (11), consider it in a position straight on the black line and it will move forward. When the mobile robot position is not straight on the black line, either one of the sensors will detect the black line. When the left on white (1) and the right sensor on black line (0), the robot will have to correct its position straight on the black line by turning right until its position is straight and vice versa for the other case (10). Figure 4. Line following behaviour based on two inputs Figure 5.A grid follower must be able to manoeuvre on a grid according to the route programmed into it

Grid Following In grid following navigation, the single line is replaced a grid of intersecting lines, 90 degrees to each other. The difference between line following and grid following is that grid following, in addition to following a line, the mobile robot must also be able to turn 90 degrees left or right. A grid following robot must be able to recognise an intersection or junction. Moving from one point on the grid to another point, it must turn at some intersections and go through some others such as shown in Figure 3. The route may also be pre-programmed into the robot. It may not be a simple point to point trip, but rather a trek containing several segments. At the end of each segment, the robot has to make a turn to enter the next segment as shown in Figure 4. In order to do this, it must also count the number of intersections it has encountered. Table 3 shows the pertaining behaviour of the grid trekker in which the movements are based on what was programmed. The trek data consisted of numbered segments, s. Each segment contained a specific number of intersections, j; and the direction (left or right) of the 90 degree turn to take at the end of it. By keeping track of the segment it is in and the number of intersections it has encountered, a robot can effectively navigate through the trek. The STD and STT for this grid trekking behaviour are in Figure 4 and Table 4 respectively.

Figure 6.An example of trek which is essentially a route consisting of several segments and turns

Route Junction (s) (j) 0 J=1 At route s=0, junction is counted until reaches j=2 J=2, 0 then reset. S is then incremented to a new route. When this condition reached, the grid trekker will turn right 90 degrees. 1 J=1, 2 At route s=1, junction is counted until reaches j=3 J=3, 0 then reset. S is then incremented to a new route. When this condition reached, the grid trekker will turn left 90 degrees. 2 J=1 At route s=2, junction is counted until reaches j=2 J=2, 0 then reset. S is then incremented to a new route. When this condition reached, the grid trekker will Stop. 3 J=1, 2,3 At route s=3, junction is counted until reaches j=3 J=4, 0 then reset. S is then incremented to a new route. When this condition reached, the grid trekker will Stop. 4 J=1 At route s=4, junction is counted until reaches j=2 J=2, 0 then reset. S is then incremented to a new route. When this condition reached, the grid trekker will Stop.

TABLE 3 GRID TREKKING BEHAVIOUR Event Response

Maze Navigation Algorithm The following pseudo-code is the maze navigation algorithm produced using the method discussed.
Loop Select state Case IDLE Stop_robot If L=1, F=0, R=1, then state = FORWARD Else state = IDLE Case FORWARD Move_forward If L=0, F=0, R=0, then Move_forward for 2 If L=0, F=0, R=0, then state = IDLE Else if L=0, F=0, R=1, state = FORWARD Else if L=0, F=1, R=0, state = RIGHT Else if L=0, F=1, R=1, state = LEFT Else if L=1, F=0, R=0, state = RIGHT Else if L=1, F=0, R=1, state = FORWARD Else if L=1, F=1, R=0, state = RIGHT Else if L=1, F=1, R=1, state = UTURN Case RIGHT Turn_right_90_degrees State = FORWARD Case LEFT Turn_left_90_degrees State = FORWARD Case UTURN Make_u_turn State = FORWARD End Select End Loop

sec

Figure 7.FSM state chart for grid follower robot

then then then then then then then

RESULTS AND D ISCUSSIONS From the state transition diagrams and tables, pertaining algorithms were produced. The algorithms were essentially built on event-driven programming concept. Each algorithm is essentially made up a continuous iteration that contains a series of event handlers. An event handler consisted of the machines current state, followed by one or more actions. A select-case construct was used to denote the state and its corresponding responses. To decide which state is the next state, an if-then-else construct is applied to the sensor inputs conditions [5]. The structure of the algorithm is such, so that it can be easily mapped back to the corresponding STT and STD. Any changes in the behaviour analysis and subsequent update in the STD and STT can be, in relative term, easily translated into the algorithm and corresponding source code produced thereof.

The resulting pseudo-code retained the basic structure of the original STT. The code is modular and structured such that
TABLE4. STATE TRANSITION TABLE FOR BEHAVIOUR OF THE GRID TREKKING ROBOT Entry Actions 1 Entry Actions 2 Next State 1/ Direction (D) R j S L R j 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 j=0 j=0 j=0 j=0 j < L1 j < L1 j < L2 j < L2 j < L3 j < L3 j < L4 j < L4 j < L5 j < L5 j=0 s=0 s=0 s=0 s=0 s=0 s=0 s=1 s=1 s=2 s=2 s=3 s=3 s=4 s=4 s = smax Forward Forward Turn Right Turn Left Forward Turn Right 90 Forward Turn Left 90 Forward Turn Right 90 Forward Turn Left 90 Forward Turn Right 90 Stop 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 j=0 j=0 j=0 j=0 j = j+1 j=0 j = j+1 j=0 j = j+1 j=0 j = j+1 j=0 j = j+1 j=0 -

Current State Idle Forward Forward Forward Forward Forward Forward Forward Forward Forward Forward Forward Forward Forward Forward

L 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0

S s=0 s=0 s=0 s=0 s=0 s = s+1 s=1 s = s+1 s=2 s = s+1 s=3 s = s+1 s=4 s = s+1 -

Next State 2 Forward Forward Forward Forward Forward Forward Forward Forward Forward Forward Forward Forward Forward Forward Stop

even when there were many conditions and multiple levels of if-then-else required, the complexity of the code is confined within a single case condition. Figure 8 illustrates the design of the maze robot which comprised of a plastic base attached to two DC motors. A mobile robot controller board was affixed on top of the robot base with the batteries fitted in between those two. Three infra-red medium range sensors were attached to the front, left and right of the robot base. These locations were chosen because the maze robot was designed to detect the presence of obstacles at the front, left, or right. The actual robot is shown in Figure 9.The maze constructed to verify the algorithm is shown in Figure 10.
Right Sensor

Multiple runs were made to verify the effectiveness of the algorithm. Using the algorithm the robot managed to navigate itself through the maze successfully 70% of the time. Shown in Figure 11 is the most effective and shortest pathtaken by the robot, which is essentially as described by the behaviour analysis discussed earlier.
FINISH

START

Right Wheel

Figure 11. The most effective path navigated by the maze robot
Front Sensor MC40A Board Batteries

Grid Following Algorithm

Left Wheel

Left Sensor

The same method was applied on developing the grid following algorithm which was extended to be applied by a grid trekker robot. The algorithm produced is as follows:
Loop Select State Case IDLE If L=1 And R=1 Then State=FORWARD Case FORWARD Move_forward If L=0 And R=0 Then Increment Junction_counter If Junction_counter = Segment_length Then State = next direction Reset Junction_counter Increment Segment_counter Else if L=0 And R=1 Then State=TURNLEFT Else if L=1 And R=0 Then State=TURNRIGHT Case TURNLEFT Turn_left If L=1 And R=1 Then State=FORWARD Case TURNRIGHT Turn_right If L=1 And R=1 Then State=FORWARD Case TLEFT90 Turn_left_90_degrees If L=1 And R=0 Then State=TURNRIGHT Else if L=0 And R=1 Then State=TURNLEFT Else if L=1 And R=1 Then State=FORWARD Case TRIGHT90 Turn_right_90_degrees If L=1 And R=0 Then State=TURNRIGHT Else if L=0 And R=1 Then State=TURNLEFT Else if L=1 And R=1 Then State=FORWARD Case PAUSE Stop_robot End select End loop

Figure 8: Design of the mobile robot for maze navigation, showing the locations of its proximity sensors

Figure 9: The mobile robot for maze navigation

Figure 12 shows the robot on the grid that it traversed on using the just mentioned algorithm. The grid trekker robot relied upon two infra-red sensors placed underneath it to detect the grid. The movement was provided by two servo motors at its sides.
Figure 10: The maze used for verification of the maze navigation algorithm

Several test runs were made to ascertain the effectiveness of the algorithm. It was found out that the robot managed to successfully perform the task 60% of the time. It was found out that using just a pair of sensors was not enough to have a high success rate in trekking the grid. Sometimes, the robot did not have enough input to ascertain it actual orientation. When the orientation was wrong it miscalculated the number of intersections it has encountered, thus affecting its ability to successfully completing the task.

[3] [4] [5] [6] [7]

[8]

Ferdinand Wagner, Ruedi Schmuki, Thomas Wagner, Peter Wolstenholme. Modeling Software with Finite State Machines, A Practical Approach. Taylor & Francis Group. 2006. John Iovine. PIC Microcontroller Project Book (pp. 1-11). USA: McGraw-Hill. 2004 Milan Verle. Programming Microcontrollers. PIC Microcontrollers Programming in Basic. (Chapter 2). mikroElektronika. 2010. John Vetelino, Aravind Reghu. Introduction to Sensors. CRC Press. 2010. Kim B. Bruce and Andrea Danyluk. Event-driven programming facilitates learning standard programming concepts. In Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications (OOPSLA '04). ACM, New York, NY, USA, 96-100. 2004. Jeffrey Fischer, Rupak Majumdar, and Todd Millstein.Tasks: language support for event-driven programming. In Proceedings of the 2007 ACM SIGPLAN symposium on Partial evaluation and semantics-based program manipulation (PEPM '07). ACM, New York, NY, USA. 2007

Figure 12

CONCLUSIONS This paper describes a technique that can simplify the implementation of artificial intelligence in mobile robotics, specifically in autonomous navigation. The steps were clear and modular: (1) behaviour analysis, (2) finite state machine development and (3) algorithm development. The algorithm derived from the said steps, produced a relatively easy implementation of event-driven programming which can be carried with minimum programming skill. The algorithms can be clearly mapped back to the finite state machines, providing a structured, manageable and easy to maintain programs. Using the method, it was demonstrated that with minimum to moderate programming skill, even with a hardware that was far less that ideal, an effective algorithm can be produced. In this case two types of navigational algorithms have been successfully developed and verified. Future works include expanding the algorithms to solve more complex problems, for example a maze navigation in a larger, more complex maze; or a more elaborate grid manoeuvrings which can include several stopping points and several different routes. With improved hardware sets, it is imperative to see how this technique will stand against a larger scale of complexity in autonomous navigation problem solving. REFERENCES
[1] [2] Johann Borenstein, Liqiang Feng, and H. R. Everett. Navigating Mobile Robots: Systems and Techniques. A. K. Peters, Ltd., Natick, MA, USA. 1996 Miro Samek. Practical UML Statecharts in C/C++, Second Edition. USA: Newnes. 2009