Software Enabled Control for Intelligent Uninhabited Aerial Vehicles UAVs

1
Software Enabled Controlfor Intelligent
Uninhabited Aerial Vehicles (UAVs)
26 October 1998, Berkeley

• Principal Investigators
• Georgia Tech Daniel Schrage, George Vachtsevanos
• Key Personnel
• Georgia Tech Bonnie Heck, J.V.R. Prasad, Linda
  Wills
• Boeing Bryan Doerr, Kevin Wise

http//uav.ae.gatech.edu/sec
2
Presentation Outline

• Program Description
• objective
• tasks
• schedule
• Technical Description
• Task I
• Task II
• Demonstration Plans
• Hardware-in-the-loop simulation
• Flight test demonstration
• Current Status

3
Organizational Chart
4
Project Objectives

• Develop software-enabled control methods for
  complex dynamic systems with application focus on
  intelligent UAVs
• Develop and implement a plug-and-play, real-time
  software architecture for SEC integration
• VTOL UAV hardware-in-the-loop simulation with
  potential follow on flight test demonstrations
• Collaboration with other research teams and
  toolkit providers

5
Quad Chart
Internal Failures
Situation
External Threats
NEW IDEAS
High-Level
Awareness
Fault
Reactive Control
Diagnosis

Intelligent control methods for mode switching
Mode
Fault
Real-Time Distributed
and fault tolerance in
UAVs
Tolerance
Selection
Reconfigurable
Architecture

Interchangeable control modules that allow for
Mode
Reconfigurable
Real Time Sensor
Switching
Control
Processing
changing the mission and modes quickly

Open, distributed, plug-and-play software
architecture for interoperability among
heterogeneous components
SCHEDULE
IMPACT
(2-year project)

Improved mission effectiveness for
UAVs
Months
(smoother operation, improved
Mid-level Coordination
maneuverability and robust to failures)

Rapid response to mission or operational
changes through
reconfigurable
software
architecture for
UAVs
Control Integration and Simulated Demonstration

Increased interoperability among
Multi-level controllers
heterogeneous components
Run-time infrastructure and
and sensor processing
Hardware-in-the-loop

Reduced development costs due to reuse of
software architecture developed.
modules integrated.
simulation demonstrated.
generic control algorithms and integration
Intelligent VTOL UAV Demonstration
patterns
Flight
Infrastructure developed.
Test support developed.
test.
6
Tasks

• Task I Mid-Level Coordination for Mode Switching
  and Fault Tolerant (Reconfigurable) Control
• Task II Control Integration and Simulation
  Demonstration
• Task III VTOL UAV Demonstration

7
Schedule (2-year project)
Months
Mid-level Coordination
Control Integration and Simulated Demonstration
Multi-level controllers and sensor
processing modules integrated.
Run-time infrastructure and software architecture
developed.
Intelligent VTOL UAV Demonstration
Flight test.
Infrastructure developed.
Test support developed.
8
Mission Scenario
9
Mission Abstraction
10
Mission Intelligence Flow
Situation Awareness
Mission Planning
Fault Tolerant Control
Target Tracking
Mode Selection
Mode Switching
Yes
Target Identification
Continue Mission
Flight Control System
No
Target Detection
UAV
Diagnostics
Sensors
Sensor Fusion
11
Model Inversion with Adaptive Neural- Net / Fuzzy
Logic Flight Controller
12
Software Enabled Control
Task I
Mid-Level Coordination for - Mode Switching
(MS) - Reconfigurable Control (RC)
http//uav.ae.gatech.edu/sec
13
Fault Tolerant Control

• Types of faults being considered
• Actuator faults
• Tail Rotor
• Sensor faults
• Yaw Rate Gyro
• Operational faults
• Stall
• Component faults
• Rotor Blade Crack

14
Fault Tolerant Control
15
Yamaha R50 HelicopterActuators, Sensors, and
Linkages
16
Design of Mode to Mode Controllers

• Available techniques
• Gain scheduling
• Phase-space design techniques
• Phase Space Navigator
• Perfect Moment
• Heuristic Approaches
• Our Approach
• Combine nonlinear dynamics and fuzzy logic tools

17
Cell-to-Cell Mapping

• analyze the global behavior of nonlinear
  dynamical systems by partitioning the continuous
  phase space into a finite number of disjoint
  cells and approximating the system trajectories
  as cell transitions

18
Phase Portrait Assignment Algorithm

• Employs a hybrid methodology of cell-to-cell
  mappings and AI algorithms to design optimal
  fuzzy controllers for a class of nonlinear
  systems subjected to dynamic or parametric
  disturbances

19
Mode to Mode Controller DesignProblem Statement

• Given a large-scale dynamic interconnected
  system
• decomposed into N interconnected subsystems Si, i
  1,2,,N
• where each subsystem represents the modes of
  operation and the
• ith subsystems state equation
• How do we design a controller that transitions
  from a starting
• mode of operation to a desired mode?

20
Mode to Mode Controller DesignApproach

• Step 1 Design local controllers for
  operating modes
• modep and modeq

21
Mode to Mode Controller DesignApproach (Cont.)

• Step 2 Model combined dynamics of modep and
  modeq
• and determine the region of interest and the
  partition of the xpq phase
• space

22
Mode to Mode Controller DesignApproach (Cont.)

• Step 3 Determine the region of interest and
  partition the blending weights phase
  space
• Modep and Modeq controller has the following
  form
• where Kp(xpq) and Kq(xpq) are blending matrices

23
Mode to Mode Controller DesignApproach (Cont.)

• Step 4 Determine the nonzero elements of Kp
  and Kq in
• order to transition from modep to modeq
• Let
• Fuzzy linguistic rules

24
Mode to Mode Fuzzy Controller Sensitivity Analysis

• Let the error be defined as the perturbed
  trajectory minus the
• nominal trajectory

25
Mode to Mode Fuzzy Controller Sensitivity
Analysis (Cont.)

• Definition
• The performance measure
• The Fuzzy Sensitivity Measure (FSM)
• where
  and
• Procedure Find Vmin so that FSM has
  linguistic value of
• Not Sensitive

26
Mode to Mode Fuzzy Controller Example

• Hover mode to Forward Flight mode Controller
  Design
• heuristic model representing the longitudinal
  dynamics of a small-scale helicopter
• States forward velocity (ft/s)
• forward
  acceleration (ft/s2)
• pitch angle (rad)
• pitch angle rate
  (rad/s)
• Control longitudinal cyclic
  (rad)
• minimum-time hover to forward flight controller
  designed to go
• from
• to

27
Mode to Mode Fuzzy Controller Example
Helicopter Model
28
Mode to Mode Fuzzy Controller Example
Helicopter Model (Cont.)
29
Mode to Mode Fuzzy Controller Example
Controller Structure
30
Mode to Mode Fuzzy ControllerExample PPAA
design parameters
31
Mode to Mode Fuzzy ControllerResults
32
Mode to Mode Fuzzy ControllerResults (Cont.)
33
Mode to Mode Fuzzy ControllerResults (Cont.)
34
Mode to Mode Fuzzy ControllerResults (Cont.)
35
Robust Stability AnalysisApproach

• Stability of nominal mode to mode trajectory
• small, bounded variations of systems parameters
• small, bounded variations of initial conditions
• Performance measure of error between nominal and
  perturbed mode to mode trajectories
• Incorporates sensitivity of the deviations from
  nominal mode to mode trajectory
• Robustness analyzed by observing a definiteness
  condition of a time-varying matrix
• Robustness measured using the largest singular
  value of a time-varying matrix

36
Robust Stability AnalysisFormulation Main
Result

• Theorem
• Let fuzzy controller transition
  from modep to modeq stablely for the system
• having nominal parameters. The fuzzy controller
  is robust with respect to initial
  condition uncertainty if

37
Current Work

• Simulink Implementation of TMAN Model of an
  Apache Helicopter
• nonlinear state equations
• scheduled aerodynamic parameters (stability and
  control derivatives) according to forward and
  sideward velocities
• Design Hover to Forward Flight Mode Controller
• obtain reduced order longitudinal dynamics model
  of Apache helicopter (forward velocity, forward
  acceleration, pitch angle and pitch angle rate)
• design stabilizing local controllers for the
  helicopter trimmed at 0 and 100 knots
• design a minimum - time hover to forward flight
  controller to go from 0 knots to 100 knots

38
Future Work

• Algorithmic Improvements
• Improve off-line mode switching algorithm
• smoother transitions between start and goal modes
• automating the partition of the phase space
• Real-time mode switching algorithm
• local A search
• reinforcement learning
• use off-line information

39
Fault Tolerant Control
Where do we go from here?
Fault Isolation
Qualitative Physics
Structure-basedMethods

• Tree Structure,
• Block-Arrow Structure,
• etc.

Fault Accommodation
Control Reconfiguration
AnalyticMethods

• Objective function,
• Optimal/Robust control
• etc.

40
Software Enabled ControlModeling and Simulation
http//uav.ae.gatech.edu/sec
41
The Integrated Model
The helicopter model will be an integration of
many sub-systems.
42
Simulation Modelsat Georgia Tech

• Linearized Model from Analytical Equations
• NASA Min. Complexity HeliModel
• TMAN
• ARMCOP
• GENHEL, FLYRT
• FlightLab

Increasing Fidelity
43
Simulation Model (1)

• ARMCOP (ArmyCopter)
• Rigid Body Assumption with 6 DOF
• Uses Rotor Disk Model for the Main Rotor
• Has Component Aerodynamic Models
• Simple Engine and Governor Model

44
Modifications on ARMCOP

• The original Unix ARMCOP Version has been ported
  to a PC and will be used as a C Application in
  the future.
• A RPM degree of freedom has been included in the
  study of control reconfiguration and fault
  tolerant control simulation.
• An inner-loop Adaptive Neural Network Controller
  has been integrated.

ARMCOP will be used as an Initial Evaluation and
Validation of the Control Software.
45
Simulation Model (2)

• FLIGHTLAB
• Most flexible modeling environment available
• Has many Application areas.
• Object Oriented Approach
• 6 DOF Body, Rigid or flexible Blade, Rotor Models
  and inflow dynamics.
• Component aerodynamic models, representation of
  dynamic components
• Engine model

46
FlightLab Applicationsfor this Project

• A Team is formed and trained to use FlightLab
• R-50 can be modeled easily
• New Technology developed at Georgia Tech will be
  implemented.
• Sensors models and Actuator models can be easily
  developed and fidelity increased whenever needed

FlightLab will be used as the Main Simulation
Model for the detailed evaluation of Control
Configuration and Fault Tolerant Control Software
and Hardware-in-the-loop simulation.
47
Model ApplicationHardware in the Loop
On Board System
Sensors
Airframe
Computer
D-GPS
Flight Control Processor
MUX
Motion Pak
3-Axis Magnetometer
R-1 Integrated Avionics System
Control Actuators
Digital Data Link
Altitude Sensor
?
?
?
Ground Station
?
?
Hand Held Radio Control Transmitter
Ethernet
Parallel
Wireless Ethernet
D-GPS Ground Unit
Human Safety Pilot
Mission Control Station
48
Hardware-in-The- Loop Simulation
Simulated Sensor data
Pilot and/or Ground Station Operator
PC based Helicopter Simulation
Flight Hardware
Actuator responses

• Real time PC based dynamic simulation of
  helicopter
• Network Communications between PC based
  simulation and flight control computer
• Dynamic response of simulation is used as sensor
  data
• Flight control laws are run in real time based on
  actual pilot input and simulated response
• This capability allows testing of control laws
  and presence of various digital implementation
  effects including time delays and facilitate
  flight hardware and software qualification

49
Model Application - Main Rotor
Failure Mode Analysis (Main Rotor Control
Failure)
50
Model Application - Tail Rotor
Failure Mode Analysis (Tail Rotor Failure)
51
Research issues

• RPM Control is proposed as a solution for control
  reconfiguration and fault tolerant control.
• Some issues are to be investigated
• Sensitivity Analysis of RPM Control.
• Stability Control investigation.
• Coupling effect of the RPM change with other
  Control Channels.
• Control Reconfiguration in Partial or Full Fault
  of other Controls.
• Effect of Saturation in Control
• Method of implementation.
• Adaptive Neural Net / Fuzzy Logic Control

RPM Control can be introduced as an additional
control in VTOL-UAVs.
52
Research issues
Control Reconfiguration in Partial or Full Fault
of other Controls.
Stability Control investigation.
Coupling effect of the RPM change with other
Control Channels.
Variable RPM
A similar approach can be used for the Tail Rotor
Adaptive Net / Fuzzy Logic Control
Control Saturation
Sensitivity Analysis of RPM Control
53
Response to RPM Step
RPM Control does affect the dynamics and may be
used as a separate control channel
54
Software Enabled ControlTask II Control
Integration Simulated Demo
http//uav.ae.gatech.edu/sec
55
Task II Control Integration and Simulated Demo

• Software architecture and run-time infrastructure
• Integration of mid-level and low-level control
  algorithms
• Integration of inputs from other contractors
• Simulation of VTOL UAV
• Demonstration of software-enabled control
  routines via simulation

56
Task II Details (cont.)

• Integration of mid-level and low-level control
  algorithms and software development
• Development, analysis and simulation evaluations
  of control reconfiguration strategies
• Simulation demonstration of selected failure
  scenarios
• Flight test evaluation of selected failure
  scenarios

57
Software Enabled ControlTask II.A Software
Architecture
http//uav.ae.gatech.edu/sec
58
Overall Functional Architecture
Other Projects
SEC Algorithms
GUT Interface
Generic UAV Testbed (GUT)
Simulation Platform
Hardware Platform
Operator Interfaces
ArchitectureFramework
59
Overall Software Architecture
Other SEC Algorithms
Fault Tolerance
Mode Switching
Sensor Suite
Reconfigurable Algorithms Patterns
Actuation Suite
Virtual Resource Network
SEC
Bold-Stroke
Voyager
Airframe
Flight Control System
Switching
Plug Play
Distributed Computing
GUT
60
Distributing Computing Architecture

• Bold Stroke
• Provides real-time high performance distributed
  computing
• Data flow occurs through event channels
• Provides the abstract real-time constructs for
  high frequency timing
• Slightly difficult to implement
• All implementations will be in C
• Will be used to implement the avionics software
  such as the flight control system and sensor
  fusion
• Voyager
• Provides top level distributed computing
• It is CORBA compliant and thus can refer to CORBA
  objects
• Seamless implementation of distributed objects
• Used to implement the Virtual Resource Network
  which allows a Plug Play architecture
• Implementation will be in Java and used for low
  frequency communications such as visualization,
  high-level mission commands and online
  reconfiguration of resources

61
Boeings Bold Stroke Open Systems Architecture

• Real-time CORBA-based integration of distributed,
  heterogeneous components.
• Builds on the Real Time (RT) Object Request
  Broker (ORB) developed as part of the TAO project
  at Washington University in collaboration with
  Boeing.

62
Why two technologies ?

• Using a hybrid of two distributed computing
  technologies will do the job better
• RT-CORBA (Bold Stroke) provides high performance
  but its implementation is not seamless
• Distributed Java technology is intuitive and very
  easy to implement but slow
• Hence, using BoldStroke where high-performance is
  required and using distributed Java everywhere
  else satisfies critical criteria in the relevant
  components
• Voyager (Java ORB) is CORBA compliant and thus
  can be integrated easily with CORBA

63
Virtual Resource Network Architecture

• Virtual Resource Network
• is a distributed computing network of resources
• resources are simply an aggregation (assemblage)
  of software/hardware objects that fulfil a
  certain functionality fulfill
• Using a VRN to setup a UAV mission
• Resources required for a mission are assembled
  into a tree hierarchy
• Data communications between the resources are
  defined (registering with event channels for
  specific events)
• Then the mission is started and resources are
  reconfigured if necessary during the mission
  on-line
• The operator interface displays the VRN tree. Any
  resource can be visualized and reconfigured by
  dragging it into the visualization space

64
Visualization Space
Drag Drop a resource to visualize it
Virtual Resource Network Tree
Visualization Component
65
Algorithm Architecture Implementation

• Use UML for design of these components
• Use Design Patterns to abstract common factors
  and provide hooks for algorithms using a common
  interface
• Algorithm integration occurs through the common
  interface hooks provided by the design patterns

66
Algorithm Architectures (1)
High Level Reconfiguration Commands
Trajectory Commands
Mid Level Control
High Level Control
Mode Reconfiguration Implementor
Mid Level Control
Mode Transitioning Module
Low Level Control
Sensor Suite
Mode Strategy

• Flight Management
• Collision Avoidance
• Trajectory Optimization
• Formation Management

Mode Strategy
Framework
Reconfigurable Component interface
Algorithm Hooks
67
Algorithm Architecture (2)
Trajectory Reconfiguration Commands
Actuator Commands
Low Level Control
High Level Control
Control Reconfiguration Implementor
Control Transitioning Module
Mid Level Control
Low Level Control
Control Strategy
Sensor Suite

• Pure PID
• Model Inversion Control
• Neural Net Augmented Control

68
Algorithm Architecture (3)
Reconfiguration Commands
State and Navigation Info.
Sensor Suite
Sensor Reconfiguration Implementor
High Level Control
Transitioning Module
Mid Level Control
Low Level Control
Filter Strategy

• Filter type
• Filter constants etc.

Sensor Suite
GPS
Vision
IMU
Altimeter
Vehicle Dynamics and External Stimuli
69
Component Communication Example
Simulation
Propagation Strategy
Rigid Body Dynamics (50 Hz)
Swash Plate Servo dynamics (50 Hz)
UAV Interface
PID
Aerodynamics
Control rotor dynamics (100 Hz)
Rotor dynamics (100 Hz)
Controller Strategy
Neural Net
Controller Interface
Open Systems Architecture
Testbed
Actuators

• Distributed objects
• Plug-and-play
• Encapsulation
• Reconfiguration

UAV Interface
Sensor Suite
70
What have we done so far

• Requirements Analysis
• capture functional requirements
• create tractability relationship between
  requirements
• Initial use-case specs for software architectures
• map requirements from Requisite Pro to UML Use
  Cases
• Initial design of a subset of components
• UML models of software components such as the FCS
• Initial design of operator interfaces
• Initial survey of implementation technologies
• UML models of critical components

71
Software Enabled ControlTask III VTOL UAV
Demonstration
http//uav.ae.gatech.edu/sec
72
Task III VTOL UAV Demonstration

• Ground-based and onboard software-enabled control
  implementation
• Demonstration of software-enabled control
  technologies on a small VTOL UAV

73
Proposed Main Rotor Failure(for Simulated Demo)
With fault tolerant and reconfigurable control
system
Failure detection and control reconfiguration
with RPM control
Main rotor control failure
Without fault tolerant and reconfigurable control
system
74
Proposed Tail Rotor Failure(for Simulated Demo)
Failure Mode Analysis (Tail Rotor Failure)
75
Software Enabled ControlSystem Integration
http//uav.ae.gatech.edu/sec
76
Team Collaboration
The Repository
Testbed
Code conforming to interface guidelines committed
over network
Digital Data Link
Run-time Code
Component Algorithm Configurations
Internet
Boeing R-50 So
Other Algorithm Developers
Georgia Tech Algorithm Developer
Mission Control Station
77
Rational Unified Process For UML Implementation
Use Cases
Requirements
Implementation
Design
Analysis
Test

• Architecture-centric
• Incremental

• Use-Case-Driven
• Iterative

Component View
Logical View
Use-Case View
Deployment View
Concurrency View
78
GUT Design Process
Map requirements (functionality) into UML use
cases
Testbed Requirements
Analysis
Capture requirements in a database
Unified Process
Iterate
Design
Verify and Flight Test
Implement
79
Step 1 Requirements Capture

• Top level requirements captured to a database
• Detailed requirements appear as sub-requirements
  resulting in a tree
• These requirements are mapped to Rose as
  functional requirements (Use Cases).
• The software for these requirements are then
  analyzed using UML (Rose)
• The architectures will then be designed
• Finally, implementation will be in C and Java

80
Step 2 UML Use Case Model

• An example of required functionality is
  trajectory following
• The requirements are mapped from the requirements
  database to the Rose Use Case model
• The above Use Case diagram showing the
  trajectory following Use Case employing other
  Use Cases to fulfil the top level requirement

81
Step 3 Analysis
82
Step 3 4 Design and Implement

• Design
• The software architectures and components are
  designed using the UML employing Use-Cases,
  sequence diagrams etc.
• All critical timing sequences are identified
• In addition to the architecture design, the
  components required for SEC and other functions
  are designed and implemented
• Implementation
• Code is hand generated
• Code is then reverse engineered to reflect it in
  design models
• Verification and Testing of the code occurs
• Hardware-in-the-loop simulations and flight tests
  follow

83
Rose User Interface
84
Summary and Conclusions

• We have begun definition of the system
  architecture for Software Enabled Control of
  Intelligent UAVs and the associated algorithm
  development
• We have presented our technical approach and
  computing architecture modeled in UML. More
  iterations are required with Boeings
  participation in analyzing, designing and
  implementing the architectures described.
• The ultimate objective of this project is to
  demonstrate the SEC algorithmic developments and
  the software architectures using a
  hardware-in-the-loop simulation environment
• The planned hardware-in-the-loop simulation will
  demonstrate a new run-time infrastructure for
  Software Enabled Control of Intelligent UAVs
• Follow on work is anticipated to include flight
  test demonstrations