USF Libraries
USF Digital Collections

Implementation of unmanned vehicle control on FPGA based platform using system generator

MISSING IMAGE

Material Information

Title:
Implementation of unmanned vehicle control on FPGA based platform using system generator
Physical Description:
Book
Creator:
Murthy, Shashikala Narasimha
Publisher:
University of South Florida
Place of Publication:
Tampa, Fla
Publication Date:

Subjects

Subjects / Keywords:
FPGA
SysGen
Matlab
PID
VHDL
Dissertations, Academic -- Electrical Engineering -- Masters -- USF   ( lcsh )
Genre:
non-fiction   ( marcgt )

Notes

Abstract:
ABSTRACT: The goal of this research was to explore a new and improved software development tool for the implementation of control algorithms on Xilinx Field Programmable Gate Arrays (FPGA). The Simulink plug in, System Generator, complements traditional Hardware Description Language (HDL) by providing a higher level graphical language for the development of FPGA designs. The design is then translated into the lower level required by the Xilinx's ISE program. By utilizing this graphical based higher level of abstraction at the design entry level, the requirement of a detailed knowledge of HDL languages is no longer required. Because of this new environment the time required to implement the previously developed control design on the FPGA is reduced. The initial work began with a study of System Generator capabilities. One of the primary areas of interest is the difference on how the mathematical model representations are implemented between Simulink and the logic based hardware. From this initial work, a methodology for conversion between the developed and verified Simulink design and hardware implementation was obtained. As a case study, a control design was implemented for a Simulink model of an Unmanned Ground Vehicle (UGV) based on an RC-Truck. The control system consists of a simple mission planner to generate a vector of waypoints, a proportional-integral velocity controller and a proportional heading controller. The derived hardware design process is then utilized and validated by converting the control system into the available System Generator blocks. The final verification of the FPGA design was a hardware-in-the-loop simulation utilizing a Xilinx prototyping board. This design example demonstrated the validity of the presented approach as an efficient and reliable method for rapid system prototyping for designs developed within the Simulink environment.
Thesis:
Thesis (M.S.E.E.)--University of South Florida, 2007.
Bibliography:
Includes bibliographical references.
System Details:
Mode of access: World Wide Web.
System Details:
System requirements: World Wide Web browser and PDF reader.
Statement of Responsibility:
by Shashikala Narasimha Murthy.
General Note:
Title from PDF of title page.
General Note:
Document formatted into pages; contains 47 pages.

Record Information

Source Institution:
University of South Florida Library
Holding Location:
University of South Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
aleph - 001989376
oclc - 309145361
usfldc doi - E14-SFE0002287
usfldc handle - e14.2287
System ID:
SFS0026605:00001


This item is only available as the following downloads:


Full Text

PAGE 1

Implementation of Unmanned Vehicle Contro l on FPGA Based Platform Using System Generator by Shashikala Narasimha Murthy A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering Department of Electrical engineering College of Engineering University of South Florida Major Professor: Wilfrido Moreno, Ph.D. Kimon Valvanis, Ph.D. Paris Wiley, Ph.D. Date of Approval: October 26, 2007 Keywords: FPGA, SysGen, Matlab, PID, VHDL, Unmanned Systems Copyright 2007 Shashikala Narasimha Murthy

PAGE 2

DEDICATION I dedicate this thes is to my parents.

PAGE 3

ACKNOWLEDGEMENTS I would like to express my deep and sinc ere gratitude to my mentor and guide, Dr Wilfrido Moreno, Associate Professor in th e Department of El ectrical Engineering, College of Engineering, University of South Florida. His encouragement, motivation and personal guidance have provided a basis for the work represented in this thesis. In addition, I would like thank my comm ittee members, Dr. Kimon Valavanis and Dr. Paris Wiley for their assistance and expert ise throughout the duration of this project. My special thanks to Wendy Alvis, who di d an enormous amount of work for the Autopilot project. Her experiments and sugge stions for further development as well as her assistance during writing the thesis were invaluable to me. I also would like to than k the Ibero-American Science and Technology Education Consortium, ISTEC and Xilinx for supporting my research with the required hardware and software tools. Last, but not least, thanks to my husba nd, Praveen, for his love and support. His kindness and compassion have he lped to keep my sanity throughout the many challenges faced over the past few years.

PAGE 4

i TABLE OF CONTENTS LIST OF FIGURES ........................................................................................................... iiiABSTRACT ...................................................................................................................... .. vCHAPTER ONE INTRODUCTION .................................................................................. 1CHAPTER TWO SOFTWARE PLATFO RMS FOR SYSTEM DESIGN ........................ 42.1The MathWorks MATLAB and Simulink .............................................. 52.2Xilinx System Generator for DSP ................................................................. 52.3Xilinx ISE Overview..................................................................................... 7CHAPTER THREE FPGA PLATFORMS ......................................................................... 83.1Virtex II Pro Development Board ................................................................. 83.2Overview of Autopilot ................................................................................ 103.3Comparison of Hardware Platforms ........................................................... 12CHAPTER FOUR OVERVIEW OF RC-TRUCK MODEL/SYSTEM ........................... 134.1Forward Body-Reference Dynamics ........................................................... 134.2Motor Model ............................................................................................... 144.3Kinematic Calculations ............................................................................... 154.4Control System............................................................................................ 15CHAPTER FIVE DESIGN PROCESS ............................................................................ 185.1Timing Issues with Algebraic Loops .......................................................... 185.2Math Issues ................................................................................................. 19

PAGE 5

ii 5.3Floating to Fixed Point Conversion, Qu antization and Overflow Issues .... 205.4Timing Analysis .......................................................................................... 235.5Hardware Co-Simulation ............................................................................ 245.6Proposed Design Procedure ........................................................................ 25CHAPTER SIX TESTING A ND VERIFICATION ........................................................ 286.1Step One: Testing Control Algorithms in Simulink .................................... 286.2Step Two: Simplify Any Complex Math ................................................... 306.3Step Three: Optimize for Ha rdware Characteristics ................................... 306.4Step Four: Build and Test in System Generator ........................................ 316.5Step Five: Calculate Word Length .............................................................. 346.6Step Seven: Hardware Co-Simulation & Final Results .............................. 35CHAPTER SEVEN CONCLUSION S AND FUTURE WORK ...................................... 44REFERENCES ................................................................................................................. 46

PAGE 6

iii LIST OF FIGURES Figure 1 System Generator Block Diagram ....................................................................... 4Figure 2 Software Design Overview .................................................................................. 7Figure 3 Block Diagram of the XUP Vi rtex-II Pro Development System ...................... 10Figure 4 Autopilot Hardware Overview .......................................................................... 11Figure 5 Open Loop RC-Truck Model ............................................................................ 13Figure 6 RC-Truck System .............................................................................................. 16Figure 7 Mission Planner M-File ...................................................................................... 17Figure 8 Floating Point to Fixed Point Conversion ......................................................... 21Figure 9 Gateway In Block Settings ................................................................................ 22Figure 10 Timing Analyzer ............................................................................................... 24Figure 11 Design Flow..................................................................................................... 27Figure 12 Simulink Implementation of RC-Truck System .............................................. 28Figure 13 Mission Planner M-File ................................................................................... 29Figure 14 Star Trajectory ................................................................................................. 29Figure 15 Star Trajectory Velocity .................................................................................. 29Figure 16 Figure Eight Trajectory ................................................................................... 30Figure 17 Figure Eight Velocity ...................................................................................... 30Figure 18 System Generator Mission Planner and Heading Control ................................ 32Figure 19 System Generator Velocity Control ................................................................. 33

PAGE 7

iv Figure 20 Star Trajectory Hardware Simulation ............................................................... 33Figure 21 Star Trajectory Veloc ity Hardware Simulation ................................................ 33Figure 22 Figure Eight Trajectory Hardware Simulation ................................................. 34Figure 23 Figure Eight Velocity Hardware Simulation ................................................... 34Figure 24 Timing Analysis of RC-Truck System ............................................................ 35Figure 25 Hardware Co-Simulation Block Diagram ....................................................... 35Figure 26 Hardware Co-Simulation Module ................................................................... 36Figure 27 Star Trajectory Co-Simulation ......................................................................... 37Figure 28 Star Trajectory Velocity Co-Simulation ........................................................... 37Figure 29 Figure Eight Trajectory Co-Simulation ............................................................ 37Figure 30 Figure Eight Velocity Co-Simulation .............................................................. 37Figure 31 Simulink Star Trajectory X Vs. Error .............................................................. 38Figure 32 Simulink Star Trajectory Y Vs. Error ............................................................... 39Figure 33 Co-Simulation Star Trajectory X Vs. Error ...................................................... 39Figure 34 Co-Simulation Star Trajectory Y Vs. Error ...................................................... 40Figure 35 Simulink Figure Eight Trajectory X Vs. Error .................................................. 40Figure 36 Simulink Figure Eight Trajectory Y Vs. Error .................................................. 41Figure 37 Co-Simulation Figure Eight Trajectory X Vs. Error ........................................ 41Figure 38 Co-Simulation Figure Eight Trajectory Y Vs. Error ........................................ 42Figure 39 Errors of Star Trajectory .................................................................................. 42Figure 40 Errors of Figure Eight Trajectory .................................................................... 43

PAGE 8

v Implementation of Unmanned Vehicle Contro l on FPGA Based Platform Using System Generator Shashikala N. Murthy ABSTRACT The goal of this research was to explore a new and improved software development tool for the implementati on of control algorithms on Xilinx Field Programmable Gate Arrays (FPGA). The Simulink plug in, System Generator, complements traditional Hardware Descri ption Language (HDL) by providing a higher level graphical language for the developmen t of FPGA designs. The design is then translated into the lower level required by the Xilinx’s ISE program. By utilizing this graphical based higher level of abstraction at the design entry level, the requirement of a detailed knowledge of HDL languages is no longer required. Be cause of this new environment the time required to implement the previously devel oped control design on the FPGA is reduced. The initial work began with a study of System Generator capabilities. One of the primary areas of interest is the difference on how the mathematical model representations are implemented between Simulink and the logic based hardware. From this initial wo rk, a methodology for conversion between the developed and verified Simulink design and hardware implementation was obtained. As a case study, a control design was implemented for a Simulink model of an Unmanned Ground Vehicle (UGV) based on an RC-Truck. The control system consists of a simple mission planner to generate a vector of waypoints, a proportional-integral velocity

PAGE 9

vi controller and a proportional head ing controller. The derived hardware design process is then utilized and validated by converting the control system into the available System Generator blocks. The final verification of the FPGA design was a hardware-in-the-loop simulation utilizing a Xilinx prototyping boar d. This design example demonstrated the validity of the presente d approach as an efficient and reliable method for rapid system prototyping for designs developed within the Simulink environment.

PAGE 10

1 CHAPTER ONE INTRODUCTION Typically efficient implementation of cont rol system applications utilizing FPGAs requires a thorough understand ing of both the hardware platform and Hardware Description Language. FPGAs have always had the advantages of parallel processing and asynchronous timing capabilities. Over th e past decade both the increased number of gates and the development of new software tools have lead to a rapid increase in popularity of FPGAs. New software tools have been developed to allow for higher level abstraction in the development of the FPGA implementations. Within the past few years, Xilinx has presented and made continued improvements to a Simulink add on, System Generator, that allows the design of the hardware from within the graphical, high level Simulink environment. System Generator replaces the traditional Hardware Description Language (HDL) design, and thus does not require a de tailed knowledge of this lower level, complex language. In addition, the graphical language allows an abstraction of the design through the use of available System Generator blocks and subsystems. This reduces the time necessary between the deri vation of control design and hardware implementation. This software is extrem ely attractive because of the popularity of Simulink as tool for both modeling the physical system and testing the derived control design. It is a natural progr ession to include the hardware simulation and hardware-in-

PAGE 11

2 the-loop verification from within this environment. However, the behavior of the Simulink mathematical simulation in comparison to the hardware implementation is not an exact match. Simulink allows for floating point, complicated math to be completed within a single, virtual time step by slowing the simulation to allow for precise calculations. In addition, Simulink will adjust the size of the time step when required by the underlying calculations. By compar ison, the FPGA hardware implementation requires a pre-defined fixed time step that ope rates in real time. While rates can be adjusted at different points within the hard ware to allow for asynchronous timing, each of these rates are run at consistent time step with a fixed word length. The conversion between these two forms must be done in a systematic way that takes these differences into consideration. Thus the derivation of the hardware impleme ntation can become a difficult and frustrating task for those unfamiliar with the FPGA environment. The goal of this research was twofold, to explore this new and improved software development tool and to develop a systematic approach of conversion from the verified Simulink design to the hardware implementation. This objective can be broken further into three smaller objectives – design, impl ementation and verification. The design flow allows the developers to quickly explor e FPGA design options and to check if the resulting module fulfills the de sign constraints. The succe ssful development of such a systematic approach allows the controls engineer to follow this procedure in order to obtain a successful hardware design without extensive knowl edge in logic theory. In addition, this work compliments an FPGA base d autopilot hardware design for use with unmanned systems by simplifying the implementa tion of the controls algorithm onto an available, off-the-shelf platform.

PAGE 12

3 A case study utilizing a pre-developed Simulink system model of an Unmanned Ground Vehicle (UGV) ba sed on an RC-Truck model was completed. A Simple Mission planner to generate a vector of waypoints, a velocity PI cont roller and proportional heading controller were designed, simulated and verified within Simulink The FPGA design process was utilized in order to convert these algorith ms into the available System Generator blocks. After veri fication from the simulated ha rdware, the design was then downloaded into the prototype board cont aining a Xilinx FPGA for Hardware-in-theLoop verification. This design example de monstrated th e validity of the presented approach as an efficient a nd reliable method for rapid system prototyping of control theory in the area of unmanned systems. Chapter Two introduces the MATLAB and Simulink software environment, followed by an explanation of the workings of the toolboxes available within System Generator. Chapter Three give s an overview of the prototypi ng board utilized with this research, along with a brief description of the complimentary autopilot platform under development. An overview of the RC-Truck model, mission planner and control design is presented in Chapter Four. Chapter Five discusses the key issues with implementing control algorithms on an FPGA platform and th en presents the propos ed design approach. This approach is verified in Chapter Si x by following the spec ified procedure to implement and verify the RC-Truck control design on the FPGA prototyping board. Chapter Seven completed this presented ma terial with an overv iew of the knowledge obtained and recommendati ons for future work.

PAGE 13

4 CHAPTER TWO SOFTWARE PLATFORMS FOR SYSTEM DESIGN An efficient rapid system prototyping environment demands a feasible and efficient development environment in which the hardware and soft ware modules can be co-designed, co-debugged, and co-verified. The integrated software design platform containing MATLAB R2007a with Simulink from MathWorks, System Generator 9.2 for DSP and ISE 9.2 from Xilinx present such capabilities. Although the Xilinx ISE 9.2 foundation software is not directly utilized, it is required due to the fact that it is running in the background when the System Generator blocks are implemente d. An overview of the complete design environmen t is presented in Figure 1. Figure 1 System Generator Block Diagram

PAGE 14

5 2.1 The MathWorks MATLAB and Simulink MATLAB is an interactive software for doing numerical computations to simplify the implementation of linear algebra routines Powerful operations can be performed by utilizing the provide d MATLAB commands. Simulink is an additional MATLAB toolbox that provides for modeling, simula ting and analyzing dynamic systems from within a graphical environment. This software allows for bo th modular and hierarchical models to be developed providing the advant age of developing a complex system design that is conceptually simplif ied. Due to this modular, si mplified high level approach, Simulink has gained popularity among engineer s and researchers for development, verification and modification of control algorith ms [1]. Because of this wide-spread use, the ability to design and verify hardware implementation from within this same software environment becomes a great advantage for rapi d prototyping of new theory and designs. In addition, the capabil ity for hardware-in-theloop simulation with the Simulink plant models provides the additional benefit of this verification to take place without risking the loss of hardware. Because the software th is final verification to take place through the use of standard computer ports no additi onal data acquisition hardware is required. This presents a far more cost efficient soluti on than other methodologies It is because of these advantages that the Simulink /System Generator environment was selected as the best available development platform for this project. 2.2 Xilinx System Generator for DSP Xilinx System Generator is a MATLAB/ Simulink -based design tool for Xilinx’s line of FPGAs. Typically complicated digi tal circuits have been developed using

PAGE 15

6 multiple Hardware Description Language (HDL) modules. Because the level of abstraction is very low within the HDL environment, the difficulty increases as the design becomes more complex. These designs typically contain such considerations as feedback, word length requirements and dela ys. Because of the graphical nature of System Generator, the overall design is able to be viewed as a modular system with a high level of abstraction that does not requir e HDL code from the designer. For those designers already familiar with HDL, Syst em Generator does provide an additional capability of allowing pre-developed HDL modules to be incorporated directly into the System Generator model. In addition, the integration with Simulink provides for the hardware design and verificati on to be performed from within the same environment as the mathematical system model, reducing bo th the required design time and hardware resources [2]. Particularly relevant to this project, is the ability for the hardware-in-the-loop simulation, referred to by Xilinx as “hardware co-simulation”. The integrated Xilinx ISE software provides for an automatic generatio n of HDL code direct ly from the System Generator blocks that is then mapped to the Xilinx FPGA. This underlying code is synthesized and implemented in a Xilinx FPGA in order to perform a hardware-in-theloop verification, as defined by Xilinx as “hardware co-sim ulation”. Thus, System Generator provides engineers a sophisticated platform for developing, simulating and implementing bit-true and cycle-true models [2 ]. Figure 2 presents an overview of the software development process from within the Simulink environment.

PAGE 16

7 MATLAB/Simulink Xilinx's System Generator (Hardware Design) HDL Synthesis Simulation & Verification FPGA Implementation & Verification Simulink System Model Simulink Modelled Control System Figure 2 Software Design Overview 2.3 Xilinx ISE Overview The Xilinx Integrated Software Environment (ISE) is a powerful design environment that is working in the bac kground when implementing System Generator blocks. This software environment consists of a set of program modules, written in HDL, that are utilized to create, capture, simulate and implement digital designs in a FPGA or CPLD target device. The synthesis of these modules creates netlist files which serve as the input to the implementation module. After generating these files, the logic design is converted into a physical file that can be downloaded on the target device. The software also provides a simulation tool where the functionality, behavior and timing can be verified for users that are familiar with the ISE software.

PAGE 17

8 CHAPTER THREE FPGA PLATFORMS This research was started in combinati on with a proposed off-the-shelf autopilot hardware design. The goal of the autopilot is to both provide a flexible platform for unmanned system development and a simplif ication of algorithm implementation by allowing for the incorporation with the System Generator programming environment [3]. Because the hardware is still under developm ent, an available prototyping board was selected to provide the co-simulation plat form. This chapter discusses both the development board and the autopilot hardwa re to allow for a comparison between the research platform and the final hardware platform that will be utilized when the development has been completed. 3.1 Virtex II Pro Development Board Diligent’s Xilinx University Program Virtex-II Pro Development System, the XUP board, was selected as the hardware platfo rm for this research. The XUP board is a powerful, multipurpose and low-cost system which consists of a high performance Virtex-II Pro FPGA with PowerPC cores and a comprehensive collection of supporting components, such as on-board Ethernet device serial ports and AC97 audio codec [4]. The Virtex –II Pro FPGA consists of the following logic building blocks; 13,969 slices, 428KB distributed RAM, 136 Multiplier Bl ocks, 2448 KB of Block RAM and 2 PowerPC RISC Cores. The board provides 100MHz system clock which improves the

PAGE 18

9 performance of any complicat ed module. The development system also includes an embedded USB 2.0 microcontroller capable of communications with other USB hosts. This interface is used for programming or configuring the Virtex-II Pro FPGA in Boundary-Scan mode. Communication clock sp eeds are selectable from 750 kHz to 24 MHz.. The USB 2.0 microcontroller attaches to a desktop or laptop PC high-speed A-B USB cable. Onboard external devices such as pr ogram memory and analog to digital converters that directly connects to the FPGA are also available. Although not necessary for the co-simulation verification, these peri pheral devices can be used by defining the controls and interface logic from within the System Generator design. Because of the available program memory, the FPGA can be c onfigured by the bit stream stored within this memory during the power up phase or di rectly through the volatile internal flash memory by utilizing the embedde d USB2 high speed interface.

PAGE 19

10 AC97 Audio CODEC & Stereo Amp XSGA Video Output User LEDs (4) User Switches (4) User Push-button Switches (5) 10/100 Ethernet PHY RS-232 & PS/2 Ports (2) Serial ATA Ports (3) Multi-Gigabit Transceiver Port 2 GB DDR SDRAM DIMM Module 5V Tolerant Expansion Headers High Speed Expansion Port VIRTEX II PRO FPGA External Power Internal Power Supplies 3.3V 2.5V 1.5V CPU Debug Port 100 MHz System Clock 75 MHz SATA Clock User Clocks (2) Platform Flash Configurations (2) Platform Flash Configurations (2) Platform Flash Configurations (2) VIRTEX II PRO FPGA Figure 3 Block Diagram of the XUP Virtex-II Pro Development System 3.2 Overview of Autopilot The autopilot hardware design that is curr ently under developmen t also utilizes a Xilinx FPGA and has surrounding peripherals. However, the surrounding hardware on this design is specific for use with unmanne d systems. An overview of the peripheral hardware is presented in Figure 4. This hardware includes the following; On board pressure sensors for a m easurement of forward velocity and altitude A Field Programmable Analog Array to allow for flexibility in analog sensor inputs Digital I/O ports that can be progra mmed to accept voltage levels ranging from 1.8 to 5 volts

PAGE 20

11 Digital 3.3 Volt I/O ports for a cu stom daughter board connection SPI flash memory for data acquisitions RS232 ports that allow for communicat ion with an exte rnal processing system A built in safety switch to allow take-over of the actuators by a human pilot A standard JTAG connector for bot h programming and hardware cosimulation It was not necessary to include external pr ogram memory because the selected FPGA, the Spartan3 1400AN, has non-volatile program memory residing within the FPGA. XILINX SPARTAN3AN FPGA RS232 INTERFACE CONNECTORS TO CUSTOM BOARD SAFETY SWITCH CIRCUITRY ACTUATORS HUMAN PILOT MASTER COMPUTER ANALOG INPUTS PRESSURE SENSOR PROGRAMMABLE ANALOG CIRCUITRY [ANADIGMFPAA IC] ANALOG SIGNAL CONDITIONING A/D CONVERTER COMMUNICATION LOGIC & SIGNAL CONTROL CLOCK RS232 INTERFACE S E L E C T O R S W I T C H SIMULINK PROGRAMMING & HARDWARE-IN-LOOP ON CHIP NON-VOLATILE PROGRAM MEMORY USF SENSOR INPUTS SWITCH CONTROL CUSTOM DAUGHTER BOARD FOR EMERGENCY TAKE-OVER BY MASTER COMPUTER VARIABLE LOGIC LEVEL INPUT/OUTPUT VOLTAGE TRANSLATOR CIRCUITRY DATA ACQUISITION MEMORY Figure 4 Autopilot Hardware Overview

PAGE 21

12 The selected FPGA consists of the following logic bu ilding blocks; 11,264 slices, 32 multipliers, 176K distributed RAM, 576K RAM Block and 1,400K system gates. Although the Spartan series does not include embedded PowerPCs, Xilinx’s EDK program can be utilized to provide soft core DSPs. 3.3 Comparison of Hardware Platforms Although there are major differences in the peripherals available on the XUP board and the autopilot, the primary focu s of this work is the conversion of Simulink to System Generator, which does not utilize this hardware. Of c oncern for portability of this work to the autopilot design is the actual FP GA utilized for the hardware co-simulation. Because the extra functionality of the built in PowerPCs cannot be accessed from within System Generator, the portion of the XUP FPG A utilized in the co-simulation is similar to the autopilot FPGA in number of availa ble logic gates and ac cessible RAM. In addition both the XUP board and the autopilo t operate at a fre quency of 100 MHz. Because of the similarities of the two FPG As and the clock rate, the XUP board is a sufficient platform for developing the desi gn process that will be utilized with the autopilot in future work. In addition the work presented is general in its nature and applicable to a wide va riety of applications.

PAGE 22

13 CHAPTER FOUR OVERVIEW OF RC-TRUCK MODEL/SYSTEM A Simulink model of an RC-truck robot with Ackerman steering was developed using the equations given in [5] as the phys ical system under study. These equations can be divided into separate por tions of the overall robot m odel; the motor, the forward dynamics and the kinematics, Figure 5. MOTOR FORWARD DYNAMICS 1/s axs KINEMATICS v x RobotTmVact Y X Figure 5 Open Loop RC-Truck Model In order to complete the system, a cont rols design containing a mission planner, velocity control and heading control wh ere developed and verified within the Simulink environment. This system was then used to confirm the effectiveness of the design procedure presented in Chapter Five. 4.1 Forward Body-Reference Dynamics The primary force on the truck is the fo rward motion due to the torque produced by the motor. Other forces acting on the ro bot, such as ground re sistance, wind or uneven ground, were not included in the model. Because this work presents a study into the design of FPGA hardware implementation of the control of a pre-developed system

PAGE 23

14 model, the simplifications are acceptable. The calculation of the force providing movement in the forward direction is given in Equation(4.1) where Te(t) is the torque produced by the motor, Nmw is the motor to wheel ratio and r is the radius of the tire. The forward body-reference velocity is obtained by integrating this force and dividing by the mass of the vehicle, Equation(4.2). mw() Nre xTt F(t) (4.1) 0() () Mt x xFt Vtdt (4.2) 4.2 Motor Model Equations(4.3),(4.4) and (4.5) are used to model the electric motor of the RCtruck. The input variable, or control variab le, is the motor voltage. The output of the motor model is the torque that is applied to the drive train of the RC-truck. The constants relating to the motor specificati ons are as follows; R is the electrical resistance, L is the electrical inductance, Kt is the motor torque constant, Kv is the motor voltage constant, and J is the motor inertia. The motor variables are the current, i(t) the angular velocity, (t) the input voltage Vin(t) and the output torque, Te(t) v() R1 ()() LKLLinVt di(t) itt dt (4.3) tvKK () ()() JJ dt itt dt (4.4) t()K()eTtit (4.5)

PAGE 24

15 4.3 Kinematic Calculations Kinematic equations for a bicycle model have been used to convert the motion along the x-body axis to robot’s position in the world reference frame. These equations are given in Equations ( 4.6), (4.7), and (4.8) where vs(t) is equal to the velocity in the body reference frame, L is the distance betwee n the center of the fr ont and back wheels, s(t) is the steering angle of the front tires, and (t) is the heading in the world reference frame. In addition, the steering an gle of the truck has been limited to +/-30 degrees due to the physical limitations of Ackerman steering. 0()()cos(())cos(())t ss X tvtttdt (4.6) 0()()cos(())sin(())t ssYtvtttdt (4.7) 0() ()sin(()) Lt s svt ttdt (4.8) 4.4 Control System The control system comprises of a missi on planner, a heading controller and a velocity controller, Figure 6. The velocity c ontroller is proportional-integral (PI) control, Equation(4.9) with the proportional gain, KP equal to 0.15 and the integral gain, KI, equal to 0.002. The error between a measured pro cess variable and a de sired set point is corrected by choosing gain parameters appr opriately. The proportional gain determines the reaction to the current erro r and the integral gain determines the reaction based on the sum of recent errors. The heading control is a proportional contro ller, Equation(4.10), with KP equal to 1. This forces the wheels to tu rn in the direction of the error. With a

PAGE 25

16 large error the turning angle is limited to the maximum 30 degrees, which is representative of the true behavior of the vehicle. PIK()K() etetdt (4.9) PK() et (4.10) The mission planner is contained in a si ngle m-file, given in Figure 7. The individual way points are contained two vectors, Xtraj and Ytraj, with the index of the arrays as the way point number. The distance is calculated so that when the robot is close to the current way point, the next way point is sent out as the mission planner as the X and Y position set point. RC-TRUCK MODEL vx Robot Y X PIvx Set Point +WAY POINT GENERATOR P ATAN2 + ++spXtraj Ysp Figure 6 RC-Truck System

PAGE 26

17 Figure 7 Mission Planner M-File

PAGE 27

18 CHAPTER FIVE DESIGN PROCESS Several issues create difficulties in the process of converting the Simulink design to the FPGA implementation due to the underlying hardware characteristics of the available System Generator blocks. The desi gner must give careful consideration to certain issues such as timing synchronization, delays associated with complicated mathematical calculations, and conversion to fixed point. After c onsideration of these issues and the tools provided by System Gene rator, a design procedure was derived for systematically converting the Simulink design into System Ge nerator blocks. This chapter discusses each of these issues, the Sy stem Generator tools available and presents a detailed overview of the method for deve lopment of the hardware implementation. 5.1 Timing Issues with Algebraic Loops In the design of the mathematical algor ithms, there are times when the result of one calculation must be returned to use in a comparison or cumulative type calculation. This is done in the context of an algebraic feedback loop. Logic gates that occur within this loop may have an associated delay that wi ll affect the stability of the system that was not present in the Simulink mathematical model. For example, within the truck control system, the set point number is held in a register then returned to the m-file controlling the way point generation, creating a de lay of one hardware clock cycle.

PAGE 28

19 5.2 Math Issues System Generator provides a math block set that includes standard functions that carry only small delay because of both the e fficient algorithms that underlie the blocks and the simplicity of the math itself. This block set includes calculations such as add, subtract, shift, multiply, divide by 2n, and the cosine and sine function. These functions can be included within the system with only a slight delay that can be easily compensated for with careful timing synchronization. A second mathematical block set is pr ovided that contains the Coordinate Rotation Digital Computer (CORDIC) algorit hms for a few calculations that are not easily translated to the gate level. The prov ided blocks are for the division, log, sine, cosine, square root and inverse tangent fu nctions. These CORDIC algorithms utilize coordinate rotations as the basis for an it erative method for the calculation of more complex math functions [6]. It is particularly suited to hardware implementations because it does not require any multipli es. CORDIC revolves around the idea of "rotating" the phase of a complex number, by multiplying it by a succession of constant values. However, the "multiplies" can all be po wers of 2, so in binary arithmetic they can be done using just shifts and adds; no act ual "multiplier" is needed. These provided blocks must be used with care due to the longer potential delay that may occur. Within the blocks there are settings that allow the user to compromise between accuracy and hardware usage. The user may select the number of number of processing elements, the input data word length, and the latency for each processing element. Although there is no clear cut process for se lecting this, running a few simulations with varying selections will allow a good estimation.

PAGE 29

20 Although time and resource consuming ma th cannot always be avoided, certain considerations can be taken to minimize this cost. Whenever a divide by can be replaced by a divide by 2n, this should be considered. For exampl e, if a series of sensor readings are to be averaged, selecting a 2n value should prove sufficient. In addition, selecting the minimum number of processing elements and shortest delay for the required precision within the CORDIC blocks w ill also reduce the cost. 5.3 Floating to Fixed Point Conversion, Quantization and Overflow Issues The FPGA requires fixed point arithmetic that must be defined during the hardware design phase. However, a great deal of flexibility is provided by allowing the definition of signed or unsigned, word le ngth and binary point position at any point within the logic design flow. In order to determine these settings, the designer must weigh the necessary precision against increased logic and potential dela ys associated with long word length. FPGAs handle the signed numbers the same manner as a microprocessor. The signed number is represented as twos compleme nt using a binary sequence of 1’s and 0’s. It is the designer’s responsibi lity to select whether or not to utilize the signed extension bit in any selected design environment, in th is case System Generator. A simple solution is to sign extend as a general rule. In many cases, since this only requires one additional bit, this provides the best solution. Because MATLAB/ Simulink uses floating point representation any N-bit number can have any value from -2N-1 to +2 N. The standard format assigns an N value of 32 which is able to provide a fractional resolution as small as 1/2N, equal to 2.3283(10-10),

PAGE 30

21 when all the bits are assigned to the binary point. The only way to assign this type of resolution throughout the fixed point design is to alloca te 64-bits with 32 for the binary point. This cannot be implemented in the fixed point hardware and still maintain hardware and timing efficiency. For this reason, all the values in logic must be represented in a smaller pre-de fined word length. Figure 8 demonstrates the conversion of floating point number into fixed. The d ecimal in the top number will adjusts as the size of the number changes. When converte d to the lower representation, the decimal maintains the same position, creating potential issues when the number is either too large or too small to be accurately represented. Figure 8 Floating Point to Fixed Point Conversion The conversion from floating point to fixedpoint is not a lossless transition. Two phenomena can occur, called overflow and quantization. Quantization can be handled in two ways, either truncation which discards the bits to the righ t of the most significant bit after the number of decimal value or r ounding which estimates to the nearest representable value. Overflow occurs when the resulting output from mathematical calculation lies outside the range of the fi xed-point representation set. The System

PAGE 31

22 Generator blocks allow for the output values be either saturated, where the MSB’s are neglected, or wrapped to the nearest value. Within the System Generator blocks, fields are available to select the necessary settings to control the hardware with respect to word length. Using these settings the designer can choose the required type of fixed point number (signed/unsigned or Boolean), width and the position of the least significant count of decimal point. For example in the ‘gateway in’ block settings, Figure 9, 16 is written in the ‘no of bits field’ and 8 to the ‘binary point’ field. This dire cts System Generator to create a 16-bit fixed point number with eight bits reserved for the fractional portion. Figure 9 Gateway In Block Settings In terms of hardware usage, the saturate and truncate selectio ns are preferable because they use less hardware resources as compared to round and wrap. In addition, if the word length is selected only to reflect th e necessary precision, rather than all possible values, wrap should be avoided due to roll-over to the zero value on overflow.

PAGE 32

23 Several iterations may be required to fine tune each block in the system until both acceptable amounts of quantization error resu lts and overflow is eliminated. This iterative analysis of quan tization and overflow, along w ith verification within the Simulink environment, results in a hi gh level software design tool. 5.4 Timing Analysis While the system generator blocks produce a bit and cyclic true simulation, they do not take into account the timing issues that may occur when converted and download to the hardware implementation. This is an advantage because it allows testing the System Generator design before optimizing for speed and hardware usage. However, before finalization, the design must be chec ked with respect to th e processor and clock speed to be sure that all timing constraints are met. Timing violations occurs when the signal form one synchronous output stage does not reach the input of the next stage within the required time allocated by the system design. The System Generator timing analysis t ool is provided to assist with this aspect of the hardware design. It provides a report on any slow paths within the design flow and clearly displays the specific paths that will fail in hardware. When the timing analysis is invoked from the System Generator block, the design is compiled, netlisted into HDL source and a timing analysis run. The results appear in the System Generator timing analyzer tool, Fi gure 10. Selecting the histogram displays a detailed chart providing the path timing information. In addition, this display will highlight each path that does not meet the specifications. The trace icon provides the details about each specific path analyzed.

PAGE 33

24 Figure 10 Timing Analyzer Once an issue is discovered both replic ation of registers an d increased control over sampling time can be utilized for correction. Replication is often performed automatically by the tools in order to reduce the capacitance of the neat, which in turn reduces the net delay. While adding these pipelining registers does increases latency and the number of logic gates; it should be seen that this provides a ba lance to other portions of the design and also reduces the fan out on the replicated objects. Up-sample and down-sample blocks can be included to be sure that those portions of the design that can be operated at a slower rate are calculated th is reduced rate. If these blocks are not used, then the timing analyzer will generate the over constraint error. 5.5 Hardware Co-Simulation After the System Generator model is verified through both simulation and a timing analysis, hardware co-simulation shou ld be performed in order to validate the design operating on the FPGA platform. The co-simulation process uses Xilinx IS E and core generator to synthesize and generate an FPGA programming bit file from th e System Generator blocks in the design.

PAGE 34

25 A new system block is genera ted called ‘JTAG co-sim block’ This block replaces the previously used System Generator design. The hardware implementation is then executed by connecting the board to the PC, thereby, closin g the loop. When the model is run, a pearl script links the Xilinx ISE an d the core generator software. The Xilinx ISE program then generates the bit file and loads it into FPGA through a standard JTAG connection. There are two selections for the System Generator Hardware co-simulation, the single-step mode and free running mode. In free-running mode, the FPGA is under the control internal clock signal on the hardware platform. In single-step mode the hardware receives the clock signal through the JTAG connection which is synchronized to the simulation environment. This allows the co-simulation operating in this mode to be bit-true and cycle true [7] to the original design while allowing the correct timing to occur between the simulated plant and the logic gates within the FPGA. For this reason, the single step mode must be selected when working with a Simulink system model. 5.6 Proposed Design Procedure The design process is an iterative one th at requires revision s and re-testing, see Figure 11. The hardware desi gn process begins once the Simulink model containing mathematical algorithm used to control the system has been verified. Before the hardware model is build consid eration must be given to any potential simplification of complicated math to help prevent potential timing issues. This modification should be made and re-verified within the Simulink blocks before beginning the hardware phase. Once any mathematical modifications have checked, the design can

PAGE 35

26 be optimized for hardware and build with the provided System Generator blocks. The most efficient approach is to look for any eff ective modularity to the original design that can be brought into the hardware blocks and tested a portion at a time. This optimization of hardware involves breaking any long m-file code into smaller blocks and looking for any mathematical functions that can run in parallel. Once the System Generator model is developed, an initial check for potential timing synchronization issues should be completed, in particular with algebraic loop s. In addition sampling rates at different stages of the hardware flow should be c onsidered and ‘sample-up’ and ‘sample-down’ blocks inserted where necessary. At this stage of the design de velopment, the word length does not necessarily need to be c onsidered. Because the timing issues are dependent on the clock rate and specific hardware, the hardware simulation process will allow for more flexible test of the hardware design. Once the general design is verified, then the word length can be minimized in or der reduce the amount of logic gates required and reduce the chances of timing issues. Once the word length modifications are checked, then a timing analysis can be r un and, after any nece ssary corrections, a hardware co-simulation test can be performed.

PAGE 36

27 Figure 11 Design Flow SIMULINK TEST OF SYSTEM UNDER DESIGN DESIGN VERIFIED? REVISESYSTEM DESIGN CAN MATH BE SIMPLIFIED? YES NO OPTIMIZE FOR HARDWARE TEST SYSTEM GENERATOR DESIGN DESIGN VERIFIED? YES NO NO OPTIMIZE WORD LENGTH & TEST IN SIMULATION YES DESIGN VERIFIED? NO TIMING ANALYSIS TIMING VERIFIED? YES HARDWARE CO-SIMULATION DESIGN VERIFIED? DESIGN COMPLETE NO NO YES YES

PAGE 37

28 CHAPTER SIX TESTING AND VERIFICATION The design procedures were applied to th e RC-Truck system presented in Chapter Four. This resulted in a systematic conversi on of the tested control design into System Generator blocks, simulation and modification of these blocks and a fi nal verification of the design utilizing co -simulation. This chapter presen ts the work done in each of the design flow steps along with the results pres ented by the final hardware co-simulation. 6.1 Step One: Testing Control Algorithms in Simulink Figure 12 presents the Simulink model containing the RC-Truck model, the mission planner, the heading control and veloci ty control. The system was tested in the variable time step setting of Simulink and proved to work properly as demonstrated in Figure 14, Figure 15, Figure 16, and Figure 17. MISSION PLANNER CALCULATING HEADING SET POINT VELOCITY PIHEADING PROPORTIONAL CONTROLLER RC-TRUCK MODELFigure 12 Simulink Implementation of RC-Truck System

PAGE 38

29 Figure 13 Mission Planner M-File -100 -50 0 50 100 -100 -50 0 50 100 Trajectory One X-Coordinate (meters)Y-Coordinate (meters)Figure 14 Star Trajectory 0 1 2 3 4 x 104 0 0.5 1 1.5 2 2.5 3 3.5 Trajectory One Velocity Time Step (10 mSec)Velocity m/Sec Figure 15 Star Trajectory Velocity

PAGE 39

30 -100 -50 0 50 100 -100 -50 0 50 100 Trajectory Two X-Coordinate (meters)Y-Coordinate (meters) direction simulation path way points Figure 16 Figure Eight Trajectory 0 0.5 1 1.5 2 x 104 0 0.5 1 1.5 2 2.5 3 3.5 Trajectory Two Velocity Time Step (10 mSec)Velocity m/SecFigure 17 Figure Eight Velocity 6.2 Step Two: Simplify Any Complex Math A potential simplification is the removal of the square root function utilized when calculating the distance. This function is a po tential issue because it requires utilizing the ‘cordic sqrt’ block which, not onl y utilizes quite a bit of logi c gates, but has a long delay associated with it which would occur within an algebraic loop. Because the distance is only used as a measure for determining when to increment to the next way point, an acceptable approximation can be obtained ut ilizing Equation(6.1). The simulation was re-run to confirm this a nd presented good results. 6.3 Step Three: Optimize for Hardware Characteristics The m-file utilized for generating the way points contains the calculations for the approximation of the distance to the way po int. The squared terms shown in Equation (6.1) can be calculated in parallel. For this reason, this equation was removed from the embedded m-file and calculated wi th System Generator blocks.

PAGE 40

31 22()()spspdXXYY (6.1) The mission planner must calculate the next way point from the current position. This creates a feedback loop that may creat e some timing issues. This must accounted for when converting to System Generator bl ocks. The memory block was replaced by a register, which essentially works the same, except the register adds a delay of one time step. The sampling time of the input port, 0.1 sec, sets the rates of following the blocks, including the register. In order for the position set points to ‘line up’ with respect to the correct samples of the robot position, X and Y, a delay of one time step must also be added to both of these paths. This was accomplished by utilizing two register blocks. When the PI controller was implemented with Simulink blocks, the provided PID block was used with the derivative gain set to zero. This block utili zes the correct digital algorithms and time step in order to appr oximate the continuous time calculations. However, implementing this controller in th e hardware FPGA requires a digital version because a PID block is not prov ided by System Generator. The integral portion of the controller requires a digital integration algorithm, which is more complicated than the proportional which only requires a simple multip lication. The standard trapezoidal rule is implemented for the integral calculation. The controller al gorithm is given in Equation(6.2), where KP is the proportional gain and KI is the integral gain. PI[K+K]() 1 z E z z (6.2) 6.4 Step Four: Build and Test in System Generator The System Generator was developed in two steps, first the heading control, Figure 18, and then the velocity control logic, Figure 19. This system was tested using

PAGE 41

32 word lengths of 64 bits, with 32 allocated to the decimal portion a nd the most significant bit as the sign bit. While th is would result in an excessive use of resources and more than likely cause issues with timing in the hardware, it allows a verificati on of the logic design before reducing the word length. An additional a change was made from the Simulink model within the register holding the set point number. This valu e was started at -1 because the delay in the loop cau ses the set point to be incremented immediately. This is due to the multiplier’s initial output of 0. Sett ing the initial set point number to be equal to -1, allows a value of 0 as the starting point causing the model to start at the first way point setting. It is also important to note that System Generator starts the vector numbering at 0, rather th an the value of 1 used by Simulink MISSION PLANNER CALCULATING HEADING SET POINT HEADING CONTROLLER Figure 18 System Generator Mission Planner and Heading Control

PAGE 42

33 CALCULATE ERROR P*ERROR I*INTEGRAL OF ERROR Figure 19 System Generator Velocity Control The developed System Generator was simu lated to test the hardware design before modifying the word size, Figure 20-Figu re 23. It was noticed that there was a difference in the behavior of the velocity cont roller. It was determined that this was due to the sampling time characteristics of the digital implementation. The digital version had more of an overshoot and slightly quick er response, but stil l performed well. -100 -50 0 50 100 -100 -50 0 50 100 Trajectory One X-Coordinate (meters)Y-Coordinate (meters) direction simulation path way points simulated hardware path Figure 20 Star Trajectory Hardware Simulation 0 1 2 3 4 x 104 0 0.5 1 1.5 2 2.5 3 3.5 Time Step (10 mSec)Velocity m/SecTrajectory One Velocity simulation velocity simulated hardware velocity Figure 21 Star Trajectory Velocity Hardware Simulation

PAGE 43

34 -100 -50 0 50 100 -100 -50 0 50 100 Trajectory Two X-Coordinate (meters)Y-Coordinate (meters) direction simulation path way points co-sim path Figure 22 Figure Eight Trajectory Hardware Simulation 0 0.5 1 1.5 2 x 104 0 0.5 1 1.5 2 2.5 3 3.5 Time Step (10 mSec)Velocity m/SecTrajectory Two Velocity simulation velocity co-sim velocity Figure 23 Figure Eight Velocity Hardware Simulation 6.5 Step Five: Calculate Word Length The goal in determining the word length is to use the minimum length while still achieving the necessary accuracy. The input ports through which X and Y are sampled allow were first considered. It is sufficien t for the RC-Truck to travel within a meter’s accuracy, for this reason the decimal accuracy was limited to 1/(24). Because X and Y are limited to approximately +/-100 by the pred efined trajectory area, a word length of 12 is sufficient. This allows for the 4 binary bits, 7 bits to allow for a maximum magnitude of 128 and a sign bit. The velocity input port along with the controller blocks were set to 32 bits, with 16 allocated to the decimal and the highest bit for the sign bit. The longer word length was selected due to the potential variation in values within the velocity controller calculations. A timi ng analysis was run, and indicat ed that the design met all timing constraints, Figure 24. Had the timing failed for the paths within the velocity controller, the word length could have been iteratively reduced until satisfactory results obtained.

PAGE 44

35 Figure 24 Timing Analysis of RC-Truck System 6.6 Step Seven: Hardware Co-Simulation & Final Results The final verification was completed by im plementing the hardware co-simulation of the system, Figure 25. By selecting the XUP platform and implementing the ‘generate’ a new hardware co-simulation block is automatically. A Simulink library is created where the hardware co-simulation block present, Fi gure 26. This block is copied into the Simulink project file replacing all the X ilinx System Generator blocks. RC-Truck Model Running in Simulink Velocity, Position & Heading Sent to FPGA Board Mission Planner & Controllers in FPGA Motor & Steering servo signals sent back to helicopter model Figure 25 Hardware Co-S imulation Block Diagram

PAGE 45

36 Post-generation script creates a new library containing a parameterized run-time co-simulation Figure 26 Hardware Co-Simulation Module The port names on the hardware co-simul ation block are matched to the port names on the original subsystem. The port types and rates also match the original design. When a value is written to one of the block's input ports, the block sends the corresponding data to the appropriate location in hardware, the controller output from the hardware is read back into the Simulink module using the USB interface, the output port converts the fixed data type into the Simulink format and fed into the model. The output plots generated is similar to the simulation path The controller in co-simulation is tested for two different paths and the results in bot h the cases are shown in Figure 27, Figure 28, Figure 29 and Figure 30.

PAGE 46

37 -100 -50 0 50 100 -100 -50 0 50 100 Trajectory One X-Coordinate (meters)Y-Coordinate (meters) direction simulation path way points simulated hardware path Figure 27 Star Trajectory Co-Simulation 0 1 2 3 4 x 104 0 0.5 1 1.5 2 2.5 3 3.5 Time Step (10 mSec)Velocity m/SecTrajectory One Velocity simulation velocity simulated hardware velocity Figure 28 Star Trajectory Velocity CoSimulation -100 -50 0 50 100 -100 -50 0 50 100 Trajectory Two X-Coordinate (meters)Y-Coordinate (meters) direction simulation path way points co-sim path Figure 29 Figure Eight Trajectory CoSimulation 0 0.5 1 1.5 2 x 104 0 0.5 1 1.5 2 2.5 3 3.5 Time Step (10 mSec)Velocity m/SecTrajectory Two Velocity simulation velocity co-sim velocity Figure 30 Figure Eight Velocity CoSimulation In addition the differences in error between the Simulink and FPGA implementation are also considered. The Simulink system outperformed the hardware implementation. This finding is not unexpect ed and can be typical of the hardware implementations due all the issues previously discussed. The goal of a designer is not to design a perfect system, but meet design specifications within a compromise between resources and precision. Had the hardware re sults not been acceptable, then the process would include iterations until the best comp romise found. Figure 31 through Figure 38

PAGE 47

38 demonstrate that for both the Simulink and hardware implementation, the error is less than two meters just before a way point upda te. This indicates that the robot comes within 2 meters for each way point along the trajectory. Because the error jumps to a high value each time a new way point is implement as the X and Y set points, it is difficult to ge t a feel for the differences in error between the two implementations. In order to more accurately compare the errors, the vectors containing the magnitude of th e errors was sorted in desc ending order and plotted in Figure 39 and Figure 40. 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 -100 -50 0 50 100 Time Step (10 mSecMetersX-Trajectory for Simulation X Set Points X Trajectory 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 0 0.5 1 1.5 2 Magnatude of Error < 2 MeterMetersTime Step (10 mSec) Figure 31 Simulink Star Trajectory X Vs. Error

PAGE 48

39 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 -100 -50 0 50 100 Time Step (10 mSec)MetersY-Trajectory for Simulation Y Set Points Y Trajectory 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 0 0.5 1 1.5 2 Magnatude of Error < 2 MeterMetersTime Step (10 mSec) Figure 32 Simulink Star Trajectory Y Vs. Error 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 -100 -50 0 50 100 Time Step (10 mSec)MetersX-Trajectory for Co-Simulation X Set Points X Trajectory 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 0 0.5 1 1.5 2 Magnatude of Error < 2 MeterMetersTime Step (10 mSec) Figure 33 Co-Simulation Star Trajectory X Vs. Error

PAGE 49

40 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 -100 -50 0 50 100 Time Step (10 mSec)MetersY-Trajectory for Co-Simulation Y Set Points Y Trajectory 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 0 0.5 1 1.5 2 Magnatude of Error < 2 MeterMetersTime Step (10 mSec) Figure 34 Co-Simulation Star Trajectory Y Vs. Error 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 -100 -50 0 50 100 Time Step (10 mSecMetersX-Trajectory for Simulation X Set Points X Trajectory 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 0 0.5 1 1.5 2 Magnatude of Error < 2 MeterMetersTime Step (10 mSec) Figure 35 Simulink Figure Eight Trajectory X Vs. Error

PAGE 50

41 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 -100 -50 0 50 100 Time Step (10 mSec)MetersY-Trajectory for Simulation Y Set Points Y Trajectory 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 0 0.5 1 1.5 2 Magnatude of Error < 2 MeterMetersTime Step (10 mSec) Figure 36 Simulink Figure Eight Trajectory Y Vs. Error 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 -100 -50 0 50 100 Time Step (10 mSec)MetersX-Trajectory for Co-Simulation X Set Points X Trajectory 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 0 0.5 1 1.5 2 Magnatude of Error < 2 MeterMetersTime Step (10 mSec) Figure 37 Co-Simulation Figure Eight Trajectory X Vs. Error

PAGE 51

42 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 -100 -50 0 50 100 Time Step (10 mSec)MetersY-Trajectory for Co-Simulation Y Set Points Y Trajectory 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 x 104 0 0.5 1 1.5 2 Magnatude of Error < 2 MeterMetersTime Step (10 mSec) Figure 38 Co-Simulation Figure Eight Trajectory Y Vs. Error 0 0.5 1 1.5 2 2.5 3 3.5 x 104 0 20 40 60 Magnatude of Error in Descending OrderMetersSample Number Y Simulation Error X Simulation Error Y Co-Simulation Error X Co-Simulation Error Figure 39 Errors of Star Trajectory

PAGE 52

43 0 0.5 1 1.5 2 2.5 3 3.5 x 104 0 10 20 30 40 50 60 Magnatude of Error in Descending OrderMetersSample Y Simulation Error X Simulation Error Y Co-Simulation Error X Co-Simulation Error Figure 40 Errors of Figure Eight Trajectory

PAGE 53

44 CHAPTER SEVEN CONCLUSIONS AND FUTURE WORK This rapid prototyping de sign flow was initiated from the idea proposed by the team of researchers from unmanned system s lab for developing a FPGA based autopilot system for research and development across mu ltiple platforms. The work presented is intended to compliment this hardware platfo rm by providing a systematic approach for converting designs that have been built and tested in Simulink to FPGA hardware implementation. Utilizing the System Generator Environment allows the software developers to explore the design options in terms of size an d speed to fulfill the design constraints. This is due to the fact that system generator allows the algorithms designed to be implemented from within the Simulink environment. This allows the designer the flexibility to analyze the issu es that causes the error when the design is transferred from the MATLAB simulation to the FPGA. While the initial concept seems a simple one, the distinct differences between the FPGA hardware behavior and the Simulink simulation environment can make this a difficult task for those unfamiliar with logic/FPGA design. This research has, not only analyzed and di scussed these differences, but in addition, has developed a systematic approach to the design process. Util izing the presented methodology, along with the gr aphical System generator environment, is extremely simple as compared to the manual conversi on when done using a hardware description

PAGE 54

45 language. In addition the design process was verified by utilizing it to convert an RCTruck control system into system generato r blocks and then su ccessfully running a hardware-in-the-loop simulation. While this work has demonstrated the e ffectiveness and efficiency of System Generator for the rapid systems prototyping of control systems on FPGAs, the process is still not a simple one. As the systems become more complex, for example, the inclusion of a Kalman Filtering for sens or integration and more comple x controllers such as model predictive or sliding mode control, the conve rsion from m-file to simplistic graphical math blocks and fixed point also becomes much more difficult. Within the past few years Xilinx has also included AccelD SP to its line of software packages. This software provides assistance to the desi gner by converting a floating point MATLAB m-file to a fixed point Simulink block by running numerous iterati ons and comparisons to provided m-file input and output data. Future work s hould include research into this software to learn of the capabilities and potentially in corporate into the design flow for further simplification of this rapid system prototyping approach.

PAGE 55

46 REFERENCES [1] Mathworks, http://www.mathworks.com. [2] Xilinx, "User's Guid e for Xilinx System Generator for DSP," 2006. [3] W. Alvis, S. Murthy, K. Valavani s, W. Moreno, S. Katkoori, and M. Fields, "FPGA Based Fl exible Autopilot Platform for Unmanned Systems," presented at 15th Medite rranean Conference on Control and Automation, Athens, Greece, 2006. [4] Xilinx, "Xilinx University Program Virtex II-Pro Development System, Hardware Reference Manual." [5] L. Barnes, W. Alvis, M. Fiel ds, K. Valavanis, and W. Moreno, "Heterogeneous Swarm Formation C ontrol Using Bivariate Normal Functions," IEEE Workshop on Distributed Systems: Collective Intellegence and Its Applications pp. 85-94, 2006. [6] R. Andraka, "A Survey of CORDIC Algorithms for FPGAs," presented at Proceedings ACM/SIGDA Conference Si xth International Symposium on Field Programmable Gate Arrays 1998. [7] G. D. Michell and R. K. Gupt a, "Hardware/software co-design," Proc. IEEE vol. 85, pp. 349-365, 1997. [8] D. N. Borys and R. Colgren, "Advances in Intellegent Autopilot Systems for Unmanned Aerial Vehicles," 2004 IEEE International Conference on Industrial Technology pp. 1394-1397, 2002. [9] G. Brandmayr, G. Humer, and M. Rupp, "AUTOMATIC COVERIFICATION OF FPGA DESIGNS IN SIMULINK." [10] C.A.Wisknesky, "Analysis of Xilinx FPGA Architecture and FPGA Test: A Basis for FPGA Enhanced D SP Algorithmic Acceleration and Development in Matlab/Simulink via Xilinx System Generator," Binghamton University, State Universi ty of New York, Master Thesis 2004. [11] B. Dhillon, "Optimization of DS SS Receivers Using Hardware-in-theLoop Simulations," The University of Tennessee 2005.

PAGE 56

47 [12] G. Gateau, A. M. Lienhardt, and T. Meynard, "Digital sliding mode observer implementation using FPGA," IEEE Trans. Ind. Electron. vol. 54, pp. 867-880, 2003. [13] T. H. S. Li, C. Shih-Jie, and C. Yi-Xiang, "Implementation of humanlike driving skills by autonomous fuzzy behavior control on an FPGAbased car-like mobile robot," IEEE Trans. Ind. Electron. vol. 50. [14] E. Monmasson and M. N. Cirs tea, "IEEE FPGA Design Methodology for Industrial Control Systems—A Review," IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS vol. 54, 2007. [15] Xilinx, "Presentati on Material & Lab Files." [16] Xilinx, "Processing with FPGAs Workshop," www.xilinx.com [17] Xilinx, "Xilinx University Progra m Virtex II-Pro Development System, Hardware Reference Manual." [18] Xilinx, "User's Gu ide for Xilinx System Generator for DSP," 2006. [19] Y.-J. Yang, J.-P. Chen, J.-S. Cheng, C. Zhang, and Y.-L. Xiao, "Autonomous Micro-Helicopter Control Based on Reinforcement Learning with Replacing Eligibility Traces," Proceedings of the First International Conference on Ma chine Learning and Cybernetics pp. 860864, 2002.


xml version 1.0 encoding UTF-8 standalone no
record xmlns http:www.loc.govMARC21slim xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.loc.govstandardsmarcxmlschemaMARC21slim.xsd
leader nam 2200385Ka 4500
controlfield tag 001 001989376
005 20090218075156.0
007 cr mnu|||uuuu
008 090218s2007 flu s 000 0 eng
datafield ind1 8 ind2 024
subfield code a E14-SFE0002287
035
(OCoLC)309145361
040
FHM
c FHM
049
FHMM
090
TK145 (Online)
1 100
Murthy, Shashikala Narasimha.
0 245
Implementation of unmanned vehicle control on FPGA based platform using system generator
h [electronic resource] /
by Shashikala Narasimha Murthy.
260
[Tampa, Fla ]:
b University of South Florida,
2007.
500
Title from PDF of title page.
Document formatted into pages; contains 47 pages.
502
Thesis (M.S.E.E.)--University of South Florida, 2007.
504
Includes bibliographical references.
516
Text (Electronic thesis) in PDF format.
3 520
ABSTRACT: The goal of this research was to explore a new and improved software development tool for the implementation of control algorithms on Xilinx Field Programmable Gate Arrays (FPGA). The Simulink plug in, System Generator, complements traditional Hardware Description Language (HDL) by providing a higher level graphical language for the development of FPGA designs. The design is then translated into the lower level required by the Xilinx's ISE program. By utilizing this graphical based higher level of abstraction at the design entry level, the requirement of a detailed knowledge of HDL languages is no longer required. Because of this new environment the time required to implement the previously developed control design on the FPGA is reduced. The initial work began with a study of System Generator capabilities. One of the primary areas of interest is the difference on how the mathematical model representations are implemented between Simulink and the logic based hardware. From this initial work, a methodology for conversion between the developed and verified Simulink design and hardware implementation was obtained. As a case study, a control design was implemented for a Simulink model of an Unmanned Ground Vehicle (UGV) based on an RC-Truck. The control system consists of a simple mission planner to generate a vector of waypoints, a proportional-integral velocity controller and a proportional heading controller. The derived hardware design process is then utilized and validated by converting the control system into the available System Generator blocks. The final verification of the FPGA design was a hardware-in-the-loop simulation utilizing a Xilinx prototyping board. This design example demonstrated the validity of the presented approach as an efficient and reliable method for rapid system prototyping for designs developed within the Simulink environment.
538
Mode of access: World Wide Web.
System requirements: World Wide Web browser and PDF reader.
590
Advisor: Wilfrido Moreno, Ph.D.
653
FPGA
SysGen
Matlab
PID
VHDL
690
Dissertations, Academic
z USF
x Electrical Engineering
Masters.
773
t USF Electronic Theses and Dissertations.
4 856
u http://digital.lib.usf.edu/?e14.2287