Inertial Navigation System (INS) is the most important component of an Unmanned Aerial Vehicle (UAV).

The UAV must be able to flight with or without support from the base station. In order to do that, the UAV, must have an intelligent system in order to find the position and the traveled route of the vehicle, also doing the necessary calculation using the desired trace they will control the actuators of the vehicle in order to have the right direction and speed. The navigation system will have 7 degrees of freedom.

UAVs are used in many fields such as traffic control, military applications, surveillance missions and many others. The main advantages of using a UAV are the following:

• No human risk, we can send a UAV in high risk mission (such as surveillance missions with bad weather conditions).
• Reduced equipment needed, since the vehicle is unmanned we can discard all the safety equipment of the vehicle and also many safety tests that cost too much.
• Low cost, we have the ability to use equipments with decreased performance.
• Easy to use, there is no need for highly skilled staff.
• Easy to build, it is much easier to build a UAV than a real aircraft.

The UAV will have an embedded digital camera that will send video to the ground station real time through the embedded RF transmitter. There are many applications in real life such as surveillance detection projects, traffic control system, air photography and more.

Basic System Diagram

In order to create an autonomous vehicle we will use a combination of Global Position Satellite (GPS) and Inertial Navigation System (INS) approach. The advantages of the INS are the following:

• It is autonomous, no external source needed
• It is well suited for navigation. It measures the variables to be controlled
• It has good immunity to jamming
• It is stealth

On the other hand, sensor errors increase with time.

By using INS/GPS approach we are able to have better performance, unacceptable (for INS only mode) sensors errors now can be handled easily (using Kalman filters), navigation performance is not affected by GPS signal losses and more.

Hardware

Hardware Structure

Basic Hardware Diagram

The Hardware consists of the five following basic parts:

• Sensors (and the related Analog part)
• Field Programmable Gate Array Section (FPGA)
• Central Processor Unit Section (CPU)
• Peripherals
• Fault Safe Unit (FSU)

Sensors

This is the most important part of the system, it provides information that we need in order to calculate the position and the condition of the vehicle. We can split this part in three sections:

• The sensor section
• The Analog Filters
• Analog to Digital Converter

Totally 12 analog sensors have been used in the system in order to implement a complete 7 degree of freedom INS:

• 3 Rate Gyros (one for each axis XYZ)
• 3 Accelerometers (one for each axis XYZ)
• 3 Compass (one for each axis XYZ)
• 2 Pressure Sensors
• 1 Temperature Sensor

To be more specific the following sensors have been used:

• Gyroscopes

The term gyroscope comes from the Greek words γύρος and σκοπός. First used back in 1852 to demonstrate the rotation of the earth. There are many applications based on gyros from 1920 up to today, such as ship navigation, torpedo steering, rocket design, technical horizon display for aircraft and many more.

The ADXRS300 solid state rate gyro from Analog Devices has been selected. The ADXRS300 is a complete angular rate sensor (gyroscope) that uses Analog Devices’ surface-micromachining process to make a functionally complete and low cost angular rate sensor integrated with all the required electronics on one chip. The manufacturing technique for this device is the same high volume BIMOS process used for high reliability automotive airbag accelerometers.

The analog output of the sensor provides a voltage of 5mV/o/sec and the maximum range of the sensor is ±300o/sec (so, the maximum voltage variation at the output will be ±1.5V). The bandwidth of the sensor is 40Hz and the noise density of the sensor is 0.1o/sec/ so, for the specific bandwidth the noise will be 0.016o/sec.

2.2 ADXRS300 Block Diagram

• Acceleration Sensor

A good estimation of the acceleration needed in order to calculate the velocity of the vehicle (by simple integration of the acceleration) and also the traveled distance (by integration of the velocity). For the Acceleration the ADXL103 solid state sensor from Analog Devices has been used. The sensor has high precision, low power, complete single and dual axis accelerometers with signal conditioned voltage outputs, all on a single monolithic IC. The sensor measures acceleration with a full-scale range of ±1.7 g and can measure both dynamic acceleration (e.g., vibration) and static acceleration (e.g., gravity).
Integration of acceleration sensing errors causes INS velocity errors to grow linearly with time. These errors are generally not known.

The typical noise floor is 110 μg/?Hz, allowing signals below 1 mg (0.06° of inclination) to be resolved in tilt sensing applications using narrow bandwidths (<60 Hz).

2.3 ADXL103 Block Diagram

An important point that we must mention is the effect of the earth gravity on the sensor, it is important to have an accurate estimation for the inclination of the vehicle before you use any output of the acceleration sensors because we have to arbitrary submit earth gravity (1g) at all times.

• Compass Sensor

The HMC1021 magnetic sensor (MR) from Honeywell has been selected in order to detect the magnetic field of the earth. The sensor is configured as a 4-element wheatstone bridge, these magnetoresistive sensors convert magnetic fields to a differential output voltage, capable of sensing magnetic fields as low as 85μgauss.

2.4 HMC1021 Block Diagram

These MRs offer a small, low cost, high sensitivity and high reliability solution for low field magnetic sensing. The range of the sensor is ±6Gauss. The output of the magnetic sensors will give us important heading information about the vehicle that will be very helpful in order to increase the performance of the INS. In order to achieve high accuracy a magnetic switching technique can be applied to the MR bridge that eliminates the effect of past magnetic history. The purpose of the Set/Reset (S/R) strap is to restore the MR sensor to its high sensitivity state for measuring magnetic fields. This is done by pulsing a large current through the S/R strap. The Set/Reset (S/R) strap looks like a resistance between the SR+ and SR- pins. Those pulses are generated and monitored by logic in the FPGA that synchronize this process with the sampling process and automatically provide those pulses when it is necessary.

• Pressure Sensor

Two pressure sensors have been used for two reasons. First, we need an accurate measurement of atmospheric pressure in order to calculate the real altitude of the vehicle and second, we can calculate the air speed of the vehicle (very important for the navigation in order to prevent vehicle from stalling).

2.5 Pressure Vs Altitude

The MPXA6115A sensor from Motorola has been selected.

2.7 MPXA6115A Block Diagram

The MPXA6115A series piezoresistive transducer is a state-of-the-art, monolithic, signal conditioned, silicon pressure sensor. This sensor combines advanced micromachining techniques, thin film metallization, and bipolar semiconductor processing to provide an accurate, high level analog output signal that is proportional to applied pressure.

• Analog Filters

We have used 12 low pass active filters to limit the bandwidth of the signal before the input of the ADC. The salen key topology has been used for the implementation of the filters with the cut of frequency of 80Hz (the sampling frequency is 250Hz). The filter components have been selected for a Butterworth filter since we want linear phase with no variations in the filter pass band.
In the following schematic diagram we can see the filter topology with the components values as well as the filter frequency response.

2.8 Filter Schematic Diagram

2.9 Frequency Response of the Active Analog Filter

• Analog To Digital Converter

The ADC converter we have used is the AD974 from Analog Devices. The AD974 is a four-channel, data acquisition system with a serial interface. The part contains an input multiplexer, a highspeed 16-bit 200Ksps sampling ADC and a +2.5 V reference (in our application we will use an external reference voltage source for better accuracy and in order to have all ADC with absolutely the same reference voltage). All of this operates from a single +5 V power supply. The part will accommodate 0 V to +4 V, 0 V to +5 V or ±10 V analog input ranges but we will use only the 0 to 5V input range. The interface is designed for an efficient transfer of data while requiring a low number of interconnects. The AD974 is comprehensively tested for ac parameters such as SNR and THD, as well as the more traditional parameters of offset, gain and linearity. The AD974 is fabricated on Analog Devices’ BiCMOS process, which has high performance bipolar devices along with CMOS transistors.

AD974 Block Diagram

FPGA 

FPGA Block Diagram

In the FPGA we have implement the following parts:

• Interface to ADC: this part has the responsibility of collecting the data from the three ADC (12 channels) each time the sampling timer ticks. The interface with the three, quad-channels ADC is serial and uses a serial DATA, a serial Clock and three synchronization signals. In the following picture we can see a graphical description of the serial interface.

AD974 Timing Diagram

• Data filtering: a first low pass comm filter and down sampling has implement in the FPGA in order to decrease CPU utilization.

• UART: two more UART (RS-232) channels have been implemented in the FPGA for the communication with the two GPS.

• IO Controller: 16 memory mapped IO provided from the FPGA basically for providing status information.
• Compass Set/Reset Controller: This part is important in order to achieve high accuracy for the magnetic sensor. This part controls an embedded demagnetizer in the magnetic sensors and provides ‘degaussing’ to the sensors by applying high current pulses. The controller synchronizes its output with the sampling frequency of the ADCs and provides the appropriate pulses to a current driver that feed the embedded demagnetize coils of the compass sensors. The functionality of the block is very simple and also very essential for the appropriate functionality of the compass sensors. In the following simulation snapshot we can see the output of the controller.

2.13 Compass Reset Timing

• SERVO Interface: This part is the interface for the servo motor. The servo motors can be controlled by Pulse Width Modulation (PWM) so applying pulses with specific duty cycle in the servo input we will have the desired angle in the servo axis. At least four servos needed in order to control an aircraft (one for aileron, one for rudder, one for elevator and one for throttle). The PWM frequency used is 50Hz (20mSec period). In the following picture we can see the PWM input to the system.

SERVO IF Timing Diagram

• SPI Interface: For communication with the digital thermometer. The SPI interface used for communication with the DS1626 digital temperature sensor of DALLAS Semiconductors is a three wire serial interface based on a Data, a Clock and a Reset signal. In the following picture we can see the timing description of the protocol:

DS1626 Timing Diagram

• Global System Base Timer: a 32 bit timer that keeps the real time from the initialization of the system. All the modules refer to this timer in order to synchronize their functionality. The time base of the timer is 1/65536 Sec = 1000 CPU ticks (the system clock is 65,536MHz).

We use a ALTERA Cyclone Device in the Board that can be operated with a clock frequency up to 250MHz (in our application we use a clock of 66MHz for the FPGA). The implementation of the FPGA design has been done in the Quartus II development software and most of the parts have been developed in VHDL language.
The following diagram describes the top level design of the FPGA.

FPGA Top Level Design

The specific device has about 6000 logic elements (we use the 2500 of them in the current design, also the board can support devices with up to 12000 logic elements), 92Kbyte of RAM (we use the 12KByte) and we can have up to 185 input output pins (we use the 119 of them).

Also, the device has two embedded PLLs (we only use one of them) in order to make a clock stabilization, in order to reduce the jitter from the crystal oscillator and also give us the ability to multiple or divide the main system clock.

CPU

The CPU is the brain of the system, we have used a powerful 32bit little-endian, ARM base CPU @66MHz that , also we have expanded the single clock access 256KByte of internal memory with 1MByte more using a fast external SRAM memory and we have placed a 4Mbyte of flash memory. There is also a voltage supervisor circuit for system voltage monitoring; we use 3,3V for the IOs and 1,7V for the core of the CPU. The CPU has direct access to FPGA using a 16bit wide bus.
Also, the CPU has two UART channels that we use in order to communicate with the base station.

ARM7TDMI Based CPU

An embedded In Circuit Emulation Channel gives us the ability to use tools such as the ARM Developer Suite for on chip debugging, this reduces the developing time and increases the quality of the software. In our application we have used the wiggler hardware interface in order to connect the board with the ADS and the H-Tag software driver.

Also, the specific processor provided us with many useful peripherals devices embedded in the same chip. The most important of them are the following:

• Dual channel asynchronous receiver-transmitter (UART)
• Programmable watchdog timer
• Three 16bit general purpose timers
• Advanced interrupt controller
• Advanced power saving unit

Peripherals

The main peripheral components of the system are the following two:
a. GPS
b. MODEM

• GPS

The GPS is an important part of the system. The GPS will provide us we position information that we will use in order to correct the error from the sensors. The following data will be used from the GPS:

• Latitude
• Longitude
• Altitude
• East Velocity
• North Velocity
• Up Velocity
• GPS Time Output
• Position Dilution of Precision (DOP)

Typically, that information arrives every second but the accuracy of data depends on the signal of the receiver. We will use two GPS receivers, the software will decide from which of the two GPS receivers will be the master from the Position Dilution of Precision (DOP) parameter.
DOP is the measurement of the error caused by the geometric relationship of the satellites used in the position solution. The satellite set which is tightly clustered or aligned in the sky will have a high DOP and will contribute to a lower position accuracy.

GPS Receiver

GPS Antenna

The GPS receiver will be used is the Lassen iQ GPS Module Low-power, high-quality GPS from Trimble. The Lassen iQ GPS receiver is a full featured, ultra low power receiver on a miniature form factor, suitable for a variety of mobile, embedded applications. The Lassen iQ GPS receiver incorporates Trimble’s FirstGPSTM architecture in the form of two ASICS: Colossus RF down converter and IO-C33 baseband chip.

The IO-C33 integrates Trimble’s IO digital signal processor with the Epson C33 RISC processor, real-time clock, UART, and 1Mbit memory. Together with the colossus RF, this implementation of FirstGPS technology makes possible one of the smallest (26 mm x 26 mm x 6mm) and lowest power (less than 89 mW) GPS modules available.

The Lassen iQ GPS receiver outputs a complete position, velocity, and time (PVT) solution in the NMEA Version 3.0 ASCII protocol, the Trimble ASCII Interface Protocol (TAIP), and the Trimble TSIP binary protocol. A Pulse-Per-Second signal is available for very accurate timing applications.

Lassen iQ Block Diagram

• MODEM

The XStream 2.4 GHz – Long Range OEM RF Modules by MaxStream, Inc. we will be used for communication with the vehicle. This is important especially for the development and the testing of the system in order to have real time access to the system parameter while the vehicle flies.

XStream Module

The communication is half duplex in the baud rate of 19,2Kbps and the outdoor line of sight range of the modem using 2.1db antenna can be up to 5Km (we do not plan to fly more than 1Km from the base station). The frequency range of the receiver is ISM 2.4000 – 2.4835 GHz and also we have frequency hopping with 7 channels. The module can be used not only for Point to Point connections but also in Point to Multipoint Networks or in Multidropp Networks (this can be useful if we have many UAVs flying at the same time and exchanging information real time with each other).

PCB  Design

The board is consisting of four layers PCB with thickness of 18μm each. The overall thickness is 1.7mm and the dimensions are 134mm x 62mm. The weight of the main board is about 120gr. The supply voltage of the board is 7 to 12V and the current is about 450mA (including the digital MODEM and the two GPS receiver).

Most of the components have fine pitch SMD packages and that is the main reason for achieving such a small dimension of the board.

Four Layers Main Board PCB

Fault safe unit

This unit is a complete autonomous switch that monitors the system and the state of a specific channel of the RC, it is able to switch the full control of the vehicle to the user if it decides to take over full control of the vehicle. The hardware consists of an independent board that has a PLD (ALTERA MAX EPM7128) that contains all the necessary logic to switch the full control of the vehicle to the user if required.

Futaba R147F Receiver & S3003 Servos
Plugged in Fault Safe Unit

Software

Software Structure

The software implementation of the system is the most important part. It is responsible for the data collection and processing and also for all the decisions.
The following diagram describes the main software components of the system:

Basic Software Block Diagram

First of all we can recognize the software drivers for all hardware devices. This is the link layers between the software and the hardware. The basic device drivers are the FPGA driver that gives us the ability to communicate and exchange data with the FPGA of the system, the GPS drivers that collect data from the two GPSs receivers, the SERVO driver that gives us the ability to export the decisions of the system and finally the telemetry driver that transmits and receives data to and from the base station.

If we continue we can see two signal processing components, the first is process data from the sensors, which mainly removes the offsets of the sensors and performs a low pass filtering. The second controls the outputs to the SERVOs, this is a PID controller for the system outputs.

The INS and KALMAN software components are responsible for knowing the position of the system. The first takes all the sensor outputs and calculates the INS parameters (traveled distance, velocity, acceleration, heading information etc). The second takes the output from the previous component and the output from the GPS receivers and calculates the real position the vehicle.

The Navigation component is responsible for calculating the desired route and output to SERVO the appropriate commands in order to achieve it.

The two storage components are used in order to store the predefined route in the first and the traveling data in the second (used in order to improve the navigation algorithm).

Kernel Implementation

A custom real-time monolithic non-preemptive kernel has been developed to support the proper functionality of the system. The main tasks that the kernel must handle are the following:

A. Process scheduling
B. Low level hardware support
C. Exception handling
D. System failure handling
E. Missing deadline handling

The major characteristics of the kernel are the following:

Priority scheduling: The system has many hard deadlines, for example the data from the acceleration sensors, if we lose any interrupt from the sensor then we will insert an error to the velocity (we will lose a sample in the integration needed in order to calculate the velocity) and this will cause an error for the estimation of the position. So, missing deadlines may be catastrophic for the performance and the functionality of the system.In order to protect system from missing hard deadlines we have created priorities for the various tasks. In the following table we can see some of the basic tasks of the system and each priority:

Scheduler

No Preemption: there is no preemption in the processes, this makes the system more simple, but extra care must be given in order to protect the system from deadlocks, in order to achieve this, processes must be as small as possible so that a high priority will not have to wait for a long time for execution while a low priority process is running. Also, extra care must be given to prevent the system from deadlock, so a sophisticated lock structure has been developed in order to achieve boundary wait, especially for the access to hardware, and also the structure of the task (especially the low priority tasks) guarantee that we will not have a low or medium priority task waiting for a resource while executing in the CPU (no spin locks).

Real Time: this means that the system has many deadlines (hard & soft). For example, a hard deadline case is the following: if an interrupt from the INS comes then the process that handles the new data from the sensors must finish the data collection and processing before the next interrupt from the INS comes. A soft deadline is the one from the GPR, if the GPS has a new position packet (usually this happens every one second) we can miss it if we have already enough packets so we are sure for the position and all the necessary corrections that have been made (of course this does not mean that we do not need the GPS data but under specific conditions if a soft deadline for the GPS is lost the only think that can happen is to have for one second an error of some centimeters in the position estimation).

Memory management: There are three main memory banks. One memory bank of 256KByte embedded in the processor that is used for saving system data, stack & heap and two external SRAM banks of 512KByte each, the first used for storing and running the software code and the other used as buffer basically for the hardware (storing data from and to GPS devices, telemetry data, and statistical information used for calibration system self test and history purposes).

Major Devices Drivers

The following component has been implemented in order to support the system hardware:

Flash Memory controller: provides functions such as Flash_Erase, that can erase a sector in the flash memory of the system Flash write, to write a sector, flash_lock & flash_unlock to control write access to the memory and more.

FPGA Controller: used for access to the various register of the FPGA logic.

V24 Driver: this driver provides the communication of the system with RS232 devices such as the GPS, Digital MODEM, Direct connection to Base Station.

I2C driver: a software implementation of the I2C 2 wire serial communication protocol that has been implemented in order to support communication with I2C compatible devices, such as the EEPROM device (24C64) used for storing general system parameter and variables.

IIR  Filters

The following low pass Butterworth (in order to have flat pass band) IIR filter has been implemented for each ADC channel. The order of the filter is four and we use two sets of coefficients, one for cut off frequency of 40Hz and one for 10Hz.

2.30 IIR Low Pass Filter

In the following graph we can see the magnitude response of the filter:

2.31 IIR LP Filter Response

A software structure has been implemented in order to keep the global coefficients of the IIR filters. Each time new data arrive from the ADCs we call the function adc_filters() that calculate the output of the filter for the twelve channels of the ADCs

INS

The main objective of the INS module is to collect the sampling data from the twelve analog to digital channels and then to process them in order to feed the Kalman filter with valid data. After the IIR filtering of the data the INS module can extract information about the vehicle position and state. Except the data form the pressure sensors and the compass, all the other outputs need to be integrated in order to give us useful information. So, extra care is needed in the data handling. Hard deadlines must be set in order to avoid loss of samples, also a Fast Interrupt used each time that new data arrive in order to collect them as fast as we can.

The data processed by the INS are the following:

3 Axis Acceleration: with the first integration we get the speed and with a second integration the traveled distance

3 Axis Gyroscope: we continuously integrate in order to have to real state of the vehicle:

3 Axis Compass: we just filter to get heading information of the vehicle (based on the earth magnetic field).

Altimeter Pressure Sensor: we filter and then we convert the output to Altimeter using the following formula:

Air Speed Pressure Sensor: we filtered the output and then we subtract the output of the previous sensor in order to convert to result to real Vehicle Air Speed using the following formula:

Where:

Vi         = Velocity in i axis
ΔDi      = Traveled Distance in i axis
Acci     = Acceleration in i axis
Gyroi    = Gyroscope output in i axis
pv        = Airspeed pressure sensor
pa        = Altimeter pressure sensor
ρ          = air density at sea level (1.225 kg/)

Kalman  Filters

The position and velocity of the vehicle can be determined, when navigating and guiding an autonomous vehicle, with the Global Positioning System (GPS). However, several errors are associated with the GPS measurement. It has superior long-term error performance, but poor short-term accuracy. For many vehicle navigation systems, GPS is insufficient as a stand-alone position system.

Basic Kalman Filter Configuration

Kalman filtering is a form of optimal estimation characterized by recursive evaluation, and an internal model of the dynamics of the system being estimated. The dynamic weighting of incoming evidence with ongoing expectation produces estimates of the state of the observed system. An extended Kalman filter (EKF) can be used to fuse measurements from GPS and INS. In this EKF, the INS data is used as a reference trajectory, and GPS data is applied to update and estimate the error states of this trajectory.

SERVO  Driver

An important part of the whole implementation is the interface with the actuators. In our application we will use Servos used in radio-controlled modeling in order to link the system output with the real world. Servos is electromechanical devices that take as input a Pulse Modulation Waveform (PWM) add turn the motor to an angle that depends on the Duty Cycle of the PWM input. As we can see, perhaps it is the easier and the most accurate way to convert a digital signal to a mechanical action.

The PWM modulator (consisted of seven input and seven output channels) has been implemented in the FPGA and is memory mapped in to an address range of the ARM external memory map. So, no extra effort needed by the processor for the PWM conversion.

In order to make the navigation algorithm easier we have implemented a function in the device driver of the SERVO Ctrl that gives the ability to set any servo for specific time to a specific angle for specific time and then, after the time passes, without any action the SERVO returns to the initial position. The function takes as input the SERVO ID, the desired angle and the time. So, we can easily perform maneuvering using this function.

GPS

One of the most important parts of the application is the GPS and all the related software and hardware components. In order to achieve better performance, we have implemented two hardware universal asynchronous (UART) channels in the FPGA that are dedicated for the communication with the two GPS (Primary and Secondary). The UARTs collect all the messages from the GPS and put them in two dual port RAMs in the FPGA (one for each GPS of 512byte). At the same time an interrupt signal the processor that data from GPS is available. The ARM processor has direct access to the DPRAM so the data collection is very fast (only some ARM cycles).
Then, a GPS driver takes action to verify and extract the useful information from the packets.
The format used for the communication with the GPS is the Trimble Standard Interface Protocol (TSIP).  The main advantages of TSIP comparing with the standard NMEA protocol are the following:

1. Smaller packets (TSIP is binary protocol so the packet length is less than this of NMEA that is ASCII protocol)
2. TSIP provides more command for GPS configure and data acquisition.
3. Simpler packet striping with predefined packet length and fixed length data fields
4. Full configurable automatic packet output

GPS Driver Test Data Output:

GPS Position Output

GPS Velocity Output

Navigation

The navigation algorithm is responsible to manage the route of the vehicle and to give the command in order to keep the right route based on the desired predefined waypoints.

So, the main parameters of the navigation algorithm are the following:
First of all, the list of the waypoints, a user predefined list of the points that that vehicle must pass through. For its point the user must specify the desired coordinators of the point (longitude, latitude, altitude).
Some secondary parameters, that will help the navigation algorithm to be more efficient, are: the desired velocity, the approximation factor (how far from the point the vehicle can pass) and optionally some time parameters (in order to make a real time shortcuts if it is necessary).

The implementation of the algorithm is simple. First of all the points are shorted in the memory in the same order as we want them to be accessed by the vehicle. The algorithm reads the first point and set it as target. Then calculate the error from the current route (basically the angles between the target and vehicle route and also the difference in the velocity) then calculate the desired action and sends a massage to the SERVO control unit with the desired action (how many degrees we need to turn which SERVO for how long). In this way the navigation module constantly tries to keep the head of the vehicle “looking” the target.
In parallel the algorithm checks how far we are from the target compared with the approximation factor. So, if we are close enough to the target then a flag arises for the specific waypoint saying that we have successfully passed from the point. The algorithm gets the next waypoint only if the flag is set for the current point and only if the vehicle traveling away from the current waypoint. So, even if the flag is set the navigation tries to pass as close as it can from the waypoint.

Navigation Algorithm

The basic components cooperating with the navigation are the INS (in order to have a valid position of the vehicle and also information about the velocity and the traveling destination), the global system timer (a hardware timer located in the FPGA and used for synchronization of all the system) and finally the SERVO control module (in order to control the vehicle).

In the current implementation the software has the ability to keep up to 100 waypoints (no limitation on that by the hardware but no reason for more). The waypoint can be downloaded only before the starting of the system and for security reasons cannot be updated real time during the autonomous mode.

Base Station  Communication  Software

This part is very important especially in the development and debugging period.
The main functions that can be performed from a PC using the base station software are the following:

Sensor real time data acquisition, that give us the ability to have a real time visual estimation of the sensors output.

Application Code downloading. We can update the application of the board and also download new FPGA versions to the board.

Waypoint uploading. We can enter in to the system new waypoints for the navigation. Except the latitude and the longitude we have the ability to upload the altitude, the speed the approximation factor for each point.

Waypoint upload panel

Real time event log viewer. We can get in real time useful information from the board.

Perform real time tests for the hardware parts of the board (i.e. check SERVO hardware/software interface).

Upload and processing trace memory from the system. The board has the ability to log for five minutes all the sensors output pure data and all the data coming from the GPS in order to simulate situation and test the algorithms with real data. All the recorder data saved to the disk in two files (one binary file that includes the image of the system log memory and one ASCII file with a fixed size table that includes the data after the processing).

The communication with the board is based on the RS232 port of the PC. The baud rate is 115200bps for direct connection to the board and 19200bps for wireless connection (using the XStream modem), in both cases a ODD parity bit is used.

Base Station Main Panel

The following picture shows the output format (ASCII) of the logging data:

Log File

Vehicle

For the filed test we used the a RC vehicle which has enough power to accommodate the system and can also reache speeds up to 80Km/h.

Kyosho Mad Force

The final target is to achieve a completely autonomous flight with a vehicle such as the following acrobatic RC aircraft:

CAP232 Acrobatic RC Aircraft

Field Tests

Field Tests

Plan description

The first phase of the project is the acquisition of all navigation data (sensors, GPS, SERVO control) in order to trim the navigation algorithms with real data. The data will be used in order to simulate the vehicle and to verify the output of the navigation algorithm and INS filtering. In this part the analysis will be done using the Matlab software tool and we will check all the systems phases from the input IIR filters to the output SERVO commands.

First Step: Data Acquisition

After the software and hardware implementation has finished the next step is to test the whole system in a real scenario. First we will collect the full data in a predefined route in order to emulate the navigation algorithm and make all the necessary modifications to the system’s hardware and software in order to adapt it to the real “life”.
The first step is to collect and examine all the sensors and GPS pure data. With the first look in the pure data we can not extract enough information as we can see in the following graphs. So, we conclude to the obvious, signal processing is necessary.

Pure Sensor Data

The results are better when we apply the necessary filtering in the incoming data from the sensors. In the following graphs we can see the output data from the low pass filters that will feed the INS. With a short view in the following graphs, we can notice the noise reduction after filtering. Also, we can easily notice the correlation between the Gyro’s outputs the compass’s outputs, this will be very helpful to improve the performance of the INS when running along without any GPS data. Note that the three rate gyro sensors and the three compass sensors feed the INS with almost the same information (heading information) and also if the vehicle is an aircraft then data coming from compass sensor are very accurate since no external magnetic fields can easily affect the performance of the sensor. Heading information is very critical in the overall system performance when the GPS data absent. This information will be used to reject the earth gravity from the accelerometer outputs.
Finally, we can see the two small section with no GPS data.

Field Data Part I

INS Data (Acceleration, Rate Gyro, Compass)

GPS Data (Velocity, No of Satellites)

GPS Position

Now, we can focus on a smaller part of samples, about 45sec, to test the INS algorithm.

First of all, we must integrate the gyro output in order to have the rotation of the vehicle from the initial position. The sensor output voltage changes by 5mV for each degree of rotation per second. So, we can change the Y axis to degrees from Volts. In the following graph we can see the data from the gyros. In the Yaw (X axis) we have a grate change, about 85 degrees, and also we can notice an increase for the Pitch (Y axis).

Gyro Output (After Processing)

We can process the compass output for the same duration in order to compare it with the results from the gyros.
The earth magnetic field gives us a variation of ±25mV on the compass sensor output. So, we can calculate the heading information of the vehicle using the following equation:

Compass Roll Output

It is time to examine the output of the acceleration sensors. The first step is to integrate the output. Before this it is necessary to remove the offset of the sensor and then make a correction for the earth gravity. For this data examination will use the previous calculated rotation from the rate gyro outputs as reference. The following graph presents the acceleration of the vehicle after offset and earth gravity removing:

Vehicle Acceleration

The next step is to integrate the ‘clean’ acceleration in order to obtain the vehicle velocity for the three axes. We can see the vehicle velocity in the following graph:

Vehicle Velocity (INS Only)

Now, we can integrate one more time the velocity in order to get the displacement of the vehicle in the three axes:

Position Displacement (INS Only)

The above graph will help us to calculate the vehicle route. In order to calculate the route we need information for the rotation of the vehicle.  For the route calculation we will use the output of the rate gyros. We will calculate the position using the following equation:

INS Route

From the atmospheric pressure we can calculate the altimeter of the vehicle. The output of the pressure sensor increases 45.9mV for each kPa of pressure change. The transfer function of the sensor is:

   (Volt)
Also,           (feet)

The following graph shows the altitude, calculated from the pressure sensor:

Altimeter

Finally, we must mention the temperature changes inside the sensors that affect the offset voltage of the sensors output. In the following graph we can see the changes in the temperature from an embedded temperature sensor inside to the gyroscope. Correction needed in order to reduce the effects of those changes to the INS.

Temperature

Comparing the results from the INS with those from the GPS we can see that the output from the INS is extremely good. Note, that in the calculations we have discarded many parameters that will cause improvement to the INS output (Temperature compensation, better earth gravity correction, better sensor offset calculations and many others). From the first field test we can see that the vehicle can be self guided without GPS information for many seconds (in the last analysis the performance seems absolutely good for the duration of 45sec that examined).