Software Enabled Control of Intelligent Unmanned Aerial Vehicles

1
Software Enabled ControlofIntelligent Unmanned
Aerial Vehicles

• Suresh Kannan
• Georgia Institute of Technology

2
Lecture Plan

• Global Picture of Intelligent UAVs
• Motivation for the Open Control Platform
• Some associated control problems in UAVs
• Architecture description and application to
  control problems
• Control System Reconfigurability (Decoupling)
• Real-Time Quality of Service
• Distributed Control Functionality
• Multiple UAV Scalability
• Conclusion

3
Global Picture of Intelligent UAVs

• An Intelligent UAV is more than just a
  stabilized, remotely piloted flight vehicle.
• An Intelligent UAV can take a high-level goal
  such as UAV2 Kill SAM site at xxx coordinates
  and then make all the decisions necessary to
  leave its parent swarm, destroy the target and
  rejoin the swarm.

4
(No Transcript)
5
UAV Local Decisions

• Some decisions the UAV must take are
• How to leave the swarm ?
• How to replan the route when chased by a missile
  ?
• How to avoid a flock of birds ?
• How to redistribute control authority to
  secondary control surfaces when the primary
  surface fails.
• How to make an autorotation landing or land on a
  heaving shipdeck in an emergency.

6
UAV Brain Dissection
Intelligent
Internal Abnormal Conditions
External Abnormal Conditions
7
(No Transcript)
8
UAV Brain Dissection
Intelligent
Internal Abnormal Conditions
External Abnormal Conditions
9
Software Enabled Control

• Software Enabled Control attempts to raise the
  degree of autonomy of Unmanned Aerial Vehicles by
  developing control algorithms that can handle
  abnormal situations.
• Before such control algorithms may be
  implemented, the architecture and framework in
  which these algorithms will work and interact
  with each other must be worked out.
• The big question is how do we ascertain that each
  control system receives the right quality of
  information and at the right time in order to
  make the best decisions.

10
Motivation

• There exists no central architecture that will
  integrate the various interdisciplinary systems
  such as Artificial Intelligence, Flight Control,
  Signal Processing etc. into one collaborating set
  of algorithms.
• The Open Control Platform Architecture will
  provide the distributed control and
  reconfigurable architecture that allows control
  and intelligence algorithms at all levels and
  timescales to interact in a decoupled, real-time
  and distributed fashion.

11
Scenario - Tail Rotor Failure
I
Tail rotor fails and the fuselage starts to
accelerate about the shaft axis
Redundant yaw control surfaces may be used to
regain some control over yaw rate and/or main
rotor rpm may be manipulated to minimize torque
B

12
Scenario - Tail Rotor Failure
The flight control algorithm now attempts to
perform in a rotating system. Before failure, all
three attitude channels were equally important.

• After failure, the yaw attitude information
  becomes more important in determining the control
  outputs in the longitudinal and lateral channels
  in order to maintain trajectory.

13
Scenario - Tail Rotor Failure

On board computer
50 Hz INS Sensor Driver
Integrated Inertial Navigation System
500 Hz Gyros Driver
High precision, high rate gyro
The attitude rates of the aircraft fall outside
the nominal operation of the controller. The
controller is only able to continue providing
stabilizing control when higher quality yaw rate
information is available. Hence, switch
(reconfigure) the navigation data source from the
INS to the high rate gyros.
14
Scenario - Mission Reconfiguration
Algorithms running on the onboard computer

High Precision Gyro
Integrated INS
Target Tracking Algorithm
FLIR
Vision System
Ship Deck Landing Algorithm
Attitude Control Algorithm
Mission Planning Algorithm
Translation Control Algorithm
Tail Rotor Failure Control Algorithm
Over a short period of time the interconnections
are reconfigured many times. The same data is
needed at a low priority at one point and at a
very high priority at different times.
15
Open Control Platform Software Architecture
Fault Tolerance
Other SEC Algorithms
Control Algorithms
Mode Switching
Sensor Suite
Actuation Suite
Extensible Interfaces
Open Control Platform
Standardization
Airframe
Flight Control System
Virtual Resource Network
Control Patterns
Voyager
Bold-Stroke
Plug Play
Real Time Distributed Computing
16
Real Time Distributed Computing Functionality

• Provided by Boeings Bold Stroke Software
  designed for precision Avionics algorithms such
  as weapons release
• Bold Stroke is Boeings implementation of the
  industry standard Common Object Request Broker
  (CORBA). CORBA allows different software
  algorithms on different computers on a network to
  talk to each other.
• Boeing has made performance extensions that
  provide real-time guarantees when sending
  messages across a network.
• Most important of all, Bold Stroke provides the
  Real Time Event Channel which decouples
  information transmitted between algorithms

17
Coupled
18
Any controller can subscribe to new data during
the mission. No physical connection between the
control systems. Everybody is connected through
data flow and data flow only.
19
Decoupling Algorithm Interaction
Data OutFlow
Object
Data InFlow
10 Hz
Controller (100 Hz)
20 Hz
100 Hz
Gyros (500 Hz)
500 Hz
Helicopter (Real Time)
20 Hz
50 Hz
Sensors (50 Hz)
Object/Algorithm Names
Data Names
Helicopter - uav (actual helicopter) Controller
- uav.controller (flight controller) Sensors
- uav.sensors (INS sensors) Gyros -
uav.gyros (high rate gyros)
20
Event Channels

• Every piece of data pushed into the event channel
  is of a unique type. Say helicopter position is
  of the type uav.navdata.

• The sensors uav.sensors connects connect to the
  event channel as a Supplier of uav.navdata
  information.

• Say a flight control algorithm uav.controller
  is interested in uav.navdata data. It simply
  connects to the event channel as a consumer and
  declares it is interested in uav.navdata.
• The flight control algorithm is completely
  decoupled from the source of information. As long
  as it gets uav.navdata reliably the controller
  can provide stabilizing control to uav.

21
Reconfiguration
Nominal mission configuration uav.sensors supplies
uav.navdata _at_ 50 Hz uav.controller consumes uav.n
avdata _at_ 100 Hz uav.controller consumes pilot.comm
ands _at_ 10 Hz uav.actuators consumes uav.delta _at_
100 Hz
Tail Rotor failure reconfiguration uav.gyros suppl
ies uav.navdata _at_ 500 Hz
In the reconfiguration, the source of navigation
data was changed from conventional INS sensors to
high rate gyros which provide higher quality
information albeit over a shorter period of
time. By algorithms being decoupled, only one
simple statement is required to reconfigure for a
tail rotor failure.
22
Real Time Quality Of Service
Note that during tail rotor failure the
uav.navdata is required at a very high rate and
is of very high priority Other less important
data is flowing through the event channel at the
same time. Thus, uav.navdata might not reach
uav.controller in time. Hence, reconfiguration
can include the following statements including
data priority information
Tail Rotor failure reconfiguration uav.gyros sup
plies uav.navdata _at_ 500 Hz uav.controller consume
s uav.navdata _at_ 500 Hz _at_ priority 20 The
event channel then automatically schedules all
events of the type uav.navdata at a high
priority and the navigation information is
received at the best possible rate. Control
System stabiliy and performance requirements may
be mapped directly into Real-Time QoS information
23
Distributed Control Functionality
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 Control Platform
fast-sgi.ae.gatech.edu
Testbed
gras-slowdesktop.ae.gatech.edu
Actuators

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

UAV Interface
Sensor Suite
onboard-computer.ae.gatech.edu
24
Multiple UAV Scalability
uav3
Objects / Control Algorithms uav uav.sensors uav.g
yros uav.controller uav.shipdecklanding uav.missio
nplanner Data uav.navdata
uav1
uav5
uav4
uav2
To fly in a swarm uav5 needs to be configured as
follows uav5.missionplanner consumes uav1-4.na
vdata When trying to leave a swarm uav5.missionpl
anner consumes uav1-4.navdata _at_ priority 20
25
Conclusions

• The Open Control Platform provides an environment
  in which control algorithms, intelligence,
  hardware, vision etc may configured to
  collaborate and accomplish a mission.
• The stability and other performance requirements
  of control algorithms may be directly mapped into
  a Real-Time Quality of Service information
• The behavior of a single UAV or a swarm may be
  reconfigured by simply rerouting data between
  algorithms.
• This internetworking type of architecture is
  based on types of information rather than the
  physical location of the algorithms.

26
Architecture Overview
VTOL UAV
Pitch Controller

Roll Controller
-
Yaw Controller
27
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

28
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
29
Control Reconfigurability
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