Final Report
EE 3331-002 Project 2
GPS Guided Vehicle

By: Yasser Khan
December 10th 2004

Instructor: Dr. Andreas Neuber
Advisor: Dr. Jon G. Bredeson

Team Member(s):
Travis Vollmer
Justin Griffin

Abstract

This paper illustrates the implementation of an autonomous robot that navigates around the TTU R4 parking lot using the guidance of a GPS sensor. Choosing of this robot will be discussed, as well as the different components needed to make such a project possible. The GPS sensor is manufactured by GARMIN and its accuracy will be evaluated in this report. The Texas Instrument microcontroller MSP430F149 will receive GPS data from the sensor and run well assembled software to evaluate and control the motor controller which controls the motors. The microcontroller will control movements of the chosen robot and do actions such as move straight and turn a number of different degrees.

Table of Contents

Table of Contents…………………………………………………………………2

Introduction……………………………………………………………………….3

Researching GPS………………………………………………………………….3

GPS statistics…………….………………………………………………………..6

Block Diagram…………………………………………………………………...10

Texas Instruments MSP430 Microcontroller………………………………….10

DC Motor and Futaba Servo……………………………………………………13

Voltage Regulators & Transceiver……………………………………………..14

Motor Controller………………………………………………………………...16

Power supply……………………………………………………………………..17

Chassis……………………………………………………………………………17

Programming in C Code………………………………………………………...18

GPS Integration………………………………………………………………….19

Programming flow chart………………………………………………………...21

Problems………………………………………………………………………….22

Result & conclusion……………………………………………………………...23

Gantt chart……………………………………………………………………….24

Budget…………………………………………………………………………….25

References………………………………………………………………………..26

Introduction

This project requires an intensive study and understanding of the GPS system, and its uses. In this project, a car uses a GPS sensor that receives GPS data and sends it to another component that is connected to it. This is accomplished by connecting a GPS sensor to a microcontroller via the universal synchronous/asynchronous receive transmit (USART) component. The microcontroller can then process this data and use the current position to navigate the car wherever it needs to go. In the course of this report, it will be explained how the GPS was integrated into the vehicular system and a stepwise look at the progress of this group, from day 1 through final demonstration day. Since the schedule of this project is for 8 weeks, a considerable amount of time management is necessary to achieve full potential. The Gantt chart for this project was thoroughly planned and made up.
Researching about GPS
The next task was to research and find out more about GPS or Global Positioning System.
GPS is a satellite-based navigation system made up of a network of 24 satellites placed into orbit by the U.S. Department of Defense. GPS was originally intended for military applications, but in the 1980s, the government made the system available for civilian use. GPS works in any weather conditions, anywhere in the world, 24 hours a day. GPS receivers take this information and use triangulation to calculate the user's exact location. A GPS receiver must be locked on to the signal of at least three satellites to calculate a 2D position (latitude and longitude) and track movement. With four or more satellites in view, the receiver can determine the user's 3D position (latitude, longitude and altitude). * Global Positioning System * GPS provides “Specially coded satellite signals” that can be processed in a GPS receiver, enabling the receiver to compute position, velocity and time. * There are three segments of the GPS A. Space Segment B. Control Segment and C. User Segment Figure 1: The GPS system

* These are the following types of Sentences our GPS collected when we connected it to the Hyper Terminal Program: * Sentence Description * $GPGGA Global positioning system fixed data * $GPGSA GNSS DOP and active satellites * $GPGSV GNSS satellites in view * $GPRMC Recommended minimum specific GNSS data * We used the $GPRMC sentence in our program and testing. Figure 2: Parking lot GPS data

GPS Statistics
It was found that at any one point on the track, the GPS reading varied a lot. So, in order to better estimate the errors in the track, a series of GPS readings were taken. These readings were taken using the GPS 35, the actual sensor which we will mount on our car in the future. The GPS35 sensor was connected to a Laptop through a serial RS232 cable and the output of the sensor was read in by Hyper Terminal and saved as a text file and the Readings were taken.
Figure 3: GPS data through Hyper Terminal

For better accuracy Differential GPS might be a good choice. But it should be researched whether it is possible or not to use DGPS in the R4 parking lot.

Data Analysis:

Figure 4: Latitude data analysis (1st set of data)

Figure 5: Longitude data analysis (1st set of data) Figure 6: Latitude data analysis (2nd set of data)

Figure 7: Longitude data analysis (2nd set of data)

Figure 7a: Excel screen shot of GPS data analysis
Covariance:

Covariance (lat-long 1st set of data) -8.84345E-08
Covariance (latitudes 1st and 2nd set of data) 6.10766E-08
Covariance (longitudes 1st and 2nd set of data) -6.88493E-09
Correlation coefficient:

Correlation coefficient lat-long (1st set of data) -0.64951768
Correlation coefficient lat-lat (1st vs. 2nd) 0.26132284
Correlation coefficient long-long (1st vs. 2nd) -0.038159514
Block Diagram for Project
The block diagram shows the basic ingredients required to make this project work. Other smaller essentials like the motor controller and null modem which are not mentioned here will be discussed later. Figure 8: Overall Block diagram

Microcontroller
After the R/C components and the turret of the car were stripped away, the only thing that remained on the car was the two motors driving each of the tracks. To make the car move there would need to be some kind of commanding element which told the car what to do. A microcontroller would do that job. We had two choices when it came to the microcontroller. * The Texas Instruments MSP430 * Motorola HC12
Texas Instrument MSP430 Low-Power Microcontroller: In this design, the Texas Instrument’s MSP430 microcontroller was chosen. An advantage for this decision is that it consumes less power than the other available microcontroller, the Motorola M68HC12. Since the car uses so much power to run, there is a concern that if the HC12 microcontroller was used then the power consumption would drain the battery much faster than the MSP430. This is important because the car needs enough power to run the full lap around the parking lot. The MSP430 operates at a voltage ranging from 2.7V to 3.6V. The HC12, on the other hand, operates at a voltage of at least 5V. When operating at a higher voltage, more power is consumed by operating at higher voltages. Another reason that the MSP430 was chosen is because the MSP430 can be programmed in the C coding language. By using this higher language, functions and programming of the MSP430 is simplified. The HC12 is best programmed in assembly language. This programming language is much harder to understand at first glance and much harder to program. The MSP430 is used to operate the car by sending two PWM signals to the dc motor and the servo. The MSP430 is using the capture compare registers 1 and 2 to send a PWM signal through pins 14 and 15. The PWM signal is created by using a clock and dividing the oscillations of that clock by powers of 2. In this way, the MSP430 can send a PWM signal to the H-bridge which powers the movement of the dc motor. The microcontroller can also send a signal to the servo to turn the servo in both directions. When running the PWM signal generator from the microcontroller, the PWM period can be changed as well. This, in turn, allows the microcontroller to change the frequency of the PWM signal. The microcontroller is programmed to send a 50Hz signal to the servo, and the duty cycle of the PWM signal controls how far the servo turns left or right. The MSP430 is connected to the GPS sensor and has a peripheral that interfaces the sensor to the microcontroller. The USART peripheral is used when transmitting and receiving data. The data gets stored in a buffer setup specifically for the USART and the data gets stored into this buffer until a program gets that data or the next line of data is received. This function of the microcontroller makes it very versatile. The baud rate, or the rate of which data is transferred, can vary as well. Since the Garmin GPS sensor is operating at 9600 baud, then the MSP430 is set to receive data at the same rate. Figure 9: MSP430f149 chip

DC Motor and Futaba Servo In this design, the use of a dc motor and servo is needed to drive and navigate the car. A standard dc motor was used in this design as well as a Futaba S3003 servo. (See Figure 5) This servo operates at a voltage of 5V and a PWM signal frequency of 50Hz. Depending on the duty cycle, or how long the servo is turned on by the PWM signal, the servo will turn left or right. Since the servo direction is maintained by the PWM duty cycle, this means that the microcontroller can control the servo position which controls the direction of the car. Therefore, the program that sets the values for the PWM signal duty cycle has control of the direction of the servo. So using this design allows complete control by the program. The dc motor is controlled in a similar way. The microcontroller sets values to the capture compare registers (CCR) and changes the duty cycle via the code. However, the dc motor operates through an H-bridge chip. This means that when a PWM signal is generated that, according to the H-bridge schematics, the higher the duty cycle is set on the microcontroller, then the slower the motor operates. (See figure 6) Figure 10: Futaba S3003 servo
Maxim IC Voltage Regulators and Transceiver This design also employs the use of two Maxim IC voltage regulators and a SIPEX IC transceiver. The reason for the use of the voltage regulators is that the voltage needs to be reduced for both the MSP430 microcontroller and the Futaba S3003 servo. The MAX639 chip circuit regulates to a voltage of 5V. (See Figure 9) The MAX640 chip circuit regulates to a voltage of 3.3V. (See Figure 10) The microcontroller is powered by the 3.3V being regulated by the MAX640 and the Futaba servo is power by the 5V regulator, or the MAX639. By connecting these regulators in parallel with the battery, the design allows for the operation of multiple devices to connect to one battery. To keep the battery from running out of power though, these three devices are the only devices connected in parallel with the battery. The GPS sensor which operates at 5V uses the other battery only in order to maintain optimum operating voltage since the GPS data is imperative to the navigation of the car. Figure 11: Maxim IC Figure 12: Voltage vs. current curve

The Transceiver is another important component to this design. The SP3223E transceiver is used in this design to step the voltage down from the GPS sensor. The transceiver operates at 3.3V, and, therefore, it is connected in parallel with the MSP430 microcontroller from the MAX640 voltage regulator. The reason that the transceiver is needed is that the voltage sent by the GPS exceeds 3.6V which is the maximum threshold that the MSP430 can handle. Since the MSP430 cannot accept voltage over 3.6V, then the transceiver is needed to step the voltage down. The SP3223E steps the voltage down to 3.3V while still maintaining the correct GPS data. This means that in order for the MSP430 to receive GPS data, the transceiver has to be in series with between the GPS sensor and the MSP430 microcontroller. Figure 13: Sipex 3223E chip

Figure 14: Transceiver-msp-gps connection diagram

Motor Controller

Figure 15: Chopper Circuit schematic * AKA chopper circuit * MOSFET rapidly switches battery current on and off * Varying the “chopping” ratio will vary the amount of voltage seen by the motor * This will allow for varying of speeds with the motor Figure 16: Chopper Circuit Hardware

Power
It was decided that the original 9.6 V battery which came with the R/C car will be parallel with another 9.6 rechargeable to maintain enough power supply for the motor, servo, microcontroller and the GPS. We used two voltage regulators to step down the supply for the servo and motor controller and one with the transceiver for the msp. We did not use any external switch rather we used the regular jack came with the rechargeable battery pack.
Choosing / acquiring our chassis
Week 1 of the project was used mainly to get familiarized with the new group, agree on a possible chassis idea and understand the GPS concept further. The Chassis decision would be crucial to the project, since everything used would be built around it. There were a few ideas. One that a few groups from previous semesters had used was to build a chassis from scratch. This would give a lot of flexibility in terms of positioning the various elements in the car. Another was to buy a Remote Control Car with 4 wheels, take out the R/C part and add whatever was needed to it. The car has 2 motors, one making it move and the second, which could either, be a motor or a servo, making it turn. Ordering off the internet however, would take around a week for it to ship in. We got our RC car in between second and third week. And implemented the idea of making new chassis with the flexi glass and mounted rest of the hardware on it. It was an wonderful idea to make a new chassis and had the 10 feet long GPS wire placed on the back trunk of the car.
Final Chassis Figure 17: Final chassis of the car

Coding and Programming
The MSP430 can be programmed in C code. This is commonly what is used to program the microcontroller. It is a higher level language compared to assembly which can also be used when programming the microcontroller. The basic flow of the code explains the basic operation of the car. First, the microcontroller receives GPS data and processes it. From there, the data is compared to the hard coded points from the virtual track that is laid out on the parking lot. When the car is inside the track, then the motor is turned on and the car starts to drive. Every time an interrupt occurs, the GPS data is received, processed, and compared. This repeats until the power is turned off. When the situation arises that the car is outside of the virtual track, then the program calls a navigation correction function and corrects the car’s position. From this program design, the car can be driven using GPS data. For every corner of the parking lot, there is a point on the track that signifies to the microcontroller that the car needs to turn the corner. This is accomplished in the same way that the navigation correction algorithm is setup. The car receives data and compares it and then corrects itself according to the GPS data it just processed and compared. This program design is essentially what drives the car the full lap around the parking lot. A few test programs had to be written before the main code was created. These programs tested the various ideas, like blinking the LED of the MSP with different time frame. Sending the PWM signal through the MSP etc.

GPS Integration

After the driving codes were done, the GPS needed to be tested for compatibility with the system.

Hardware Integration
The Garmin GPS35 supplied had a long 10 foot RS232 cable attached to it. It was necessary to make enough room in our car to accommodate the wiring. So, an extra pocket was created (the trunk) on the back of the car to fit the wiring in. To connect the GPS35 to the MSP, we needed an extra piece of hardware. It is the Transceiver board with “sipex” chip on it. When we connect the GPS35 sensor to the MSP the transceiver converts the RS232 logic to TTL so that the MSP can read the GPS data.
Software Integration
To make the MSP430 receive data from the GPS35, we have to give it some software commands in the code. * The Transmission / Reception. * The BAUD rates have to match (9600 BPS) * Some Software which understands the input from the GPS sensor and interprets it for the rest of the code to understand.
A code which takes in data from the GPS sensor, interprets it and stores the longitudes and latitudes into variables was written by Dr. Neuber, a professor at the Electrical Engieneering Dept. at Texas Tech University, and with his consent, we used it as part of our code.

Programming Flowchart

Figure 18: Programming flow chart
The flowchart for our code follows a simple algorithm with hard-coded waypoints and dynamic tunneling. This means that, to get from one leg of the track to another, the destination waypoints are hard-coded, but once the car gets there and turns, the tunnel walls are dynamically assigned depending on the latitude or longitude of that position.
A very important system variable is the ‘Path’ variable. This stores which leg of the track the car is on. The reason for it being so important is that on paths 1 and 3, the latitudes are used as side tunnel walls and the longitudes are used for waypoints. For paths 2 and 4, these are reversed.

Problems encountered 1. Selection of the motor control: * First we decided to go with the ready-made motor control available in the market. Then we decided to make similar to that one because the available motor control is expensive. After that we switched to another kind of motor control called the “chopper circuit”. The problem is we changed our design almost every week which wasted our time. Rather we could go with the ready-made one which would definitely save some time. 2. Communication with the MSP: * This is the big drawback of our project – never been able to talk to the MSP. We first tested the “blinking LED” program. And the week after that the program stopped working. And we did not get another evaluation board for the MSP to test. After that week till the day of the demonstration we couldn’t able to talk to the MSP. * The IAR loads the program and compiles it with no error but the MSP did not give us any output. * We traded our code with another group’s working code which also failed in our MSP * We had several Lab 1 friends to come and see our code and also few graduate students to look at it. And they couldn’t give us anything more.
To solve the problem with the MSP: * Tested Pin Connections * Tested Chip Connection * Tested Transceiver / Voltage Regulators * Ran sample programs * Ran programs for pwm * Established Communication between GPS and MSP by using different Evaluation Board.

Results and Conclusion
Although we couldn’t establish communication with the MSP before the day of the demonstration, still we learned a lot from our achievements and failure. The day after the demonstration, we again tried to talk to the MSP using another MSP kit. This time we successfully communicated with the MSP. But although it’s too late to complete the assigned task we are still happy to have some sort of communication between the MSP and the transceiver. This makes us feel that we did something and the problem is not with us but with the evaluation board as far as we understood. Other than the problem with the MSP we fairly completed all other electrical and mechanical requirements for the project.

Gantt chart

Figure 19: Gantt chart

Budget

Figure 20: Budget

References

Dr. Andreas Neuber Dept. of EE, Texas Tech University
Dr. Jon G. Bredeson Dept. of EE, Texas Tech University http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1068/ln/en http://www.maxim-ic.com.cn/quick_view2.cfm/qv_pk/1138/ln/cn http://e-www.motorola.com/webapp/sps/site/overview.jsp?nodeId=03t3Z http://focus.ti.com/mcu/docs/overview.tsp?familyId=342&templateId=5246&navigationId=11466&path=templatedata/cm/mcuovw/data/msp430_ovw&DCMP=TIHomeTracking&HQS=Other+OT+home_p_micro430 http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html http://www.garmin.com/aboutGPS/manual.html http://www.hvwtech.com/pages/products_view.asp?ProductID=68&CurPage=2 http://www.gpmd.com/cgi-bin/wgpinf100p?&I=FUTM0031
MSP430 User’s Guide

APPENDIX
Appendix 1.1 (Test Program)

Figure 21: Sample code for MSP

Appendix 1.2 (Final Code for the Car):
Code written in “C”
#include <msp430x14x.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>

//Global Functions void usart(void); void motorInit(void); void newline(void); void turn(int); void navigate(void); void get_data(void); void warmup(void);

//Global Variables const int MAX = 68; char curr_N_pos [5]; char curr_W_pos [5]; char sentence[68]; char sigAquired = 'F'; char check = 'F'; int count = 0, Nvalue = 0, Wvalue = 0, Drv_Dir = 1; int North1 = 0, North2 = 0, North3 = 0, North4 = 0; int West1 = 0, West2 = 0, West3 = 0, West4 = 0; int wayA = 6015, wayB = 1999, wayC = 5560, wayD = 2080;

//example sentence
//$GPRMC,225446,A,4916.2000,N,12311.6078,W,000.0,258.0,191194,020.3,E*68

/*******************************************************************/ void main(void)
{
WDTCTL = WDTPW +WDTHOLD; // Stop the watchdog timer usart(); motorInit(); warmup(); for(;;) { _BIS_SR(LPM3_bits); get_data(); navigate(); _NOP(); }
}

/*******************************************************************/ void warmup(void)
{
int x = 0; long avgW = 0; long avgN = 0; CCR1 = 640; while(x<17) { _BIS_SR(LPM3_bits); process(); if(sigAquired != 'F') { ++x; avgN += Nvalue; avgW += Wvalue;} }

avgN /= x; avgW /= x; // Get the average of all points if(Drv_Dir == 1) { North1 = (avgN - 2); North2 = (avgN + 2); } else if(Drv_Dir == 2) { West1 = (avgW - 1); West2 = (avgW + 1); } else if(Drv_Dir == 3) { North3 = (avgN + 1); North4 = (avgN - 1); } else { West3 = (avgW + 1); West4 = (avgW - 1); } sigAquired = 'F';
}
/*******************************************************************/

void motorInit(void)
{
TACTL = TASSEL0 + TACLR; // ACLK, Clear Tar CCR0 = 640; // PWM Period/2 CCTL1 = OUTMOD_7; // CCR1 reset/set CCR1 = 640; // CCR1 PWM duty cycle CCTL2 = OUTMOD_7; // CCR2 reset/set CCR2 = 38; // CCR2 PWM duty cyle: 10;38;66 rail to rail P1DIR |= 0x0C; // P1.2 and P1.3 output direction P1SEL |= 0x0C; // P1.2 and P1.3 TA1/2( Pins 14 and
15)
TACTL |= MC0; // Start Timer_A in up-down mode
}
/*******************************************************************/ void get_data(void)
{
int i; //Checks for good signal and that the line is of the form $GPRMC: //$GPRMC,225446,A,4916.2000,N,12311.6078,W,000.0,258.0,191194,020.3,E*68 if(sentence[13] == 'A' && sentence[4] == 'C') { //Collects points from GPS data for(i = 0; i<4; i++) { curr_N_pos[i] = sentence[20 + i]; curr_W_pos[i] = sentence[33 + i]; } curr_N_pos[4] = NULL; curr_W_pos[4] = NULL;

sigAquired = 'T'; P1OUT ^=1; //Convert characters to a integer value Nvalue = atoi(curr_N_pos); Wvalue = atoi(curr_W_pos); } else sigAquired = 'F';
}

/*******************************************************************/

void turn(int value) // Reset/Set CCR2 (servo) & Amount to turn
{
CCTL2 = OUTMOD_7; CCR2 = value;
}
/*******************************************************************/ void usart(void)
{
UCTL0 = CHAR; // Enable 8-bit character length UTCTL0 = SSEL0; // Sets UCLK = ACLK UBR00 = 3; // Sets baud rate factor of lower 16 bits UBR10 = 0; // Sets buad rate factor of upper 16 bits UMCTL0 = 0x4A; // Modulation of 32.768 kHz BRCLK ME1 |= URXE0 + UTXE0; // Enables transmit and receive on USART0 IE1 |= URXIE0; // Enables interrupt on USART0 receive P3SEL |= 0x20; // Enables P3.4 and P3.5 UT/RXD0( Pins 32 and 33) P3DIR |= 0x10; // P3.4 UTXD0 as output direction //////////////////////////////////////////////////////////////////////////// //This portion sets of the LED to be as a visual that incoming data is being //recieved P1DIR = 1; P1OUT = 0; // P1.0 TACLK as output direction & LED off //////////////////////////////////////////////////////////////////////////// _EINT(); // Enable interrupts
}
/*******************************************************************/
// Interrupt Subroutine interrupt[USART0RX_VECTOR] void usart0_rx(void)
{
if(RXBUF0 == '$') // Test to see if first character is a $ { check = 'T'; count = 0; } // If true,check = TRUE & count = 0 else if(check == 'T') // Test to see if checking is still ok to do { sentence[count++] = RXBUF0; // Adds character array, increase count if(RXBUF0 == '*') // Test to see if count = 68 { check = 'F'; _BIS_SR(LPM3_EXIT); } // Resets check to FALSE } else if(RXBUF0 == 0x0D) // Test to check for end line character newline();
}

/*******************************************************************/

void newline(void)
{
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer ready? TXBUF0 = 0x0A; // Write a endline to the TXBUF0 while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer ready? TXBUF0 = 0x0D; // Write a newline to the TXBUF0
}
/******************************************************************/ void navigate(void)
{
int i = 0; CCR1 = 220; if(Drv_Dir == 1 && sigAquired == 'T') { if(Wvalue >= wayA) { turn(70); // Turn Corner to the left Drv_Dir = 2; for(i = 0; i < 20000; ++i) _NOP(); for(i = 0; i < 20000; ++i) _NOP(); warmup();// Exit Loop } else if(Nvalue > North1) { if(Nvalue < North2) turn(38); else { turn(41);// Correct Left for(i = 0; i<20100; i++) _NOP(); turn(38); for(i = 0; i<20000; i++) _NOP(); } } else { turn(37); //Correct Right for(i = 0; i<20000; i++) _NOP(); turn(38); for(i = 0; i<20000; i++) _NOP(); } } else if(Drv_Dir == 2 && sigAquired == 'T') { if(Nvalue <= wayB) { turn(70); // Turn Corner to the left Drv_Dir = 3; for(i = 0; i < 20000; ++i) _NOP(); //turn(38); for(i = 0; i < 20000; ++i) _NOP(); warmup();// Exit Loop } else if(Wvalue > West1) { if(Wvalue < West2) turn(38); else { turn(40);// Correct Left for(i = 0; i<20000; i++) _NOP(); turn(38); for(i = 0; i<20000; i++) _NOP(); } } else { turn(37);// Correct Right for(i = 0; i<20000; i++) _NOP(); turn(38); for(i = 0; i<20000; i++) _NOP(); } } else if(Drv_Dir == 3 && sigAquired == 'T') { if(Wvalue <= wayC) { turn(70); // Turn Corner to the left Drv_Dir = 4; for(i = 0; i < 20000; ++i) _NOP(); //turn(38); for(i = 0; i < 20000; ++i) _NOP(); warmup();// Exit Loop } else if(Nvalue < North3) { if(Nvalue > North4) turn(38); else { turn(41);// Correct Left for(i = 0; i<20000; i++) _NOP(); turn(38); for(i = 0; i<20000; i++) _NOP(); } } else { turn(37);// Correct Right for(i = 0; i<20000; i++) _NOP(); turn(38); for(i = 0; i<20000; i++) _NOP(); } } else if(Drv_Dir == 4 && sigAquired == 'T') { if(Wvalue >= wayD) { Drv_Dir = 1; for(i = 0; i < 20000; ++i) _NOP(); CCR1 = 640;// Exit Loop for(i = 0; i < 40000; ++i) _NOP(); } if(Wvalue < West3) { if(Wvalue > West4) turn(38); else { turn(41);// Correct Left for(i = 0; i<20000; i++) _NOP(); turn(38); for(i = 0; i<20000; i++) _NOP(); } } else { turn(37);// Correct Right for(i = 0; i<20000; i++) _NOP(); turn(38); for(i = 0; i<20000; i++) _NOP(); } }
}// End Func void navigate()

/*******************************************************************/