Transcript DARPA SEC presentation

Software-Enabled Control HWIL and
Flight Tests*
Gary Balas
Aerospace Engineering and Mechanics
University of Minnesota
[email protected]
www.aem.umn.edu
2 March 2005
* The theoretical development of the algorithms was funded by NASA Langley under the NASA
Cooperative Agreement NCC-1-03028. Dr. Celeste M. Belcastro is the technical contract monitor.
The application to the DARPA SEC fixed-wing capstone demonstration was funded as part of the
Software Enabled Control Program, Dr. John Bay Program Manager. The contract number is
USAF/AFMC F33615-99-C-1497, Dale Van Cleave was the Technical Contract monitor.
Software Enabled
Control (SEC)
The objective of SEC is to co-develop advanced real-time control system
algorithms and the software services and infrastructure necessary to
implement them on distributed embedded processors in a robust and
verifiable way
Dr. John Bay
DARPA
Information Technology Office
Software-Enabled Control (SEC)
• Control Systems for innovative vehicles
-
UAVs, rotorcraft, fighters
• Increase automation for extreme maneuvers
-
Assured stability for flight mode transition
• Improve disturbance rejection and fault tolerance
-
Automatic control reconfiguration
Redundancy management
Maneuverability
Program Objectives:
• Provide reusable middleware for coordinated, embedded
software control on multiple aircraft types
-
Traditional
control
methods
Modernize flight control with adaptive, distributed computing
On-board control
and fault
management
SEC provides control systems for innovative
vehicles that exceed the capability of
conventional flight controllers
C(s)
Multiple levels of control:
•
•
•
Vehicle management (including flight-critical systems)
Mission management (including route planning)
Multi-vehicle (e.g. automatic formation flight)
Vehicle
capability
Speed
Distributed Monitoring,
Modeling, and Control
Human pilots
Moller
Proprietary
SEC Technologies
•
Active State Models: Prediction & Assessment
–
–
–
•
On-Line Control Customization: Adaptation
–
–
–
•
Achieve global stability, maximize system and mission performance
Provide joint fault detection, isolation, and recovery
Enable distributed control implementation for physically separated
components
Gain altitude using
main rotor collective
Control
reconfiguration
for autorotation
Tail rotor failure
Safe
Landing
Open Control Platform (OCP): Software
–
–
–
•
Enable precise mode transition
Support control re-parameterization and reconfiguration during operation
due to environmental disturbances, interference, and damage
Accommodate dynamic coordination requirements
Coordinated Multi-Modal Control
–
–
–
•
Dynamically exploit on-line system and environmental data to improve
reference models
Predict effects over very large state and mode spaces
Rapidly assess damage
Provide reusable control middleware and tool support for building
controllers from SEC technologies
Provide parametric open systems framework necessary to support SEC
active state model, hybrid/coordinated, and adaptive multi-modal control
Provide flexible experimental platform for SEC control research and
demonstration
High Confidence Software Control Systems
–
–
Assure safety and reliability under fault conditions
Design for verification, validation, and certifiability
S/W Components
API
API
OCP Middleware
Operating system
Board support package
Hardware (CPU, memory, I/O)
API
Open Control Platform (OCP)
The Open Control Platform (OCP) is a program task as
well as the vehicle for contractor integration into
demonstrations and experiments in flight control systems
Control Application
Software Components
Distributed Processing
distributed systems
multi-vehicle
API
Fault Management
detection and isolation
reconfiguration
error recovery
OCP Middleware
Operating system
Active Models
model servers
estimators
multi-model management
Board support package
Hardware (CPU, memory, I/O)
Optimal Control
multi-criteria
receding horizon
distributed
Hybrid Control
switching services
blending
planning
API
API
API Examples:
(EXAMPLES)
SEC Tasks and Milestones
Active State
Models
Honeywell
U Washington
Vanderbilt
OGI
U Minnesota
Legacy
Technology
Multi-Modal
Control
On-Line Control
Customization
Northrop Grumman
Draper Labs
Vanderbilt
Cal Tech
U Minnesota
UC Berkeley
U Minnesota
Northrop Grumman
Stanford
Ga Tech
High-Confidence
Systems
Boeing
SRI
Honeywell
MIT
Cal Tech
Rockwell
Northrop Grumman
TRANSITION
Prediction
Real-Time
Services
Switching
Adaptation
Confidence
OPEN CONTROL PLATFORM
Boeing, GaTech, UC Berkeley, Honeywell
Bold Stroke
Milestones
API for switching svcs.
Predictive models oper.
Hybrid multi-model svcs
Integrated model svcs.
Mode triggering defs.
CLF and LPV control
Hybrid stability, single sys.
Customization svcs.
Hybrid run-time svcs
High-level multi-mode API
Multi-mode run-time svcs.
Multi-vehicle hyb. control
Hybrid model checking
Formal specification lang.
Integrated fault mgt.
Sensor/act reconfig.
UMN/UCB SEC team members
University of Minnesota
• Gary Balas, Raktim Bhattacharya, Tamas Keviczky, Praveen
Vijayaraghavan, Katherine Zhou, Deenadayalan
Narayanaswamy, Nachiket Bapat, Yohannes Ketema Ph.D.,
George Papageorgiou Ph.D., Richard Russell, Aron Cooper,
Capt. Paul Blue, Francesco Borrelli Ph.D, Matt Payne, Ryan
Ingvalson, Riccardo Oreste Natale Ph.D., Prof. Hector
Rotstein, David Weyrauch
University of California, Berkeley
• Andy Packard, Alpay Kaya, Zachary Jarvis-Wloszek, Sean
Estill, Ken Hsu, Kunpeng Sun
8/77
SEC Technical issues addressed by UMN/UCB
Increase autonomy, reliability and aggressiveness of UAVs for
a range of potential missions through advances in control
and trajectory generation.
Objective:
Development of software based control technologies that use
dynamic information about the controlled system to adapt, in
real-time, to changes in the systems and its operating
environment. This will enable UAVs capable of
• extreme performance
• accommodation to changes in mission/tactical goals, environmental
conditions, failures and constraints
• use of diverse information from on and off-vehicle sensors
9/77
Technical Approach
Specific technologies developed:
• Receding horizon control (RHC)
– 3D time-stamped position reference trajectory tracking.
– Respecting aircraft constraints.
• Integrated and independent trajectory generation and innerloop control
• Anytime control algorithms
• Fault detection algorithms
• Seamless integration with OCP
– Implementation of control algorithms using RT-ARM
• RHC API to interface with the OCP
– Interface with online optimization solver within the OCP.
10/77
Receding Horizon Control Algorithm
11/76
Receding Horizon Autopilot Scheme
• Exploits a priori reference information, accomplishes
higher level control objectives.
• Acts as a system/mission-state dependent variable innerloop command pre-filter.
• Ensures that the aircraft’s inputs are held within
saturation limits even in the presence of wind gusts.
• Respects flight envelope constraints and system-state
dependent maneuver limits.
Receding Horizon Controller (autopilot)
• Relies on an explicit discrete-time process model for prediction.
• Limited information and insight about actual inner control loop
by means of linearized models at certain flight conditions.
Discretized linear inner closed-loop
• Outputs:
• Commands:
– Tracking performance (y):
– thrust
altitude, speed
– pitch rate
– Maneuvering limits (z):
vertical acceleration
– Actuators (u):
thrust and thrust rate, elevator defl. and rate
Disturbance model augmentation
13/77
Receding Horizon Control
14/77
Linear and adaptive RHC schemes
based on [Maciejowski, 2001]
• Uses a discrete-time LTI or linear, parameter-varying (LPV)
internal model that depends on the actual flight condition.
• Prediction model is LTI over prediction horizon, but changes
every time a new control input is calculated.
• Internal model input, input rate, output and state constraints can
be imposed.
• Unconstrained problems, analytic solution (least-squares).
• Constrained problems lead to QP problems, efficient solvers.
• Desired maneuver limits are imposed as soft constraints to
alleviate infeasibility problems.
15/77
Receding Horizon Control: Problem Formulation
16/77
RHC problem formulation and cost function
Optimization problem solved at each sampling time:
subject to
1. Flight condition dependent inner closed-loop dynamics
(augmented with estimated disturbance state)
2. Flight envelope constraints
3. Maneuvering limits
4. Actuator constraints
17/77
RHC problem formulation and cost function
• Using a linear internal model, the problem becomes a Quadratic Program:
with the appropriate
matrices that depend on the
linear prediction model, the measured states and signal limits.
• The  slack variable represents an -norm penalty (soft constraint) on flight
envelope and maneuvering constraint violations.
• This type of soft constraint is an “exact penalty function”, i.e. its value is nonzero
only if the original problem with hard constraints is infeasible.
18/77
RHC Summary
• Real-time implementation is feasible.
• On-line constraint modification allows straightforward
incorporation of system-state dependent, and time-varying
constraints.
• Linear prediction models should be flight condition dependent,
either in the form of a selection of LTI models or an LPV
system description.
• Using LPV models for prediction, the modest complexity of the
predictive control problem can still be retained (QP) with
improved accuracy and extended operation limits, which are
comparable even to the nonlinear solution.
19/77
Receding Horizon Control API
20/76
Every Major Frame
PRE: User-code uses “set()” methods to map input port data
(model parameters, modes, faults and state estimates) into
problem data (dynamics, costs, constraints).
• RHCAPI retrieves problem data, formulates constrained
quadratic program.
OPT (anytime task): RHCAPI solves the constrained
Quadratic Program. If infeasible, relax and solve again.
POST: User code interprets optimal solution and problem data
to issue commands
21/76
RHC API Component: Problem Formulation
•
•
•
•
Model Data:
Cost Data:
Horizon Length:
Signal Estimate:
•
•
•
•
Initial State Estimate:
Input Subspace:
Constraint Data:
Constraint Relaxation:
At each time step, solve
with
subject to:
22/76
Relaxing the constraints
Each constraint is associated with a
relaxation group (G0, G1, …)
Constraints in G0 cannot be relaxed
The unit cost of relaxing any/all
constraints in G1 is
The unit cost of relaxing any/all
constraints in G2 is
and so on…
Each individual constraint is linear in the decision variable . Express the
. Let
denote the original cost. The relaxed problem is:
constraint as
23/76
RHC-API
24/76
RHC-API Timing
• PRE Hard Real-Time (HRT) task starts at beginning of a major frame (2Hz).
– Starts a timer, after 450 ms calls POST, other HRT task.
– When PRE finishes, flag set enabling anytime task OPT to call optimizer.
• If optimization converges, flag is set to indicate optimizer no longer running.
• When POST gets called, it checks the optimizer running flag.
– If optimizer is no longer running, processes optimization results and sends
control commands.
– If optimizer is still running, implements baseline solution control
commands.
25/76
Fault Detection
26/76
Fault Detection (FD) Goals
u
Nominal
Plant
y
FD
Filter
r
u
Faulty yˆ
Plant
FD
Filter
r
• Design an FD filter such that:
–
–
–
–
–
Input to filter: plant input/output pair u-y.
Output from filter: “residual” signal r.
r is independent from the input u.
r is insensitive to plant noise and model mismatch (MM).
r is sensitive to the faults in the plant.
• Channel of interest for FD:  cmd to 
27/76
Fault Detection Challenges
Challenge 1: Black Box Simulation, Demosim.
– No Access to internal signals.
– Closed-loop system dynamics - i.e. T-33/UCAV autopilot
Solution: Generate own fault implementation.
– Inject fault as multiplicative input error.
– Identified by simulating the response of an aircraft using a
faulted aileron actuator (fault block Wf )
 cmd
Fault
Block Wf
Faulty plant
DemoSim/
Aircraft

28/76
Fault Detection Challenges
Challenge 2: DemoSim complexity
– Unknown internal nonlinearities (saturations, rate limits,
quantization levels, etc).
– Linear models fail to capture these dynamics.
– Model mismatch looks like a fault.
Solution: Incorporate model mismatch into design.
– Model plant mismatch as input multiplicative uncertainty.
– Optimally design a filter to account for this uncertainty.
Model mismatch
Wf
u

noise
Wp
Wn


P0
Wf Fault weight
Wp MM weight
Wn Noise weight
y
P0
Nominal plant model
29/76
Model Mismatch
For some input signals, model
mismatch dominates fault!
30/76
FD Simulation Results: Pulse Example
Challenge: distinguish model mismatch from fault
Solution: input-dependent threshold signal
31/76
Threshold Function s
s(t )   r ( ) d  FP0Wp
2
• s < 0: no fault
2

2
u
(

)
d  FWn

2

Pulse example revisited
• s > 0: fault
• Two tuning parameters:
– Add “forgetting factor” to
integral, removes effect of
Model Mismatch (MM).
– Scale noise term
Fault on
MM
Fault
detected
32/76
UMN/UCB SEC Final Exam
33/76
Final Exam Airplanes
The Demonstration Team
• Our Customer
– DARPA
– AFRL IFSC
and VACC
• Government
Collaborators
– Air Force
Flight Test
Center at
Edwards Air
Force Base
– NASA Dryden
Flight Research
Center
• Boeing Teams
– Phantom
Works
Network
Centric
Operations
– J-UCAS
– F-15E1
• SEC Controls Technology Teams
–
–
–
–
–
–
–
–
University of California-Berkeley
California Institute of Technology
University of Colorado
Honeywell
Massachusetts Institute of Technology
University of Minnesota
Northrop Grumman
Stanford University
SEC Ground Station and
Flight Demo Visitor RV
UMN/UCB Final Exam Sequence of Events
• Piloted approach to Ingress Point with specified flight condition
– Start recording data (REC-ON)
– Enable commands (“Fly to initial condition”) (CMD-ON)
• Engage RHC controller (START)
• Track reference trajectory (scan test range for targets)
–
–
–
–
Invoke Pop-up threat if desired (SND OBST)
Avoid pop-up threat and fly over target
Initiate fault simulator (FTSM_ON)
Detect fault and reconfigure controller
• Finish mission at Egress Point
• Disengage controller (CMD-OFF)
• Stop recording data (REC-OFF)
38/77
Flight envelope of demonstration experiment
39/77
Flight test range at
NASA Dryden Flight Research Center
40/77
Experiment Plan
41/77
Results
• Matlab/Simulink/DemoSim Simulations
• Hardware-in-the-loop Simulations
• Flight Tests
42/77
High-fidelity simulations (Matlab/DemoSim)
Comparison of results in different wind conditions
North-East trajectories (simulation)
4
x 10
4
x 10
Altitude trajectories (simulation)
6
Reference
-60 ft/s East
-50 ft/s East
-20 ft/s East
60 ft/s East
50 ft/s East
20 ft/s East
no wind
4
2
1.55
Reference
-60 ft/s East
-50 ft/s East
-20 ft/s East
60 ft/s East
50 ft/s East
20 ft/s East
no wind
0
-2
-4
WGS-84 Altitude (ft)
North coord. relative to RHC engagement (ft)
1.6
wind
wind
wind
wind
wind
wind
-6
wind
wind
wind
wind
wind
wind
1.5
1.45
1.4
-8
-10
1.35
-12
1.3
0
2
4
6
8
10
12
14
16
East coord. relative to RHC engagement (ft)
18
0
4
x 10
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
43/77
Comparison of results in different wind conditions
Velocity (simulation)
Turn rate command (simulation)
0.04
60 ft/s E wind
560
0.03
50 ft/s E wind
0.02
20 ft/s E wind
520
0.01
(rad/s)
True airspeed (ft/s)
540
upper limit
no wind
500
-20 ft/s E wind
480
0
-0.01
-0.02
460
-50 ft/s E wind
-60 ft/s E wind
440
0
200
400
600
800
1000
Time relative to RHC engagement (sec)
-0.03
1200
-0.04
lower limit
0
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
44/77
Comparison of results in different wind conditions
North trajectory tracking error
1000
(ft)
500
0
-500
200
400
600
800
1000
1200
East trajectory tracking error
500
(ft)
0
-500
-1000
200
400
600
800
1000
Altitude trajectory tracking error
40
-60 ft/s East wind
-50 ft/s East wind
-20 ft/s East 1200
wind
60 ft/s East wind
50 ft/s East wind
20 ft/s East wind
no wind
(ft)
20
0
-20
-40
-60
200
400
600
800
1000
1200
Simulation time (sec)
True airspeed limits were saturated with -60 ft/s (~18 ms/) East wind
45/77
Comparison of results in different wind conditions
Ground speed (ft/s)
Velocity command
580
560
540
520
500
480
200
400
600
800
1000
1200
1000
1200
Turn rate command
0.05
(rad/s)
upper limit
0
lower limit
-0.05
200
400
600
800
Altitude command
4
x 10
1.6
-60 ft/s East
-50 ft/s East
-20 ft/s East
60 ft/s East
50 ft/s East
20 ft/s East
no wind
(ft)
1.55
1.5
1.45
1.4
wind
wind
wind
wind
wind
wind
1.35
200
400
600
800
1000
1200
Simulation time (sec)
True airspeed limits were saturated with -60 ft/s (~18 ms/) East wind
46/77
Comparison of results in different wind conditions
True airspeed (ft/s)
Velocity
560
540
520
500
480
460
440
200
400
600
800
1000
Heading
-60 ft/s East
-50 ft/s East
-20 ft/s East
60 ft/s East
50 ft/s East
20 ft/s East
no wind
150
100
50
(deg)
1200
0
wind
wind
wind
wind
wind
wind
-50
-100
-150
200
400
600
800
1000
1200
Roll angle
30
(deg)
20
10
0
-10
-20
-30
200
400
600
800
1000
1200
Simulation time (sec)
True airspeed limits were saturated with -60 ft/s (~18 ms/) East wind
47/77
Comparison of results in different wind conditions
Fault detection threshold residual comparison (focus on detection part)
0.01
0.005
0
residual value
Fault detection
-0.005
-60 ft/s East
-50 ft/s East
-20 ft/s East
60 ft/s East
50 ft/s East
20 ft/s East
no wind
-0.01
-0.015
Fault button press
-0.02
wind
wind
wind
wind
wind
wind
Start of "fault detection turns"
-0.025
-0.03
1020
1040
1060
1080
1100
1120
1140
1160
1180
1200
Simulation time (sec)
48/77
Hardware-in-the-loop simulations
North-East trajectories (HIL test)
4
x 10
Altitude trajectories (HIL test)
4
x 10
Reference
HIL test
1.6
4
2
1.55
0
WGS-84 Altitude (ft)
North coord. relative to RHC engagement (ft)
6
-2
-4
-6
1.5
1.45
1.4
-8
1.35
-10
-12
Reference
HIL test
0
2
4
6
8
10
12
14
16
East coord. relative to RHC engagement (ft)
1.3
18
0
4
x 10
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
49/77
Hardware-in-the-loop simulations
Fault detection threshold residual comparison (focus on detection part)
Fault detection threshold residual comparison (focus on detection part)
0.03
0.03
UMN test run
HIL test run (no fault)
0.02
0.02
0.01
Residual value
Residual value
0.01
0
0
-0.01
-0.01
-0.02
-0.02
-0.03
UMN test run
HIL test run
940
960
980
1000
1020
1040
1060
1080
Time relative to RHC engagement (sec)
1100
1120
-0.03
940
960
980
1000
1020 1040 1060
1080 1100
1120
Time relative to RHC engagement (sec)
HIL fault button press
50/77
51/77
Flight test results
North-East trajectories (flight test)
4
x 10
Altitude trajectories (flight test)
4
x 10
6
Reference
Flight test
1.65
2
1.6
0
WGS-84 Altitude (ft)
North coord. relative to RHC engagement (ft)
4
-2
-4
-6
1.55
1.5
1.45
-8
-10
1.4
-12
Reference
Flight test
0
2
4
6
8
10
12
14
16
18
East coord. relative to RHC engagement (ft)
0
4
x 10
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
June 18, 2005
52/77
Flight test results
North-East trajectories (flight test)
4
x 10
6
1.7
Reference
Flight test
4
Reference
Flight test
1.65
2
0
WGS-84 Altitude (ft)
North coord. relative to RHC engagement (ft)
Altitude trajectories (flight test)
4
x 10
-2
-4
-6
1.6
1.55
1.5
-8
1.45
-10
1.4
-12
0
2
4
6
8
10
12
14
16
18
East coord. relative to RHC engagement (ft)
0
4
x 10
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
June 24, 2005
53/77
Comparison of speed commands & responses
Velocity command and response (simulation)
Ground speed (ft/s)
600
command
response
550
500
450
400
0
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
Velocity command and response (HIL test)
Ground speed (ft/s)
600
command
response
550
500
450
400
0
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
Velocity command and response (flight test)
June 24
flight test
Ground speed (ft/s)
600
command
response
550
500
450
400
0
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
54/77
Comparison of speed commands & responses
Velocity command and response (simulation with 50 sec delay on Vcmd)
Ground speed (ft/s)
600
550
500
450
command
response
400
0
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
Velocity command and response (flight test #1)
June 18
flight test
Ground speed (ft/s)
600
550
500
450
command
response
400
0
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
Velocity command and response (flight test #2)
June 24
flight test
Ground speed (ft/s)
600
command
response
550
500
450
400
0
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
55/77
Simulation with 50 second delay on Vcmd
x 10North-East
trajectories (simulation with delay)
4
x 10
Altitude trajectories (simulation with delay)
4
Reference
Simulation
1.6
2
1.55
0
WGS-84 Altitude (ft)
North coord. relative to RHC engagement (ft)
4
Reference
Simulation
-2
-4
-6
1.5
1.45
1.4
-8
1.35
-10
1.3
0
2
4
6
8
10
12
14
16
East coord. relative to RHC engagement (ft)
18
4
x 10
0
200
400
600
800
1000
1200
Time relative to RHC engagement (sec)
56/77
Important points
• Guidance-level control commanding a legacy autopilot.
• Objective is to track time-stamped position reference.
– Good speed control is critical.
– Must respect maneuvering limits.
• Online optimization by use of enabling software infrastructure.
– Quadratic programming based RHC using linearized prediction models.
– RHC API and anytime processes.
57/77
Summary
• Computational and real-time objectives accomplished.
• Deviation from reference trajectory
– Discrepancy between commanded and achieved speed response under piloted
throttle control.
– Receding horizon controller tries to “bleed off” time by fishtailing around
reference trajectory in the N-E plane.
– The experienced time delay in speed control response was 50-100 times
greater than anticipated.
– Very strong wind gusts in flight test area (~30 knots).
• Fault detection experiment
– Results very encouraging based on high-fidelity and HIL simulations.
– Flight tests unsuccessful due to issues in tracking and speed control.
• Flight test of RHC-based guidance controller showed
promising results for use in autonomous aircraft.
– Output constraints and reconfiguration implemented and tested in high fidelity
simulations.
58/77