2008:174 CIV

M A S T E R ' S T H E S I S

Defining a Modular, High Speedand Robust Avionic Architecture

for UAV´s

Amin Shahsavar

Luleå University of Technology

MSc Programmes in Engineering Space Engineering

Department of Space Science, Kiruna

2008:174 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--08/174--SE

Defining a Modular, High Speed and Robust

Avionic Architecture for UAV’s

Amin Shahsavar

2008-08-18Ångström Aerospace Corporation | Luleå University of Technology

Abstract

This report covers the works in the NFFP project at Ångström Aerospace Cor-poration (ÅAC) in Uppsala, Sweden. The goals of the project is to, within theproject span of three years, define and design a modular, robust and reliableavionics architecture based in microtechnology for UAV’s (Unmanned AerialVehicles). The project also incorporates a collaboration with Saab Aerosys-tems and their UAV helicopter “Skeldar”, which is thought to carry the finalarchitecture as a test platform. The thesis work of the author began at thestarting phase of the NFFP project and was hence concentrated on the definingand feasibility aspects of the architecture. After doing some research on existingavionic systems and reading papers on new concepts such as Integrated ModularAvionics, design of a particular high speed network was initiated. After trips toUAV companies such as CybAero and Saab, where knowledge and feedback wasobtained, an upgradable and modular architecture began to take shape. Thefinal system, which is proposed in this thesis, was dubbed the “ÅAC ModularArchitecture” (ÅMA). It was presented to ÅAC and Saab and later developedfurther in terms of UAV flight control. An overview of how the modularity ofthe ÅMA could be used in order to integrate changeable flight sensors is alsogiven. The report thus consists of two parts, one dealing with the defining ofthe ÅMA, and the other covering how the ÅMA can sustain controlled flightwith the help of different sensors and Kalman filters.

Contents

I The ÅAC Modular Architecture 9

1 Avionics 111.1 Point-to-point Vs Bus . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Bus protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2.1 ARINC 429 . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.2 CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2.2.1 Higher layer implementations . . . . . . . . . . 131.3 Federated Vs IMA approach . . . . . . . . . . . . . . . . . . . . . 131.4 Point-to-point protocols . . . . . . . . . . . . . . . . . . . . . . . 15

1.4.1 Low speed networks . . . . . . . . . . . . . . . . . . . . . 151.4.1.1 AFDX . . . . . . . . . . . . . . . . . . . . . . . . 151.4.1.2 FlexRay . . . . . . . . . . . . . . . . . . . . . . . 16

1.4.2 High speed networks . . . . . . . . . . . . . . . . . . . . . 161.4.2.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . 171.4.2.2 SpaceWire . . . . . . . . . . . . . . . . . . . . . 181.4.2.3 Comparison between SpaceWire and Ethernet . 19

2 Market analysis 212.1 The UAV avionic market . . . . . . . . . . . . . . . . . . . . . . . 212.2 Systems today: WePilot1000 . . . . . . . . . . . . . . . . . . . . 212.3 Saab Aerosystems collaboration . . . . . . . . . . . . . . . . . . . 23

2.3.1 Saab Skeldar V-150 . . . . . . . . . . . . . . . . . . . . . 232.3.2 Skeldar avionics . . . . . . . . . . . . . . . . . . . . . . . 242.3.3 Presentation at Saab . . . . . . . . . . . . . . . . . . . . . 24

3 A modular architecture 253.1 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Adding the Bus concept . . . . . . . . . . . . . . . . . . . . . . . 273.3 The concept of general modules . . . . . . . . . . . . . . . . . . . 273.4 The concept of modularity . . . . . . . . . . . . . . . . . . . . . . 283.5 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.6 Topological redundancy . . . . . . . . . . . . . . . . . . . . . . . 303.7 Error detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1

4 The ÅAC Modular Architecture (ÅMA) 334.1 The Bridge module . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1 Sub-units . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2 The Error Checking module . . . . . . . . . . . . . . . . . . . . . 354.3 The Computational module . . . . . . . . . . . . . . . . . . . . . 364.4 The Interface module . . . . . . . . . . . . . . . . . . . . . . . . . 374.5 The IMU module . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.6 The TMTC module . . . . . . . . . . . . . . . . . . . . . . . . . 384.7 The Mass Memory module . . . . . . . . . . . . . . . . . . . . . . 38

5 Network issues 405.1 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2 SpaceWire-RT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.1 Time-Slots . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3 Deviating from the standard . . . . . . . . . . . . . . . . . . . . . 425.4 Power handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4.1 Power handling Bridge module . . . . . . . . . . . . . . . 43

6 Final version of the ÅMA 456.1 SpaceWire + CAN . . . . . . . . . . . . . . . . . . . . . . . . . . 456.2 CAN Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.3 CAN power handling . . . . . . . . . . . . . . . . . . . . . . . . . 46

7 Conclusion of Part I 48

II The principles of UAV flight control 49

8 Inertial sensors 518.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.2 Inertial Measurement Unit . . . . . . . . . . . . . . . . . . . . . . 51

8.2.1 The MEMS Gyroscope . . . . . . . . . . . . . . . . . . . . 528.2.1.1 Tuning Fork Gyroscopes . . . . . . . . . . . . . 528.2.1.2 Ring Laser Gyroscopes . . . . . . . . . . . . . . 53

8.2.2 The MEMS Accelerometer . . . . . . . . . . . . . . . . . . 538.3 Inertial Navigation System . . . . . . . . . . . . . . . . . . . . . 54

9 Attitude kinematics 559.1 Euler angles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

9.1.1 Example of kinematic transformation equations . . . . . . 569.2 Quaternion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

9.2.1 Method of use . . . . . . . . . . . . . . . . . . . . . . . . 58

10 Kalman filtering 5910.1 The standard Kalman filter . . . . . . . . . . . . . . . . . . . . . 59

10.1.1 Mathematical derivation . . . . . . . . . . . . . . . . . . . 6010.2 The Extended Kalman Filter (EKF) . . . . . . . . . . . . . . . . 62

2

11 Integration of INS & GPS 6411.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

11.1.1 The benefits of integration . . . . . . . . . . . . . . . . . . 6511.2 Integration configurations . . . . . . . . . . . . . . . . . . . . . . 66

11.2.1 Uncoupled Systems . . . . . . . . . . . . . . . . . . . . . . 6611.2.2 Loosely coupled systems . . . . . . . . . . . . . . . . . . . 6711.2.3 Tightly coupled systems . . . . . . . . . . . . . . . . . . . 6811.2.4 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 70

11.3 Mathematical approach to the loosely coupled configuration . . . 7111.3.1 The Linear error model . . . . . . . . . . . . . . . . . . . 7111.3.2 Determining the filter parameters . . . . . . . . . . . . . . 73

12 UAV flight control on the ÅMA 7412.1 Implementing multiple aiding sensors . . . . . . . . . . . . . . . . 7412.2 Measurement packets on the network . . . . . . . . . . . . . . . . 75

12.2.1 INS option . . . . . . . . . . . . . . . . . . . . . . . . . . 7612.2.2 IMU option . . . . . . . . . . . . . . . . . . . . . . . . . . 7612.2.3 A comparison . . . . . . . . . . . . . . . . . . . . . . . . . 78

12.3 Flight control in the Computational module . . . . . . . . . . . . 78

13 Conclusion of part II 80

3

List of Figures

1.1 Point-to-point. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Bus network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 Federated architecture. . . . . . . . . . . . . . . . . . . . . . . . . 141.4 Integrated Modular Avionics. . . . . . . . . . . . . . . . . . . . . 141.5 The SpaceWire connector. . . . . . . . . . . . . . . . . . . . . . . 19

2.1 The WePilot1000 avionics cube. . . . . . . . . . . . . . . . . . . . 222.2 The architecture of the WePilot1000 system for small UAV heli-

copters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3 The Saab Skeldar V-150. . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Three distinctive topologies. . . . . . . . . . . . . . . . . . . . . . 263.2 A general Star topology and a more redundant one. . . . . . . . 263.3 A redundant but complex Hybrid network. . . . . . . . . . . . . 273.4 The router takes care of forwarding packets between the modules. 283.5 A basic version of the ÅAC Modular Architecture. . . . . . . . . 293.6 The basic version (blue) together with user chosen units (yellow). 293.7 Cold Standby redundancy. . . . . . . . . . . . . . . . . . . . . . . 303.8 A distributed redundant topology with two double redundant

modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.9 Detection scheme for Random faults. . . . . . . . . . . . . . . . . 32

4.1 . The idea of Sub-units inside a host module. . . . . . . . . . . . 354.2 Simple scheme of the Bridge module. . . . . . . . . . . . . . . . . 354.3 Topological redundancy. . . . . . . . . . . . . . . . . . . . . . . . 364.4 Schematic for the computational module. . . . . . . . . . . . . . 37

5.1 The Atmel SpaceWire Router ASIC. . . . . . . . . . . . . . . . . 425.2 The IEEE 1355-like connector suggested for SpaceWire. . . . . . 435.3 The ÅAC Modular Architecture with power handling. . . . . . . 435.4 Schematic of the power providing Bridge module. . . . . . . . . . 44

6.1 The final version of the ÅAC Modular Architecture. . . . . . . . 46

8.1 Resonating mass of a MEMS gyroscope. . . . . . . . . . . . . . . 528.2 The ADXRS chip. . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4

9.1 The Z-X-Z rotations of a rigid body from its inertial to non-inertial reference frame. . . . . . . . . . . . . . . . . . . . . . . . 56

10.1 Flowchart over the Kalman filter. . . . . . . . . . . . . . . . . . . 6010.2 The standard linear Kalman filter presented with its 5 steps of

calculations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6210.3 The non-linear EKF together with its 5 steps. . . . . . . . . . . . 63

11.1 Illustration of how an INS and a GPS can aid each other. . . . . 6511.2 Uncoupled, direct structure. . . . . . . . . . . . . . . . . . . . . . 6711.3 Loosely coupled configuration. . . . . . . . . . . . . . . . . . . . . 6811.4 Tightly coupled configuration. . . . . . . . . . . . . . . . . . . . . 6911.5 How zp & zv are obtained. . . . . . . . . . . . . . . . . . . . . . . 72

12.1 The concept behind integrating an IMU and multiple aiding sen-sors on the ÅMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

12.2 ÅMA process flow in the INS option. . . . . . . . . . . . . . . . . 7712.3 ÅMA process flow in the IMU option. . . . . . . . . . . . . . . . 77

5

List of abbreviations

ACK - Acknowledge packetADN - Aircraft Data NetworksAFDX - Avionics Full-Duplex Switched EthernetAMBA - Advanced Microcontroller Bus ArchitectureAOCS - Attitude and Orbital Control SystemAPEX - APplication EXecutiveARINC - Aeronautical Radio IncorporatedARQ - Automatic Repeat reQuestASIC - Application-Specific Integrated CircuitCAN - Controller Area NetworkCOTS - Commercial Off-The-ShelfCPU - Central Processing UnitCRC - Cyclic Redundancy CheckD-GPS - Differential GPSDIMA - Distributed Integrated Modular AvionicsDITS - Digital Information Transfer SystemDSP - Digital Signal ProcessingECEF - Earth Centered Earth Fixed (coordinates)ECU - Engine Control UnitEKF - Extended Kalman FilterEMI - ElectroMagnetic InterferenceESA - European Space AgencyFCU - Flight Control UnitFDIR - Fault Detection, Isolation and RecoveryFEC - Forward Error CorrectionFIFO - First In, First OutFPGA - Field-Programmable Gate ArrayGNSS - Global Navigation Satellite SystemGPS - Global Positioning SystemI/O - Input/OutputIEEE - Institute of Electrical and Electronics EngineersIMA - Integrated Modular AvionicsIMU - Inertial Measurement UnitINS - Inertial Navigation SystemLAN - Local area network

6

LRM - Line Rack ModulesLRU - Line Rack UnitsLVDS - Low Voltage Differential SignalingMCM - Multichip ModuleMEMS - MicroElectroMechanical SystemsMTTF - Mean Time To FailureNASA - National Aeronautics and Space AdministrationNFFP - Nationella Flygtekniska ForskningsProgrammetNRZ - Non-Return-to-Zero line codeOSI - Open Systems InterconnectionPLC - Power Line CommunicationPoE - Power over EthernetPPS - Precise Positioning ServiceQoS - Quality of ServiceRC - Radio ControlRDC - Remote Data ConcentratorRF - Radio FrequencyRISC - Reduced Instruction Set ComputerRLG - Ring Laser GyroscopeRMAP - Remote Memory Access ProtocolRX - ReceiveSEU - Single Event UpsetSpaceWire-RT - SpaceWire Reliably, TimelySpW - SpaceWireSTP - Shielded Twisted PairTCP - Transmission Control ProtocolTM - Transformation MatrixTMR - Triple Modular RedundancyTMTC - TeleMetry TeleCommandTX - TransmitUAV - Unmanned Aerial VehicleUDP - User Datagram ProtocolUTP - Un-shielded Twisted PairVLSI - Very-Large-Scale IntegrationWYSIWYG - What You See Is What You GetÅAC - Ångström Aerospace CorporationÅMA - ÅAC Modular Architecture

7

Acknowledgments

I would first and foremost like to thank my beloved good mother and father whohave basically been waiting for this M.Sc. thesis since the day I was born. I canjust imagine how proud you are, and I thank you for that. Also, “mille merci”to my supervisor at ÅAC; Dr. Enrique Lamoureux, for keeping me on track andbelieving in my ideas. I also appreciate the help and e-mail conversations fromDr. Peter Mendham at STAR-Dundee Ltd. when it came to SpaceWire issues.Thanks also to the people at Saab Aerosystems and of course all my co-workersat ÅÅC, a cheerful young group who knows when to work and when to party.Thank you all.

Two roads diverged in a wood, and I–I took the one less traveled by,And that has made all the difference.

Robert Frost (1874 - 1963)

8

Part I

The ÅAC ModularArchitecture

9

Introduction to Part I

The constant advancements in Unmanned Aerial Vehicle (UAV) avionics de-mands new approaches for dealing with issues such as autonomous flight reli-ability and low upgrading costs. This thesis work and report follows the workwithin the NFFP project (Nationella Flygtekniska ForskningsProgrammet) åtÅngström Aerospace Corporation (ÅAC) in Uppsala, in the search for a solu-tion to these demands by using new concepts and utilizing modern technology.The aim of the thesis work was to come in at the starting phase of the NFFPproject and help ÅAC take the first steps in defining a high speed, robust andmodular avionic architecture. At first, a review of the advantages with olderapproaches is dealt with. Later on, different protocols, networks and topologiesare discussed and reviewed so that, conclusively, a modular solution, named theÅAC Modular Architecture (ÅMA), is presented.

10

Chapter 1

Avionics

1.1 Point-to-point Vs Bus

Point-to-point telecommunications generally refers to a connection restrictedto two endpoints, usually host computers. In avionics, a traditional point-to-point data link is a communications medium with exactly two endpoints andno data or packet formatting. The host computers at either end have to takefull responsibility for formatting the data transmitted between them. The greatbenefit with a Point-to-point communication is the dedicated bandwidth; all sentand received data is guaranteed to come through, especially if it is operatedunder full duplex. The disadvantage on the other hand, is the complicatedwiring procedure that can be seen in figure 1.1. Furthermore, if one would like

Figure 1.1: Point-to-point.

to change or add some node in the system, a great deal of rewiring must bedone. Another, more commonly used approach, is the so called Bus networkshown in figure 1.2. Here, while one loses the protocol simplicity and dedicatedbandwidth of Point-to-point, one gains the possibility of easily modifying thenetwork. The major disadvantage with most Bus networks is the slow bit rate(up to 1 Mbit/s). Thus, what is wanted is a combination of the two differentmethods. Sections 1.2 and 1.4 will discuss different Bus and Point-to-pointprotocols.

11

Figure 1.2: Bus network.

1.2 Bus protocols

1.2.1 ARINC 429

ARINC 429 is a data format for aircraft avionics. It provides the basic descrip-tion of the functions and the supporting physical and electrical interfaces for thedigital information system on an airplane. Two communication standards, AR-INC 429 and MIL-STD 1553B, have long dominated commercial and militaryaviation. ARINC 429 connects units aboard the Boeing 737 and other civilianaircraft using distributed avionics architectures. The MIL-STD 1553B is usedin most military aircraft for flight-critical control and control of various missionsystems. Both are half-duplex communication standards. [3]

The physical layer of ARINC 429 consists of a twisted pair. ARINC 429utilizes a unidirectional bus with a single transmitter and up to 20 receivers.Words are 32 bits in length and most messages consist of a single data word.The unidirectional data bus standard (TX and RX are on separate ports) isknown as the Mark 33 Digital Information Transfer System (DITS). There aretwo speeds of transmission; high speed at 100 kbit/s and low speed at 12.5kbit/s.

1.2.2 CAN

Controller Area Network (CAN) is a bus standard designed to allow devicesto communicate with each other without a host computer. It was designedprimarily for the automotive industry but is now also used widely in otherareas.

Each node is able to send and receive messages, but not simultaneously. Amessage is transmitted serially onto the bus, one bit after another. This signal-pattern codes the message (in NRZ line code) and is sensed by all nodes. Bitrates up to 1 Mbit/s are possible at network lengths below 40 m. Decreasingthe bit rate allows longer network distances (e.g. 125 kbit/s at 500 m).

The strength of the CAN-bus is the fact that it is one of the most acceptedstandards in network communication. It is simple to use, requires only two wiresas its physical layer and can withstand harsh environments. These featuresmakes the CAN-bus an ideal candidate for low speed avionic buses.

12

1.2.2.1 Higher layer implementations

As the CAN standard does not include tasks of application layer protocols, suchas flow control, device addressing, and transportation of data blocks larger thanone message, many implementations of higher layer protocols have been created.Among these is the CANaerospace open standard. CANaerospace is specificallydeveloped for the aerospace community and is an extremely lightweight proto-col/data format definition which was designed for highly reliable communicationof microcomputer-based systems in airborne applications via CAN. [16]

Commercial air transport aircraft have already incorporated CAN as an an-cillary subsystem network to Integrated Modular Avionic (IMA) architectures.This has prompted an ARINC technical working group to develop a ARINC 825standard which has special requirements for the aviation industry. In order toensure interoperability between CAN subsystems, the new standard has beendeveloped by the Network Infrastructure and Security Committee of ARINC.The ARINC 825 standard (General Standardization of CAN Bus Protocol forAirborne Use) was driven by Airbus and Boeing and defines a communicationstandard for airborne systems using CAN, which has been identified by bothcompanies as an important baseline network for their future transport aircraft.In fact, ARINC 825 will be the CAN standard for all future Airbus and Boe-ing aircraft. Offering a high degree of compatibility with the widely acceptedCANaerospace standard, ARINC 825 is applicable to General Aviation aircraftas well. If the CAN protocol is to be used in the proposed architecture, thenperhaps these newer versions of CAN can be of interest instead of the primarystandard. [17]

1.3 Federated Vs IMA approach

When it comes to data handling and avionics, the traditional solution has alwaysbeen the federated architecture. Illustrated in figure 1.3, it is based on the ideathat every sensor, actuator or interface has their own devoted I/O modules,their own data handling units and a dedicated network interface. While thisbeing a simple and easy to implement model, it does require a lot of mass andcabling. On modern aircraft, the avionics takes up a great deal of space andweight, plus the need of upgradeability is becoming more and more important.These matters are not resolved with a federated architecture that becomes moreand more complex with further advanced aircraft.

With avionics taking on a larger part of the total aircraft development timeand financial budget, the need for a simpler general architecture has been ad-dressed since more than a decade back. A more modular, upgradeable andweight effective approach has been sought. Up until recently, the technologicalpossibilities have not been advanced enough for providing such an architecture,being reliable for a UAV as well. This new kind of architecture is called Inte-grated Modular Avionics (IMA) and has been crystallizing during the last coupleof years. Airbus, for instance, uses it on some non-critical systems on their new

13

Figure 1.3: Federated architecture.

A380. IMA is essentially a real-time computer network for airborne systems.The network consists of different modules capable of supporting numerous ap-plications. Figure 1.4 shows a general IMA architecture interconnected on anetwork. If compared to the federated approach in figure 1.3, one can see thatthe number of CPU’s and physical communication channels have decreased re-markably. [11]

Figure 1.4: Integrated Modular Avionics.

Federated avionics architectures make use of distributed avionics functionsthat are packaged as self-contained units (Line Rack Units, LRU / Line RackModules, LRM). IMA architectures employ a high-integrity, partitioned environ-ment that hosts multiple avionics functions of different criticalities on a sharedcomputing platform. This provides for weight and power savings since comput-ing resources can be used more efficiently due to space and time partitioning.Given that IMA makes use of shared computing resources, the circuitry thatonce was contained within each federated LRU/LRM is now contained withina common IMA platform. Computing processors that were duplicated in eachfederated LRU/LRM are replaced by a common set of IMA processors (so theassociated infrastructure such as power, cooling, and redundancy mechanismsis no longer needed). [2]

14

The above improvements are the key issues when wanting to implementIMA. Furthermore, IMA offers the possibility to easily upgrade or change thesystem, it also presents better redundancy solutions. Applications, for example,can be reconfigured on spare modules if the module that supports them is de-tected faulty during operations, increasing the overall reliability of the avionicsfunctions.

Ergo, the goal of standard, reusable and interchangeable modules is centralto the concept of IMA. By rigorous definition and control of each module, bothhardware and software, and of its interfaces, the aim is to permit a minimumnumber of different module types to support the broad range of current andfuture avionics system functions. [1]

1.4 Point-to-point protocols

This section covers the the most common IMA compliant Point-to-point proto-cols available today. Comparisons are given as well as a decision on which onethat suits the NFFP project the best. Since network speed is a relative termit should be settled that in this report ”low speeds” are considered to be 100Mbit/s or less and ”high speeds” 100 Mbit/s or more.

1.4.1 Low speed networks

1.4.1.1 AFDX

The most reliable IMA communication protocol today is considered to be theAvionics Full-Duplex Switched Ethernet (AFDX). It is a network and not a bus,it is based on the IEEE 802.3 Ethernet technology. It utilizes Commercial Off-The-Shelf (COTS) components and is a deterministic data network for safetycritical applications that utilizes dedicated bandwidth while providing Qualityof Service (QoS). AFDX is Part 7 of the ARINC 664 Specification which defineshow COTS networking components will be used for future generation AircraftData Networks (ADN). The six primary aspects of AFDX include full duplex,redundancy, deterministic properties, high speed performance, switched andprofiled network. AFDX adopted concepts from the telecom standard: Asyn-chronous Transfer Mode to fix the shortcomings of IEEE 802.3 Ethernet. Byadding key elements from Asynchronous Transfer Mode to those already foundin Ethernet, a highly reliable Full-Duplex deterministic network is created pro-viding guaranteed bandwidth and QoS. The AFDX standard includes the UserDatagram Protocol (UDP) which is one of the core protocols of the InternetProtocol Suite. UDP has lower overhead and is thus faster than the Transmis-sion Control Protocol (TCP), but it provides less reliability than TCP. Yet, itis favored by time-sensitive applications because dropped packets are preferableto delayed packets.

IMA, as described in ARINC 653 (which defines an APplication EXecutive,APEX, for space and time partitioning), distributes functional modules into a

15

robust configuration interconnected with a “virtual back-plane” data communi-cations network. Each avionic module’s function is defined in software compliantwith the APEX Application Program Interface. The AFDX network replacesthe point-to-point connections used in previous distributed systems with “vir-tual links”. [3]

The great benefit with AFDX is that it is already proven and used in IMAarchitectures (together with ARINC 653 in Airbus A380).

1.4.1.2 FlexRay

FlexRay is a communication system that will support the needs of future in-car control applications. At the core of the FlexRay system is the FlexRaycommunications protocol. The protocol provides flexibility and determinismby combining a scalable static and dynamic message transmission, incorporat-ing the advantages of familiar synchronous and asynchronous protocols. Theprotocol also supports:

• Fault-tolerant clock synchronization via a global time base

• Collision-free bus access

• Guaranteed message latency

• Message oriented addressing via identifiers

• Scalable system fault-tolerance via the support of either single or dualchannels

A physical layer incorporating an independent Bus Guardian provides furthersupport for error containment. The FlexRay system is targeted to support adata rate of 10 Mbit/s with increased flexibility for easy system extension andthe dynamic use of bandwidth. The 10 Mbit/s data rate is available on twochannels, giving a gross data rate of up to 20 Mbit/s. The system consists of abus and processors (Electronic Control Units, or ECU’s).

This high-speed serial (Synchronous and Asynchronous) communication sys-tem can either use a Star topology, a Bus structure or even a combination ofthe two. The 10 Mbit/s link is fault-tolerant over an Un-shielded Twisted Pair(UTP) or Shielded Twisted Pair (STP) cable. The FlexRay bus defines thephysical layer (electrical and optical) and protocol.

While FlexRay does offer interesting properties, it is determined that thisprotocol is not suited for a future IMA-like architecture. This choice is basedmainly upon Flexray’s low speed communications and the fact that it is princi-pally unused in the flight and space business.

1.4.2 High speed networks

If an IMA architecture should be used, a high speed communications network isrequired. The network must not only provide enough bandwidth to cope with

16

all the communicating nodes of the architecture, but must also have a greaterbuffer for possible future upgrades. There will be a lot of packets transmittedover the network, not only the information packets sent from one node to an-other, but also acknowledgments, duplicates, error checking information, house-keeping, telecommands and more. In addition to this, payloads, such as camerasoperating under high data rates, might also be connected to the network. Allthis will have to be forwarded through a central router and it is imperative thatno hick ups occur just because the network has insufficient bandwidth.

A minimum data rate of 100 Mbit/s is sought for. To this date, there arebasically two competing high speed communication networks that are used onaircraft and spacecraft. These are the Ethernet standard and the SpaceWirestandard.

1.4.2.1 Ethernet

Ethernet is a family of frame-based computer networking technologies for LocalArea Networks (LAN’s). It is standardized as IEEE 802.3 and is the mostwidespread wired LAN technology. It has been in use from around 1980 tothe present, largely replacing competing LAN standards, making it commonlyavailable and hence providing COTS technology. Ethernet has many varietiesthat diverge both in speed and physical layer. The most common forms used are10BASE-T, 100BASE-TX and 1000BASE-T. All three utilize twisted pair cablesand 8P8C modular connectors (often called RJ45). They run at 10 Mbit/s, 100Mbit/s and 1 Gbit/s, respectively. [4]

The Ethernet physical layer evolved over a considerable time span and en-compasses quite a few physical interfaces. The physical medium can range frombulky coaxial cable to twisted pair to optical fiber. In general, network protocolstack software will work identically on most of the types.

If Ethernet would to be used in the proposed avionic architecture, then itwould most probably have the AFDX protocol tunneled over it. AFDX, asdescribed earlier, offers many great features such as QoS to Ethernet. A heavyreason for choosing Ethernet and AFDX is the fact that it is accepted within theaviation industry as reliable as well as having many certified flight hours. Thisfactor should not be forgotten when designing avionics, seeing as many timeseven though a certain solution may be better than another more commonly usedone, the more established one will be preferred by the industry.

Another great feature of Ethernet is the Power over Ethernet (PoE) option.The ability to provide power over the same cables that transmits data willconsiderably help the integration process of an entire avionic architecture. Thisoption will be discussed further on.

When it comes to tunneling AFDX over Ethernet, part 7 of ARINC 664allows for the mapping of other bus standards (e.g., ARINC 429 or MIL-STD-1553) onto the network and allows for communication with other ARINC-664-compliant but non-deterministic networks through gateways and routers. ThePhysical layer of AFDX is not defined as part of ARINC 664 - Part 7, but canbe any of the solutions defined in ARINC 664 - Part 2, including previously

17

mentioned 10BASE-T, 100BASE-TX, and 1000BASE-T.

1.4.2.2 SpaceWire

SpaceWire is a communications network for use on board spacecraft. It isdesigned to connect high data-rate sensors/payloads, large mass memories, pro-cessing units and downlink telemetry, providing an integrated on-board data-handling network. SpaceWire is based on the IEEE 1355 standard of commu-nications and coordinated by the European Space Agency (ESA). It has serial,high-speed (2 Mbit/s to 200 Mbit/s), bi-directional, full duplex, point-to-pointdata links which connect together SpaceWire equipment in a network. Withinsuch a network, the nodes are connected through low-cost, low-latency linksconnected to packet switching wormhole routing routers. While wormhole rout-ing is notorious for causing blocking, it has two major advantages over thealternatives (the major one being store-and-forward):

1. Simple hardware and low memory requirements in routers. This makesrouters smaller, simpler, cheaper, lower power consuming and easier toqualify for space.

2. Very low latency. The routing latency (port-to-port) in the SpW-10Xrouter chip (mentioned in section 5.3) is in the order of 500 ns. Theseadvantages outweigh the disadvantages which can be mitigated with goodnetwork design.

Application information is sent along a SpaceWire link in discrete packets. Con-trol and time information can also be sent along the links. SpaceWire is based onthe “DS-DE” part of the IEEE-1355 standard [8] combined with the TIA/EIA-644 Low Voltage Differential Signaling (LVDS) standard [9]. Several problemswith IEEE-1355 have been solved in SpaceWire and connectors and cables suit-able for space applications are defined. SpaceWire covers two of the seven layers(physical and data-link) of the OSI model for communications. [5, 7]

In addition, SpaceWire has extremely low error rates, deterministic systembehavior, and relatively simple digital electronics. Also, since SpaceWire em-ploys LVDS, it is easy to implement the protocol directly on FPGA’s using onlya few gates. Figure 1.5 shows the Pin-out of the standardized SpaceWire con-nector. Notice that the cable does not contain a ground connection betweenthe nodes. This may induce issues in case of floating since there is no commonground. Another, not so critical, disadvantage is the maximum cable length of10 meters. Normally this is not a problem since most satellites and UAV’s haveless length than 10 meters, but it is still drawback of freedom. Nonetheless, asolution exists where one could add repeaters.

18

Figure 1.5: The SpaceWire connector.

RMAP The first protocol that has been defined for SpaceWire is a relativelylow-level service called the Remote Memory Access Protocol (RMAP). RMAPis used to write to and read from memory or registers in a destination node on aSpaceWire network. While being quite simple, the aim of the RMAP protocol isto standardize the way in which SpaceWire units are configured and to provide alow-level mechanism for the transfer of data between two SpaceWire nodes. Forexample, RMAP may be used to configure a camera or a mass memory device.The camera device may then write image data to allocated storage areas in themass memory, or the mass memory may read image data from the camera. [7]

1.4.2.3 Comparison between SpaceWire and Ethernet

The choice between SpaceWire and Ethernet is not an easy one. The goal isto design a modular high speed architecture, and this can be achieved withboth networks. The main benefit of Ethernet is the relatively cheap alreadymanufactured COTS networking equipment that is easy to find. Furthermore,the already developed and tested AFDX protocol on Ethernet is another strongreason for choosing it. On the other hand, the AFDX protocol can, in the-ory, be tunneled over SpaceWire as well. In addition to this, a new, moreadvanced protocol for SpaceWire is being developed as we speak. This proto-col, called SpaceWire-RT, will provide many of the AFDX-features such as QoSto SpaceWire. SpaceWire-RT will be described in chapter 5.2.

The goal for this project is to develop an architecture that could work on anytype of unmanned vehicle, such as an aircraft, a helicopter or even a satellite.A satellite can in many ways be regarded as a UAV. However, since the spaceindustry has much higher standards to live up to, one must take these extraregulations and limits in consideration when designing such an overall architec-ture. In this manner, SpaceWire is clearly preferred since it is already certified

19

for space use. In addition to the above, according to the SpaceWire communityitself, SpaceWire offers many benefits over Ethernet [10]:

• SpaceWire is more fault-tolerant than Ethernet

• SpaceWire is more deterministic than Ethernet

• SpaceWire is more responsive than Ethernet

• SpaceWire has lower protocol overhead than Ethernet

• SpaceWire does not use analogue circuits nor DSP

• Airbus using “Ethernet” but not standard Ethernet (AFDX)

• NASA using SpaceWire in preference to Ethernet

Benefits of SpaceWire:

• Satisfies more requirements than any other standard

• Is best basis for modularity and re-use

• So is best basis for COTS subsystems, reduced cost

• Rad-Hard System Design with COTS components

• Excellent Failure Detection, Isolation and Recovery (FDIR)

On the downside, when compared to other standards, SpaceWire does not have ahuge common mode voltage tolerance. It has a maximum common mode voltageof +/- 1V which is not so much compared to Ethernet, CAN or MLT-STD-1553.

At a physical point of view, SpaceWire does not require any coil or trans-former in the connection like Ethernet does. This makes SpaceWire easier tointegrate in micro modules.

Taking all this into account, SpaceWire seems to be the better choice. Still,the easy access to Ethernet products weighs in as a heavy argument. Yet, forconsistency in the report, the architecture will be assumed to run on SpaceWirefrom now.

20

Chapter 2

Market analysis

2.1 The UAV avionic market

The ambition is to create a liberal, easy to use architecture. This requires mucheffort but is worth it if one examines how the UAV market for small to mediumsized companies looks today. As a matter of fact, many companies prefer toput their resources on other matters than the general control and avionics oftheir UAV helicopters. Of course, these companies want to manufacture thebest possible helicopter on the market, but they rather improve their UAV’sthrough other features than stable flight, since this is something offered byevery UAV. Thus many companies buy an already designed and constructedavionic system with a built in Inertial Navigation System (INS) and FlightControl Unit (FCU). These assumptions are partly based on the success of the“WePilot1000”-system. This solution, sold by the Swiss company WeControl,can be found in many UAV helicopters around the world. The reason for this,as we shall see, is the simplicity this system offers to the end user. This is whythe soon to be proposed architecture; the ÅAC Modular Architecture (ÅMA),puts a lot of effort in providing the same avionics freedom.

2.2 Systems today: WePilot1000

This is a short study on the WePilot1000 by WeControl, pictured in figure 2.1.This system is quite commonly used in UAV helicopters. The unit itself is acube containing most attitude sensing equipment that is needed. It includes aGPS, an Inertial Measuring Unit (IMU), a barometer and an external magne-tometer. It also contains a FCU with a built in Kalman filter. Further on, ithas a general I/O interface were the user can connect their own sensors andpayloads. The WePilot1000 acts as the heart of the autonomous helicopterand it is to here all actuators are connected and controlled from, based on itscalculations and measurements. One can also connect a direct Radio Control(RC) channel to it for manned control of the helicopter. The architecture of

21

Figure 2.1: The WePilot1000 avionics cube.

the WePilot1000 is illustrated in figure 2.2. The central role of the WePilot1000can clearly be distinguished here, acting as a “Black box”. If one wishes to addsensors or actuators using different protocols than what is provided in the I/Ointerface, one will have a problem. The WePilot1000 does not normally supportall the different protocols found in the aviation industry. On the contrary, thisis something that will not be necessary to worry about in the soon proposedÅMA. Its “Bridge module” should take care of the protocol translation fromany protocol to SpaceWire. It is believed that simplicities like these are highlyappreciated by companies in the UAV business. When constructed, they will beable purchase a complete system which they can modify as they wish. The ÅMAwill provide the same straightforwardness of WePilot1000, but also adds manyother functions such as modularity, redundancy and upgradeability. Another

Figure 2.2: The architecture of the WePilot1000 system for small UAV heli-copters.

22

advantage of the ÅAC system that has not yet been addressed is its extrememiniaturization due to thin film MCM 3D stacking technology. This way ofmanufacturing the electronics makes the complete system small and lightweightcompared to everything else on the market.

2.3 Saab Aerosystems collaboration

Within the NFFP project, a partner and key contributor of UAV informationis Saab Aerosystems. The proposed architecture can possibly be integrated ina future version of their unmanned helicopter Skeldar, pictured in figure 2.3.

Figure 2.3: The Saab Skeldar V-150.

2.3.1 Saab Skeldar V-150

Skeldar is a fully autonomous mobile system, it can perform take-offs and land-ings without any field preparations or additional equipment. Moreover, itsmodular design makes it possible to choose between different payloads. Thestructural material for the fuselage is carbon fiber, titanium and aluminumcomposite. The engine, that can be customized, runs on petrol or heavy fuel.The power train consists of a robust drive shaft with a centrifugal clutch thatrelays the power to the rotor system via a drive belt and a main gearbox. Themain rotor uses a well-proven Bell-Hiller configuration system, comprising astabilizer bar and paddles. Avionics include redundant computers, GPS re-ceivers, IMU’s, air-data system and magnetic heading indicator, allowing fullyautonomous operation while maintaining total radio silence.

Skeldar is primarily designed for observation and aid in civilian accident andnatural catastrophe situations. But also for the pursuit of criminality, terrorismand other military operations. The helicopter has a length of 4.1 m , a height of1.3 m and a maximum take of weight of 200 kg, where around 30 kg is dedicatedfor payloads. It can reach speeds up to 130 km/h and has an endurance of upto 5 hours. [6]

23

2.3.2 Skeldar avionics

Today, the Skeldar avionic architecture has a classical Federated approach. Oneof the main goals of the NFFP project is that ÅAC and Saab Aerosystemstogether develop a new IMA based architecture that can replace the currentfederated one.

Due to NDA issues, the avionics of the Skeldar cannot be discussed furtherin this report. It should be noted though, that during the work of this thesis, thehelicopter and its avionic architecture have been carefully examined in order tounderstand standalone systems on today’s market. The same has also been donewith UAV manufacturer CybAero, thus not much about its detailed avionics canbe mentioned here. During the discussions with Saab Aerosystems, it becameclear that the main interest of Saab, within the scope of the NFFP project, isto miniaturize their avionics and minimize weight. ÅAC’s small size electronicstogether with the soon to be proposed ÅMA will provide a completely enhanced,considerably less weighing and miniaturized platform for the Skeldar avionics.

2.3.3 Presentation at Saab

During the visit to Saab Aerosystems’ Skeldar team in Linköping, a 45 minutepresentation was held by the author. The aim of the presentations was to,from ÅAC’s side, present the first draft of the ÅMA to the approximately 8Saab engineers involved in Skeldar. Valuable feedback was obtained from thispresentation since ÅAC by doing this understood Saab’s key issues in the NFFPproject. Their main interest was to simply minimize their avionics in both sizeand weight. Since SpaceWire is a relatively new protocol on the market, theSaab engineers were interested to know how we wanted to implement it. Theywere on the other hand sceptical to the 8 wire cabling of SpaceWire which theysaw as too bulky in comparison with the CAN standard for example. After thepresentation, discussions were held and a new type of architecture was conceived;a SpaceWire + CAN integrated model. This version of the ÅMA covered inchapter 6.

24

Chapter 3

A modular architecture

This chapter follows the work in defining a modular architecture for the SkeldarV-150, or any other UAV based system that will benefit from the advantagessuch an architecture can render. The work flow is well represented through thesubsequent sections of the chapter, starting with finding a suitable topology andending with classifying how to detect possible faults.

3.1 Topology

There are several ways of constructing an architecture through its topology.Network topology is the study of the arrangement of the elements (links, nodes,etc.) of a network. As discussed under section 1.1, a combination of Point-to-point and Bus structures would be preferred. But at the same time, a modularapproach is sought after, as described in section 1.3. Taking all these matters inconsideration, there are numerous alternative topologies to choose from. Theyall provide the distinguished features of a combined Bus and Point-to-point net-work. The simplest solution is a ring network where all nodes are connected ina circle. Data can be transferred both clockwise and counterclockwise at thesame time, but other than that, the network is quite limited. Introducing mul-tidimensional arrangements gives more freedom in transferring critical packetsat the same time. The multidimensional Chain and Ring topologies in figure 3.1illustrate the idea. By adding a “Ring-feature” to the multidimensional Chaintopology, one obtains a better connected arrangement while adding cable har-ness mass and complexity. It must be stressed that simplicity has always beena key issue when it comes to the design of the modular architecture. Hence,these solutions, containing a great deal of cabling and at the end not so differentfrom traditional Point-to-point networks (similar to the one in figure 1.1), willnot do. Another drawback is the fact that each node has to contain routingcapabilities, making the nodes more complex.

25

Figure 3.1: Three distinctive topologies.

Rather than an interconnected network, a centralized switched network willprovide a good solution. A general star shaped network is illustrated in figure3.2. Here, all nodes are connected together through a central switch or router,and with much less cabling. The main disadvantage in this topology is of coursethe single point of failure in the switch. But this weakness can be removedby introducing another switch for redundancy. This type of topology will bethe one chosen for the architecture, due to its simplicity but at the same timeadmittance of Point-to-Point and easy upgradeability. If the end user wishesto add or remove a node, it would be a simple procedure, something that is ofgreat value to the customer. The two routers can also be connected together,as will be proposed later on.

Figure 3.2: A general Star topology and a more redundant one.

There are however more advanced networks that extend even further in re-dundancy and dedicated bandwidth. These so called Hybrid networks can inprinciple be made as complex as the designer wishes. While it is consideredthat this type of network, shown in figure 3.3, may be useful if wanting to con-nect especially important nodes to another (in addition to through the centralswitch), the basic star topology is still regarded as a better overall solution. Thearchitecture is to be kept simple and elegant.

26

Figure 3.3: A redundant but complex Hybrid network.

3.2 Adding the Bus concept

While a star topology provides a good core concept, one must still deal with thedemands of real life. Most UAV architectures includes a great deal of nodes andI/O’s. Using only a star topology, this would mean a too huge amount of cablesto become realistically plausible. A solution to this is to use a combination of astar and bus topology. The star topology can be utilized for high speed, criticaland redundant modules while the Bus part can connect all the low speed lessimportant I/O’s. This is a clever way of diminishing cabling, especially on asmall helicopter where most nodes are placed close to each other and can benefitfrom bus structures. The bus part can then be connected to the star shapednetwork through the router. The ÅMA is proposed to contain a combinationof a star and a bus topologies, but for now this report will, for the sake ofsimplicity, only consider the main star topology. The bus part will be addedand explained in chapter 6.

3.3 The concept of general modules

Now that the overall topology is determined, the network nodes themselveshave to be resulted. The proposal is to use general modules who’s work is notdefined in detail, but rather conceived to take care of a certain type of task. Theproposed modules will be described further on, but for now the communicationsbetween them and the network connecting them will be clarified. The ÅMA isbased on a star shaped computer network with a router in the middle havingdifferent modules connected to it, as illustrated in figure 3.4. The router isthe heart of the system, dealing with packet forwarding between those modulesthat need to communicate with each other. So far, no real innovation hasbeen made. The improvement with this architecture is shown with ModuleC in figure 3.4. The core idea is that any type of module, using any typeof communication protocol, can be connected to the network. The networkitself will run on SpaceWire, but the nodes can use any of the more commonprotocols and interfaces. This is where a so called Bridge module becomesnecessary. It is a general module built to convert any protocol to the SpaceWirestandard and send information over the network. Like this, we can connect

27

Figure 3.4: The router takes care of forwarding packets between the modules.

countless different modules to the router and yet the high speed SpaceWirenetwork can deal with it due to the immense bandwidth (remember most avionicarchitectures today use about 1 Mbit/s, SpaceWire offers 200 Mbit/s). TheBridge module allows the end user to choose whatever component he or shewishes and connect it to the avionics so it can communicate to any other modulethrough the SpaceWire Router. Thus, taking the above into account, we have amodular avionic architecture. The Bridge module’s two main tasks are to takecare of protocol translation and networking issues. It will be thoroughly definedin section 4.1.

3.4 The concept of modularity

Introducing the ÅAC solution, a SpaceWire network with six predefined generalmodules that can be reprogrammed to perform any task within their specialty.Every one of these modules fully uses the provided high speed data handling ofSpaceWire. Together they take care of all the basic functions of a UAV avionicarchitecture. Each module can easily be replaced, duplicated or made redundantby adding or removing similar modules. The architecture provides full flexibilityand is fully programmable to operate according to user requirements. A simpleversion of the ÅMA is shown in figure 3.5. Of course, the above architecture isnot entirely enough to completely control a UAV. Many other modules, subsys-tems and units must be connected to it in order for a UAV to orient and manageitself autonomously. The ÅMA is designed in such a manner that the user canadd any sensor, actuator, payload or other necessary device to it. As long as theBridge module is connected in between each added device and the SpaceWirenetwork, the user is free to choose from whatever unit he or she wishes. Thisproperty is illustrated in figure 3.6 by the three new yellow units that are addedto build up the modified architecture that each user wishes to have. The reasonwhy the blue devices’ Bridge modules are drawn inside the boxes is that theBridge part is integrated in those modules as a layer. But when it comes tothe yellow units, chosen by the customer, the Bridge module will actually be aphysical device with connectors on both sides. The described flexibility give theuser the opportunity to, say, replace an out of date sensor with a more modern

28

Figure 3.5: A basic version of the ÅAC Modular Architecture.

type without any hassle, all that has to be done is to connect it to a Bridgemodule. The blue modules, provided by ÅAC, can also be changed and thusupgraded easily.

Figure 3.6: The basic version (blue) together with user chosen units (yellow).

3.5 Redundancy

The overall redundancy is something that has been considered carefully in thearchitecture. There are different types of redundancies and two of them will beused in the ÅMA. They are Standby redundancy and Masking redundancy. Thelatter will be discussed shortly. Standby redundancy is a form of redundancywhen one has two or more units that can do the same procedure, often theyare exactly the same piece of hardware. There are different types of Standbyredundancies; “Hot”, “Warm” and “Cold”. With Hot Standby redundancy it is

29

meant that, say, 2 modules operate fully together and then a switch chooseswhich one to use. Warm Standby implies that the second unit is on but onlyuses a small amount of its resources, e.g. running housekeeping data, so thatits lifetime will be held longer than if it would work at full capacity like in the“Hot” case. In the Cold Standby redundancy case, illustrated in figure 3.7, onemodule (in this case a CPU) is working at full capacity while the other oneis almost completely turned off (only listening to boot up signals). The Error

Figure 3.7: Cold Standby redundancy.

detecting part constantly checks the out data of the CPU and in case it findsfaulty values it will suspect that the CPU is damaged. It will then tell theswitch to choose the other CPU’s outgoing data. Of course, there is a startup time for the turned off “cold” CPU and this is seen as a drawback, but theadvantages are a Mean Time To Failure (MTTF) quota of up to 2. This is thehighest MTTF quota of all possible redundancies. Cold Standby redundancy isalso considered to be the best option for modular architectures and will thus bechosen for our system. [12]

3.6 Topological redundancy

Furthermore, even if a star shaped topology is chosen, it does not necessarilyhave to look like the one shown in figure 3.6. One possible and probably saferway of connecting the modules is shown in figure 3.8. Here the flight controlmodules are separated from less flight critical modules in order to amplify pre-cautions. Extra vital modules, like the Computational one, will be connectedto both Routers so that the most critical functions can be performed even if asignificant failure occurs.

30

Figure 3.8: A distributed redundant topology with two double redundant mod-ules.

3.7 Error detection

When it comes to reliability in avionics, detection of possible errors is as im-portant as preventing them with redundancy measures. Using the terminologyof dependable and secure computing, one usually refers to “failures” which aredue to “errors” which in term are caused by “faults”. There are mainly twocategories of errors; Random faults and Systematic faults. Random faults arehardware related physical faults; they are triggered by phenomena such as Elec-troMagnetic Interference (EMI) or particle radiation, giving rise to Single EventUpsets (SEU). An SEU occurs when a distinct part of data or code is alteredfrom its original state, creating an error that could spread when computed orsuch. [12]

Systematic faults are however not due to external matters, they are causedby flaws in system development. Systematic faults are commonly known as“bugs” and the best way to prevent them is to implement design diversity.Design diversity implies that the redundant units must have dissimilar designs.This process is often complicated and resource demanding since several differentengineering teams are needed. They are to work separately on solving the sameproblem in order for them not to make the same mistakes. Full Systematicfault measures are not considered to be an option when considering ÅAC’scapabilities. Instead, effort will be put on handling Random faults.

Figure 3.9 shows the planned scheme for detecting Random faults. Everypart of the architecture is a possible candidate for faults and thus each partmust have capabilities of coping with it. The text at the bottom of each arrowin figure 3.9 tells of what Random fault is most plausible in that specific locationand the solution for detecting it.

31

Figure 3.9: Detection scheme for Random faults.

32

Chapter 4

The ÅAC ModularArchitecture (ÅMA)

Now that the general design of the ÅMA is established, this chapter will discussthe six different modules included in it. But first, the much important Bridgemodule is explained in detail.

4.1 The Bridge module

The Bridge modules are the base of the system, while the router is the core.Together they make up the backbone of the avionics network.

The Bridge module is proposed to be designed as a small, lightweight and rel-atively cheap unit. Yet, it is supposed to perform numerous important tasks, thetwo most significant ones being translation and networking. It can be attachedto a module which will become its Host. The main idea is that any type of Hostdevice can be connected to it, even though the Host does not have networkingproperties, i.e. if the Host is constructed for a direct Point-to-Point link. TheBridge module listens to its Host, samples its output to a packet, translates itto SpaceWire, adds network information and sends it to the Router where itis forwarded to another Bridge module. This module now reads the incomingpacket, removes the unnecessary network data, re-translates it to the Host pro-tocol and delivers it to its corresponding Host. It can also send Acknowledge(ACK) packets to the transmitting Bridge module so the transfer of data canbe confirmed. In this manner, we have simulated a Point-to-point link over anetwork. The Hosts never even “know” they are connected together in anotherfashion than they were constructed to operate. This is where the flexibility ofthe architecture shows itself; the user can add any type of Host he or she wishesin order to customize the UAV according to his or her requirements.

33

The Bridge module functions are:

From Host to Network

• Takes complete care of the protocol

• Assigns service classes

• Adds To, From, CRC and Sequence Number

• Reads incoming data and samples to a packet

• If Sub-Unit: Read outgoing packet and determine where to forward it

From Network to Host

• CRC Check

• Automatic Repeat reQuest (ARQ)

- Check Sequence Number- Send ACK + Sequence Number

• Forward Error Correction (FEC) – Includes error correcting code so thatthe receiving node can repair damaged packets by itself.

• Smart functions such as discard old packets

• If Sub-Unit: Read incoming packet and determine where to forward it

4.1.1 Sub-units

With Sub-units it is meant more complex Hosts who send data to more thanone receiver. The concept of Sub-units must be dealt with in order to preparethe system for any possible case of Hosts that might be connected to the Bridgemodule. Hosts or modules that need to send and receive data to/from multipleunits are referred to as Advanced Hosts. One Advanced Host is the Compu-tational module that receives, computes and then sends commands to severaldifferent nodes. The concept is illustrated in figure 4.1 where module A has aSub-unit part (green) that might want to communicate with a Sub-unit on Mod-ule B. In order for the Bridge module to successfully be able to determine whatincoming data from its Host is from which Sub-unit, it has to be able to read thepackets and deduce its destination. This knowledge must be programmed intothe Bridge module by the user through the Interface module, the procedure isdiscussed later on. Another possibility that the Bridge module must be able tocope with is the case of connecting more than one Host/device to each Bridge.

34

Figure 4.1: . The idea of Sub-units inside a host module.

Looking at the electronic construction of the Bridge module, the basic com-ponents needed for it to be able to perform the tasks described in this sectionare shown in figure 4.2. An FPGA is needed to translate the different protocolsto and from SpaceWire (SpW). Depending on how the Bridge module is con-structed and its detailed necessities, an extra CPU might be required to copewith the data handling which comes with reading packets and deducing whereto send it, as described above with Sub-units. In case no packet reading featuresare necessary than a logic machine will be enough to handle the Bridge module’stasks.

Figure 4.2: Simple scheme of the Bridge module.

4.2 The Error Checking module

The Error Checking module basically does what the “Error detecting”-box infigure 3.7 does. It is one of the six (Bridge module not counted) suggested ÅMAmodules and its task is to check other redundant modules. By having a separatemodule doing this work, the integrated modular design is yet again highlighted.The switch in figure 3.7 is replaced by the Router who can decide from which ofits nodes it will forward data. Thus, in this manner, a sensor or any other devicecan easily become automatically redundant by just adding a duplicate of it tothe network. No extra redundancy measures are needed, the Error Checkingmodule will be able to handle this feature for all necessary modules.

One way of the Error Checking module to check other redundant modules isfor them to continuously send packets to it. These packets will then be examinedbased on different algorithms and a decision can be made weather or not the

35

Figure 4.3: Topological redundancy.

active (Hot) module is working properly or not. Incoherent data together withCRC checks can also help determining in case there are transmitting problemsto and from the modules. The amount of time elapsed between arriving packetscan also be used to deduce the health status.

The Error Checking module’s functions are:

• Checks Active module (Hot one)

• If error: Starts Redundant Backup module (Cold one)

• Tells Router to switch to Redundant Backup (Cold one)

• Raises alert level

• Can do the above for several different modules

The topology with a double redundant Computational and TMTC module isshown in figure 4.3. Each part is Cold Standby redundant with both the Activeand Redundant Backup units connected with separate wires to the Router. Allcontrolling of redundancy issues is then done by the Error Checking module. Itmust also be stressed that the Router itself has to be redundant as well in orderto not create a single point of failure, this is also illustrated in figure 4.3.

4.3 The Computational module

While the interconnected Bridge modules and Routers are the backbone of thesystem, the Computational module is the most used of the nodes connected to it.It is here all the computing of each and every module is collected and processed.Data is first gathered from sensors and ground commands and then processed

36

Figure 4.4: Schematic for the computational module.

in real time for calculations of new instructions that are sent to actuating nodesor payloads. The module will also contain the software and hardware neededfor attitude control, such as e.g. a Kalman filter. The Computational modulethus controls attitude stabilization, computes new headings and, in addition,also takes care of all background processes like housekeeping.

It is suggested that the processors in the Computational module shall beof RISC-type, using an AMBA internal bus architecture. This can be used ona System on a Chip as an embedded system. The CPU’s can in general beFPGA’s, but some companies in the aviation industry are uncomfortable withusing FPGA’s on flight critical systems, thus alternatives must be found.

A simple internal schematic of the Computational module is illustrated infigure 4.4. In order to make the unit redundant, the internal configurationutilizes Masking redundancy. The most typical form of Masking redundancy isTriple Modular Redundancy (TMR). TMR in this case implies the use of threeidentical CPU-architectures together with a 3-way voter, which gives a fairlyredundant module. The 3-way voter listens to all incoming signals and rejectsthe one that misfits. Like this, SEU’s or similar faults can be avoided. One canalso implement an even more redundant TMR approach by installing three 3-wayvoters to avoid single point of failures. Figure 4.4 also shows another interestingfeature when it comes to redundancy thinking. As mentioned before, there aretwo types of redundancies; Standby redundancy and Masking redundancy. TheÅMA is proposed to contain both, as can be seen by the Cold standby redundantmodule in the background. This combined solution grants huge benefits whenit comes to providing reliability in critical parts such as this one.

4.4 The Interface module

The Interface module is not really a node attached to the architecture like allthe other modules, but rather a connection to the outside world. It consists of

37

a little more electronics than only a connector but, in principle, what it does isto offer a way for the end user to customize his or her system in almost everydegree. It can be connected to any PC and offers software with a WYSIWYGgraphical interface. The idea is that the customer should not necessarily haveto be schooled in computer networking in order to control the architecture. Theuser should directly and easily be able to specify what modules should speakto who, i.e. controlling the Router. Furthermore, Service Classes (priorities),which will be discussed in the next chapter, for different modules can be man-aged from here. If a certain Bridge module needs to deal with Sub-units, thenthe user can here define what in an incoming packet to search for in order todeduce specifically where it shall be sent/received. All the programming ofthe architecture is done through the Interface module and then spread via theRouter to the corresponding Bridge modules.

4.5 The IMU module

The Inertial Measurement Unit (IMU) is the module who measures and thentransmits most of the attitude and positioning data to the Computational mod-ule. It contains MEMS-based technology including mainly 3 gyros and 3 ac-celerometers. Other upgradable parts can be a GPS, a magnetometer and abarometer. The selection of sensors is based upon the successful WePilot1000-system. The IMU module is constructed in such a manner so that it can provideall the basic attitude and positioning sensors in a single physical box, for sim-plicity. The customer then only needs to add any specialized sensors that thecompany wants to implement. The IMU module and the concepts behind iner-tial navigation, filtering of sensor data and integration of multiple sensors will bediscussed in much greater detail in part II of the report. The reader is referredthere for information regarding how the ÅMA is meant to sense and control theUAV dynamics.

4.6 The TMTC module

The TeleMetry/TeleCommand (TMTC) module is the unit that takes care ofall outside communications when the system is operating autonomously. Allantennas and such are directly connected here and the data is translated from/toRF inside the module. Moreover, if the helicopter needs to be radio controlleddirectly by ground, this control is done through the TMTC module. This moduleshall be based upon the ÅAC TMTC MEMS-based unit which can offer 20Mbit/s downlink and 0,5 Mbit/s uplink.

4.7 The Mass Memory module

The Mass Memory module is the storage center of the architecture. All necessaryon board flight data is stored here. Possible payloads such as cameras can also

38

store their video on this flash based drive. If wished, the Mass Memory candirectly send down its data to the ground through the TMTC module. Theconcept of this module is based upon the ÅAC Mass Memory unit but can alsobe made of any kind of reliable flash memory.

39

Chapter 5

Network issues

Chapter 5 deals with the networking concepts behind a successful operation ofthe ÅMA.

5.1 Quality of Service

Some modules in the ÅMA will be considered more critical then others, andthus the communications between them must be prioritized. The fundamentalproblem with having a router in an architecture is packet collision. This is whentwo or more modules send packets at the exact same time, creating a situationwhere the Router must hold back some packets and let others through. Thelink “Sensor - Computational - Actuator” must for example never be exposedto larger packet delivery delays since it is considered a flight critical connection.On the other hand, the link “Payload - Mass Memory” might be considered lessimportant and is acceptable if broken in order to keep the UAV stable in flight.The solution to handling these issues is defined as Quality of Service (QoS).One copes with link importance’s by dividing out Service Classes. A packetwith a high Service Class will be prioritized when arrived in the Router whileother less important packets can either be discarded or stored for a while andthen sent when the Router is less busy. Higher Service Classes also have accessto ACK-packets for reliable transmission in order to guaranty that the packetcomes through.

5.2 SpaceWire-RT

QoS in a protocol is presently not available for SpaceWire in the RMAP stan-dard. However, it is currently under construction by Star-Dundee Ltd. Thisnew protocol will be called SpaceWire-RT (where RT stands for Reliabilityand Timeliness). SpaceWire-RT, in terms of transmission reliability, is exactlywhat is needed for the ÅMA. It will basically provide the same assurances toSpaceWire as ADFX does to Ethernet. [13]

40

The term “reliably” means that the packet is reliable in such a manner thatis guaranteed to come through, i.e. the protocol retires in the event of a failureto deliver. “Timely” denotes the fact that the packet will arrive within a cer-tain time window from when it was sent (in order for it to be up to date), i.e.delivering information within specified time constraint.

SpaceWire-RT has 4 Service Classes [36]:

• Best effort - not reliably, not timely

• Assured - reliable, not timely

• Resource reserved - not reliable, timely

• Guaranteed - reliable & timely

The Best effort and Assured services are for asynchronous systems, Resourcereserved and Guaranteed services are for synchronous systems. The user canthen, through the Interface module, assign different service classes to differentBridge modules and their respective Hosts. This again gives complete freedomfor the customer to customize and experiment with their architecture in anuncomplicated manner. An example of how the different Service Classes can bedivided is given below.

• The guaranteed service: Transferring time-critical commands to, e.g., in-struments

• Resource reserved service: AOCS data (If a packet gets lost, another onewill be along in a moment)

• The assured service: General-purpose telecommands The best effort ser-vice: Background housekeeping data

5.2.1 Time-Slots

A SpaceWire-RT network’s traffic must be defined through scheduling, this of-fers a means of traffic control by splitting, using equal divisions of time duringwhich a discrete set of network communications can take place. For example,the Guaranteed class enforces timeliness by time-slotting regions of the networkusing timecodes. A node must complete all of its transactions during its al-located timeslot. During that time it is guaranteed access to the bandwidthit needs. This is done by design of the SpaceWire-RT network and timeslotallocation knowing the topology and the requirements of the devices involved.These divisions of time are known as time-slots. Time-slots are distributed inSpaceWire using SpaceWire time-codes. There are 64 unique time-codes so anatural division is to have 64 time slots in a schedule or bandwidth allocationcycle. The 64 time-slots are referred to as an epoch. Time slots are used in thescheduled system for allocating network bandwidth to the network traffic.

41

5.3 Deviating from the standard

The Router itself is of course a critical part of the architecture and must be cho-sen with care. There exists today an extensive SpaceWire Router ASIC man-ufactured by the Atmel Corporation. It consists of 8 ports switched through

Figure 5.1: The Atmel SpaceWire Router ASIC.

a Non-blocking Crossbar, it also has two external FIFO I/O’s and some otherports such as Status outputs and Time-code. The internal architecture schemeis displayed in figure 5.1. While this ASIC will work fine in the modular architec-ture, the question is whether to use it or not. Is the standard SpaceWire equip-ment good enough for the ambitions of the ÅMA? Are the standard SpaceWirecables and connectors the ones that should be used or should a more advancedcable specifically designed for our needs be developed?

While it is true that the SpaceWire standard have many improvements toits predecessor IEEE 1355, like adding time codes and a network layer, it stillchose to omit some features. Many users find these omitted features as necessaryand are often developing them themselves. The company 4Links Ltd. suggestsusing another connector than the one from the standard (figure 1.5). Thisconnector, shown in figure 5.2, can optionally carry power (not provided inthe standard SpaceWire cable) [14]. For a modular architecture, one needsto offer more than just the interconnection possibility between the modules.Simplicity and elegance must be sustained through each and every aspect of thesolution. It is thus suggested that the ÅMA will not be based upon standardSpaceWire equipment. Another, more customized, Router should be developedand the cabling and connectors should be changed and improved. It is onlylike this that our solution can provide an extraordinarily setup. The systemwill combine the best elements from different connection principles, topologies,protocols, physical layers, redundancies, minimalism and innovative thinking.

42

Figure 5.2: The IEEE 1355-like connector suggested for SpaceWire.

Figure 5.3: The ÅAC Modular Architecture with power handling.

5.4 Power handling

A great feature that can be added to the architecture is the possibility of powerhandling. A special type of router must then be implemented that could, asseen in figure 5.3, spread the power to each node. The idea is that a specialPower module will be connected to the Router, the Router shall then distributepower and data over the improved special cables.This approach will provide anunprecedented new way of handling UAV avionics. The end user will not onlyhave networking and redundancy issues solved, but will also no longer have toconnect power with separate cables to each and every module. Thanks to all theabove improvements together with MEMS-based technology, modest topologyand less cabling, the weight of the avionics is considerably diminished comparedto traditional systems.

5.4.1 Power handling Bridge module

The Bridge module in the above case is more sophisticated than previouslyin order for it to cope with the incoming power. It could contain a DC/DC-converter that could be regulated in order for it to convert the given power tothe specific needs of the Host. The output power of the DC/DC-converter willbe decided by the user through the Interface module so that each node getsthe exact power it needs. The power handling Bridge module’s schematic isdisplayed in figure 5.4.

43

Figure 5.4: Schematic of the power providing Bridge module.

44

Chapter 6

Final version of the ÅMA

During the work process, several types of architectures where considered, eval-uated and then either discarded or added to the concept. Based on articlereading, feedback from UAV companies and market analysis of what might bethe most sought after solution, the final version of the ÅMA was pinpointed.Chapter 6 presents this final version of the ÅMA; the ÅMA SpaceWire + CANversion.

6.1 SpaceWire + CAN

As mentioned earlier in section 3.2, the star topology that has been the basisfor the ÅMA up until now needs to have a bus structure added to it. Severaldifferent bus standards are available to choose from, among others there arethe previously portrayed ARINC 429 and CAN-bus. Based on discussions withSaab Aerosystems the CAN bus will be the one chosen for the task. It is moresimple and easier to implement than ARINC 429.

Thus, the final version of the ÅMA, proposed by this thesis, will containboth a star shaped and a bus topology. This combination, of the best fromtwo worlds, will offer the architecture an unprecedented flexibility. Like this,the ÅMA has a high speed and a low speed part that both still retains theirmodularity. Looking at the existing UAV architectures, one can easily see thegreat amount of nodes and sub-units, all these parts cannot be connected to oneor several different star shaped networks, that would create an immense amountof cabling. Moreover, in a small UAV helicopter or satellite, most of the unitsare located close to each other. This is where the uncomplicated Bus featureprovides simplicity and plainness to the system. The SpaceWire/CAN ÅMA isshown in figure 6.1.

45

Figure 6.1: The final version of the ÅAC Modular Architecture.

6.2 CAN Bridge

A new kind of Bridge will be required in the CAN part of the above topology.This CAN translation module, here called the CAN Bridge, will take care of pro-tocol handling and conversion. The CAN Bridge module is meant to translateto and from CAN to most industry standard protocols, much like the SpaceWireBridge does with SpaceWire.

6.3 CAN power handling

The power handling advantages discussed earlier can also be used in this newSpaceWire/CAN architecture. Due to the fact that most of the connected mod-ules will use the CAN part, it is only necessary to provide power distributionthere. It is considered feasible but maybe too complicated to introduce powerhandling in the SpaceWire part. This is because there are only a few, yet veryimportant, modules connected there and hence the amount of cables will notdecrease that much with built in power distributing possibilities. On the otherhand, the CAN part would be suitable for such an addition.

One way of providing power is to simply use regular power lines and thentransmit CAN over them. This solution is already provided by Yamar Electron-ics Ltd. with their product DCAN250. The DCAN250 is a Very-Large-ScaleIntegration (VLSI) device for Multiplex CAN bus communication over battery

46

Power Lines (PLC). It is a complete alternative solution to the CAN bus physicallayer. The device operates as a smart DC - PLC transceiver for CAN bus con-trollers. The DCAN250 contains a modem, a channel coder/decoder (utilizingerror correcting code, FEC), a communication controller and a message-bufferedhost interface to overcome the hostile environment of battery lines. It can offerspeeds up to no more than 250 kbit/s. The DCAN250 is based on the DC-BUS technology which reduces harness weight whilst enabling flexible, quickand simple installation. [15]

Whilst the above product is designed for battery and vehicular use, a similarapproach can be done by ÅAC to provide power and CAN on the same cables.

47

Chapter 7

Conclusion of Part I

Gathering all the improvements and innovative characteristics of the ÅMA, itis not far too fetched to see that it contains something that has been discussedand wanted for at least a decade. It includes something that has only beenimplemented on a few systems up until today. And even then, it has merelybeen used on non critical parts. It comprises of something that has been saidto be too complicated and elaborate to be operable within the near future. TheÅMA utilizes concepts behind Integrated Modular Avionics (IMA), or morecorrectly; Distributed Integrated Modular Avionics (DIMA). The final versionof the ÅAC Modular Architecture (figure 6.1) is thus the proposed future generalarchitecture for essentially any kind of UAV or satellite.

48

Part II

The principles of UAV flightcontrol

49

Introduction to Part II

This second part of the report will in general terms discuss the main principlesbehind the control of unmanned aircraft. It is this that the ÅAC ModularArchitecture, defined in part I, has to cope with in order to fulfill its purpose.The five chapters of part II spans over the basics of inertial navigation, sensorsfor measuring dynamics and the mathematics behind the velocity, position andattitude estimation of a rigid body (a body in which the relative position of allits points is constant). Chapter 11 covers the integration process when wantingto use several sensors to aid the flight control. Chapter 12 is more connected topart I since it essentially deals with how the flight control is performed on theÅMA network.

The informative parts of the text are gatherings from several different papersand dissertations on the subject. For more extensive information on these sub-jects, the reader is referred to the corresponding literature given as referencesin the text and found in the bibliography.

50

Chapter 8

Inertial sensors

This chapter introduces the concept of the inertial sensors used throughout thefollowing parts of the report.

8.1 Introduction

Inertia is the resistance an object has to a change in its state of motion. Theprinciple of inertia is one of the fundamental principles of classical physics whichare used to describe the motion of matter and how it is affected by applied forces.For the measurement of inertia, inertial sensors are used that can measure therotation rate and acceleration of a rigid body under dynamic stress. There are alarge number of different sensors available for measuring the inertial movementsof a rigid body. In the domain of this thesis, a rigid body is considered to bethe mass and frame of a UAV helicopter. Every autonomously flying helicoptertoday contains what is called an Inertial Measurement Unit (IMU), a devicecontaining different types of inertial sensors.

8.2 Inertial Measurement Unit

This section gives a universal description on how IMUs operate and it shouldnot be mixed together with the “IMU module”, which is a SpaceWire basedmodule connected to the ÅMA network (described in section 4.5). The IMUmodule will however, among other type of sensors, contain a MEMS based IMUinside.

An IMU usually consists of two types of inertial sensors; the gyroscope andthe accelerometer. These types of sensors have long been bulky and expen-sive, but with the advent of modern technology new MEMS class sensors havebeen introduced on the market. Being not only more sensitive, but also cheaper,smaller and more light weight, these type of inertial sensors are the most promis-ing choice when dealing with medium to small sized vehicles. They do however

51

not operate in the same fashion as traditional equivalent gyroscopes and ac-celerometers do. [25, 26]

8.2.1 The MEMS Gyroscope

Gyroscopes (or gyros for short) measure angular rate, that is; how quickly abody turns. The rotation is typically measured in reference to one of the threeaxes: yaw, pitch, or roll. The measurements from gyroscope are used for atti-tude and pointing determination. All MEMS gyroscopes take advantage of theCoriolis effect. In a reference frame rotating at angular velocity Ω, a mass Mmoving with velocity v sees a force:

F = 2 ·M · v × Ω. (8.1)

Many types of MEMS gyroscopes have been developed over the years, withmost falling into the categories of Tuning-Fork Gyros, Oscillating Wheels, Fou-cault Pendulums, and Wine Glass Resonators. As a contrast, conventionalnon-MEMS gyros use spinning wheels to sense and/or maintain angular rate.

This report will concentrate on a new type of MEMS gyros called “ADXRS”manufactured by Analogue Devices. These type of sensors are created usinga process named “iMEMS” by the company, referring to a new manufacturingprocess. These type of sensors have achieved a breakthrough since they have aangular rate sensor and signal processing electronics on a single piece of silicon.The concept of this low noise sensor is based upon a modified Tuning Fork gyro.

8.2.1.1 Tuning Fork Gyroscopes

Tuning fork gyros contain a pair of masses that are driven to oscillate with equalamplitude but in opposite directions. When rotated, the Coriolis force causes theproof masses to vibrate out of plane. This motion is sensed capacitively with acustom CMOS ASIC, giving an output signal. An example of a resonating massis illustrated in figure 8.1. In the Analog Devices ADXRS gyro, the proof massis tethered to a polysilicon frame that allows it to resonate in only one direction.Capacitive silicon sensing elements inter-digitated with stationary silicon beams

Figure 8.1: Resonating mass of a MEMS gyroscope.

52

Figure 8.2: The ADXRS chip.

attached to the substrate, measure the Coriolis-induced displacement of theresonating mass and its frame. The ADXRS chip is pictured in figure 8.2.

8.2.1.2 Ring Laser Gyroscopes

Another frequently used gyro type is the so called Ring Laser Gyroscopes (RLG).A RLG uses the interference of laser light to detect changes in angular velocity.It consists of a ring interferometer that is located on a platform that can rotate.When the platform is rotating the lines of the interference pattern are displacedas compared to the position of the interference pattern when the platform is notrotating. The amount of displacement is proportional to the angular velocityof the rotating platform. RLG’s have no moving parts which means there is nofriction, which in turn means there will be no inherent drift terms. Additionally,the entire unit is compact, light weight and virtually indestructible.

8.2.2 The MEMS Accelerometer

An accelerometer is a device for measuring acceleration and gravity inducedreaction forces. By measuring the acceleration, one can also derive the speed andlocation of the UAV (by mathematical integration, given that its initial positionis known). Single- and multi-axis models are available to detect magnitude anddirection of the acceleration as a vector quantity. Accelerometers can be usedto sense inclination, vibration, and shock.

The physical mechanisms underlying MEMS accelerometers include Capac-itive, Piezoresistive, Electromagnetic, Piezoelectric, Ferroelectric, Optical, andTunneling mechanisms. The capacitive transduction accelerometers are the

53

most used ones since they are stable over temperature variances, constructed ina simple manner and modest in power consumption.

A MEMS accelerometer usually consist of a stable proof mass that is dis-turbed from its original position by accelerative forces. By measuring the mis-alignment with different techniques, the acceleration at hand can be derived.The measuring range can reach up to thousands of g’s. Among the specifica-tions to consider when choosing an accelerometer are bandwidth, noise floor,cross-axis sensitivity, drift, linearity, dynamic range, shock survivability, andpower consumption.

8.3 Inertial Navigation System

An INS is simply an IMU together with the necessary computational powerand algorithms to take in the IMU measurements and calculate exact position,velocity and attitude of the vehicle in hand. An INS can thus independently helpa UAV to navigate and control its dynamics. Inertial Navigation Systems can bepurchased as a complete system or one can create ones own INS by integratinga Kalman filter to the IMU data. The latter option is the one proposed for thearchitecture in this report, due to the fact that one has greater control abilities.

54

Chapter 9

Attitude kinematics

When attempting to describe the attitude change of a rigid body, there areseveral different inertial frames of reference to choose from. The most intuitiveone is using “Euler angles”, based upon trigonometry. But the non-commutativeextension of complex numbers called “Quaternion” has become the most usedmethod for calculations involving three-dimensional rotations. This section givesa short introduction to both approaches together with an analysis of how theyare used and which one that is recommended. [27]

9.1 Euler angles

Euler angles, developed by Leonhard Euler, describes the orientation of a rigidbody in 3-dimensional Euclidean space. This method states that in order togive an object a specific orientation, it shall be subjected to a sequence of threerotations where the respective rotation angles are the “Euler angles” themselves.

When wanting to represent the spatial orientation of a body, one startswith a frame being the primary one, called the “inertial reference frame”, andfinishes with a subsequent frame (after the rigid body has rotated), called the“non-inertial reference frame”. It is the difference between these two frames, ormore precisely “states”, that is interesting when determining the attitude of avehicle. The Euler angles help describe this difference, which is a 3-dimensionalrotation made by the body. These rotations, represented by the angles φ, θ andψ, are in aeronautics called roll, pitch and yaw, respectively. The angle of roll(φ) describes a rotation around the X-axis, the angle of pitch (θ) around theY-axis and the angle of yaw (ψ) around the Z-axis.

Thus, in the calculation method of Euler angles, starting from the inertialreference frame, three successive rotations are performed, each about one of thereference axes. This will change the vehicle’s attitude from the inertial referenceframe to the non-inertial one, and thus the complete attitude kinematics of therigid body is described. It should be noted that it is not necessary to rotatearound each and every axis, like first X, then Y and finally Z. There are many

55

Figure 9.1: The Z-X-Z rotations of a rigid body from its inertial to non-inertialreference frame.

ways of rotating the body, and moreover, one does not have to use every axis.For example in the Z-X-Z convention, where a Y-axis rotation is not used. TheZ-X-Z convention is in fact the most usual one, although there is no decisivestandard of how to rotate the body. Figure 9.1 shows the Z-X-Z rotations inEuler angles through three consecutive steps where the state before step 1 isthe inertial frame and the state at step 3 is the non-inertial one. Here:

• φ is the angle between the X-axis and the line of nodes.

• θ is the angle between the Z-axis and the Z’-axis.

• ψ is the angle between the line of nodes and the X-axis.

Consequently, a rotation has first been made around the Z-axis, then the X-axisand lastly the Z-axis again.

9.1.1 Example of kinematic transformation equations

Traditionally, the aviation industry utilizes the Z-Y-X convention, being therotations performed about an axis of a moving reference frame (which is thecase for a flying aircraft).

So here, to get from the inertial to the non-inertial frame in the Z-Y-Xconvention one has to:

1. Rotate ψ about Z axis

2. Then rotate θ about Y axis

3. Then rotate φ about X axis

To describe the rotations mathematically each rotation around each axis is rep-resented trigonometrically with the matrices:

RZ(ψ) =

cosφ sinφ 0− sinφ cosφ 0

0 0 1

, (9.1)

56

RY (θ) =

cos θ 1 − sin θ0 1 0

sin θ 1 cos θ

, (9.2)

RX(φ) =

1 0 00 cosψ sinψ0 − sinψ cosψ

. (9.3)

The three transformations are added by matrix multiplication, hence giving:

RY XZ(ψ, θ, φ) = RZ(ψ) ×RY (θ) ×RX(φ) = (9.4)

cosφ sinφ 0− sinφ cosφ 0

0 0 1

cos θ 1 − sin θ0 1 0

sin θ 1 cos θ

1 0 00 cosψ sinψ0 − sinψ cosψ

.

Calculating the above gives the Transformation Matrix (TM) between thetwo states;

TM =

cosφ · cosψ cos θ · sinψ − sin θ(sinφ · sin θ · cosψ − cosφ · sinψ) (sinφ · sin θ · cosψ + cosφ · cosψ) sinφ · cos θ(cosφ · sin θ · cosψ + sinφ · sinψ) (cosφ · sin θ · sinψ − sinφ · cosψ) cosφ · cos θ

.

(9.5)

Equation 9.5 is for relating an inertial frame to a non-inertial one. It is usedto describe the UAV’s attitude change and movements, by operating with themon specific attitude and movement related mathematical equations. It can forinstance be used if one would need to relate the ground speed to the airspeed.

While the approach of Euler angles works fine and is not too mathematicallycomplicated, it does contain a lot of trigonometric functions. This makes theneed of computational processes higher. These equations are computed on ahigh update rate in order to follow the kinematics properly, thus making thisapproach demand a lot of processing power. Another weakness with the Eulerangles is the phenomenon of “gimbal lock”. Gimbal lock occurs when the axes oftwo of the three gimbals in a gyroscope (in three dimensional space) are drivento the same direction. This effect can particularly happen on aircraft, and if ithappens the Euler angles will represent a faulty value in comparison with theactual attitude.

57

9.2 Quaternion

Quaternions were invented by Sir William Rowan Hamilton as a way of extend-ing the imaginary numbers. Its rotational representation is based upon fourparameters instead of the Euler angle’s three. These four parameters are knownas the quaternion of finite rotation and are defined as follows [29];

q = q0 + qx · i + qy · j + qz · k, (9.6)

where

q0qxqyqz

=

cos(Θ/2)Ex · sin(Θ/2)Ey · sin(Θ/2)Ez · sin(Θ/2)

. (9.7)

Here (E, Ey, Ez) is a unit vector and Θ is the rotation angle around its axis. Inequation (9.6) the quantity q0 is scalar and the rest are imaginary values in 3Dspace. It is not in the scope of this thesis to derive the equations of Quaternion,more than to state that the Transformation Matrix from inertial to non-inertialcoordinates is given by [30]:

TM =

(q20

+ q2x − q2y − q2z) 2 · (q2x · q2y + q20· q2z) 2 · (q2x · q2z + q2

0· q2y)

2 · (q2x · q2y + q20· q2z) (q2

0− q2x + q2y − q2z) 2 · (q2y · q2z + q2

0· q2x)

2 · (q2x · q2z + q20· q2y) 2 · (q2y · q2z + q2

0· q2x) (q2

0− q2x − q2y − q2z)

.

This TM can, just as in the case of the TM in Euler angles, help describe theattitude and velocity change of a rigid body.

9.2.1 Method of use

The use of Quaternion greatly reduces the computational complexity because,unlike Euler angle transformations, the Quaternion transformations do not in-volve trigonometric functions. On the other hand, Euler angles are more intu-itive than Quaternions and only three parameters are needed to represent ro-tation instead of four parameters in the unit quaternion. Quaternions, though,have the advantage of numerical robustness in attitude representation and atti-tude estimation, since the effect of gimbal lock cannot occur as the total rotationis computed all at once. For these reasons, the Quaternion approach is muchmore widely used in aeronautics, and it is also the recommended method of thisthesis.

58

Chapter 10

Kalman filtering

Once the measurements have been taken by the inertial sensors, and later trans-ferred to a correct coordinate system in Quanternions, the data must be handledin order to filter out biases and errors. Not only might an inertial sensor be noisy,it could also provide faulty data due to drift issues, being mentioned later inthe text. The function of the Kalman filter, primarily, is to through a recursivemathematical method eliminate the faulty data and give out a correct optimalestimate of the current attitude, position and velocity of the vehicle. In otherwords, it is to estimate the state of a dynamic system from a series of incompleteand noisy measurements. There are many types of Kalman filters, one being thespecific Information Filter that is used to integrate data from multiple sensors,as discussed in the INS/GPS integration section (chapter 11). But for now, afundamental glimpse of the standard versions of the Kalman filter is given. Thistext is a gathering of information from several different sources, one notably be-ing the excellently written paper “An introduction to the Kalman Filter” by G.Welch et al. [31], but also sources like [32] has been looked at. The reader isreferred to the bibliography for a more in depth explanation.

10.1 The standard Kalman filter

The Kalman filter, derived first by R.E. Kalman, consists of several mathemat-ical formulas that help estimate a process by using a form of feedback control.In short, the filter works as such that it makes an estimate at time step k-1, forthe next state, being time step k. Then, when time step k is reached, it updatesthis estimate with a noisy measurement. By having a solid estimate plus reallife data, it can now filter out the eventual errors or noise factors from the mea-surements by comparing the two. This process is known as one complete loopof Kalman filtering. The more loops that are done, the more solid the estimatesget, since each step of data input helps strengthen the mathematical backboneof the predictions. This is due to the Kalman filter’s recursive conditioning ofthe current estimate on all of the past measurements.

59

Figure 10.1: Flowchart over the Kalman filter.

So by first estimating the process state at some time, and then obtainingfeedback from measurements, the equations for the Kalman filter can fall intotwo groups; “time update equations” and “measurement update equations”. Thetime update equations are responsible for projecting forward (in time from k-1to k) the current state and error covariance estimates to obtain the “a priori”estimates for the next time step. The measurement update equations are re-sponsible for the feedback, i.e. for incorporating a new measurement into the apriori estimate to obtain an improved “a posteriori” estimate. Hence, the timeupdate equations can be thought of as predictor equations, while the measure-ment update equations can be thought of as corrector equations. See figure 10.1for a simple flowchart describing the different phases of the Kalman filter. Beforetaking a closer look at the mathematics behind the workings of the Kalman fil-ter, it should be known that two different forms of the filter exist. The standardKalman filter addresses linear cases, but in order to estimate states in a non-linear environment (which almost everything exists in), the Extended KalmanFilter (EKF) is used. This report will only go through the linear Kalman filter,as it is easier to comprehend, but a short introduction to the EKF is also givenso that the reader can see the similarities without having to dig deep inside thederivation of the formulas.

10.1.1 Mathematical derivation

When addressing the general problem of trying to estimate the state x∈ Rn of

a discrete-time controlled process, one can use the linear stochastic differenceequation;

xk = Axk−1 +Buk−1 + wk−1. (10.1)

And combine it with an actual measurement, represented by z ∈ Rm that is;

zk = Hxk + vk. (10.2)

Here, x is the ”state” that is going to be predicted and later corrected. Thenxn matrix A relates the state at the previous time step k−1 to the state at the

60

current step k, just as stated earlier. Also, the nxl matrix B relates the optionalcontrol input to the state x. And the matrix H in the measurement equation(10.2) relates the state to the measurement. In addition, the random variableswk and vk represent the process and measurement noise, respectively. They areassumed to be independent of each other, white, and with normal probabilitydistributions, according to;

p(w) ∼ N(0, Q), (10.3)

p(v) ∼ N(0, R). (10.4)

Where Q is the ”process noise covariance” and R is the ”measurement noisecovariance”. R is also called the “observation noise matrix”, since it is a matrixcontaining a mathematical model of the noise given by the sensors. Both Q andR need to be determined and changes in every case, more on this in section11.3.2.

With all the above stated, in deriving the equations for the Kalman filter, anequation that computes an “a posteriori” state estimate as a linear combinationof an “a priori“ estimate is needed;

xk = x−k +K(zk −Hx−k ). (10.5)

Here, the second term is a weighted difference between an actual measure-ment and a measurement prediction H · x−k . The difference (zk −Hx

−

k ) is calledthe measurement “innovation” or “residual”. It reflects the difference betweenthe predicted measurement and the actual measurement. A residual of zeromeans that the two are in complete agreement.

The term K in equation 10.5 is an nxmmatrix being the “gain” (or “blendingfactor”) that minimizes the “a posteriori” error covariance. It can be shown thatK is given by;

Kk = P−

k HT (HP−

k HT + R)−1. (10.6)

We are now ready to look at the operation and complete set of equations ofthe Kalman filter, as shown in figure 10.2. The feedback and recursive featuresof the filter can be seen directly if examining figure 10.2. The process startswith calculating the state ahead, the “a priori” estimate, marked by (1). The“predictor” phase of the filter is ended with projecting ahead the error covari-ance in step (2). Moving from time step k − 1 to k, the “corrector” part starts.Here, after computing K, the noisy IMU or GPS measurements are directlyinserted in step (4) to get the “a posteriori” final corrected state that can beused for navigation and control of the UAV. After each cycle in the time andmeasurement update pair, the process is repeated with the previous “a posteri-ori” estimates used to project or predict the new “a priori” estimates, and so onand so forth.

61

Figure 10.2: The standard linear Kalman filter presented with its 5 steps ofcalculations.

10.2 The Extended Kalman Filter (EKF)

As stated earlier, the standard Kalman filter only estimates linear processes,since this is often not the case in most systems due to the fact that we livein a non-linear world, a non-linear extension of the Kalman filter has beendeveloped. In short, what the EKF does is to linearize the process around thecurrent estimate using the partial derivatives of the process and measurementfunctions. By doing so, it can compute estimates even in the face of non-linearrelationships. This is done by something similar to a Taylor series expansion. Inorder to explain the EKF, some earlier presented material in section 10.1.1 mustbe modified. Assume that our process again has a state vector x∈ R

n, but thatthe process is now governed by the non-linear stochastic difference equation;

xk = f(xk−1, uk−1, wk−1), (10.7)

again with a measurement z ∈ Rm that is;

zk = h(xk, vk), (10.8)

where the random variables wk and vk once more represent the process andmeasurement noise as in (10.3) and (10.4). In this case the non-linear functionin the difference equation (10.7) relates the state at the previous time step k−1to the state at the current time step k. It includes, as parameters, any drivingfunction uk−1 and the zero-mean process noise wk. The non-linear function hin the measurement equation (10.8) relates the state to the measurement.

The function f in equation (10.7) is used to compute the predicted statefrom the previous estimate. Similarly, the function h can be used to compute

62

Figure 10.3: The non-linear EKF together with its 5 steps.

the predicted measurement from the predicted state. However, f and h cannotbe applied to the covariance directly. Instead a matrix of partial derivatives(the Jacobian) is computed. Thus, at each time step the Jacobian is evaluatedwith the current predicted states. These Jacobian matrices can be used in theKalman filter equations. And it is like this that the filter essentially linearizesthe non-linear function around the current estimate.

The complete equations and process loop of the EKF is given in figure 10.3.For the full derivation of these equations, the reader is referred to the literature.It should be noted that, unlike its linear counterpart, the extended Kalman filteris not an optimal estimator. For example if the initial estimate of the state iswrong, or if the process is modeled poorly, the filter may quickly diverge, due toits linearization process. Yet, even with this stated weakness, the EKF can givereasonable performance, and is arguably the de facto standard in navigationsystems and GPS solutions. It is also the recommended version of the Kalmanfilter for use in the flight control structure of the ÅMA.

63

Chapter 11

Integration of INS & GPS

11.1 Introduction

When dealing with the control of unmanned aircraft, a multitude of sensorsare utilized to determine the aircraft dynamics. The ÅMA will help simplifythe process of integrating these sensors. This chapter describes the process ofintegration between the two most fruitful and usual sensors types; the INS andthe GPS.

GPS navigation is based and extracted from weak satellite signals that areabout 100 times fainter than the Cosmic Background Radiation. With signalsbeing this weak, the GPS system is easily disturbed causing poor GPS perfor-mance or total GPS outage in urban environments, in tunnels, under water andin forests with heavy foliage. In addition, there are a lot of cheap and simpleways to jam GPS functions over large areas, several types of GPS interruptershave existed for many years.

Hence it is not a good idea to only rely on GPS signals when determiningthe position and speed of a UAV. Traditionally, an INS system has been usedfor navigation due to its robust nature and the fact that it is hard to disturbexternally. On the other hand, inertial navigation does lead to unbounded,exponential error growth when operating under dead reckoning. Because of this,an INS drifts over time, even though it exhibits relatively low noise. The positionsolution of an INS is based on the integration of accelerometer and gyro sensormeasurements, as stated earlier. Errors introduced in these measurements, suchas biases and noisy sensor data, will accumulate and result in an unboundedposition error. As a comparison, it takes very expensive and bulky systems to,even during short periods of time, achieve a performance comparable to GPSsystems. Fortunately, during the last decade, more improved MEMS basedsensors have started to approach these expensive and large systems when itcomes to performance.

According to [35] there are four performance grades of IMU’s; Strategic,Navigation, Tactical and Consumer grade, see table 11.1. Even though iner-

64

Table 11.1: The four performance grades of inertial sensors.Inertial System Grade Position Error [km/h] Gyro Error [o/h] Accelerometer Error [mg]

Strategic < 0.03 0.0001 0.001Navigation < 4 0.015 0.1Tactical 18.5 to 40 1 to 10 1.0

Consumer > 40 1000 20

tial systems having the “Strategic” or “Navigation” high precision grades areextremely expensive, their performance can be matched by constantly GPScompensating for the drift in cheaper “Consumer” grade systems. Thus eventhough using a simple Consumer grade MEMS gyro, one can achieve better per-formance by integrating a GPS with an INS. Like this a low cost, light weightnavigation system can be built with sufficient accuracy. Since both systemshave their advantages and disadvantages, an integration of a GPS and an INScan overcome the defects of the standalone systems, while benefiting from theircomplementary characteristics. When discussing this integration process, oneoften refers to a main “inertial device” that is backed up by an “aiding source”.

11.1.1 The benefits of integration

The sole equations of inertial navigation are essentially integrators and they giverise to inherent noise and biases in the system. Hence, the desirability of aidinginertial sensors with GPS measurements has long been known. For aided inertialnavigation systems, the inertial device can either be an IMU, which only pro-vides the raw acceleration and rotation rate data, or an INS providing position,velocity and attitude information. The aiding source can either be considered asa sensor providing raw sensor information, or as a navigation system providingthe position, velocity and/or attitude information (like a GPS). The main ideaof integrated navigation systems is to take advantage of the ideal complemen-

Figure 11.1: Illustration of how an INS and a GPS can aid each other.

65

tary attributes of two or more sensor types, resulting in a greater precision. Fig11.1 illustrates the advantages and is divided into 5 steps, namely:

1. Only GPS: Has limited error but noisy and has a low measurement rate(1 Hz).

2. Only INS: High measurement rate and low noise, but unlimited errorgrowth.

3. INS + GPS: Robust combination with high accuracy, the system alsoestimates sensor errors.

4. Satellite outage: Position error grows, but slower than with only an INS,since sensor errors are estimated at point 3.

5. Recovery: Depending on the degree of coupling, the system can recoververy quickly as soon as satellite coverage is back.

11.2 Integration configurations

While researching on the subject of INS/GPS integration, several different mod-els of how to solve the problem where found. Furthermore, they all seemed tostate that only that specific model can be called e.g. loosely coupled, whileother papers described different architectures yet stating the same name. Inthis section of the report, which is a combination of the information given in[18, 19, 20, 21, 22, 23, 24], the definitions of [18] was chosen due to its straight-forward and clear description, but also its solid argumentation.

A number of different integration architectures have been developed over theyears to allow GPS and INS to be combined. There are four main classes ofintegration architectures:

• Uncoupled systems

• Loosely coupled systems

• Tightly coupled systems

• Deep/Ultra-tightly coupled systems

11.2.1 Uncoupled Systems

This is the simplest method of integrating a GPS and an INS. The two systemsoperate independently; when a GPS position and/or velocity measurement isavailable the INS is reset. This bounds the error growth of the position andvelocity estimates from the INS. The method does not provide performanceenhancement and jamming avoidance like the coupled architectures.

The most natural implementation of an aided inertial navigation system is todrive a non-linear filter with the raw acceleration and rotation rate data provided

66

Figure 11.2: Uncoupled, direct structure.

by the IMU, together with position and velocity from a GPS, as shown in Figure11.2. The implementation is known as a “direct filter”. While this solution isthe simplest one, it is far from the best. By only advancing the integrationprocess with a few steps, a much more robust solution can be provided.

11.2.2 Loosely coupled systems

The traditional approach to INS/GPS integration with Kalman filters leads to aconfiguration termed “loosely coupled” or “decentralized system”. It is a simpleand effective way of integrating GPS and INS. The GPS operates autonomously,whilst providing measurement updates to the inertial system. The GPS partworks like any other GPS; inside it has an EKF that processes the signals andoutputs a three dimensional position and velocity vector in the standard GPSEarth Centred Earth Fixed (ECEF) reference frame. General GPS design isbased on a requirement of a minimum of four tracked satellites in order to solvefor three dimensional position. When less than four satellites are visible, stand-alone 3D GPS positioning cannot be thoroughly accomplished. However, whenan accurate position and velocity is determined, this information is sent to asecond, integration Kalman Filter to predict inertial sensor errors coming fromthe INS. The INS computations are then updated with direct observations ofthe position error derived from the outputs of the inertial unit and the GPS.Thus, like this, the INS computational part can hence see its faults and calibrateitself from bound errors in a feedback loop.

The standard Kalman filter equations are optimal when sensor observationsare unbiased with white noise. By filtering the GPS data twice this optimalityconstraint is effectively abandoned. The main advantages of loosely coupledintegration are the simplicity and redundancy factors, based on its internalarchitecture. Yet, the same architecture also gives rise to its main problem; thecascade coupled Kalman filters, where the position noise from the GPS receivercan be coloured. This might create problems depending on for example updaterates.

67

Figure 11.3: Loosely coupled configuration.

The method is known as a loosely coupled implementation since there is nofeedback to the aiding sensor/navigation system, see figure 11.3. If feedback isprovided to the aiding source a tighter configuration is obtained which in turnimproves system integrity but increases complexity.

11.2.3 Tightly coupled systems

“Tightly coupled” or “centralized integration” only uses the raw pseudorangesfrom the GPS receiver. The GPS ranging signals are fused directly in theupdate stage of the Kalman filter. Among the main advantages of the tightlycoupled integration is the use of only one Kalman filter, so the problem withcoloured noise does not arise. It also offers the advantages of being robust andincreases performance since it allows the systems designer to explore into theoperation and algorithms of both the inertial and aiding sensor. The inertialsensor provides raw data to the filter which usually incorporates a kinematicmodel of the vehicle. The aiding sensor also provides raw information and herethe system does not require a full GPS solution (i.e. tracking of four satellites) toaid the INS. Even GPS data from only one or a few satellites will now contributeenough information to the Kalman navigation filter to estimate the IMU-errorsand thereby bounding the navigation errors. Furthermore, the more satellitesused in the ranging process - the more information the filter can constrainfrom the INS, and vice versa. Consequently, in the coupled configuration, itis the aiding sensor that gets feedback from the non-linear Kalman filter, asapposed to the inertial sensor in the loosely coupled configuration. Moreover,a tightly coupled filter processes the GPS signals directly. In a well designedsystem this increases the chance of optimal filter performance. Figure 11.4shows a simplified representation of a tightly coupled integration architecture.The root of the tightly coupled integration technique is thus integration by

68

Figure 11.4: Tightly coupled configuration.

directly utilizing GPS pseudorange and deltarange (i.e. raw data) from theGPS receiver. This data is to correct the INS error growth with a user designedKalman filter that models the INS errors. The INS Kalman filter could bedesigned to accept non-GPS measurements and can incorporate as many INSerror states as deemed necessary to optimize performance. The filter estimatesthe state of the vehicle, and uses these estimates to assist the aiding sensor in itsattainment of observations. For example, the aiding information can help GPSwith tracking satellites or assist a scanning radar with pointing and stabilization.

Although conceptually simple to understand, the design of a tightly coupledsystem is a complex process which will involve a significant integration effort.In addition, the transmission of the accurate Precise Positioning Service (PPS)pseudoranges and deltaranges outside of the GPS receiver module might makethis classified data susceptible to unauthorized use, thus raising a security issue.

It should be noted that both loosely and tightly configurations are sensi-tive for environments with weak GPS coverage, interfering signals or extremelydynamic motions. The difference in this case is that the tightly coupled config-urations gives rise to a faster GPS lock if the signal has been lost. This featureof course gives better navigational performance since more detailed models layground for the integration process. The reason for loosing a signal, or GPS lock,in extreme dynamics is that a so called phase-slip occurs. Normally, during startup, GPS receivers only have knowledge about the transmitting satellite’s veloc-ity and not its own movements. A sort of feedback of its own data is given to itso that it could calculate a predicted phase shift of the incoming signals. Butwhen under high dynamic stress it cannot cope with this phase shift any longerand slowly looses grip of its real position and velocity. All this is due to theDoppler shift of the signal which the receiver has no knowledge of. This factcan be changed in tightly coupled configurations since, as mentioned previously,the aiding sensor (i.e. the GPS) gets external feedback from the Kalman filterwhich in turn relies on the INS. These features can be found in tightly coupled

69

configurations but does require even more integration work. More advancedsolutions are often called “ultra-tightly coupled systems”. This report will notgo in further on the ultra-tightly configurations more than to state that theyare even more sophisticated and robust, but at the same time significantly morecomplex than the other coupled solutions.

11.2.4 Comparison

The ÅMA IMU module is first and foremost developed for UAV helicopters.Helicopters often fly at a certain altitude and do not operate down on theground where GPS signals can be blocked or reflected by surrounding buildings.Nonetheless, there could exist a scenario where they would have to navigatein urban surroundings. But in general, the issue of weak or erroneous GPSsignals is not considered to be a huge problem for helicopters and particularlynot in the case of the first test bed versions of the ÅMA. Of course the tightlycoupled filter would be considered an “optimal” solution, but one has to considerother factors than just plain simple performance when choosing which solutionto embed in the ÅMA. It is only in dense urban locations where a significantdistinction between the tightly and loosely configurations shows itself. Thusfor the ideal GPS satellite coverage scenario, there is virtually no difference inperformance between the two solutions. [19]

The loosely coupled configurations offer the distinct advantage of beinghighly modular in accuracy and cost. Namely because any aiding sensor can thenbe added or changed in the navigation system. Although the tightly coupledconfiguration is more robust than the loosely coupled one, it is more expensiveto implement and more difficult to develop. This thesis is based upon what canbe done in house at ÅAC today. Developing a complex integration couplingmay not be plausible for a company with the resources of ÅAC. The simplicityand modularity approach, which has been the cornerstone of this project so far,must also be assessed when choosing the INS/GPS integration method. Thetightly coupled solution would require a substantial change in the models andalgorithms of the system if the end user would wish to change to a differentaiding sensor. This approach would simply obliterate all the other modularitywork that has been put down on the architecture. The GPS system should beseen as any other module in the ÅMA architecture, and can thus become subjectof change or upgrade. The end user should not have to possess the knowledge ofcomplex integration techniques and mathematical Kalman formulas to be ableto operate the ÅMA. Hence, in this case, the loosely coupled option presentsopportunities that the tightly coupled one does not.

The use of Global Navigation Satellite Systems (GNSS) as an aiding sys-tem for inertial navigation systems has been the subject of study for a numberof years. In fact, the majority of implementations have been loosely coupled[33]. This is due to companies specializing in inertial systems developing INSunits with built in filtering techniques in a loosely coupled configuration and inturn, GNSS companies focusing on delivering state of the art GPS navigationsystems independently. Implementing a tightly coupled configuration requires

70

close collaboration with GNSS companies, since the aiding information fromthe navigation filter which is fed back to the GPS sensor assists with the satel-lite tracking algorithms. Normally, these algorithms are kept secret since thespeed of satellite reacquisition (the ability to locate and track satellites afterthey have been lost) is what separates the quality of receivers between differentmanufactures, and hence is a strong marketing tool.

Work has been carried out in [34] to implement a tightly coupled naviga-tion loop. It was observed that the benefits of implementing a loosely coupledform outweigh those of its counterpart since the increase in optimality of thetightly coupled configuration is slight (and only observed during extreme con-ditions). This was mainly due to the difficulty of developing GPS algorithmsand hardware that can be aided by navigation filters. Thus the majority ofimplementations of aiding inertial navigation systems have been loosely coupledconfigurations, and this will also be the approach chosen in this thesis.

11.3 Mathematical approach to the loosely cou-pled configuration

It is not within the scope of this report to present all the equations and the exactmathematical steps in order to integrate an INS and a GPS. Instead, the workhas been concentrated on opening a path and presenting a feasible approachfor taking it. The NFFP project spans over several years and this thesis is thefirst step in the entire endeavor. After the end of the thesis, work will continueuntil at least 2010 in order to essentially develop software and hardware for atest bed version of the ÅMA architecture. Nevertheless, a short mathematicalwalk through showing the benefits that helps keeping the ÅMA modular is givenbelow.

11.3.1 The Linear error model

When using a direct feedback to the INS, one of the possible filter modelsthat could be implemented is a “linear error model” representing the errors inthe UAV states (being generally its position, velocity and attitude). When anew inertial observation becomes available, the filter estimates the errors inthese states. Since this model is an error model of the inertial equations, theobservation z(k) is the observed error of the inertial navigation solution andnot the observation delivered by the aiding sensor. Thus if an aiding systemprovides say, position and velocity data, then the observation vector becomes;

z(k) =

(

zP (k)zV (k)

)

= (11.1)

(

P inertial(k) − P aiding(k)V inertial(k) − V aiding(k)

)

.

71

Figure 11.5: How zp & zv are obtained.

Where zp is the position data and zv the velocity data. Figure 11.5 [18]illustrates how the filter works in practice when comparing incoming INS andGPS data. The true (actual) acceleration A, velocity V and position P of thevehicle have noise v added to them to represent measurements taken by sensors.The acceleration, as measured by the INS, is mathematically integrated twiceto obtain the indicated velocity and position of the vehicle. The accelerationinformation is obtained by the accelerometers and it is assumed that accelerationdue to gravity has been compensated for. By defining the terms δP (k) andδV (k) as the position and velocity errors in the inertial data after the integrationprocess, the observation model becomes;

z(k) =

(

P inertial(k) − P aiding(k)V inertial(k) − V aiding(k)

)

= (11.2)

(

(PT (k) + δP (k)) − (PT (k) − vP (k))(VT (k) + δV (k)) − (VT (k) − vV (k))

)

=

(

δP (k)δV (k)

)

+

(

vP (k)vV (k)

)

.

It can thus be concluded that the observation is the error between the in-ertial indicated position and velocity and that of the aiding sensor. And theuncertainty in this observation is reflected by the noise of the aiding observa-tion (the last term in equation 11.2). This offers another benefit in the directfeedback implementation and involves the tuning implementation; the noise on

72

the observation is the noise on the aiding sensor. Thus once an inertial unit andprocess model is fixed then the process noise matrix Q is also fixed, and tuningthe filter is solely based on the observation noise matrix R. Here, one can di-rectly see the modular advantages of implementing a feedback structure to theINS (the case of the loosely coupled config.). Recalling the ÅMA main principle,its modularity, this solution would fit perfectly within the ÅMA frames. Thesystem designer may want to change or add an aiding sensor to the network, andlike this, he/she need only once have to set up the inertial navigation algorithmsalong with the filter code. Any external aiding can then be replaced or addedwith the only mathematical modification being the “observation noise matrix”R.

11.3.2 Determining the filter parameters

When implementing the Kalman filter, some parameters need to be obtained.Since it is a recursive filter, one can determine these parameters (often timesbeing matrices) by methods of fine tuning. For instance, the “measurementnoise covariance” or “observation noise matrix”, R, is usually measured priorto operation of the filter. Measuring R is generally simple and is done bytaking some straight off-line sample measurements which can help determinethe variance of the measurement noise.

The determination of the “process noise covariance”, Q, is usually moredifficult as one does not typically have the ability to directly observe the processthat is being estimated (by the Kalman filter). Sometimes a relatively simpleprocess model can produce acceptable results if one “injects” enough uncertaintyinto the process via the selection of Q. But in this case, one would hope thatthe process measurements are reliable enough.

In either case, whether or not a rational basis is possible for choosing theseparameters, often times superior filter performance (statistically speaking) canbe obtained by tuning the filter parameters and R and Q. The tuning is usuallyperformed off-line, frequently with the help of another (distinct) Kalman filterin a process generally referred to as system identification.

73

Chapter 12

UAV flight control on theÅMA

Now that the integration process of inertial sensors with aiding sensors havebeen cleared, we will take a step back and try to see the big picture; howthis arrangement can be utilized on the ÅMA network. When choosing anddefining the integration technique to be used, effort was put on maintaining thesimplicity and modularity of the ÅMA. This work will now give great paybackwhile defining how different navigational ÅMA modules will communicate witheach other.

12.1 Implementing multiple aiding sensors

In order to get as good estimate as possible of the vehicle dynamics, a multitudeof different sensors are required. A helicopter, for instance, does not solely relyon an INS and a GPS to be able to navigate and hold course. While inertial sen-sors such as gyroscopes and accelerometers combined with GPS measurementsgive a fair basic knowledge, the more sensors the user adds to the system, thebetter the results. An example of different aiding sensors that can be used on aUAV helicopter is given in below.

Basic:

• Gyroscope – Attitude

• Accelerometer – Velocity, position

• GPS – Position and velocity

74

Aiding:

• DGPS – Attitude (when using 2 or more receivers)

• Barometer (pressure sensor) – Altitude

• Ground laser – Altitude

• Inclinometer – Attitude

• Magnetometer – Heading

• Airspeed sensor - Velocity

By incorporating many or all of the above aiding sensors, more information isprovided for correction of errors in the inertial data given by the IMU. Addingthese sensors to the ÅMA will be relatively easy. They can either be connectedto the SpaceWire part by a SpW Bridge module, or to the CAN part througha CAN Bridge module. After connection, the respective Bridge modules can beprogrammed, through the Interface module, to receive measurements from theirhosts (i.e. the aiding sensors) and transform it to a packet that it sends to theComputational module which will then process it. Once connected, the aidingsensors will then have to become a part of the complex event of chains thatgives rise to a more reliable estimate of the UAV’s movements. This process isillustrated in figure 12.1. As can be seen, the aiding sensors do not need to havefeedback loops, all the calibration is done together with the IMU part. Supposeusing a tightly coupled configuration together with a multitude of aiding sensors,the feedback processes would load the network considerably. The preventionof this happening is the main reason why a loosely coupled configuration waschosen earlier. Each aiding sensor is now just a “dumb” sensor that sends outdata with user specified time intervals (the Bridge module can control this),making it straightforward to implement and unproblematic to configure. TheKalman filter here takes in raw IMU data and observed errors to give an optimalestimate of the vehicle state.

12.2 Measurement packets on the network

There are different techniques of solving how data packets from the sensors willbe transmitted and received through the router and over the network. Thesedifferent ways of data handling are quite dissimilar and each affect the entirestructure of the architecture in a fundamental manner. After some evaluationof different routing maneuvers, two possible options where picked and furtherdefined.

75

Figure 12.1: The concept behind integrating an IMU and multiple aiding sensorson the ÅMA.

12.2.1 INS option

Here the aiding sensor/sensors send their respective navigational data throughthe network as a packet to a INS module. In this option, the ÅMA INS module,having not only built in inertial sensors, also has its own sophisticated computa-tional power. It will receive the data from aiding sensors and will itself compareit and run it through its included Kalman integration filter. Once this is done,it will error correct the inertial part and compute a final packet with correctposition, velocity and attitude and send it to the Computational module. TheComputational module then reads this current state data and uses it to computethe next movement together with command data taken from the TMTC and/orMM modules. When the computation of the UAV’s next move is completed, itwill decide which actuators have to do what in order for the UAV to carry outthe next move. The Computational module hence translates the new commandfor each and every actuator that is necessary to make an action, see figure 12.2.Like this a full control loop of the UAV flight is completed and after a userdefined time delay the process can start over again.

12.2.2 IMU option

In this option, all the processing is done in the Computational module andhence more critical information is transferred through its network link. This isbecause the measurement data from the IMU module and all other aiding sen-sors is directly sent towards the Computational module. It gathers all data andcomputes the current and next state of the vehicle. The networking process andits corresponding steps are illustrated in figure 12.3. The main principle here isthat the IMU, being the sensor with the fastest update rate, first sends an iner-

76

Figure 12.2: ÅMA process flow in the INS option.

Figure 12.3: ÅMA process flow in the IMU option.

77

tial state to the Computational module. A short period of time later an aidingsensor (e.g. a GPS) sends more information to the Computational module, itthen compares the two to predict the current and next state through the Kalmanintegration filter. Now that the filter has two independent measurements, it cancalibrate the IMU data.

An effective solution is reached when the INS computation of the IMU datais done inside the Computational module. Like this, no return calibration datahas to be sent back to the IMU over the network, creating a more robust solutionand reliving the network of traffic. In the next step, new measurements come infrom a third aiding sensor (like an airspeed sensor). This data is incorporatedinto the model to create an even better estimate of the current state of theUAV. Thus the Kalman integration filter constantly receives new updates of thedynamic state of the UAV. Some sensors update more frequently than others,but this is not seen as a problem since the filter can manage these perturbationsand still make the best estimate based on the data at hand. This alternativedelivers the advantage of having all processing power in one and the same moduleand the disadvantage of being slightly more risky since data packets can get lostwhile transmitted on the network. On the other hand, a lot of work will be puton preventing this from happening, as described in chapter 5. In addition, theComputational module can be connected to the router via two separated SpaceWire links, in order to generate robustness, see figure 12.3.

An alternative to the above is to develop a type of “sensor box” containingmany or most of the needed inertial and aiding sensors, and have them connectedto a separate router which is in turn connected to the main Router. This can berewarding if one intends to gather all sensors in the same area, it is illustratedon the right hand side of figure 12.3.

12.2.3 A comparison

The IMU option is seen as more fruitful than the INS one since it harmonizeswith the ÅMA main guiding principle; modularity. Yet still, the INS option issimpler to design, in terms of software. Software issues may very well be thehardest part of the ÅMA to develop, due to its complex nature, coming from thedemanded implementation simplicity for the end user. Both options are seen asvalid, but if time and manpower permits, the IMU option is the recommendedsolution for flight control over the ÅMA network. If not, the INS option mightbe a good choice for a first version or test platform.

12.3 Flight control in the Computational module

Since the Computational module has become such an intricate part of the UAV’stotal architecture, its workload must be defined in detail. This section will con-centrate on the steps it has to take in order to fulfill full flight control of thevehicle, i.e. keeping it stable in flight and on course. The process is the one

78

taken if the IMU option is chosen.

The 11 basic steps go on as follows:

1. Take in IMU data.

2. Take in Aiding sensor data.

3. Transform to correct coordinate system (e.g. Quaternion).

4. Compare Aiding data with latest IMU-data.

5. Compute 4.) into Kalman integration filter to resolve current dynamicstate and error correction codes.

6. Use result of 5.) in error correcting equations.

7. Read command for next position/movement from TMTC/MM.

8. Use 5.) to compute the next move command.

9. Use 8.) and compute which actuators need to do what.

10. Translate 9.) to each corresponding actuator “language”.

11. Send result of 10.) to the equivalent actuators.

These actions can be divided into two main groups. Steps 1 to 6 all help estimatethe current dynamic state while steps 7 to 11 compute and decide the next moveto initiate, in order to hold a predefined course. It is the steps of 3, 4, 5, 6,8, 9 and 10 that are actually using the processing power of the Computationalmodule. The rest, steps 1, 2, 7 and 11 can be classed as network related tasks.

79

Chapter 13

Conclusion of part II

Part II has stated how inertial flight control can be managed on the ÅMAnetwork. From measurement gathering with the use of MEMS based inertialsensors, to a mathematical implementation of the data for finding the correctreference frame. The Kalman filter process was described, as it is a necessarystep in every inertial system. It was also suggested that several aiding sensorshelp the IMU in its estimation of the vehicle kinematics. The recommendedmethod for this integration process was determined to be a so-called looselycoupled configuration, due to its coherence with the ÅMA modularity princi-ples. Finally, the packet sending and computational processes on the ÅMAwere established. It was concluded that this can be done in two different fash-ions; either with an INS module or with an IMU module. Both options havetheir benefits but the most modular, and also complex, solution is given byhaving an IMU module. This module, together with all aiding sensors, sendsmeasurements to the Computational module that in turn does all the necessarycomputing. The computing node then directly controls the actuators and thusa full control loop is established.

80

Bibliography

[1] C. R. Spitzer. “The Avionics Handbook”, p. 534-540, CRC press, 2000.

[2] C. B. Watkings et al. “Transitioning from Federated Avionics Architecturesto Integrated Modular Avionics”, 2007. ISBN: 978-1-4244-1108-5.

[3] R. L. Alena et al.. “Communications for Integrated Modular Avionics”,NASA AMES, 2007.

[4] Ethernet, Wikipedia – the free encyclopedia, 2008-05-05,http://en.wikipedia.org/wiki/Ethernet.

[5] SpaceWire, Wikipedia – the free encyclopedia, 2008-05-05,http://en.wikipedia.org/wiki/Spacewire.

[6] Saab Aerosystems Skeldar Information Sheet

[7] S.M. Parkes et al. “SpaceWire: Links, Nodes, Routers and Networks,” Eu-ropean Cooperation for Space Standardization, Standard No. ECSS-E50-12A,Issue 1, January 2003.

[8] IEEE Computer Society, “IEEE Standard for Heterogeneous Interconnect(HIC) (Low-Cost, Low-Latency)”.

[9] Tele-communications Industry Association, “Electrical Characteristics ofLow Voltage Differential Signaling (LVDS) Interface Circuits,” StandardANSI/TIA/EIA-644 1995, March 1996.

[10] B. Cook et al. ESTEC Data Systems Workshop, May 2003, 4Links Limited.

[11] C. B. Watkins. ”Transitioning from Federated Avionics Architectures toIntegrated Modular Avionics”, GE Aviation, Grand Rapids, Michigan.

[12] FoT25 FS2020 Systemarkitektur - WP 1.2 Technology trends, April 2008,TDC-2008-0084.

[13] SpaceWire-RT Requirements, Issue 1.0, February 2008, ESA ContractNumber: 220774-07-NL/LvH.

[14] SpW and IEEE1355 Revisted, B. Cook, P. Walker, 4Links Ltd., Int SpWConference 2007.

81

[15] YAMAR Electronics Ltd., PODCAN250, Rev 1.0, 2007.

[16] CANaerospace Interface specification V. 1.7, Stock Flight Systems.

[17] ARINC 825, Innovative Control Systems, Stock Flight Systems, WetzelTechnology.

[18] S. Sukkarieh. "Low Cost, High Integrity, Aided Inertial Navigation Systemsfor Autonomous Land Vehicles", PhD thesis, University of Sydney, March2000.

[19] J. David Weiss. "Analysis of an Upgraded GPS Internal Kalman Filter",Galaxy Scientific Corporation, IEEEAES Systems Magazine, January 1996.

[20] Yong Li et al. "Low-cost tightly coupled GPS/INS integration based on anonlinear Kalman filtering design", University of New South Wales.

[21] S. Rönnbäck. "Developement of a INS/GPS navigation loop for an UAV",2000:081, ISSN: 1402-1607, ISRN: LTU-EX–00/081–SE.

[22] N. Hjortsmarker. "Experimental System for Validating GPS/INS Integra-tion Algorithms", 2005:307 CIV, ISSN: 1402-1607, ISRN: LTU-EX–05/307–SE.

[23] B. Boberg et al. "Robust Navigering - Slutrapport", Totalförsvarets forskn-ingsinstitut, ISSN: 1650-1942, FOI-R–2081–SE.

[24] M. George et al. "Tightly Coupled INS/GPS with Bias Estimation for UAVApplications", University of Sydney.

[25] J. Bernstein. “An Overview of MEMS Inertial Sensing Technology”, Feb 12003, Corning-IntelliSense Corp.

[26] J. Geen et al. “New iMEMS® Angular-Rate-Sensing Gyroscope”, ADI Mi-cromachined Products Division

[27] W.F. Phillips et al., “A Review of Attitude Kinematics for Aircraft FlightSimulation,”AIAA-200-4302

[28] Euler Angles, Wikipedia – the free encyclopedia, 2008-05-05,http://en.wikipedia.org/wiki/Euler_Angles.

[29] M. Skoglund. "Evaluating SLAM algorithms for Autonomous Helicopters",LITH-ISY-EX–08/4137–SE.

[30] P. B. V. Reddy. “FPGA based Kalman filtering for aircraft attitude andposition determination”. MSc thesis, KTH.

[31] G. Welch et al. "An Introduction to the Kalman Filter", July 24 2006, TR95-041, University of North Carolina.

82

[32] Kalman Filter, Wikipedia – the free encyclopedia, 2008-05-05,http://en.wikipedia.org/wiki/Kalman_filter.

[33] B.W. Parkinson et al. "Global Positioning System: Theory and Applica-tions". American Institute of Aeronautics and Astronautics, Inc, 1996.

[34] S. Cooper. "A Frequency Response Method for Sensor Suite Selection withan Application to High-Speed Vehicle Navigation", PhD thesis, Universityof Oxford, 1996.

[35] D. Titterton et al. "Strapdown Inertial Nevigation technology, 2nd Edi-tion". IEE Radar, Sonar and Navigation series 17, 2004.

[36] “SpaceWire-RT Initial Protocol Definition”, University of Dundee, Draft AIssue 1.1, 12th May 2008, SpW-RT WP3-200.1.

83