MIT's Fan Embeds Math Barriers in AI to Prevent Robot Crashes

Stanford Robotics Seminar ENGR319 | Autumn 2026 | Bridging Rigorous Methods with Machine Learning — Stanford Online

Stanford Online

Autonomous systems fail under standard reinforcement learning because soft penalties prompt agents to freeze or crash, requiring hard neural barrier functions and active Bayesian falsification to guarantee real-world safety.

AI-assisted summary of Stanford Robotics Seminar ENGR319 | Autumn 2026 | Bridging Rigorous Methods with Machine Learning — original source. Check the original for full context.

Source published:

Key ideas

  • MIT researcher Chuchu Fan presents a closed-loop framework uniting formal synthesis (designing controllers with hard mathematical guarantees) and Bayesian falsification (actively uncovering rare failure modes). (5:06)
  • Neural constraint value functions formulated as Graph Control Barrier Functions (GCBFs) enable purely simulation-trained decentralized multi-agent policies to scale zero-shot to 1,000 agents and transfer directly to real hardware. (14:41)
  • Falsification is reframed from brittle optimization into Bayesian MCMC sampling over energy-based distributions, cutting testing evaluation costs tenfold across spaces reaching 250,000 dimensions. (39:07)
  • Retrospective failure analysis of the December 2022 Southwest Airlines meltdown isolated airplane reserve depletion at warm-weather hubs like Las Vegas and Dallas, disproving the official winter-storm narrative. (54:57)

Detailed notes

## Background This seminar was published by Stanford Online on YouTube on October 29, 2026, featuring MIT Associate Professor Chuchu Fan for the Stanford Robotics Seminar ENGR319. According to the page description, the session explores why learning-based controllers struggle with real-world deployment, introduces a framework bridging synthesis and falsification to guarantee safety as a structural policy property, and presents adaptive Bayesian active learning techniques to discover failure modes and stress-test autonomous systems.

## TL;DR Chuchu Fan outlines a unified methodology for autonomous robotics that pairs safe policy synthesis with active failure falsification. On the synthesis side, neural constraint value functions and temporal logic are converted into Control Barrier Functions and decomposed Bellman equations, enabling zero-shot scaling across multi-agent drone swarms, heterogeneous delivery systems, and autonomous vehicles without relying on soft penalty tuning. On the falsification side, she recasts safety testing from traditional optimization into high-dimensional Bayesian active inference and MCMC sampling to map multimodal risk landscapes. The talk illustrates how these testing frameworks uncover edge cases in autonomous driving, stress-test foundation models on disaster response triage, and conduct retrospective root-cause analysis on complex systemic disruptions like the 2022 Southwest Airlines meltdown.

## Atmosphere & style The presentation is intellectually rigorous, authoritative, and paced with academic clarity. Fan delivers her insights with a measured, matter-of-fact tone, punctuated by candid observations on real-world engineering realities, such as how poorly tuned agents learn to freeze rather than move safely. The visual rhythm shifts smoothly from dense mathematical control formulations to dynamic hardware demonstrations and real-world failure post-mortems, creating an engaging, deeply technical atmosphere focused on solving the fundamental fragility of modern autonomous systems.

## Bulletin - [05:06](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=306s) MIT researcher Chuchu Fan presents a closed-loop framework uniting formal synthesis (designing controllers with hard mathematical guarantees) and Bayesian falsification (actively uncovering rare failure modes). - [14:41](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=881s) Neural constraint value functions formulated as Graph Control Barrier Functions (GCBFs) enable purely simulation-trained decentralized multi-agent policies to scale zero-shot to 1,000 agents and transfer directly to real hardware. - [39:07](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2347s) Falsification is reframed from brittle optimization into Bayesian MCMC sampling over energy-based distributions, cutting testing evaluation costs tenfold across spaces reaching 250,000 dimensions. - [54:57](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3297s) Retrospective failure analysis of the December 2022 Southwest Airlines meltdown isolated airplane reserve depletion at warm-weather hubs like Las Vegas and Dallas, disproving the official winter-storm narrative.

## Key takeaways - [00:09](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=9s) Classical control theory guarantees safety and stability on explicit models but hits scalability bottlenecks, while modern machine learning scales to high dimensions but remains opaque and empirically unsafe. - [05:06](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=306s) Scalable provable autonomy requires two complementary pillars: rigorous design via formal synthesis and empirical evidence from automated falsification testing. - [13:16](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=796s) Soft penalties and Lagrangian relaxations in standard reinforcement learning cause catastrophic failures or degenerate behaviors like freezing when safety objectives conflict with task progress. - [14:41](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=881s) Formulating infinite-horizon safety as a constraint value function satisfies Bellman equations, mathematically proving that learned neural value functions can serve as valid Control Barrier Functions. - [14:41](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=881s) Graph Control Barrier Functions enable decentralized execution using local sensor graphs, scaling policies trained on 8 simulated agents up to 1,000 agents without centralized coordination. - [23:07](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1387s) Temporal logic formulas paired with large language model translation decompose complex missions into graphs of atomic Hamilton-Jacobi value functions trained independently or in parallel. - [27:37](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1657s) Real-world demonstrations show hard temporal constraints reliably enforce complex traffic rules at stop signs and yield zero-shot cooperative driving through unseen roundabouts. - [30:42](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1842s) Formal certificates inside design models cannot eliminate real-world failures due to unmodeled dynamics, necessitating active adversarial testing to discover latent blind spots. - [37:07](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2227s) Failures in autonomous systems span five distinct dimensions: distributional, reality (sim-to-real gap), contextual, normative, and retrospective. - [39:07](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2347s) Standard optimization algorithms fail to locate failure modes because failure landscapes are highly multimodal and non-convex, trapping optimizers in single local attractors. - [44:23](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2663s) Bayesian active inference guided by an acquisition function balancing Information Gain and User Utility maps complex topological risk landscapes under limited real-world test budgets. - [49:39](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2979s) Contextual edge cases synthesized by combining causal factors from historical crashes expose safety failures across leading autonomous driving stacks and multimodal foundation models. - [53:24](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3204s) Stress-testing multimodal LLMs on paired satellite imagery revealed that newer models like GPT-5.2 exhibited significantly higher output variance and sensitivity to minor perturbations than older models like GPT-4.1. - [58:53](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3533s) Conflicting hard constraints must be managed through formal priority hierarchies where physical collision avoidance strictly overrides nominal operational rules such as lane markings.

## Detailed walkthrough ### [00:09](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=9s) Bridging Rigorous Methods with Machine Learning

Chuchu Fan introduces the overarching focus of her lab: building safe and intelligent autonomy by creating a bridge between classical, rigorous methods and machine learning. She clarifies that highlighting "rigorous methods" is not meant to imply that machine learning lacks rigor, but rather to point out the distinct engineering trade-offs inherent in how both paradigms are traditionally formulated. Autonomous systems designers today—whether in robotics or engineering more broadly—are faced with a choice between classical approaches (such as control theory, formal methods, and optimization) and purely data-driven methods (such as deep reinforcement learning and large foundation models). While the boundaries between these fields are increasingly blending, engineers often find themselves having to trade off critical capabilities:

```mermaid flowchart TD accTitle: Classical vs Data-Driven Methods Tradeoff accDescr: Comparison of properties between classical formal approaches and modern data-driven machine learning methods. subgraph Classical["Classical Methods"] C1["Safety & Stability: By Design"] C2["System Model: Explicitly Required"] C3["Scalability: Limited by Complexity"] C4["Reasoning: Trackable & Interpretable"] C5["Guarantees: Mathematical Proofs"] end subgraph DataDriven["Data-Driven / ML Methods"] D1["Safety & Stability: Empirical Only"] D2["System Model: Learned from Data / Model-Free"] D3["Scalability: High Capacity"] D4["Reasoning: Opaque / Black-Box"] D5["Guarantees: Rare or Lacking"] end Classical <-->|"Trade-off Gap"| DataDriven ```

In classical control, core guarantees such as stability and safety hold *by design* based on the underlying theory and an assumed model of the system. In purely data-driven frameworks, however, safety metrics are largely empirical. While empirical performance may suffice in low-stakes scenarios, it is inadequate for safety-critical settings such as physical robots collaborating alongside humans. Conversely, classical methods suffer from severe scalability bottlenecks and are bounded by the fidelity of human-engineered models—recalling the adage that all models are wrong and diverge from reality. Machine learning excels precisely where classical methods fail by remaining model-free and learning directly from high-dimensional data, but it lacks interpretable reasoning. As Fan explains:

> “So this reasoning is not the reasoning mode of your large model. Although I do acknowledge that is reasoning. Although that reasoning is more of the datadriven based reasoning where we don't really know what they're reasoning about there they show you something but you if we use the classical approaches we have a way of understanding which components is supposed to do what what's the bottleneck when a problem arises there's a way for us to track now where these issues happen so I would say reasoning is tractable in classical methods but it's an emerging topic in machine learning and still people are defining what he means by reasoning and when it comes to being able to provide proofs and guarantees uh they are often there in the classical approaches however um in datadriven approaches we see that it's really rare that people are talking about proofs and guarantee they are harness but what I'm talking about this mathematically rigorous objects describing the guarantees we can have so the what we are looking we're looking at is this critical gap how do we provide build pro safety at scale in the sense like we don't want to compromise between the two.”

[05:06](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=306s) Two Complementary Paths: Rigorous Design and Falsification Testing

To eliminate the forced compromise between classical guarantees and data-driven scalability, Fan’s lab structures their autonomous systems research around two complementary pillars:

1. **Safety and Mission Satisfaction by Design (Synthesis):** Incorporating formal mathematical constraints directly into the learning framework. Rather than treating safety violations as soft cost penalties that can be traded off during optimization, constraints are embedded as hard mathematical requirements that the learned policy cannot violate. 2. **Understanding Failures by Testing (Falsification and Active Learning):** Recognizing that real-world deployment inevitably encounters edge cases not anticipated in any design-time model. To establish genuine trustworthiness, the system automatically discovers failure cases through targeted testing, identifying whether breakdowns stem from unmodeled environmental dynamics, missing requirements, or intrinsic physical limitations.

As Fan summarizes the core philosophy:

> “So in short the uh the rigorous uh the provable safe at scale is done by rigorous design and evidence from testing al together.”

[06:58](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=418s) Formulating Safe Synthesis as Constrained Optimal Control

Addressing the first pillar—safety and mission success by design—Fan formulates the autonomous mission as a constrained optimal control problem. The objective is to discover a policy that maximizes a chosen performance metric (or minimizes cost) while strictly adhering to safety specifications, even when the underlying robot system dynamics remain unknown to the designer at training time:

$$\max_{\pi} \quad J(\pi) \quad \text{subject to task and safety specifications, with unknown dynamics } \dot{x} = f(x, u)$$

To solve this class of problems at scale without relaxing constraints into soft penalties, Fan’s approach combines two elements: - **Hard Constraint Enforcement:** Enforcing safety and mission requirements throughout policy learning, refusing to allow constraint violations in exchange for higher rewards. - **Automated Task Decomposition:** Systematically breaking down complex, temporally extended tasks into modular components with formal reasoning to verify that compositionally fulfilling each subtask guarantees the satisfaction of the full overarching mission.

[08:52](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=532s) Motivating Scenario: Heterogeneous Autonomous Warehouse Logistics

To illustrate the challenge of enforcing complex, continuous constraints over an infinite time horizon, Fan presents an autonomous warehouse delivery environment involving heterogeneous multi-robot coordination. The setup pairs fast-moving aerial drones with ground-based quadruped robots to execute recurring supply pickups and drop-offs:

```mermaid flowchart LR accTitle: Heterogeneous Warehouse Workflow accDescr: Quadruped ground robots enter the warehouse to fetch packages and meet aerial drones at corridors for drop-offs. subgraph Warehouse["Warehouse Interior (No-Fly Zone)"] W1["Ground Quadruped fetches incoming packages"] end subgraph Corridor["Transfer Corridor"] C1["Quadruped carries package on back"] C2["Aerial Drone rendezvouses with Quadruped"] C1 -->|"Hand-off"| C2 end subgraph Delivery["External Delivery Route"] D1["Aerial Drone flies fast to deliver payload"] end W1 --> C1 C2 --> D1 ```

The system is governed by strict, persistent constraints that must hold indefinitely rather than for a single episode: - **Collision Avoidance:** Aerial drones and ground robots must continuously avoid physical collisions with obstacles and each other. - **Geographic Restrictions & No-Fly Zones:** The ground quadrupeds are physically restricted to specific transit lanes (akin to bus routes), while the warehouse interior is a strict no-fly zone forbidden to aerial drones. - **Infinite-Horizon Recurrence:** Because packages arrive non-stop, ground quadrupeds must repeatedly re-enter the warehouse, haul cargo to designated transfer points, rendezvous with drones, and hand off payloads. Drones must repeatedly track down suppliers, retrieve cargo, and complete deliveries. - **Resource Constraints (e.g., Battery Lifetimes):** Ground and aerial units must monitor their state-of-charge, cycling to charging pads or swapping roles with fully charged robots before depletion.

Fan emphasizes that these requirements cannot be treated as optional soft objectives. The goal of their design framework is to synthesize a purely learning-based policy that operates directly within these constraints, guaranteeing that the mission succeeds without ever breaching a safety threshold.

[11:02](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=662s) Mathematical Abstraction: Two Core Challenges in Safe Multi-Agent Autonomy

To bridge rigorous control with learning-based techniques, two fundamental mathematical challenges must be resolved. The first is enforcing safety and stability as hard constraints throughout the learning and control process. The second is managing complex objectives or mission goals where hand-crafting a monolithic reward function that permanently satisfies delivery constraints and dynamic tasks is impractical.

```mermaid flowchart TD accTitle: Two Challenges in Safe Multi-Agent Learning accDescr: Flowchart illustrating the decomposition into safety constraints and mission goals for decentralized agents.

subgraph Problem["Mathematical Problem Formulation"] C1["Challenge 1: Enforce Hard Safety & Stability"] C2["Challenge 2: Complex Task Objectives"] end

subgraph MultiAgent["Decentralized Multi-Agent System"] A1["Agent 1 Policy: Local Observations"] A2["Agent 2 Policy: Local Observations"] AN["Agent N Policy: Local Observations"] end

Problem --> MultiAgent MultiAgent --> JointGoal["Joint Optimization: Maximize Objective subject to Hard Constraints"] ```

Scaling this problem requires a multi-agent formulation. In realistic deployments, robotic fleets are heterogeneous, composed of distinct robot types that must execute local sub-missions while collaboratively pursuing a shared global objective. Centralized controllers cannot scale to large numbers of robots. Instead, agents must execute decentralized, distributed policies driven strictly by local observations. The system must jointly maximize a shared performance objective or reward function subject to safety constraints defined over local observations, operating over unknown underlying system dynamics:

- Multi-agent scale requires decentralized execution where each agent acts solely on local observations (e.g., cameras or LiDAR). - A shared task objective must be maximized jointly across heterogeneous platforms without centralized coordination. - Safety constraints are modeled as functions over local observations, allowing flexibility up to and including human-labeled safe/unsafe states. - The underlying physical dynamics of the agents and environment are treated as unknown during the formulation.

---

[13:16](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=796s) Why Soft Constraints and Lagrangian Relaxation Fail in Safety-Critical Robotics

In conventional reinforcement learning (RL), safety constraints are routinely converted into soft penalties or addressed via Lagrangian duality methods. This converts hard boundaries into multi-part reward or cost functions. In practice, tuning the associated hyperparameter weights is notoriously brittle: coefficients that succeed in one operating condition completely fail when environmental dynamics shift.

```mermaid flowchart LR accTitle: The Failure Mode of Reward Penalty Formulations accDescr: Diagram showing how soft penalties lead to freezing behaviors due to conflicting objectives.

subgraph StandardRL["Conventional RL Approach"] Hard["Hard Safety Constraint"] --> Soft["Soft Penalty / Lagrangian Dual"] Soft --> Monolithic["Multi-Part Cost Function"] end

subgraph FailureMode["Deployment Bottleneck"] Monolithic --> Hyper["Hyperparameter Tuning Gridlock"] Hyper --> Conflict["Mission vs. Safety Conflict"] Conflict --> Freeze["Degenerate Policy: Agent Freezes or Crawls"] end ```

This structural flaw becomes severe when safety conflicts directly with mission progress. Chuchu Fan emphasizes this trade-off:

> “The best way to be safe is to not move.”

In autonomous driving, for instance, heavily penalizing collisions causes the vehicle to stop entirely or crawl at impractical speeds, severely degrading task performance. To overcome this, hard constraints must be preserved structurally rather than treated as soft penalties.

---

[14:41](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=881s) Neural Constraint Value Functions as Graph Control Barrier Functions

Rather than penalizing collisions softly, the system leverages a specific formulation known as the constraint value function. Defined mathematically as the minimum of a safety margin function $h$ over an infinite time horizon, this value function satisfies a Bellman equation. This property allows it to be solved via traditional optimal control when a model is known, or via RL value iteration when dynamics are unknown. Crucially, this constraint value function is theoretically proven to be a Control Barrier Function (CBF).

```mermaid flowchart TD accTitle: Control Barrier Function Operation accDescr: Pipeline of a Control Barrier Function mapping states to scalar values and filtering control actions.

subgraph Evaluation["CBF Evaluation"] State["State / Sensor Inputs"] --> CBF["Constraint Value Function (CBF / GCBF)"] CBF --> Margin["Scalar Margin: Positive = Safe, Negative = Unsafe"] end

subgraph ActionFiltering["Action Space Filtering"] Margin --> Bound["Action Boundary Computation"] Bound --> Action["Safe Permissible Actions: e.g., Velocity Limits"] end ```

In control theory, a Control Barrier Function takes a high-dimensional state—including environmental context—and outputs a scalar value that is positive in safe regions and negative in unsafe regions. By monitoring this boundary, the CBF computes the exact permissible action space (such as safe velocity envelopes for a vehicle avoiding a hazard) that guarantees the existence of a safe continuation path. For partially observable, decentralized multi-agent fleets, this value function generalizes into a Graph Control Barrier Function (GCBF):

- The constraint value function computes $\min_{t \ge 0} h(x(t))$, directly evaluating whether safety holds across an infinite horizon. - It satisfies a Bellman equation, enabling solution via dynamic programming or reinforcement learning value iteration without analytical system models. - For decentralized swarms, the formulation yields a Graph Control Barrier Function (GCBF). - Each agent evaluates safety locally via its immediate neighborhood graph, while their joint execution provably maintains global system-level safety invariants.

---

[17:48](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1068s) Zero-Shot Scalability and Robust Sim-to-Real Hardware Transfer

Formulating safety as a Graph Control Barrier Function yields strong generalization across multi-agent configurations. Because policies rely entirely on local observations within a decentralized graph, policies trained in simulation on small groups transfer directly to substantially larger fleets and entirely new objects without retraining.

```mermaid flowchart TD accTitle: Training to Deployment Generalization accDescr: Generalization of decentralized policies from small-scale simulation training to massive swarms and hardware deployment.

subgraph SimulationTraining["Simulation Training"] Sim["Small Fleet: 3 to 8 Agents, Co-carrying Objects"] end

subgraph ScaledEvaluation["Zero-Shot Scaling"] Scale1["Hardware: 6 Heterogeneous Agents Carrying New Payloads"] Scale2["Simulation: 1,000+ Agents Navigating Dense Obstacles"] F16["Full-Scale F-16 Aircraft Close-Formation Flight"] end

Sim --> Scale1 Sim --> Scale2 Sim --> F16 ```

In multi-drone collaborative transport—where aerial vehicles must co-carry payloads that exceed individual capacity while avoiding mutual aerodynamic downwash, maintaining distance bounds, and dodging obstacles—policies trained on only 3 to 5 drones generalize seamlessly to 6 or more drones carrying novel payloads. In large-scale navigation, agents trained exclusively with 8-agent setups scaled up to 1,000 agents in simulation, navigating dense obstacle fields while maintaining state-of-the-art success rates.

The safety barrier abstraction functions as an inherent margin of robustness against unmodeled dynamics, enabling zero-shot simulation-to-real transfer:

> “We actually train everything in simulation. We never collect real data to do training. Everything was trained in simulation. Of course, the model will not be accurate. But when we deploy them on hardware, the robustness that we’re able to build will be able to handle like the wind disturbance or other adversarials.”

- **Cooperative Drone Transport:** Fleets maintain precise inter-agent separation to avoid mutual aerodynamic downwash and obstacle collisions while moving shared payloads. - **Extreme Swarm Scaling:** Policies trained on 8 agents generalize to thousands of agents simultaneously navigating complex obstacle environments. - **Target Tracking & Inspection:** Dual-robot systems maintain continuous camera visibility of moving targets within strict inspection zones. - **High-Fidelity Aerospace Applications:** Pairs of full-scale F-16 jet models execute close-formation maneuvers—reminiscent of safety boundaries from *Top Gun*—ensuring trailing aircraft remain within safe following envelopes without colliding into engine exhaust or jet wash. - **Physical Hardware Robustness:** Drone policies trained strictly in simulation without real-world telemetry autonomously reject physical wind gusts, track dynamic trajectories, and execute precision landings on moving platforms.

[21:20](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1280s) Enforcing Hard Constraints and the Limits of Existing Methods

Once a safety certificate is represented and integrated directly into the machine learning pipeline, reinforcement learning (RL) algorithms can be guided to enforce hard constraints rather than treating safety as a soft penalty. The resulting value function serves as a portable, explicit safety certificate that can even be transferred to other systems. However, this alone does not resolve the challenge of expressing and executing highly complex mission objectives. Returning to real-world tasks like autonomous package delivery, the field still struggles to systematically encode complex goals:

```mermaid flowchart TD accTitle: Approaches to Complex Task Objectives accDescr: Flowchart contrasting Classical Control, Standard RL or MPC, Large Models, and the Value Decomposition approach.

Goal["Complex Mission Objective"] --> CC["Classical Control / Temporal Logic"] Goal --> RL["Standard RL / MPC"] Goal --> LM["Large Models / Vision-Language Models"] Goal --> VD["Proposed: Value Decomposition"]

CC --> CC_Fail["Fails in high-dimensional state spaces"] RL --> RL_Fail["Costly reward tuning; objective misalignment"] LM --> LM_Fail["Requires vast data; unavailable for novel tasks"] VD --> VD_Success["Decomposes rigorous logic into parallel Bellman tasks"] ```

Classical control uses formal languages like temporal logic, but these methods break down when applied to high-dimensional systems. Standard RL or Model Predictive Control (MPC) requires extensive trial-and-error reward shaping or cost tuning, which incurs heavy financial costs and frequently introduces reward misalignment—where the policy optimizes the surrogate reward rather than the true mission intent. As for foundation models or vision-action models (VLMs), they demand massive datasets that simply do not exist for rare or specialized autonomous missions. As Chuchu Fan emphasizes: “What if you don't have data at all? How should I start? Then I at least need have something to generate the data for me.” The solution lies in identifying the exact mathematical object being learned—the value function—and decomposing it systematically.

[23:07](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1387s) Temporal Logic and Value Decomposition

To specify intricate multi-stage tasks, missions can be formulated in temporal logic, a rigorous symbolic framework capable of expressing infinite horizons, strict timing windows, logical dependencies, and recurrent behaviors (such as continuously picking up and delivering packages). It precisely captures complex rules: agents revisiting drop-off locations, ground delivery vehicles returning to warehouses, and vehicles respecting no-fly zones. Translating natural language into formal temporal logic used to be a bottleneck, but modern large language models handle the translation seamlessly. Fan notes that while she published research three years earlier on translating English instructions into temporal logic using models like GPT-3.5, “at that time I already knew that that work probably wouldn't have any long-term meaning because the newer generation of the model would be more powerful and now I think you can pretty confidently ask large language model to do the translation for you.”

With the temporal logic specification established, the task is addressed via **value decomposition**. Because temporal logic possesses well-defined syntactic and semantic grammar rules, any specification can be recursively broken down into a hierarchy of fundamental sub-tasks:

```mermaid flowchart TD accTitle: Value Decomposition Graph Architecture accDescr: Diagram illustrating how a high-level temporal logic formula is decomposed into parallel atomic Hamilton-Jacobi value functions.

TL["Temporal Logic Mission Formula\n(e.g., Reach A, Reach B, Always Avoid Walls)"]

subgraph Decomp ["Grammar-Based Decomposition"] D1["Disjunction / Conjunction Rules"] D2["Reach-Avoid Tasks"] D3["Recurrent Tasks (Global / Until)"] end

subgraph Atomic ["Atomic Hamilton-Jacobi Value Nodes"] A1["Node 1: Atomic Bellman Equation"] A2["Node 2: Atomic Bellman Equation"] A3["Node 3: Atomic Bellman Equation"] end

Policy["Distributed Execution Policy\n(Provable Satisfaction Guarantee)"]

TL --> Decomp Decomp --> A1 Decomp --> A2 Decomp --> A3 A1 & A2 & A3 -->|"Simultaneous Parallel Learning & Bootstrapping"| Policy ```

- **Reach-Avoid Tasks:** Directing the agent to achieve a target set while steering clear of unsafe sets. - **Recurrent Tasks:** Mandating behaviors that must repeat indefinitely over an infinite horizon. - **Disjunction Handling:** Disjunctive requirements permit parallel evaluation; satisfying either branch fulfills the clause. - **Atomic Hamilton-Jacobi (HJ) Values:** Leaf nodes resolve into atomic value functions governed by known Bellman equations, enabling standard RL algorithms to train them independently or search them in parallel. - **Cross-Node Bootstrapping:** Implicit value relationships bootstrap across graph nodes during simultaneous training; during execution, agents query the decomposed graph to execute control policies that provably guarantee specification satisfaction. - **Scalability:** In simulation benchmarks, agents scale up to tracking and visiting 100 sequential targets while maintaining near-perfect success rates.

[27:37](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1657s) Real-World Demonstrations: Shepherding, Drone Delivery, and Autonomous Driving

To demonstrate the versatility of value decomposition, Fan presents three distinct robotic applications:

1. **Multi-Robot Shepherding:** A heterogeneous team consisting of a slower ground quadruped and a agile aerial drone acts as "sheepdogs." The "sheep" are non-cooperative drones programmed simply to flee from the dogs. The dogs execute a distributed policy where active constraints dynamically highlight: they cooperatively squeeze the sheep through a boundary gate, drive them into a circular pen, and hold them there indefinitely. 2. **Infinite-Horizon Ground-Air Delivery:** In physical hardware experiments, a large autonomous ground vehicle patrols warehouse zones while smaller delivery drones repeatedly rendezvous with it. The drones touch down to collect cargo, launch toward designated delivery zones, and cycle back to the ground vehicle indefinitely, maintaining robustness across fluctuating physical environments and hardware parameters. 3. **Autonomous Driving under Formal Traffic Rules:** Every official traffic rule can be translated mathematically into a temporal logic formula. By embedding these rules directly as hard constraints during single-car training over diverse road geometries, the policy learns strict compliance with stop signs and traffic signals:

> “Believe it or not, stop sign is actually a pretty complicated rule to enforce: you have to stop, you have to look at all your surroundings, and decide when you are safe to pass.”

When interacting with surrounding vehicles displaying aggressive, conservative, or rule-violating behaviors, the autonomous agent preserves absolute rule compliance. Remarkably, the policy exhibits zero-shot generalization to environments outside its training distribution. Although the policy was never trained on a traffic circle (roundabout), the combined rules of avoiding rear-end collisions and managing right-of-way allowed the vehicles to safely and cooperatively negotiate roundabouts.

[30:42](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1842s) The Inevitability of Failures

The first phase of the synthesis framework demonstrates that mission objectives, safety envelopes, and stability requirements can be formulated as structured, computable value functions. By breaking down complex formulas into atomic Bellman equations, policies are synthesized with rigorous mathematical certificates—such as Control Barrier Functions (CBFs), Lyapunov functions, and temporal logic guarantees.

Yet, this mathematical completeness does not mark the end of the engineering problem. Fan cautions that formal guarantees inside a model are never a silver bullet in the physical world: “However, it's not the end of the story, because no matter how hard we try, failures will [occur].” Real-world uncertainty, distribution shifts, and unmodeled environmental interactions inevitably expose safety gaps, necessitating an equally rigorous framework to actively search for, test, and falsify policies.

[31:43](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1903s) Mathematical Formulation of Testing: Design Parameters vs. Exogenous Parameters

Chuchu Fan begins by emphasizing a fundamental reality of autonomous engineering: no system is completely immune to breakdowns. As she puts it:

> “I don't think there is a system that never fail.”

Instead of fruitlessly chasing impossible perfection, her approach shifts perspective to understand precisely when and why systems fail. Mathematically, whether dealing with an isolated component, a complex system-of-systems, a simulator, or physical hardware, the system's behavior is governed by two distinct classes of inputs:

1. **Design parameters**: These are the internal, tunable variables that engineers choose and optimize (for instance, using synthesis methods) to minimize a broad cost function $J$ representing goals, constraints, and physical limits. 2. **Exogenous parameters**: These are external environmental factors that cannot be directly controlled—such as terrain, lighting, weather conditions, or unpredictable humans who actively disregard safety protocols. While engineers can enforce internal constraints when dynamics are known, there is no mathematical guarantee against an uncooperative agent who refuses to comply.

In this formalization, policy design aims to find the design parameters that minimize cost $J$ under assumptions about the outside world. Conversely, testing (or falsification) searches for the exogenous parameters that maximize $J$, pushing the system into violation of safety limits, uncompleted missions, or catastrophic failure. Because design assumptions are never flawless, testing identifies the blind spots that designers overlooked.

```mermaid flowchart LR accTitle: System Parameter Interaction accDescr: Diagram contrasting how design parameters minimize system cost while exogenous parameters are searched during testing to maximize cost and expose failure modes.

subgraph Inputs["System Parameter Inputs"] DP["Design Parameters<br/>(Tunable: policies, controller gains)"] EP["Exogenous Parameters<br/>(External: weather, terrain, agents)"] end

SYS["Autonomy System / Simulator<br/>Cost Function J(·)"]

subgraph Objectives["Dual Objectives"] MIN["Design Goal:<br/>Minimize Cost J"] MAX["Testing Goal:<br/>Maximize Cost J (Induce Failure)"] end

DP --> SYS EP --> SYS SYS --> MIN SYS --> MAX ```

---

[34:06](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2046s) The Landscape of Verification, Validation, and Testing (V&V / T&E)

Engineers rely on Verification and Validation (V&V) and Testing and Evaluation (T&E) to evaluate autonomous performance. Across the literature, existing approaches navigate a three-way tradeoff between robustness, flexibility, and efficiency:

* **Formal methods (e.g., reachability analysis, optimization-based verification):** These techniques offer high robustness because they compute rigorous over-approximations of system behavior to formally prove safety. However, they lack flexibility, typically scaling only to small polynomial dynamical models, failing on black-box systems, and demanding prohibitive computational cost. * **Black-box learning and testing:** Popularized by large-model and reinforcement learning communities, this paradigm uses black-box optimization or adversarial RL agents without making structural assumptions about the underlying model. While highly flexible, it sacrifices robustness; because it relies on best-effort heuristics, failing to find a crash yields no rigorous certificate of safety. * **White-box and domain-specific simulators:** By taking advantage of differentiable simulation platforms, these tools strike a practical compromise, speeding up gradient-based search while preserving domain physics.

Fan points out the real-world consequence of relying on naive testing without formal robustness:

> “Well, if you don't have a robustness, you ended up driving a self-driving car forever on the road hoping that you will see a a tricky case.”

Her group's goal is to break these tradeoffs: preserving flexibility for complex black-box systems, achieving efficiency by generating high-coverage test cases at low computational cost, and ensuring robustness by quantifying residual risk and diagnosing failure boundaries rather than relying on luck.

---

[37:07](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2227s) Five Levels of Failure in Autonomous Systems

To systematically diagnose autonomous systems, Fan categorizes failures across five progressive dimensions:

* **Distributional failure:** Answering *"Where does it fail?"* by mapping out the statistical distribution and parameter regions where failures cluster. * **Reality failure (Sim-to-Real gap):** Evaluating whether a failure identified in simulation or on a lower-fidelity model actually manifests on physical hardware. * **Contextual failure:** Addressing the ambiguous question of *"What counts as a failure?"* For some operators, failure means failing to reach a destination in time; for others, it means bumping into a forbidden obstacle. Formulating precise semantic failure criteria is itself a significant hurdle. * **Normative failure:** Calibrating system behavior across multi-stakeholder groups to decide whose preferences and safety margins take precedence during testing and deployment. * **Retrospective failure:** Performing root-cause analysis after an incident has occurred. This entails isolating hidden environmental or state variables that triggered the crash, allowing engineers to monitor these precursor signals online or synthesize targeted test benches.

---

[39:07](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2347s) Recasting Failure Discovery: From Optimization to MCMC Sampling

Standard falsification treats finding a failure as a mathematical optimization task: searching for the exogenous parameter vector $Y$ that maximizes the failure cost function $J$. However, optimization routines reliably break down in practice because failure landscapes are fundamentally multimodal. As Fan explains:

> “Failure is a multiode case. failure could be caused by many different reasons and they they can appear in different ways and if I look at this optimization problem to generate test cases I'm really having a non-convex like a super non-convex with multiple optima if I use an optimization based approach even if there are hyper heristics to help you get rid of the getting stuck at local optima you will eventually get this what we call the region of attraction meaning where you start to test will always land to that particular ular failure and you will be bland about the other failures that could happen.”

When gradient-based or local heuristic optimizers search a non-convex failure landscape, their starting points trap them within specific regions of attraction, blinding the tester to distinct, alternative failure modes.

To overcome this limitation, Fan recasts falsification from an optimization problem into a probabilistic sampling problem over a posterior distribution. By treating test case generation as sampling from a posterior failure distribution, the search avoids getting permanently trapped in a single local optimum; different sampling paths retain non-zero probability of discovering separate modes across the parameter space.

Formally, the framework uses Bayesian inference: * The **prior** incorporates the designer's initial domain beliefs about which parameter spaces are risky or benign. * The **likelihood** measures how readily a parameter set produces high cost, commonly approximated via an energy-based exponential formulation: $$\text{Likelihood} \propto \exp(J)$$ * **Markov Chain Monte Carlo (MCMC):** Starting from the prior and updating through simulated system rollouts, MCMC chains generate diverse samples directly from high-cost, high-probability failure regions of the posterior, leveraging simulator gradients whenever available.

[42:32](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2552s) High-Dimensional Failure Generation and Racing Car Obstacle Avoidance

When exploring failure spaces across design and exogenous parameters, the availability of gradient information shapes the sampling strategy: gradient-based methods accelerate the discovery process, while model-free sampling variants handle scenarios where gradients are inaccessible. Chuchu Fan explains that this methodology has been evaluated across a wide cluster of applications where the design parameters ($X$) and exogenous parameters ($Y$) scale into the thousands or reach up to nearly a quarter-million dimensions. Across these high-dimensional benchmarks, the active sampling approach cuts testing costs by an order of magnitude: “able to see that our method can achieve a 10 times lower cost compared to other approaches to generate the diverse failure cases.” Furthermore, when those generated failures are fed back into repairing the underlying system, the process yields a five-fold boost in system robustness.

```mermaid flowchart LR accTitle: Racing Car Double-Obstacle Failure Scenario accDescr: A vehicle evades an initial obstacle but gets channeled into an unavoidable second collision. subgraph Scenario ["Racing Scenario"] A["Obstacle 1 Avoidance"] --> B["Vehicle Swerves Right"] B --> C["Unavoidable Collision with Obstacle 2"] end subgraph Analysis ["Risk Profiling"] C --> D["Failure Probability Map"] D --> E["Quantified Risk Landscape"] end ```

To ground this setup, Fan presents a concrete example involving a racing car guided by a sampling-based controller. Because sampling-based controllers are intrinsically stochastic, backpropagating gradients through them to perform optimization-based falsification is impossible. The testing objective is to determine precisely where obstacles can induce collisions for this well-tuned system. Rather than merely flagging isolated collision points, the algorithm maps out regions accompanied by explicit failure probabilities. In one demonstrated scenario featuring two obstacles, the vehicle swerves to evade the first obstacle, only to be forced into an unavoidable wreck against the second. Assigning failure probabilities to each spatial configuration produces a comprehensive risk profile for evaluating the autonomy stack.

- Design ($X$) and exogenous ($Y$) parameter spaces scale up to approximately 250,000 dimensions in benchmark testing. - Generating failure suites with this active formulation achieves a 10x reduction in evaluation cost compared to baseline techniques. - Incorporating these discovered failure modes into system repair yields a 5x improvement in operational robustness.

[44:23](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2663s) Why Classical Testing Fails: The Move to Bayesian Active Inference

Despite these successes, Fan emphasizes that standard posterior sampling relies on shaky assumptions: “A lot of people will immediately say that um well, I don't know a J, right?” In physical deployments, practitioners rarely have access to an accurate prior, simulation-to-real gaps distort system models, collecting real-world failure data is prohibitively expensive, and formalizing a scalar cost function ($J$) is notoriously hard. When working with engineers on complex systems like mobile manipulators, design requirements are buried in dense documentation where balancing task success, clearance margins, dexterous handling, and requests for human intervention cannot be collapsed into an analytical objective. Classical falsification treats testing as a rigid search for counterexamples or witnesses against a predefined metric, producing static compliance checklists that offer false security: “but we know passing those tests does not mean that you are guaranteed to be safe.”

```mermaid flowchart TD accTitle: Closed-Loop Active Inference Testing Cycle accDescr: The iterative loop between querying a system, assessing outcomes, learning risk models, and generating test cases. subgraph Execution ["1. Execution & Evaluation"] SYS["System / Simulator / LLM"] -->|"Output Trajectory / Answer"| ASSESS["Assessment Engine (Human or VLM/LLM)"] end subgraph Modeling ["2. Learning & Optimization"] ASSESS -->|"Evaluated Risk Labels"| SURR["Risk Prediction Model / Surrogate"] SURR -->|"Active Inference"| ACQ["Acquisition Function Optimization"] end subgraph Generation ["3. Test Selection"] ACQ -->|"Information Gain + User Utility"| GEN["Generate Next Test Scenario"] GEN -->|"Query"| SYS end ```

To break this impasse, the problem is reframed from a search process into an active Bayesian inference framework. Instead of seeking binary violation witnesses, the algorithm samples from a posterior distribution conditioned on existing system knowledge to trace an entire risk landscape showing where failures cluster and what triggers them. The architecture establishes a closed test-assess-learn-generate loop. A query is submitted to the target system—which can be a simulator, a physical robot, or a large foundational model—producing an outcome such as a trajectory or textual response. An evaluator assesses this output, providing objective or subjective feedback on perceived risk. That assessment updates a failure prediction surrogate model $P(\text{risk} \mid \text{parameters})$, which in turn guides the next acquisition query.

- Classical testing outputs discrete counterexample witnesses; inference-based testing constructs an entire topological risk landscape. - To bypass hand-crafted or inaccurate prior distributions, the framework leverages variational inference. - The active acquisition function balances two complementary objectives: - **Information Gain:** Drives the selection of queries that maximize uncertainty reduction regarding system boundary limits. - **User Utility:** Directs the search toward failure regimes that human operators or safety engineers prioritize. - The overarching pipeline transmutes sparse initial evidence (simulations, past incident reports, sparse hardware trials) into deployable proof of operational limits.

[49:39](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2979s) Contextual Failures, Surrogate Models, and LLM Disaster Decision Testing

Many real-world failures are inherently contextual and subjective. In robotic manipulation, for instance, defining failure mathematically is tricky: an aggressive grip may guarantee dynamic stability while simultaneously risking structural damage to a delicate object. Because human operators cannot spend all day labeling complex edge cases, Fan notes a key operational substitution: “Actually in all of our work we replace that human with large models because we think they are pretty good at uh providing assessment about if this is a failure they want to see or if you there are particular things about the failure they want to talk about.” These evaluations train surrogate models across distinct failure modes, allowing the scenario generator to systematically cover combinations of failure sources—such as compounding sensor noise, extreme lighting changes, and camera depth misinterpretations—at varied severity levels.

```mermaid flowchart LR accTitle: Disaster Response LLM Decision Profiling accDescr: Inputs of tweets and satellite imagery are evaluated by LLMs for disaster triage, guided by an acquisition utility. subgraph Ingestion ["Disaster Data Ingestion"] T["Social Media Tweets"] --> LLM["Disaster Response LLM"] S["Satellite Imagery"] --> LLM end subgraph Evaluation ["Response Assessment"] LLM -->|"Mitigation Directives"| EVAL["Difficulty & Confidence Assessment"] EVAL -->|"Utility Metric"| MAP["Decision Boundary Mapping"] end ```

In autonomous driving, this methodology synthesizes novel edge cases by recombining ingredients from separate real-world incidents. Fan highlights a scenario that synthesizes the causal factors of five historical autonomous vehicle crashes into a single synthesized challenge that none of today's leading self-driving stacks could clear, despite the exact combined sequence never having occurred in history. Extending this beyond robotics, the team evaluated large language models deployed for disaster response triage. Tasked with reading satellite images and social media tweets to allocate constrained humanitarian resources under high pressure, the system does not measure failure as a simple binary crash. Instead, mission utility tracks decision difficulty against model confidence. Clear tweets loaded with actionable facts produce high-confidence, low-difficulty decisions, whereas ambiguous, contradictory, or fragmented emergency feeds expose critical blind spots in automated operational guidance.

- Real-world autonomous vehicle failures are synthesized by stitching together causal vectors drawn from multiple recorded incident reports. - Foundation models serve as surrogate evaluators, replacing human annotators in scoring nuanced, non-binary robotic failures. - In disaster management stress testing, the acquisition utility categorizes prompt regimes into high-confidence easy choices versus low-confidence ambiguous inputs to map the reliability envelope of foundational models.

[53:24](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3204s) Stress-Testing Multimodal LLMs in Disaster Response

Professor Chuchu Fan examines how large language models handle complex disaster response scenarios. Under certain disaster conditions, an LLM might exhibit high confidence when generating actionable mitigation plans, while in other challenging cases, the situation is characterized by high difficulty and low confidence. In those ambiguous scenarios, incoming data indicates that urgent rescue interventions are necessary, yet determining the exact actionable steps remains uncertain. By feeding pre-disaster and post-disaster satellite imagery into the pipeline, the framework evaluates both low-difficulty/high-confidence and high-difficulty/low-confidence cases.

Using real satellite imagery from Hurricane Florence, the model can generate high-confidence action recommendations. However, the framework is not limited to real historical archives; it can also artificially synthesize paired pre- and post-disaster satellite imagery specifically crafted to stress-test the LLM and uncover cases where its outputs should not be trusted. As Fan warns, “We can generate pre and post satellite images to tell you this will really stress test your LLM and in this case you shouldn't trust what LLM is going to say.”

Evaluating different frontier models reveals surprising variations across generations. While comparing model behaviors, Fan notes that more advanced models such as GPT-5.2 are not necessarily more trustworthy, as their recommended actions can become highly sensitive to slight input perturbations and scatter broadly across the action space. In contrast, older iterations like GPT-4.1 demonstrate lower variance, reliably offering consistent recommendations across different types of inputs.

- Synthetic and real pre- and post-disaster satellite imagery are used to evaluate action suggestions (highlighted as purple recommendations). - Advanced models can display extreme output variance and high sensitivity to input perturbations, undermining real-world trustworthiness. - Consistent output distribution across varied inputs is critical before deploying LLMs for disaster triage and physical rescue planning.

---

[54:57](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3297s) Retrospective Failure Analysis: The 2022 Southwest Airlines Meltdown

Turning to retrospective failure analysis, Fan examines real-world system collapses where operators have no simulator or access to rerun the system, leaving only observational historical data to audit. A relatable example is widespread flight cancellations and delays, where passengers are stranded without clear insight into what triggered the breakdown or who made the operational calls. Fan grounds this challenge in the infamous December 2022 Southwest Airlines scheduling crisis, during which thousands of flights were canceled across Christmas week, stranding over two million travelers across the United States.

```mermaid flowchart TD accTitle: Southwest Airlines Meltdown Causal Analysis accDescr: Diagram illustrating how the initial Denver storm led to cascading nationwide reserve shortages in Las Vegas and Dallas.

subgraph Trigger["Initial Trigger"] A["Denver Winter Storm<br>(De-icing Delays)"] end

subgraph Impact["Observed Effects"] B["Denver Airport Reserve:<br>Sharp Dip, Rapid Recovery"] C["Las Vegas & Dallas Reserves:<br>Cascading Unrecovered Shortages"] end

subgraph Outcome["System Breakdown"] D["System-wide Cancellations<br>(2M+ Stranded Passengers)"] end

A --> B A --> C C --> D ```

Southwest leadership attributed the nationwide cascade entirely to an initial winter storm and de-icing delays in Denver. However, Denver was the only airport facing severe weather, while the rest of the country enjoyed clear operating conditions. Meanwhile, the Southwest Airlines Pilots Association (SWAPA) blamed executive leadership, and media outlets pointed to legacy scheduling software networks.

Without an internal simulator, Fan's team applied their test-case and failure-generation methodology directly to the historical flight data to uncover the hidden operational bottleneck. Their analysis pinpointed airplane reserve—the number of aircraft each airport maintains overnight to service the following day’s schedule—as the critical latent variable. While Denver’s airplane reserves dipped and then rebounded quickly following the storm, major hubs such as Las Vegas and Dallas that experienced clear weather saw their reserves steadily deteriorate over the entire week. This hidden depletion starved the downstream network of aircraft and triggered the nationwide collapse.

- Over thousands of flights were cancelled and two million passengers stranded during Christmas week 2022. - Airplane reserve was mathematically inferred across major hubs because actual reserve targets were never made public. - Denver's fleet reserve stabilized rapidly post-storm, whereas unimpacted hubs (Las Vegas and Dallas) suffered compounding reserve shortages that directly drove cancellations.

---

[57:51](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3471s) Unifying Rigorous Verification with Data-Driven Machine Learning

Fan synthesizes the seminar's core message: building dependable autonomy requires unifying two complementary paradigms. On one side is safety and mission satisfaction by design (synthesizing control policies with mathematical safety guarantees); on the other is generating empirical counterexamples through active, adaptive testing. While each paradigm probes different facets of system dynamics and environmental parameter spaces, integrating them bridges classical formal methods with modern data-driven learning.

This unified approach allows roboticists to build large-scale autonomous systems that operate with mathematical guarantees rather than unverified empirical hopes. Fan concludes her talk by stating that combining these approaches will “enable us to build systems at large scale that are safe by design, scalable by architecture and reliable by proof.”

- Safety by design guarantees that policies satisfy known bounds and certificates mathematically. - Active falsification discovers unmodeled parameter spaces and rare-event failures that violate baseline assumptions. - Bridging formal methods with reinforcement learning grounds empirical neural models in structural stability.

---

[58:53](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3533s) Q&A: Handling Contradictory Hard Constraints and Unavoidable Adversaries

During the question-and-answer session, an audience member raises a practical dilemma regarding hard safety constraints: what happens when safety constraints become contradictory in real-world edge cases? The audience member illustrates this using an autonomous driving scenario where an oncoming car veers into the ego vehicle’s lane. To avoid a catastrophic head-on crash, the vehicle must swerve into the opposing lane, thereby violating lane-keeping rules. The attendee asks how the framework arbitrates situations where not all hard constraints can be simultaneously upheld.

Fan clarifies the boundary between mathematical specification and design assumptions. Hard constraints strictly enforce whatever the engineer explicitly defines as invariant within the model: “when we say the safety are hard constraints there are hard constraints on whatever you define as safety right like as I said why the reason we need testing is there are always cases we cannot imagine at the design phase so we have to understand when they fail because certain certain assumptions we make on the design phase got broke.”

If both collision avoidance and strict lane-keeping are hard-coded with equal priority, the mathematical solver will find the problem infeasible when an unavoidable hazard appears, leaving no escape trajectory. To resolve this, safety constraints should be structured hierarchically. Severe hazards (such as physical collisions) are assigned top priority, while secondary rules (such as lane discipline) are treated as relaxable constraints when strict coexistence is physically impossible.

Finally, Fan emphasizes physical realism: if an adversary moves toward the vehicle at the speed of light, avoiding impact is physically impossible regardless of the control policy. Rigorous testing is essential precisely because it exposes these extreme scenarios, allowing designers to map the operational boundary where assumptions hold versus where environmental conditions make failure unavoidable.

- Hard constraints will be strictly satisfied mathematically only up to the exact specifications programmed into the controller. - Unanticipated conflicts require hierarchical safety specifications, treating collision avoidance as primary and road rules (like lane-keeping) as secondary relaxable constraints. - Active testing delineates the operational design domain by finding adversarial boundaries where no safe control input physically exists.

## Notable quotes > [27:37](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1657s) Believe it or not, stop sign is actually a pretty complicated rule to enforce: you have to stop, you have to look at all your surroundings, and decide when you are safe to pass. — Chuchu Fan

## Mentioned Chuchu Fan, MIT, Department of Aeronautics and Astronautics (AeroAstro), Laboratory for Information and Decision Systems (LIDS), GPT-3.5, GPT-4.1, GPT-5.2, F-16, Top Gun, Southwest Airlines, Southwest Airlines Pilots Association (SWAPA), Denver International Airport, Las Vegas, Dallas, Hurricane Florence

## Video description For more information about Stanford’s graduate programs, visit: https://stanford.io/grad-ed-engr319-1002

October 2, 2026 This seminar covers: • Why learning-based controllers struggle with real-world deployment: we can’t guarantee a learned policy is safe, and we can’t efficiently find the rare scenarios where it fails • A new approach that closes the loop between synthesis (building safe policies) and falsification (finding where they break) • How neural certificates can be formulated as value functions in reinforcement learning, producing control policies with built-in safety and stability guarantees — turning safety into a structural property of the policy rather than a soft penalty • An adaptive test-case generation method using Bayesian active learning to discover failure scenarios that are both likely to reveal problems and useful for broader coverage • How this method can predict failures from limited hardware demonstrations • How it supports scalable, evolving experimental design for system-level testing

Follow along with the seminar schedule: https://stanfordasl.github.io/robotics_seminar/archive/

Chuchu Fan is an Associate Professor (pre-tenure) in the Department of Aeronautics and Astronautics (AeroAstro) and the Laboratory for Information and Decision Systems (LIDS) at MIT.

[Source](https://www.youtube.com/watch?v=ot_whQ3xyJQ)

中文简报

麻省理工学院范楚楚将数学屏障嵌入AI以防机器人碰撞 自主系统在标准强化学习下容易失效,因为软惩罚会导致智能体死机或碰撞,因而需要硬性神经屏障函数和主动贝叶斯证伪来保障现实安全。 范楚楚概述了一种用于自主机器人的统一方法,该方法将安全策略综合与主动故障证伪相结合。在综合方面,神经约束价值函数和时序逻辑被转换为控制屏障函数(CBF)与分解的贝尔曼方程,无需依赖软惩罚微调即可在多智能体无人机群、异构配送系统和自动驾驶汽车中实现零样本扩展。在证伪方面,她将安全性测试从传统优化重塑为高维贝叶斯主动推断与MCMC采样,以映射多模态风险态势。讲座展示了这些测试框架如何揭示自动驾驶中的极端情况、对灾难响应分流中的基础模型进行压力测试,并对复杂的系统性中断(如2022年西南航空系统崩溃事件)进行回顾性根本原因分析。 麻省理工学院研究员范楚楚提出了一种闭环框架,将形式化综合(设计具有硬性数学保证的控制器)与贝叶斯证伪(主动揭示罕见失效模式)相结合。 (5:06) 构建为图控制屏障函数(GCBF)的神经约束价值函数,使完全在仿真中训练的去中心化多智能体策略能够零样本扩展至1,000个智能体,并可直接迁移到真实硬件上。 (14:41) 证伪测试从脆弱的优化重构为基于能量分布的贝叶斯MCMC采样,在高达250,000维的空间中将测试评估成本降低了十倍。 (39:07) 对2022年12月西南航空系统崩溃事件的回顾性故障分析表明,拉斯维加斯和达拉斯等温暖气候枢纽的飞机储备耗尽是主因,从而反驳了官方宣称的冬季风暴说法。 (54:57)

Reading summary

Chuchu Fan argues that dependable autonomous systems require bridging formal control methods with data-driven machine learning across two pillars: mathematical safety guarantees embedded by design and rigorous falsification testing to discover real-world failure modes. Hard Safety Enforcement via Graph Barrier Functions (13:16) Autonomous engineering traditionally forces a choice between classical control theory, which offers mathematical stability proofs but scales poorly, and deep reinforcement learning, which handles high-dimensional data but relies on empirical safety. Conventional reinforcement learning attempts to address safety by converting constraints into soft penalties or Lagrangian duals, but Fan notes this leads to brittle hyperparameter tuning or degenerate freezing behaviors, where an agent stops moving entirely to avoid penalty risks. Scaling Decentralized Execution with Barrier Functions (17:48) To enforce safety without halting task progress, Fan formulates infinite-horizon safety margins as constraint value functions satisfying Bellman equations. Theoretically proven to be Control Barrier Functions, these value functions generalize into Graph Control Barrier Functions (GCBFs) for decentralized multi-agent swarms. Operating entirely on local graph observations without centralized controllers, policies trained in simulation on small groups of three to eight agents scaled zero-shot to 1,000 agents navigating dense obstacles, hardware tests of heterogeneous robots carrying novel payloads, and close-formation flight models of F-16 aircraft rejecting unmodeled disturbances. Decomposing Complex Missions Using Temporal Logic (23:07) Beyond collision avoidance, autonomous missions require complex, temporally extended behaviors, such as recurring warehouse deliveries or strict road navigation. Fan uses formal temporal logic—translated from natural language instructions via large language models—to specify multi-stage objectives. The framework recursively breaks down these specifications into an interconnected graph of atomic Hamilton-Jacobi reach-avoid and recurrent value nodes, which standard reinforcement learning algorithms solve in parallel with cross-node bootstrapping. Hardware demonstrations showed heterogeneous quadruped-drone teams shepherding non-cooperative agents, sustained multi-robot delivery logistics, and autonomous driving policies that honored traffic rules while generalizing zero-shot to negotiate unmodeled roundabouts. Probabilistic Falsification and Bayesian Active Inference (39:07) Because mathematical models never perfectly mirror physical reality, policy design must be paired with active testing. Fan formalizes testing as searching for exogenous parameters (such as terrain or uncooperative agents) that maximize system cost. Standard optimization routines fail on these multimodal, non-convex landscapes by becoming trapped in local regions of attraction. By recasting falsification as Markov Chain Monte Carlo sampling over a failure posterior, the framework achieved a tenfold cost reduction in generating diverse test suites across parameter spaces reaching 250,000 dimensions, while retraining on these failures yielded a fivefold gain in system robustness. When analytical cost functions are unavailable, the system adopts Bayesian active inference, utilizing vision-language surrogate models to generate test cases that maximize information gain and operator utility. Systemic Stress Testing and Hierarchical Constraints (54:57) The testing framework extends to auditing complex black-box workflows and foundational models. Evaluating multimodal language models on disaster response triage using synthetic and real satellite imagery revealed that newer models like GPT-5.2 exhibited higher variance and sensitivity to perturbations than older iterations like GPT-4.1. In retrospective analysis of the December 2022 Southwest Airlines operational collapse, the framework identified compounding aircraft reserve depletions across unaffected hubs like Las Vegas and Dallas as the true driver of systemic failures, rather than localized weather disruptions in Denver. When addressing scenarios where safety rules conflict, Fan asserts that constraints must be structured hierarchically, prioritizing physical collision avoidance over secondary traffic rules while testing maps the boundaries where avoiding failure becomes physically impossible. Formal mathematical synthesis guarantees safety only within the explicit boundaries and assumptions programmed by engineers. Achieving trustworthy autonomy requires pairing safe-by-design policy synthesis with continuous probabilistic testing to uncover unmodeled dynamics, stakeholder conflicts, and physical limits.

精炼阅读摘要

麻省理工学院助理教授 Chuchu Fan 在斯坦福机器人研讨会上提出,构建兼具可扩展性与高可靠性的自主系统,必须将经典形式化方法的“设计即安全”与机器学习的数据驱动优势深度融合,并辅以主动证伪测试来探查未知现实缺陷。 硬约束安全与控制障碍函数 (14:41) 在传统强化学习中,工程师通常将安全规范转化为软惩罚或拉格朗日乘子。这种方法会导致超参数极难调整,且当安全与任务产生冲突时,系统常陷入“完全静止以求绝对安全”的退化策略。Fan 的团队将安全综合建模为受约束的最优控制问题,将安全性确立为必须在无限时界内恒成立的数学硬约束。 该方案利用满足贝尔曼方程的约束价值函数,在理论上证明其等价于控制障碍函数(CBF)。对于分布式多智能体系统,该方法进一步拓展为图控制 barrier 函数(GCBF)。每个智能体仅基于局部观测在邻域图上评估安全边界,过滤控制动作以维持全系统的不变性安全。在协同吊运与集群导航实验中,在 3 至 5 台或 8 台无人机小规模仿真中训练的模型,无需重训即可零样本扩展至 1,000 个智能体的密集避障、异构载荷运输,乃至两架全尺寸 F-16 战机的密集编队防尾流演练,并在实体无人机遭遇物理阵风时展现出强鲁棒性。 时序逻辑与价值分解架构 (23:07) 虽然安全边界可以通过控制障碍函数固化,但针对异构仓库物流等包含无限循环、严格时间窗口和依赖关系的长流程复杂任务,手写整体奖励函数极易发生对齐漂移。Fan 提出利用语法完备的时序逻辑(TL)来形式化描述任务需求,并指出当下前沿大语言模型已能可靠地将自然语言指令转化为严谨的时序逻辑公式。 借助语法树递归机制,时序逻辑规范被拆解为“到达-规避”与“循环往复”等原子哈密顿-雅可比(HJ)价值节点,形成价值分解图。各叶子节点通过已知贝尔曼方程在强化学习中并行训练并相互自举,智能体通过查询该图执行策略即可获得可证明的规范满足度。在硬件与仿真验证中,该方案成功实现了四足机器人与无人机协同“牧羊”非合作目标、天地多机交接包裹,以及在自动驾驶未见过的环岛场景中仅凭停车让行等基本逻辑实现零样本安全通行。 超越最优化:主动贝叶斯测试 (39:07) 形式化设计的理论证明完全受限于设计假设与模型保真度,物理现实中的分布偏移与未建模动态注定会导致系统失效。测试或证伪的数学本质是在不可控的外生参数空间(如极端天气、光照或不配合的人类)中搜索能最大化系统失效代价的配置。然而,传统最优化证伪方法在面对极度非凸的失效曲面时,极易陷入局部吸引域,使工程师对其他潜在失效模式视而不见。 Fan 将证伪从最优化重塑为基于后验分布的概率采样,利用马尔可夫链蒙特卡洛(MCMC)采样多元失效模式。针对缺乏先验分布与显式代价标量的现实场景,团队引入贝叶斯主动推理:利用变分推理构建由信息增益与用户效用驱动的采集函数,形成闭环迭代以绘制连续风险拓扑景观。在参数维度高达近 25 万的基准测试中,该方法将测试成本降低了十倍,利用发现的反例修复系统后使鲁棒性提升五倍。此外,针对大模型在灾害响应中的决策边界测试显示,更先进的模型(如 GPT-5.2)可能表现出更高的敏感性与发散方差,反不如旧版本(如 GPT-4.1)稳定。 回顾性归因与硬约束冲突解决 (54:57) 针对缺乏仿真环境、仅存观测数据的重大系统故障,Fan 团队展示了回顾性归因能力。以 2022 年 12 月美国西南航空因圣诞风暴导致数千架次航班取消、逾两百万人滞留的系统崩溃为例,官方归咎于丹佛除冰延误与恶劣天气。研究人员通过主动推理框架审计历史飞行数据,反向推导隐变量,发现丹佛枢纽的备用运力在暴风雪后迅速恢复,反而是拉斯维加斯和达拉斯等天气晴朗的主力枢纽隔夜飞机储备持续失衡,揭示出连锁运力枯竭的真实原因。 在问答环节,针对真实世界中突发极端险情导致“必须在追尾与违规借道之间抉择”的硬约束冲突,Fan 解释称:硬约束仅在设计者设定的数学规范内生效。若将规避碰撞与车道保持并列为平级硬约束,求解器将在无解情况下发生死锁。工程师必须建立分层安全规范,将碰撞规避设为主优先级硬约束,将交通规则设为次级可松弛约束;同时依托高覆盖率测试明确物理极限边界,识别任何控制策略都无法挽回的外部攻击场景。 Fan 总结认为,兼具高可靠与大规模特性的自主系统,必须由“设计阶段的数学安全证书”与“测试阶段的主动失效挖掘”协同构建。然而,面对物理法则不可逾越的极端对抗环境或设计初期完全未予编码的外部假设破裂,系统在真实世界中的安全裕度依然依赖工程师对边界条件的持续划分与经验校准。

Detailed notes — zh

## Background 该视频由 Stanford Online 于 2026 年 10 月 29 日在 YouTube 平台发布,记录了斯坦福大学机器人研讨会(ENGR319)的学术演讲。页面简介指出,MIT 航空航天系副教授 Chuchu Fan 在本场讲座中探讨了学习型控制器在现实部署中难以保证安全与难以发掘罕见失效的困境,并系统介绍了将控制理论与强化学习统一的神经证书方法,以及利用贝叶斯主动学习挖掘故障场景的自适应测试框架。 ## TL;DR 讲座围绕“如何兼顾经典严谨方法与数据驱动机器学习”展开,提出了构建规模化可证明安全自主系统的双轨路径。在设计端,Chuchu Fan 团队证明了约束价值函数与控制屏障函数(CBF)的数学等价性,通过时序逻辑与贝尔曼方程分解将安全性和长时程任务转化为强化学习中的硬约束,并在异构多机器人和极端仿真中实现了零样本扩展。在测试端,针对纯优化搜索容易陷入局部极值的问题,团队将失效用例挖掘重塑为贝叶斯后验采样与人在回路的主动推断过程,不仅能以低成本合成高维复合极端工况,还能对大语言模型在应急决策中的可靠性进行压力测试,甚至用于事后追溯复杂系统的级联崩溃根因。 ## Atmosphere & style 整场研讨会充满扎实、硬核的学术思辨氛围,讲者风格沉稳且兼具幽默感,擅长用通俗生动的比喻拆解复杂的数学推导。从推演贝尔曼方程的严密理性,到坦陈“现实中没有任何系统永不失效”的工程务实,叙事节奏层层递进、逻辑环环相扣。听众既能感受到顶尖控制学者直面大模型与强化学习黑箱局限时的犀利洞察,也能在西南航空危机分析等现实案例中体会到数据驱动逆向推理带来的强烈启发感。 ## Bulletin - [00:09](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=9s) MIT 团队提出融合经典严谨方法与机器学习的双轨安全框架,将约束价值函数与控制屏障函数(CBF)在理论上统一,使强化学习策略能够在结构上原生满足安全硬约束而非依赖软惩罚项。 - [17:46](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1066s) 基于图控制屏障函数(GCBF)的去中心化策略展现出卓越的零样本泛化能力,在 8 个智能体仿真中训练后可直接无缝扩展至 1000 个智能体的超大规模协同投递任务,且具有强抗模型误差能力。 - [39:07](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2347s) 失效证伪环节将系统测试从传统的对抗反例搜索重构为贝叶斯后验采样与主动推断问题,能够处理高达 25 万维的参数空间,以降低 10 倍的计算成本生成多样化多模态失效用例。 - [53:24](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3204s) 该测试框架可无缝跨越实体机器人扩展至前沿大语言模型与宏观复杂系统分析,不仅揭示了更先进大模型在灾害响应下输出方差极大的鲁棒性隐患,还成功推断出 2022 年西南航空大规模瘫痪的关键隐变量。 ## Key takeaways - [00:09](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=9s) 经典控制方法提供严格的设计安全保证但面临建模与高维瓶颈,纯数据驱动方法扩展性强但仅能提供经验性安全,二者亟需在规模化可证明安全上实现融合。 - [05:25](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=325s) 高可靠自主系统的安全保障依赖双轨互补路径:一是在设计端将任务规约编码为硬约束进行策略合成,二是在测试端通过对抗挖掘暴露失效边界与成因。 - [11:02](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=662s) 传统强化学习采用惩罚项或拉格朗日乘子处理安全问题会导致繁琐的超参数调优,并在安全与效率冲突时诱发系统停滞不前等次优行为。 - [14:41](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=881s) 约束价值函数在理论上被严格证明等价于控制理论中的控制屏障函数(CBF),通过贝尔曼方程即可在无模型强化学习中直接求解安全动作边界。 - [17:46](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1066s) 图控制屏障函数(GCBF)赋能多智能体仅依据局部观测即可维持全局协同安全,具备极高鲁棒性,甚至能直接实现纯仿真策略向真实复杂扰动硬件的零样本迁移。 - [24:34](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1474s) 复杂长时程任务可形式化为时序逻辑(Temporal Logic),并能严格递归分解为到达-避障与循环两类原子任务,利用解耦价值图实现并行贝尔曼求解。 - [31:43](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1903s) 自主系统的测试本质是在给定的系统设计下,主动在外生参数空间寻找能击穿预设假设、导致高代价失效的外部环境组合。 - [37:10](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2230s) 自主系统的失效可递进划分为五个层次:分布层级、现实层级、语境层级、规范层级以及事后溯因层级失效。 - [39:07](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2347s) 测试绝不能简化为单目标优化,因为优化容易陷入局部吸引盆;重塑为贝叶斯后验 MCMC 采样能跨越势垒,高效覆盖多模态失效情景并绘制风险景观。 - [46:40](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2800s) 人在回路的主动推断测试闭环通过变分推断平衡信息增益与用户效用,能够利用大语言模型评估主观失效并融合同类历史事故特征合成出新型极端测试用例。 - [53:24](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3204s) 对灾害响应大模型的压力测试显示,更先进的模型如 GPT-5.2 在扰动下决策动作方差巨大,反而是早期模型展现出更高的输出一致性与可靠性。 - [55:01](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3301s) 事后追溯性故障归因在无仿真器条件下,利用数据反向推断揭示出 2022 年西南航空全美瘫痪的真正深层隐变量是枢纽机场隔夜备用机储备赤字。 - [58:46](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3526s) 现实中遇到不可抗拒的极端安全约束冲突时,系统必须在设计端预先设定约束优先级,并依据测试反馈通过数学松弛机制允许牺牲次级约束以保全核心底线。 ## Detailed walkthrough ### [00:09](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=9s) 经典严谨方法与数据驱动机器学习的权衡与鸿沟 MIT 航空航天系(AeroAstro)兼信息与决策系统实验室(LIDS)的副教授 Chuchu Fan 开场指出,她实验室的核心研究特色在于将“严谨方法”(Rigorous Methods)与“机器学习”(Machine Learning)相融合。这并不是说机器学习本身不严谨,而是工程界在设计任何自主系统时,都面临着在两大方法集群之间做出抉择的困境:一方面是经典工程方法,涵盖控制理论、形式化方法(Formal Methods)以及优化设计;另一方面则是纯数据驱动的方法,涵盖机器学习、强化学习与大模型。 这两种途径在关键系统属性上展现出鲜明的权衡对比。在安全性和稳定性(Safety and Stability)方面,经典方法是“通过设计”(by design)来保证的——工程师基于先验系统模型和明确的优化目标,从底层数学理论上直接推导出系统的这些核心属性;而在纯数据驱动方法中,此类严格保证往往只是经验性的(Empirical)。Chuchu Fan 强调:“Well, in many cases, empirical is fine, but for uh critical systems like robot interacting with human, maybe empirical is not enough.”(在许多情况下,经验性表现或许足够好,但对于诸如机器人与人交互的安全关键系统,仅靠经验性保证是远远不够的)。 | 维度 | 经典方法 (Classical Approaches) | 纯数据驱动方法 (Pure Data-Driven) | |:--- |:--- |:--- | | **安全与稳定性** | 通过设计理论内建 (By design) | 经验性验证 (Empirical) | | **先验模型需求** | 必须依赖物理模型(模型皆有误差) | 通常无需物理模型,直接从数据学习 | | **扩展性 (Scalability)** | 面对高维复杂系统存在明显瓶颈 | 具备极强的泛化与可扩展能力 | | **可追溯推理 (Reasoning)** | 结构可解构,组件与失效原因可明确追踪 | 处于黑箱/涌现阶段,机理不透明 | | **数学证明与保证** | 具备严格的数学对象和形式化证明 | 极少能提供严格的数学保证 | 经典方法往往必须以模型为前提,但正如公理所言“所有模型都是错的”,现实世界与物理建模始终存在保真度鸿沟;机器学习虽不强求物理模型且具有处理超大规模复杂系统的优秀扩展能力,却丢失了经典方法的结构化因果推理能力与可证保证。Chuchu Fan 指出,当前大模型的所谓“推理”仍主要属于数据模式层面的推理,而经典系统可以清晰定位哪个组件负责什么、瓶颈在哪里、问题因何而起。因此,核心研究痛点在于:“how do we provide build pro safety at scale in the sense like we don't want to compromise between the two.”(我们如何在规模化扩展的同时构建可证明的安全,而不是在这两者之间妥协折中)。 ```mermaid flowchart TD accTitle: Bridging Rigorous Methods and Machine Learning accDescr: Diagram contrasting Classical Methods and Data-Driven ML, showing their convergence into provable safe autonomy at scale. subgraph Classical["经典方法 (Classical Approaches)"] C1["设计内建安全性 (By Design)"] C2["系统逻辑可追溯 (Traceable Reasoning)"] C3["形式化数学证明 (Proofs & Guarantees)"] end subgraph DataDriven["数据驱动方法 (Data-Driven ML)"] D1["无需显式物理模型 (Model-Free)"] D2["极高系统扩展性 (High Scalability)"] D3["从高维数据学习 (Learned from Data)"] end subgraph Bridge["融合框架:规模化可证明安全"] B1["设计阶段:硬约束强化学习"] B2["测试阶段:贝叶斯主动失效证伪"] end Classical --> Bridge DataDriven --> Bridge ``` ### [05:25](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=325s) 双轨互补路径:从“设计保障”到“测试证伪” 为了在不妥协系统能力的前提下填补这一鸿沟,Chuchu Fan 团队提出了构建安全自主系统的双轨互补路径(Two Complementary Paths)。 ```mermaid flowchart LR accTitle: Two Complementary Paths to Safe Autonomy accDescr: Flowchart illustrating the dual paths of synthesis by design and falsification by testing. subgraph Path1["路径一:设计端构建 (Synthesis)"] P1A["任务与安全约束"] --> P1B["转化为硬约束优化"] P1B --> P1C["自动化任务分解"] P1C --> P1D["安全策略学习"] end subgraph Path2["路径二:测试端挖掘 (Falsification)"] P2A["开放动态环境"] --> P2B["主动生成极端测试用例"] P2B --> P2C["揭示失效边界与因果"] P2C --> P2D["提供系统信任度证据"] end P1D -.->|"部署与验证"| Path2 ``` 第一条路径是“通过设计实现安全与任务达成”(Safety and Mission Satisfaction by Design)。其核心理念是将安全要求与任务规范直接编码为数学对象,作为硬约束(Hard Constraints)嵌入到机器学习流程中,而非使用传统的软惩罚项(Soft Penalties),从而保证学得的策略在结构上自然满足安全约束。针对极其复杂的长期任务,算法会自动对其进行分解,并能在数学上推导论证该分解为何能严格满足原始任务。 第二条路径是“通过测试理解系统失效时机与原因”(Understand When and Where it Fails by Testing)。Chuchu Fan 直言,无论在设计阶段考虑得多细致,设计者的假设始终是有限的,而现实世界充满不确定性与极端工况,系统必然会发生故障。因此必须通过生成有针对性的测试用例,主动暴露系统在何时失败、为何失败——究竟是设计缺陷、遗漏的边界工况,还是底层硬件无法应对的极限。她总结道:“the provable safe at scale is done by rigorous design and evidence from testing altogether.”(规模化可证明安全必须依靠严谨的设计与来自测试的实证证据共同实现)。 ### [07:00](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=420s) 约束最优控制表述与复杂仓储协作示例 深入到“通过设计实现安全与任务达成”的具体数学架构,该问题在宏观上被定义为一个带约束的最优控制问题(Constrained Optimal Control Problem)。目标是在底层机器人系统动力学未知的前提下,寻找一个控制策略,使其在最大化系统性能指标(或最小化成本)的同时,严格满足给定的任务规范与安全硬约束。 为了具象化这种长时程、强交互的复杂控制场景,Chuchu Fan 介绍了一个未来智能立体物流仓储的异构多机器人协同配送场景: - **异构协作单元**:系统由空中飞行机器人(无人机/巡检飞行器)和地面四足/大型运输车辆组成。空中机器人速度极快,负责在指定空域穿梭、从地面单元取件并完成派送;地面机器人则类似于运输巴士或四足搬运器,负责进入仓储深处取货并背负包裹运送到走廊交接点。 - **空间与运动硬约束**:仓储库房由于空间狭窄、人员与货架密集,被设定为严格的“禁飞区”(No-Fly Zone),无人机绝不可闯入;地面机器人体型庞大,只能在限定的地面走廊与轨道路线通行,且多机器人之间必须严格避免碰撞(Collision Avoidance)。 - **无限时程(Infinite-Horizon)任务**:这一任务并非一次性的点对点轨迹规划,而是一个在运行期间永不终止的循环作业。包裹持续不断入库,地面机器人必须周期性、无休止地重访库房取货并运出,飞行机器人必须实时响应配送需求、搜寻对应的地面机器人、悬停对接取件并完成派件,同时所有机器人的电量与充电调度亦受制于连续约束。 Chuchu Fan 表示,传统的基于罚函数的学习方式极易在多约束、长时程的冲突下崩溃或产生违规,而她们的方法能够在无需预知精确动力学模型的前提下,合成出不仅严格达成配送使命、同时在数学上严格保证无一碰撞和越界行为的强化学习控制策略。 - **问题本质**:$\max_{\pi} \mathbb{E}[\text{Objective}]$,且在未知非线性动力学 $\dot{x}=f(x, u)$ 下严格满足 $x(t) \in \mathcal{C}_{\text{safe}}$ 及长时程任务规约 $\phi$。 - **空间约束特点**:无人机受限于空间几何划分(仓库为禁飞区,交接走廊为共享区);地面载具受限于一维/二维拓扑路径,存在严格防碰撞要求。 - **时序与资源维度**:约束要求在无限时间轴(Infinite Horizon)上恒成立,涵盖电量耗尽前自主充电与冗余机器人的无缝接替。 ### [11:02](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=662s) 数学抽象与强化学习中的硬约束困境 范楚楚教授将复杂的机器人多任务问题收敛回清晰的数学抽象结构。要运行经典控制方法或基于学习的方法,必须先克服两大核心挑战:其一,如何在系统运行过程中将安全与稳定性作为“硬约束”(hard constraints)严格执行;其二,面对如前文所述的货物运送等复杂任务目标与随机突发状况,根本不存在一个现成的标量奖励函数,能够直接保证安全约束和长期递送任务在无限时域内始终成立。她指出,系统最终需要具备高度的可扩展性,而在现实中,机器人往往是异构的,拥有各自的动力学特性与子任务。要实现规模化部署,唯一的出路是“去中心化”(decentralized),让每个智能体仅依据自身局部观测(local observation)学习分布式控制策略(distributed policy),同时在全局上协同优化同一个代价函数或最大化目标收益,并受制于安全约束。 ```mermaid flowchart TD accTitle: Conventional RL vs CBF Hard Constraint RL accDescr: 比较传统RL软约束惩罚与基于约束价值函数的硬约束控制架构 subgraph ConventionalRL["传统强化学习做法"] A["多目标/任务奖励"] --> C["混合目标函数"] B["碰撞惩罚 / 拉格朗日对偶"] -->|"转化为软约束"| C C --> D["参数调优极其繁琐<br/>产生'停滞不前'等安全与效率冲突"] end subgraph ProposedApproach["约束价值函数 (GCBF) 架构"] E["局部环境观测"] --> F["约束价值函数 (GCBF)"] F --> G["贝尔曼方程求解<br/>(值迭代 / 优化控制)"] G --> H["安全控制输入边界<br/>(硬约束保证)"] end ``` 然而,传统的强化学习路线在处理此类问题时存在根本性缺陷。通常的做法是将安全等硬约束转化为软约束进行惩罚,或者引入拉格朗日对偶法(Lagrangian duality)。这种方法不仅把绝对不能违背的底线降级为可以妥协的惩罚项,还会让整个目标函数变成由多个加权系数拼接而成的庞然大物。任何调过强化学习超参数的人都知道,平衡这些权重是极其痛苦且脆弱的经验过程;在一套环境下生效的参数,环境稍有变动就会彻底崩溃。更严重的是,安全往往与任务目标存在根本冲突:“在许多情况下,安全与任务目标是严格冲突的。最安全的做法就是原地不动。自动驾驶汽车尤其如此——如果你重罚碰撞,它们就会彻底停在原地或者开得极慢。” ### [14:41](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=881s) 约束价值函数与控制屏障函数(CBF)的数学统一 为了破除软约束的妥协,范楚楚团队证明了一种被称为“约束价值函数”(constraint value function)的核心机制。该价值函数在数学上定义为安全度量函数 $h$ 在无限时间域内的最小值;团队在理论上严格证明了:该约束价值函数正是控制理论中的控制屏障函数(Control Barrier Function, CBF),而在分布式多智能体部分可观测系统(POMDP)中,它对应为一个图控制屏障函数(Graph Control Barrier Function, GCBF)。因为该函数在数学上本质是一个价值函数,所以可以直接写出其对应的贝尔曼方程(Bellman equation)。无论系统是否有现成物理模型,都可以通过传统的最优控制算法,或者无模型的强化学习值迭代(value iteration)来高效求解。 ```mermaid flowchart LR accTitle: High Dimensional State to Safe Action Space Mapping via CBF accDescr: 展示控制屏障函数将高维状态映射为标量并通过边界截断安全控制动作的流程 subgraph InputMapping["状态输入与屏障判断"] S["高维系统状态与环境"] --> CBF["控制屏障函数 h(x)"] CBF --> Positive["标量 > 0: 安全区域"] CBF --> Negative["标量 < 0: 不安全区域"] end subgraph ControlBound["控制输入裁剪"] Positive --> Boundary["计算安全控制边界<br/>(例如速度约束上限)"] Boundary --> Action["输出保证安全的控制动作 u"] end ``` 范楚楚向现场听众通俗地解释了控制屏障函数的直观内涵:CBF 是一种控制理论工具,它接收高维输入(包含机器人自身状态与外部环境),输出一个标量值;标量为正代表处于安全状态,为负代表处于不安全状态。更关键的是,它被称为“控制”屏障函数,是因为它能够直接反哺并指导底层控制器如何选取控制动作(control input)。例如在直升机飞越火山的简化场景中,CBF 能够在状态空间中直接划出一条控制边界(如速度上限),数学上保证只要控制输入落在该边界之内,系统就绝对不会坠入不安全的火山区域;当外部风场等环境变化时,CBF 也会动态更新对应的可行输入空间。由于数学上已经将约束价值函数与 CBF 等同起来,工程师再也不需要苦恼如何手动构造 CBF:“约束价值函数在理论上已经被证明是一个 CBF,而在多智能体场景下它就是一个图版本的 CBF。这意味着每个智能体只需要通过局部观测读取周围环境,整个多智能体系统就能共同达成全局的安全保障。” - **约束价值函数定义**:取安全度量指标在无限时间范围内的下界 $\min_{t} h(x_t)$,天然具备李雅普诺夫式的前向不变性。 - **去中心化局部计算**:图控制屏障函数(GCBF)使得单个智能体仅凭局域感知(相机或激光雷达)即可参与全局安全闭环。 - **优化与控制接口**:CBF 能够直接作为二次规划(QP)或底层动作滤波器的硬边界,避免了目标函数中安全项与任务项的相互牵扯。 ### [17:46](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1066s) 极端规模化验证、鲁棒性迁移与硬约束闭环 范楚楚展示了一系列极具说服力的实验验证。首先是多微型无人机协同搬运重型货物的实验:由于单个无人机载重有限,必须多机联手;无人机之间既不能离得太远导致货物脱落,也不能离得太近发生碰撞或遭遇相互之间的下洗气流扰动(downwash wind disturbance)。借助 GCBF,局部控制策略展现出了卓越的泛化与扩展能力:算法在训练时仅使用了 3 到 5 架无人机搬运同一物体,但在部署时可以直接无缝推广到 6 架无人机搬运完全不同形态的物体。在仿真测试中,系统仅在 8 个智能体环境下完成训练,之后直接零样本扩展到 1000 个智能体的超大规模物流投递任务;智能体在训练阶段从未见过复杂的障碍物,却依然依靠局部传感器(相机/激光雷达)结合 GCBF 维持了业内领先的安全性与任务成功率。 这种架构的另一大杀手锏是其强大的“抗模型误差能力”。由于安全屏障函数本身就是一种对系统鲁棒性的严谨数学抽象,它对动力学模型的不精确性具备极高的宽容度。团队的所有控制策略均在纯仿真环境中完成训练,完全没有采集任何真实世界的实操数据。范楚楚指着展示视频解释道,真实硬件部署时哪怕面对剧烈的未知风力扰动、甚至在移动平台上完成自主起飞与着陆,系统依靠内置的鲁棒安全裕度依然能够稳健执行任务。除无人机协同与多机器人区域巡检外,团队还将该方法拓展到全尺寸高保真 F-16 战斗机的近距离编队飞行测试中,严格再现并攻克了类似《壮志凌云》(Top Gun)电影中僚机由于距离过近引发喷气尾流事故的严苛间距保持难题:“由于将安全屏障函数作为鲁棒性的抽象表达,它能够容忍大量的模型差异或不精确性。因此我们实际上全部在仿真中完成训练,从未采集真实数据来进行训练。”在第一部分讲座的尾声,范楚楚总结指出,这正是将安全与稳定性作为“硬约束”真正植入控制系统的数学解法。 ### [21:20](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1280s) 复杂任务的形式化困境与时序逻辑(Temporal Logic)的引入 在构建具备安全证书的系统时,只要理解了证书在机器学习中的数学存在形式,就能借助强大的强化学习算法来施加强约束,并将训练得到的价值函数直接作为安全证书使用。然而,当面对如多智能体物流配送等复杂的现实任务时,如何形式化描述任务目标仍是一个瓶颈: - 经典控制理论通常采用时序逻辑(Temporal Logic)等形式化语言来描述任务,但传统方法无法扩展到高维状态空间; - 标准强化学习(RL)或模型预测控制(MPC)往往需要耗费巨资进行细致的奖励或成本调优,极易因奖励函数表达偏差而引发目标对齐问题(misalignment); - 基于大型模型(如视觉动作模型 VAM 或 LLM)的方法高度依赖数据,但在很多特种任务初期根本没有现成数据可用。 为了打破僵局,Chuchu Fan 提出继续探究学习过程的核心数学客体——价值函数(Value Function),并将其进行结构化分解。时序逻辑作为一种严谨的符号化系统语言,具备清晰的语法规则(Syntax)与语义(Semantics),能够精确描述无限时域、具备时间依赖与逻辑先序的复杂任务,例如要求智能体不断补给、访问仓库、避开禁飞区等循环往复的任务。Chuchu Fan 幽默地提到,现代研究人员甚至不需要手动编写这些复杂的逻辑公式:“三年前我做过一项用大语言模型将自然语言英文翻译成时序逻辑的工作,当时 GPT-3.5 还做不到完美,但那时我就知道那项研究大概不会有长期的学术生命力,因为新一代的模型会变得更加强大;现在完全可以信心十足地让大语言模型来完成这项翻译。” ### [24:34](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1474s) 价值分解方法与基于贝尔曼方程的图学习框架 确定任务的时序逻辑规范后,核心问题在于如何求解。团队提出了**价值分解(Value Decomposition)**方法:利用时序逻辑严格的语法规则进行递归分解,证明了任何时序逻辑任务最终都可以递归拆解为两类基础原子任务的组合: 1. **到达-避障(Reach-Avoid)**:在避开障碍物的同时到达目标区域; 2. **循环任务(Recurrent tasks)**:系统必须周期性或永久重复发生的行为。 例如,“到达 A 或到达 B,且永远不撞墙”这一任务规范,可以根据分解规则转化为析取关系(Disjunction)。析取意味着二者满足其一即可,因此可以完全并行计算。每个子节点继续按照语法规则自顶向下拆解,直到生成底层的原子 HJ(Hamilton-Jacobi)价值函数。 ```mermaid flowchart TD accTitle: 复杂时序逻辑任务的价值分解架构图 accDescr: 展示从时序逻辑规范到分解图、原子贝尔曼求解及最终策略执行的流程 subgraph Spec["规范与分解"] TL["时序逻辑规范 (Temporal Logic)"] Decomp["递归语法分解<br/>(Reach-Avoid / Recurrent)"] TL --> Decomp end subgraph Graph["解耦价值图"] Node1["原子节点 1: Reach-Avoid"] Node2["原子节点 2: Recurrent"] Node3["原子节点 3: Safety / Invariance"] Decomp --> Node1 Decomp --> Node2 Decomp --> Node3 end subgraph Learning["并行求解与执行"] Bellman["标准贝尔曼方程求解<br/>(RL / 动态规划)"] Exec["策略执行与跨节点引导<br/>(Bootstrapping)"] Node1 --> Bellman Node2 --> Bellman Node3 --> Bellman Bellman --> Exec end ``` 关键在于,分解到最底层的每一个子节点都具备明确的贝尔曼方程(Bellman Equation)。这意味着研究人员可以使用任意通用的强化学习算法独立或并行地求解这些原子价值函数,并在不同节点间引导(bootstrap)隐式价值关系。在执行阶段,底层策略通过读取该分解图依次执行,从数学层面上提供永久满足约束的安全与任务达成保证。该方法展现出极强的可扩展性,在仿真测试中,智能体能够以极高的成功率连续访问多达 100 个任务目标点。 ### [27:37](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1657s) 硬件验证:从无人机牧羊、自主配送到自动驾驶规则 Chuchu Fan 展示了三组极具代表性的软硬件实验,证实了价值分解框架在动态与异构环境中的鲁棒性: - **多智能体协同“牧羊”(Herding)**: 实验模拟真实牧犬驱赶羊群入圈的场景。由于实验室内无法饲养真正的羊,团队使用不受控、只会本能逃离“猎犬”的小型无人机模拟羊群。负责围捕的“猎犬”由一台地面四足/轮式机器人(移动较慢)和一架敏捷无人机(移动较快)组成。二者的共同任务是将羊群穿过狭窄大门并永久压制在围栏区域(Pen)内。系统采用分布式控制策略,根据当前活跃的约束状态实时切换视野与围堵方向,在多次重复测试中均实现了极其精准的围堵。 - **空地协同物流硬件系统**: 大型地面移动机器人定期巡游进入仓库区域作为移动补给点;多架小型配送无人机则不断与地面平台对接、起降、取件并完成派送,形成持续运转的闭环流程。系统在多套配置与物理参数扰动下均展现出极强的鲁棒性。 - **自动驾驶与交通法规遵从**: 学术界已有工作证明,所有人类交通规则都可以严格映射为时序逻辑公式。团队将交通法规(如红绿灯、保持车距、Stop 标志通行权)作为硬约束加入自动驾驶强化学习训练中。Chuchu Fan 强调:“信不信由你,Stop 标志其实是一个非常复杂的交通规则,你必须先完全停下,仔细观察周围路况,确认安全后才能通行。”在多路段协同测试中,系统能够模拟激进、保守以及周围车辆违章等复杂多智能体博弈环境。更令人惊讶的是系统的零样本泛化能力:系统在训练阶段从未见过环岛(Traffic Circle),但凭借不追尾以及让行等基础交通逻辑的组合,智能体自主学会了在环岛中无缝协同与让行。 ### [30:42](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1842s) 第一部分小结与通往证伪(Falsification)的转折 在第一部分报告的总结中,Chuchu Fan 梳理了核心逻辑脉络:将任务规范、安全性与稳定性等系统需求转化为硬约束,通过明确的价值函数表达,并借助基于贝尔曼方程的递归分解将其降解为完全可解的子模块,从而让强化学习拥有了可解释且具备数学保证的控制策略。 通过结合控制屏障函数(CBF)、李雅普诺夫函数(Lyapunov Functions)以及时序逻辑满足度证明,系统可以在理论上证明策略符合预期设计。然而,Chuchu Fan 随即抛出转折:“但这并不是故事的终点,因为无论我们多么努力,系统在真实世界部署中总会遭遇失败。”理论保证依赖于严格的模型假设,而现实世界充满不确定性与未建模扰动,这自然引出了报告的第二核心主题——如何高效寻找系统边界、进行对抗证伪与失败用例挖掘。 ### [31:43](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1903s) 自主系统的安全设计与测试问题形式化 Chuchu Fan 首先指出,现实中没有任何系统是绝对不发生故障的:“I don't think there is a system that never fail.” 她强调,构建并保证自主系统安全的另一重要视角,就是弄清楚当故障发生时,究竟是什么导致了失败。为了用严谨的数学语言形式化这个问题,可以把系统看作一个接受两类参数的计算实体(无论是单一子系统、复合系统、仿真环境还是真实硬件设备): 1. **设计参数(Design Parameters)**:工程师可以主动调节和优化的变量(如控制策略、增益、架构配置)。设计目标是寻找这组参数,使得系统总代价函数 $J$ 最小化。 2. **外生参数 / 外部参数(Exogenous Parameters)**:系统必须面对但无法控制的环境因素,例如地形地貌、通信信道、天气变化,甚至是完全不配合人类规则的其他行人或道路参与者。 正如 Chuchu Fan 所指出的:“We can enforce all the constraints into the system when we know how to describe them. But there's no way to force safety with respect to someone who wouldn't listen to your safety rules. Like if someone want to break my all the specification there's no way for me to ensure it.” 因此,系统设计是在对外生参数做出预设假设的前提下寻找设计参数以最小化代价 $J$;而**测试(Testing)**则是其对立面——在给定的系统设计下,主动搜索外生参数空间,去寻找那些能打破系统预期、导致极高代价(如违反硬性安全约束、突破物理极限或未完成既定任务)的外部输入与环境组合。 ```mermaid flowchart LR accTitle: System Parameters Dual Formulation accDescr: Diagram illustrating how design parameters minimize cost while exogenous parameters maximize it in system testing. subgraph Inputs["输入参数空间"] DP["设计参数 (Design) • 控制增益/策略权重 • 目标: 最小化代价 J"] EP["外生参数 (Exogenous) • 地形、天气、不可控人类 • 目标: 触发高代价/失效"] end subgraph System["自主系统 / 仿真器 / 硬件"] BB["系统动态与代价评估 Cost J: 任务、约束、极限"] end DP -->|"优化设计"| BB EP -->|"测试对抗"| BB ``` --- ### [34:06](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2046s) 现有测试与验证(V&V / T&E)方法的权衡边界 Chuchu Fan 进一步回顾了工程界常用的“验证与确认”(Verification and Validation,简称 V&V)以及“测试与评估”(Testing and Evaluation,简称 T&E)范式。她指出,纵观现有文献,不同测试手段本质上都在**鲁棒性(Robustness)**、**灵活性(Flexibility)**和**计算效率(Efficiency)**三者之间做权衡: - **传统形式化方法(Formal Methods)**:包括可达性分析(Reachability Analysis)与基于优化的验证手段。其优势在于具有极强的鲁棒性,能够给出系统行为的严格过近似(Over-approximation)证明;但缺点是缺乏灵活性,基本只能处理小尺度的多项式动力学模型,完全无法处理黑盒系统,且计算复杂度极高。 - **黑盒学习与测试(Black-box Testing)**:目前大模型或黑盒优化社区普遍使用强化学习(RL)探索对抗样本或执行黑盒寻优。该方法极为灵活,不对被测系统做任何先验假设,但鲁棒性很弱。Chuchu Fan 评价道:“These are best effort approaches meaning if I use approach to find a failure or find the uh case that doesn't work I may be lucky but if I don't find anything there's not too much I can say about the robustness of my own system.” - **白盒 / 领域专用工具(White-box Testing)**:基于领域专用仿真器(例如可微物理仿真引擎),借助梯度反向传播加速用例发现。 团队的研究愿景是在三者之间寻找最佳平衡:在不依赖精确模型假设的前提下提高黑盒与复杂系统的测试**灵活性**;以尽可能低的计算代价生成具备高覆盖率的测试用例以提高**效率**;同时摆脱“碰运气”式的测试,通过量化风险和诊断失效机理来提升**鲁棒性**。Chuchu Fan 形象地反讽缺少鲁棒保证的盲目测试策略:“Well, if you don't have a robustness, you ended up driving a self-driving car forever on the road hoping that you will see a tricky case.” | 测试范式 | 鲁棒性(Robustness) | 灵活性(Flexibility) | 效率 / 扩展性 | 典型应用与局限 | |:--- |:--- |:--- |:--- |:--- | | **形式化方法 (Formal Methods)** | 极高(提供数学保证与过近似) | 极低(仅限小尺度多项式动力学,不支持黑盒) | 计算代价昂贵 | 可达性分析、约束优化 | | **黑盒学习测试 (Black-box RL/Opt)** | 较低(“尽力而为”,未见失效不代表系统安全) | 极高(无需系统内部先验) | 盲目探索导致算力浪费 | 对抗强化学习、无梯度随机搜索 | | **白盒测试 (White-box / Differentiable)** | 中等至良好(受限于仿真精度) | 中等(强绑定专用可微引擎) | 高(利用解析/数值梯度加速) | 专用物理仿真、可微渲染框架 | --- ### [37:10](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2230s) 自主系统的五大失效层次 在明确测试目标后,Chuchu Fan 梳理了团队在评估系统安全时划分的五个递进失效层次(Levels of Failure): 1. **分布层级失效(Distributional Failures)**:回答“系统究竟在参数空间的何处失效?”(Where does it fail?),目标是构建系统失效的概率分布模式。 2. **现实层级失效(Reality Failures)**:考察仿真或低保真模型中暴露的故障是否真的会在真实硬件上发生,直面“Sim-to-Real”(仿真到真实世界)的差异与鸿沟。 3. **语境层级失效(Contextual Failures)**:厘清“什么行为在特定情境下算作失效?”(What counts as failure?)。失效定义并非一成不变,有人认为没完成导航任务是失效,有人认为蹭到障碍物才算失效,必须确立严谨的语境评价准则。 4. **规范层级失效(Normative Failures)**:涉及群体价值校准。在多主体或人机共存系统中,每个参与者的诉求不同,由谁的价值偏好来决定测试指标和系统表现,属于规范性哲学与安全伦理层面。 5. **事后溯因层级失效(Retrospective Failures)**:承认物理系统必然会发生事故的前提:“No matter what we do, when failure happened, we want to understand what has caused it.” 关键在于挖掘隐变量(Hidden Factors),以便在下次严重故障发生前提前监测阻断,或反哺用例生成引擎。 --- ### [39:07](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2347s) 将失效发现重塑为贝叶斯后验采样问题 针对“系统在何处失效”这一分布层级的问题,从数学上看似乎只需将外生参数 $Y$ 作为优化变量去最大化代价函数 $\max_Y J(Y)$。但 Chuchu Fan 明确指出,**软件与物理系统的测试绝不能简单等同于求解优化问题**。这是因为故障具有本质的“多模态特性”(Multimodal Cases),失效往往由多种完全不同性质的成因交织所致。 当面对极度非凸、存在大量局部极值点的超曲面时,基于优化的算法(即使引入复杂的元启发式技巧)也难免受制于吸引盆(Region of Attraction)机制:测试起点一旦选定,梯度或局部搜索便会不可避免地滑向该初始点所对应的局部失败模态,从而对外部空间中隐藏的其他潜在失效区域产生彻底的“盲区”。 为了突破这一局限,团队提出**将失效搜索从优化问题重构为采样问题(Sampling Problem)**,借助采样天生具备的跨越势垒、避免陷入局部极值的能力。该方法将测试过程视为从贝叶斯后验分布中采样的概率证据生成过程: - **后验分布(Posterior Distribution)**:刻画高概率诱发系统失败的外生参数敏感区域。 - **先验分布(Prior Distribution)**:编码设计者关于哪些参数区间安全或存在风险的初始信念。 - **似然函数(Likelihood)**:与代价函数 $J$ 关联(通常通过指数形式似然 $e^J$ 近似),用来量化一组具体参数导致严重违规或失效的概率强度。 借助马尔可夫链蒙特卡罗(MCMC)采样序列,测试框架能够从先验逐步逼近并高效采样出高代价、高发生概率的后验失效模态分布,若配合具备可微梯度的仿真器,该过程可以获得极大的加速与自动化执行能力。 ```mermaid flowchart TD accTitle: Bayesian Failure Discovery Pipeline accDescr: Pipeline of recasting failure discovery from optimization to Bayesian MCMC sampling. subgraph BeliefModel["贝叶斯概率建模"] PR["先验分布 Prior • 设计师初始信念 • 风险区域粗略预估"] LK["似然函数 Likelihood • 代价函数 J (物理限制/硬约束) • 指数变换: exp(J)"] end subgraph SamplingEngine["采样求解引擎"] MCMC["马尔可夫链蒙特卡罗 (MCMC) • 摆脱局部极值吸引盆 • 覆盖多模态失效模式"] end subgraph OutputSpace["评估结果"] POST["后验失效分布 Posterior • 高风险外生参数敏感区 • 全局多模态测试用例集"] end PR --> MCMC LK --> MCMC MCMC --> POST ``` ### [42:32](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2552s) 高维故障生成与赛车采样控制器的失效复现 在缺乏梯度信息时,可以借助免模型(model-free)采样版本来加速生成过程;若有梯度信息可用,则能直接利用反向传播来进一步提速。Chuchu Fan 介绍,团队在一整套复杂应用中测试了该方法,设计参数 $X$ 与外生参数 $Y$ 的维度最高可达数千甚至接近 25 万维。实验表明,与现有其他方案相比,该方法能以 10 倍更低的计算成本生成多样化的失效案例。不仅如此,若利用生成的失效样本对系统进行修复,系统的鲁棒性可以直接提升 5 倍。 为了生动说明这一点,Chuchu Fan 举了一个赛车避障的具象例子:假设正在设计一辆搭载采样控制器(sampling-based controller)的赛车。由于基于采样的控制器本质上具有随机性,无法通过梯度反向传播来进行常规的最优化采样,研发人员很难直接推导障碍物究竟放在哪里会导致碰撞。而借助该方法,不仅能够精确圈定导致失控的区域及其对应的碰撞概率,还能合成复杂的连环情景。例如在右侧的双障碍物测试用例中,赛车为了避开第一个障碍物进行机动,却不可避免地直接撞向了第二个障碍物。每一个位置都被赋予了明确的失效概率,从而完整量化了赛车算法的真实风险面貌。 - 设计与外生参数空间最高可达近 250,000 维。 - 与其他方法相比,生成多样化失效案例的成本降低了 10 倍。 - 基于生成的故障用例对系统进行修复,系统鲁棒性提升了 5 倍。 --- ### [44:23](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2663s) 从“反例搜索”转向“主动推断”:破除对单一代价函数的依赖 然而,单纯依靠后验采样并不能解决现实工程的所有困境。Chuchu Fan 指出,许多工程师会立刻提出质疑:“我根本不知道目标函数 $J$ 是什么。”在真实物理系统中,先验分布可能极不准确,仿真与现实之间存在巨大的 Sim2Real 差距,且在真机上采集故障样本代价极高。更关键的是,现实系统(如移动操作机械臂)的规范极其复杂,涉及任务成功率、安全距离、操作平稳度以及呼叫人类协助等多重诉求的权衡,根本无法凝炼成单一的代价函数 $J$ 来进行优化或采样,而且不同参与人员对于“何为失效”的标准和偏好也各不相同。 Chuchu Fan 犀利地指出了传统测试流程的死穴。经典测试预设系统已经具备明确的失效数学描述,一味去搜索所谓的反例(counter-example 或 witness),最终得到的只是一套死板固定的测试用例集,就如同当下的常规赛车规程一样,通过了固定测试并不等于具备现实安全性。为此,团队提出必须将测试用例生成从“搜索过程”彻底转变为“推断过程”(inference process):将寻找故障视为在系统已知信息和失效特征条件下的后验分布采样。这样输出的不再是几个孤立的反例,而是一个宏观的“风险景观”(risk landscape),让开发者清晰看透故障的集中区域及其诱因。 Chuchu Fan 对这一理念转变总结道:“The reason we want to turn this test case generation from a search process to inference process is because classical testing assume that we already know what constitute as a failure meaning we have a clear description of J and it will ask for what we call an contra example or witness what you're ending up with is a fixed set of things like today's regular racing process it give you a fixed set of cases you have to run and if you pass you say the system is robust but we know passing those tests does not mean that you are guaranteed to be.” --- ### [46:40](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2800s) 主动推断自适应场景生成架构 针对上述难题,Chuchu Fan 提出了一套人在回路(in-the-loop)的主动推断自适应测试场景生成框架,其核心在于主动、序列化地生成“信息量最大”的测试用例。被测系统既可以是机器人仿真器,也可以是大型基础模型。当向系统发送查询或执行仿真后,系统会给出轨迹或答案等输出结果;随后,评估模块介入对结果进行客观或主观的评价。这些评估数据被用来拟合一个外生参数条件下的故障风险预测模型,进而指导生成下一个最具信息量的测试用例。为了摆脱对初始先验分布的过度依赖,算法底层采用了变分推断(variational inference)技术。 ```mermaid flowchart TD accTitle: Adaptive Scenario Generation Loop accDescr: A closed loop showing system simulation, outcome evaluation, surrogate risk modeling, and acquisition function optimization generating the next test case. subgraph Loop["主动推断测试循环"] A["被测系统/仿真器<br/>(Robot / LLM)"] -->|"输出轨迹或决策"| B["评估模块<br/>(主观/客观/大模型打分)"] B -->|"拟合风险数据"| C["故障预测模型<br/>(变分推断 / 代理模型)"] C -->|"构建采集函数"| D["信息增益 + 用户效用优化<br/>(Acquisition Function)"] D -->|"生成最具信息量用例"| A end ``` 在该闭环中,生成测试用例的核心驱动力是精心设计的采集函数(acquisition function)。该函数包含两个不可或缺的部分:一是“信息增益”(information gain),用于最大化减少系统对未知故障的认知不确定性;二是“用户效用”(user utility),用于体现测试人员的特定偏好与主观导向。整个流程在“测试—评估—学习—生成”之间不断循环,旨在将极其有限的线索(如仿真器记录、历史故障日志或少量硬件试跑数据)转化为可直接指导真实部署的充足证据,从而回答系统会在哪里崩溃、现实中是否会持续失效、究竟由谁的价值尺度来定义失败等底层问题。 Chuchu Fan 强调测试闭环的目标是:“If I summarize, this is really a loop where we do test, assess, learn, and generate in the loop until we get what we want to see where the next test is always selected to optimize the information gain and mission utility with a goal of turning from very limited evidence to deployable evidence.” --- ### [49:36](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2976s) 复杂语境失效与自动驾驶历史故障合成 在很多现实语境下,“失效”本身高度依赖具体情境且充满主观性。例如抓取物体时,究竟是追求抓得更牢靠,还是避免施力过大压损脆弱物体,这类权衡极难写成解析形式。为解决评估难题,团队在闭环中把原本由工程师或测试员负责的评估环节替换成了大语言模型,因为大模型非常擅长对“这是否算一次令人担忧的失效”给出贴切的定性判断。系统根据这些评估训练针对不同故障模式的代理模型,在用例设计阶段最大化覆盖各种严重程度和诱因维度的潜在失效,从而挖掘出由传感器光照变化、环境噪声或远距离目标误读等多种感知缺陷交织引发的复合事故。 Chuchu Fan 分享了一个极具震撼力的自动驾驶测试案例:算法从真实世界中不同原因导致的真实事故数据中汲取模式,并合成出全新的极端场景。该合成用例有机融合了 5 起真实历史车祸中的关键致险特征,尽管这种组合在现实中从未真正发生过,但将其输入仿真后,它却能直接击溃当前市面上绝大多数的主流自动驾驶算法。这种合成能力让工程师不再局限于复现单个孤立事故,而是能够主动探寻多重致灾因素叠加下的系统崩溃边界。 Chuchu Fan 谈到这种跨源合成能力时指出:“So all of these failures they are real failures caused by different reasons and we can actually learn and generate a case that combine the information from five actual failures but they were they never happened in real world. they will fail most of the self-driving uh algorithms that that available today and like this is a generated test case that we learned from historical case.” --- ### [52:32](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3152s) 超越机器人:灾难响应中大语言模型决策的置信与难度评估 该主动测试框架的应用边界并不局限于实体机器人控制器,同样可以无缝拓展到大语言模型(LLM)的可靠性评估中。Chuchu Fan 介绍了一个具体的应用场景:在灾害发生后,利用大语言模型综合阅读公众社交媒体推文(Tweets)和卫星遥感图像,为调度人员生成缓解灾情、分配有限救援资源的行动建议。在此类高风险决策中,团队并没有粗暴地定义“成功或失败”,而是将其量化为“决策难度”(difficulty)以及“系统输出在何时值得信任”。 测试框架将模型自报的困难度与外部评估的客观难度相结合作为效用函数,从而自动化分离出“高难度决策”与“低难度决策”。例如,当推文包含大量清晰、直接相关的受灾信息时,模型往往表现出低难度和高置信度,属于能够安全交付的简单案例;而通过主动生成极端或含糊不清的多源情报组合,系统能够主动诱发模型产生幻觉或摇摆不定的决策盲区,为后续大模型在严苛任务中的安全边界划定提供了定量依据。 ### [53:24](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3204s) 大语言模型在灾害响应中的压力测试与可靠性评估 Chuchu Fan 探讨了利用测试用例生成框架对用于灾害应急决策的大语言模型(LLM)进行压力测试。在灾害响应任务中,存在模型表现极其自信且能有效给出减灾行动的简单场景,但也存在信息表明急需救援行动、却无法清晰界定应采取何种有效行动的高难度、低置信度极端场景。通过分析灾前与灾后的卫星图像,系统可以主动挖掘或人工合成两类场景。以飓风佛罗伦萨(Hurricane Florence)的真实数据为例,灾前与灾后的对比图像能够提供高置信度的行动建议(在可视化中以紫色标出);但测试框架同样能人工合成具有挑战性的灾前和灾后卫星图像来极限施压 LLM,明确指出在哪些具体情况下“绝不应该盲目相信大语言模型给出的建议”。 此外,这种测试方法被用于横向对比不同模型与模态在决策上的鲁棒性。实验发现,更先进的模型并不一定更可靠:例如 GPT-5.2 这类前沿大模型对输入扰动表现出极高的敏感性,其输出行动建议的发散度非常大、散落各处,缺乏可信度;反观较早期的 GPT-4.1,其建议的方差显著更低,无论输入发生何种变化,都能持续稳定地输出同类建议。Chuchu Fan 强调:“We can generate pre and post satellite images to tell you this will really stress test your LLM and in this case you shouldn't trust what LLM is going to say.” - **灾害评估场景**:基于飓风佛罗伦萨真实卫星图像,划分高置信度有效决策区与高难度模糊决策区。 - **合成测试数据**:主动构建边缘卫星图像,用以定向暴露 LLM 决策失效边界。 - **模型对比现象**:GPT-5.2 的动作输出方差极大,而 GPT-4.1 的建议输出更具一致性与可预测性。 --- ### [55:01](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3301s) 追溯性故障归因:2022 年西南航空大规模取消事件根因分析 在无法主动交互或运行系统的场景下,Chuchu Fan 的团队转向了“事后追溯性故障归因”(Retrospective Failure Analysis)。许多人在日常出行中都体会过毫无征兆的航班延误或取消,却无从知晓背后真正的决策链条。该研究深入复盘了 2022 年圣诞假期期间爆发的西南航空(Southwest Airlines)调度危机。当时全美有数千架次航班被取消,导致多达 200 万旅客滞留机场。这场危机最初仅源于丹佛的一场冬季暴雪,但短短三到四天内,西南航空在全美各地的航线网络全线崩溃。 ```mermaid flowchart TD accTitle: 西南航空危机推断架构 accDescr: 展示从丹佛冬季暴风雪到隐藏因子(飞机过夜储备不足)导致多枢纽崩溃的追溯推理过程。 subgraph Trigger["初始扰动"] A["丹佛冬季暴风雪 (Denver Storm)"] end subgraph Explanations["公开相互指责 (非本质根因)"] B1["航司官方声明: 除冰延误"] B2["飞行员协会 SWAPA: 管理层领导不力"] B3["媒体 CNN: 调度网络系统落后"] end subgraph RootCause["数据驱动反向推断 (Hidden Factor)"] C["隔夜备用机储备不足 (Airplane Reserve Shortage)"] end subgraph Impact["级联失衡效应"] D1["丹佛 (Denver): 暴风雪后储备快速反弹恢复"] D2["拉斯维加斯 (Las Vegas): 储备持续恶化"] D3["达拉斯 (Dallas): 储备持续崩溃导致全美瘫痪"] end A --> Explanations A --> RootCause RootCause --> D1 RootCause --> D2 RootCause --> D3 ``` 事故发生后各方推卸责任,西南航空坚称原因是丹佛除冰延误引起的恶劣天气连锁反应,西南航空飞行员协会(SWAPA)将其归咎于管理层的领导力问题,而 CNN 等主流媒体则指责其陈旧的网络调度系统。Chuchu Fan 团队在既没有精确系统模型也没有模拟器、仅掌握观测数据的情况下,运用算法进行了反向推断。分析揭示了一个从未公开的深层隐变量——“飞机储备”(Airplane Reserve,即各机场为次日首发航班预留的隔夜停机数量)。数据表明,丹佛机场虽然遭受暴雪冲击,但其飞机储备在风暴过后迅速回升恢复;真正导致崩溃的,是拉斯维加斯和达拉斯等完全未受暴雪侵袭的核心枢纽,其飞机储备赤字在随后一周内不断恶化,最终引发了灾难性的多米诺骨牌式全网瘫痪。 - **事件规模**:2022 年圣诞周 Southwest 停飞上千航班,200 万人滞留。 - **推断发现的核心隐变量**:机场隔夜预留备用机(Airplane Reserve)数量不足。 - **关键数据特征**:丹佛的运力储备在灾后迅速反弹,但拉斯维加斯与达拉斯的储备赤字持续扩大,成为系统崩溃的实际传导主因。 --- ### [57:51](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3471s) 总结:构建安全、可扩展与可靠的智能自主系统 在演讲的结尾,Chuchu Fan 对整场报告的核心思想进行了系统性梳理。构建安全智能的自主系统必须依赖两个相辅相成的支柱:一方面是“通过原生设计确保安全与任务达成”(Safe and Mission Satisfaction by Design),另一方面是“通过主动测试生成证据”(Generating Evidence Through Active Testing)。这两者从状态空间和环境参数的不同维度切入,将经典控制理论中严谨的数学验证体系注入现代数据驱动的学习方法中,以此打破单纯黑盒试错的局限。Chuchu Fan 为未来大规模自主系统的工程范式定下了基调:“And I think that they together can uh bring some of the rigorous mathematical methodology from our classical approach into using datadriven approaches and enable us to build systems at large scale that are safe by design, scalable by architecture and reliable by proof.” --- ### [58:46](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3526s) 问答环节:冲突安全约束、极端对抗与优先级松弛 在现场提问环节,一名观众提出了关于安全硬约束(Hard Constraints)在现实中发生冲突时的权衡问题。该观众举例指出,在极端自动驾驶工况下,如果前方车道有车辆突然强行变道侵入,为了避免碰撞,自动驾驶汽车可能不得不借道反向车道避险;此时“留在车道内”和“避免碰撞”这两个原本设定的安全约束便产生了直接矛盾,不得不牺牲其中一个。 Chuchu Fan 回应解释了数学设计与物理现实之间的边界。她指出,所谓“硬约束”是建立在设计阶段对系统做出的假设之上的,而主动测试之所以必不可少,正是为了找出那些在设计阶段无法预见、导致先验假设被击穿的场景。如果遇到极端对抗工况——比如“一个对抗物体以光速向你撞来”,在物理上是无论如何都无法规避碰撞的。当面对多重约束冲突时,工程师必须在设计层面明确优先级的层次划分:例如将“碰撞规避”设定为绝对不可违反的最高优先级安全硬约束,而将“保持车道”设定为次级安全约束。在测试暴露出两者不可兼得的边缘情景后,算法便可以通过数学松弛(Relaxation)机制,允许系统在必要时刻违反次级约束,以全力保障最高优先级约束的满足。正如 Chuchu Fan 所总结的:“Well, maybe through testing we figure out this could be a case. We could, you know, relax some of it like staying in the land as a secondary safety consideration that can be relaxed when they're strictly not possible to satisfy both and that we can encourage some, you know, behavior that may avoid violate certain constraints to satisfy other more higher priority constraints.” ## Notable quotes > [11:02](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=662s) 在许多情况下,安全与任务目标是严格冲突的。最安全的做法就是原地不动。自动驾驶汽车尤其如此——如果你重罚碰撞,它们就会彻底停在原地或者开得极慢。 — 范楚楚 > [34:06](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=2046s) Well, if you don't have a robustness, you ended up driving a self-driving car forever on the road hoping that you will see a tricky case. — Chuchu Fan > [57:51](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=3471s) And I think that they together can uh bring some of the rigorous mathematical methodology from our classical approach into using datadriven approaches and enable us to build systems at large scale that are safe by design, scalable by architecture and reliable by proof. — Chuchu Fan > [05:25](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=325s) the provable safe at scale is done by rigorous design and evidence from testing altogether. — Chuchu Fan > [00:09](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=9s) Well, in many cases, empirical is fine, but for uh critical systems like robot interacting with human, maybe empirical is not enough. — Chuchu Fan > [17:46](https://www.youtube.com/watch?v=ot_whQ3xyJQ&t=1066s) 由于将安全屏障函数作为鲁棒性的抽象表达,它能够容忍大量的模型差异或不精确性。因此我们实际上全部在仿真中完成训练,从未采集真实数据来进行训练。 — 范楚楚 ## Mentioned Chuchu Fan (范楚楚), MIT (麻省理工学院), MIT Department of Aeronautics and Astronautics (AeroAstro), Laboratory for Information and Decision Systems (LIDS), Stanford Robotics Seminar, F-16, 《壮志凌云》 (Top Gun), GPT-3.5, GPT-4.1, GPT-5.2, 西南航空 (Southwest Airlines), 西南航空飞行员协会 (SWAPA), CNN, 飓风佛罗伦萨 (Hurricane Florence) ## Video description For more information about Stanford’s graduate programs, visit: https://stanford.io/grad-ed-engr319-1002 October 2, 2026 This seminar covers: • Why learning-based controllers struggle with real-world deployment: we can’t guarantee a learned policy is safe, and we can’t efficiently find the rare scenarios where it fails • A new approach that closes the loop between synthesis (building safe policies) and falsification (finding where they break) • How neural certificates can be formulated as value functions in reinforcement learning, producing control policies with built-in safety and stability guarantees — turning safety into a structural property of the policy rather than a soft penalty • An adaptive test-case generation method using Bayesian active learning to discover failure scenarios that are both likely to reveal problems and useful for broader coverage • How this method can predict failures from limited hardware demonstrations • How it supports scalable, evolving experimental design for system-level testing Follow along with the seminar schedule: https://stanfordasl.github.io/robotics_seminar/archive/ Chuchu Fan is an Associate Professor (pre-tenure) in the Department of Aeronautics and Astronautics (AeroAstro) and the Laboratory for Information and Decision Systems (LIDS) at MIT. [Source](https://www.youtube.com/watch?v=ot_whQ3xyJQ)

Source quotes

[11:02] 范楚楚: 在许多情况下,安全与任务目标是严格冲突的。最安全的做法就是原地不动。自动驾驶汽车尤其如此——如果你重罚碰撞,它们就会彻底停在原地或者开得极慢。 [34:06] Chuchu Fan: Well, if you don't have a robustness, you ended up driving a self-driving car forever on the road hoping that you will see a tricky case. [57:51] Chuchu Fan: And I think that they together can uh bring some of the rigorous mathematical methodology from our classical approach into using datadriven approaches and enable us to build systems at large scale that are safe by design, scalable by architecture and reliable by proof. [5:25] Chuchu Fan: the provable safe at scale is done by rigorous design and evidence from testing altogether. [0:09] Chuchu Fan: Well, in many cases, empirical is fine, but for uh critical systems like robot interacting with human, maybe empirical is not enough. [17:46] 范楚楚: 由于将安全屏障函数作为鲁棒性的抽象表达,它能够容忍大量的模型差异或不精确性。因此我们实际上全部在仿真中完成训练,从未采集真实数据来进行训练。

Source quotes

[27:37] Chuchu Fan: Believe it or not, stop sign is actually a pretty complicated rule to enforce: you have to stop, you have to look at all your surroundings, and decide when you are safe to pass.

Original transcript

[0:09] really my pleasure to be here um and [0:12] happy to share with you what what we are [0:14] working on um to build safe and [0:17] intelligent autonomy and um the unique [0:22] uniqueness of the work we do at my lab [0:25] is to bridge what we call the rigorous [0:27] methods and machine learning and I in [0:30] this talk tell you what I mean by [0:31] rigorous method doesn't mean machine [0:33] learning is not rigorous it it can be [0:36] and what I mean by bridging them so the [0:39] motivation of what we're doing is as [0:42] engineers in general not not only [0:44] roboticism but general engineers um [0:47] designing autonomous systems like any [0:50] type of autonomous systems uh we have to [0:53] decide between a cluster of different [0:56] tools or methodologies to uh design our [1:00] system and especially nowadays when [1:04] we're looking at the very complex modern [1:06] autonomous system including modern [1:09] robotic systems we are like we we [1:12] definitely take a lot of classes on [1:14] these what do you call the classical [1:16] approaches uh include not include but [1:19] not limited to like control theory [1:21] formal methods optimization design and [1:23] many different approaches versus a pure [1:26] datadriven approach when I talk about [1:29] datadriven approach like machine [1:30] learning, reinforcement learning, large [1:32] models. Um, by no means saying like they [1:35] are now still clear separated. People [1:38] are definitely working in the mixture of [1:40] these ideas. But when I kind of like [1:43] look at the fundamentals of these [1:44] different two different classical [1:46] approaches, they are there are tradeoffs [1:50] and when we are deciding how to use [1:52] these methods, we are most ca most most [1:55] of the time looking at what to trade off [1:58] for example when we are looking at [2:01] safety stability and uh I would argue [2:04] that these very critical properties they [2:07] are typically by design using the [2:10] classical method we're given a a model [2:12] and we know what we are optimizing or [2:16] what we are controlling the system [2:17] against and by design by the theory [2:19] behind them we get these properties by [2:21] default when we use these approaches. [2:23] However, when it comes to a pure [2:25] datadriven approach a lot of these very [2:28] uh strict rigorous guarantees they are [2:31] largely empirical. Well, in many cases, [2:34] empirical is fine, but for uh critical [2:38] systems like robot interacting with [2:39] human, maybe empirical is not enough. [2:43] And uh on and on the on the other side [2:46] when it comes to the model, I just said [2:47] like classical approaches typically [2:50] require you to provide a model. So we [2:52] start with a model. Well, we all know [2:53] that models all models are wrong and [2:56] they are up to certain fidelity, but [2:59] they are distance to to the real world. [3:03] And a very big appealing part of machine [3:06] learning is that model is a a physical [3:10] model for machine learning to work on is [3:14] not always needed and uh a lot of the [3:17] information is learned from data itself. [3:19] And when it comes to scalability, I [3:22] guess that's one of the primary reason [3:23] people are looking at machine learning [3:25] approaches. The scalability is obvious [3:27] bottleneck for the classical approaches [3:29] in terms of the scale of the complexity [3:32] of the system people can work on. [3:34] However, when I look back at reasoning, [3:37] so this reasoning is not the reasoning [3:40] mode of your large model. Although I do [3:43] acknowledge that is reasoning. Although [3:45] that reasoning is more of the datadriven [3:48] based reasoning where we don't really [3:49] know what they're reasoning about there [3:51] they show you something but you if we [3:53] use the classical approaches we have a [3:56] way of understanding which components is [3:59] supposed to do what what's the [4:00] bottleneck when a problem arises there's [4:02] a way for us to track now where these [4:04] issues happen so I would say reasoning [4:07] is tractable in classical methods but [4:10] it's an emerging topic in machine [4:12] learning and still people are defining [4:14] what he means by reasoning and when it [4:16] comes to being able to provide proofs [4:18] and guarantees uh they are often there [4:21] in the classical approaches however um [4:24] in datadriven approaches we see that [4:26] it's really rare that people are talking [4:28] about proofs and guarantee they are [4:30] harness but what I'm talking about this [4:32] mathematically rigorous objects uh [4:34] describing the guarantees we can have so [4:37] the what we are looking we're looking at [4:40] is this critical gap how do we provide [4:43] build pro safety at scale in the sense [4:46] like we don't want to compromise between [4:48] the two. I don't want to just pick one [4:50] over another when I say can I have a way [4:52] to bring the strength of both in one [4:56] framework. So uh we have my my lab where [5:00] my students work on each of these topic [5:02] looking at how to bridge in this [5:04] different unique strength and in today's [5:06] talk due to time limit I will show you [5:09] two approaches two complimentary path we [5:12] are taking to build safe autonomy and [5:14] there will be a bunch of other work [5:16] unfortunately I won't have time to go [5:17] over today but happy to uh talk about [5:20] those if you have interest you can just [5:22] contact me so the two complimentary path [5:25] we're taking is from two views of [5:28] looking at how we ensure uh safety and [5:32] ensure guarantees in a safety critical [5:34] autonomous system. The first is to [5:36] ensure safety and mission satisfaction [5:38] by design. Second is to to understand [5:42] when and where it fail by testing. These [5:45] are both necessary and I will tell you I [5:47] will as I I proceed in this talk I will [5:50] hopefully convince you that both are [5:52] needed to build safe autonomy. So at a [5:55] very high level for safety and mission [5:58] satisfaction by design, we want to learn [6:01] policies that inherently have these [6:03] constraints um satisfied during the [6:06] learning process and we build the [6:08] requirements directly into the machine [6:10] learning process. While in the other [6:13] approach where you know when we build [6:16] things by design there are always just [6:19] limited consideration. We have the real [6:21] world can be wild. No matter how hard we [6:23] do there will be failures. So we want to [6:26] generate cases to reveal when they fails [6:29] why it fails. Is it by because of a [6:32] design or because of some consideration [6:33] we're missing or because of some things [6:35] that we just cannot handle and we want [6:38] to learn what to test the system to [6:41] generate the evidence about the trust [6:44] for the system. So in short the uh the [6:49] rigorous uh the provable safe at scale [6:52] is done by rigorous design and evidence [6:54] from testing al together. Now let me [6:58] start the first part what I mean by uh [7:00] safety and successful by uh safe safe [7:04] and successful by design. So we are [7:06] looking at these uh design methodologies [7:10] where people abstract the safety [7:13] satisfaction of mission as mathematical [7:16] objects and use them in the uh design [7:19] process of autonomous system versus in [7:22] datadriven approaches. We don't know how [7:24] to insert this knowledge but we do get [7:26] the scalability and model free uh model [7:29] free power of the datadriven approach [7:31] and the way we are looking to bridge [7:34] these two approaches together is to [7:36] enforce hard constraints. So we no [7:38] longer compromise to say your [7:40] constraints will be penalized they will [7:42] be hard hard constraints and I ask them [7:45] to be satisfied during the learning [7:46] process and also to be able to handle [7:49] very complex tasks. we decompose very [7:52] this very complex t in the very [7:54] automatic way but we can argue and [7:56] reason why this decomposed version will [7:59] satisfy your original mission now to be [8:01] able to do that I need a uh it's not [8:04] really a model but I need a mathematical [8:06] description of the problem we are [8:07] solving so this problem we are looking [8:09] at at a high level it is a uh [8:12] constrained optimal control problem [8:14] let's say and uh the mathematical [8:17] description can can can actually capture [8:19] a lot of interesting robotics fix design [8:21] problem but he says we want to find a [8:23] policy that maximize our objective it [8:26] can be minimize your cost it doesn't [8:28] matter and subject to task [8:31] specifications like safety constraints [8:34] etc and am I there there will be a robot [8:37] will follow the uh system dynamics [8:39] although the dynamics is not known to me [8:42] when I'm designing these things so how [8:44] would I uh how would I solve this [8:46] problem using what I talked about [8:48] enforcing part constraints and [8:49] decomposing in the complex tasks. I gave [8:52] you an example of something like that [8:55] fall under this description. Again, [8:57] that's just an example, but I personally [8:58] find is a pretty interesting example to [9:00] describe what we probably want for a [9:03] future warehouse. So, it's a warehouse [9:06] delivery task where I have two types of [9:10] robots. One is a aerial robots. They can [9:13] fly very fast and they want to revisit [9:16] the supplier, grab the package, deliver [9:19] the package. And I have the ground [9:21] supplier that always just like go to the [9:24] into the warehouse and re get the [9:26] packages on their their quadripads. They [9:29] get the packages on their back. They [9:31] meet the um uh area robots on the some [9:34] corridor, let them pick up the package. [9:36] And the safety constraints are a lot. We [9:39] want them to avoid collisions. We want [9:41] them we want that the um ground [9:44] suppliers actually they are quite [9:46] limited to where they can you can travel [9:48] thinking about like a huge ground robot [9:50] like or a bus they only can travel on [9:53] some restricted area. However, the [9:56] warehouse is not some place we want the [9:58] drones to fly in. So there's a no-fly [10:01] zone which is the warehouse and the [10:03] aerial robots are not supposed to get [10:04] into it. Now what I'm enforcing here is [10:07] not a one-time constraint. It's a [10:09] infinite. So this as long as they are up [10:12] and running of course I can also put [10:14] like a battery constraint when they are [10:15] running low on battery they should get [10:16] charged or we should fine replace it [10:18] with another robot that is fully charged [10:21] they can also be insert here but as long [10:23] as the uh warehouse is up and in [10:26] operation [10:28] I want all the constraints to be [10:29] satisfied. That means that my ground [10:31] supplier will need to constantly revisit [10:33] the warehouse because there will always [10:35] be packages coming in. they will have to [10:37] carry the packages, grab them outside [10:39] and the air robot whenever there is a [10:41] delivery need they will have to find the [10:43] ground supplier pick the package and uh [10:46] deliver them. Okay, so that is my [10:48] example. I will come back to this [10:50] example and show you how like our [10:52] approach can give you a learning based [10:54] policy but strictly satisfy the mission [10:57] objective delivery and also strictly [10:59] satisfy all the safety constraints. [11:02] Now coming back to my mathematical [11:04] abstraction, there are basically two [11:07] hard problems I need to resolve before I [11:10] can run some sort of like um uh either [11:13] classical methods or the learning based [11:14] approach. The first is how do I enforce [11:18] the safety and stability as hard [11:19] constraints in the process and second is [11:22] how do I handle this complex objective [11:24] or mission goal in the one I just [11:26] described like if if I have to say like [11:29] whenever it comes something there there [11:31] isn't really a reward function that's at [11:33] hand for me to directly say this [11:36] constraint this delivery task and random [11:39] everything will be enforced forever okay [11:42] and let's start with the first part how [11:44] do I enforce this part constraints. Now [11:46] when I further I further translate this [11:49] into a more mathematical version of a [11:51] description and um bear me of the [11:54] symbols they are the the the depth the [11:56] deepest math I'm going to talk about and [11:58] after that we'll come back to more uh [12:00] higher level description. So if I [12:04] further translate this into a multi- [12:06] aent version because eventually we want [12:09] all these tasks to be scalable and in my [12:12] uh toy example is already including [12:15] multiple robots. They are hierarch [12:17] hurtogenous they can have different [12:19] types and each have to accomplish their [12:21] own mission. And my belief is the way to [12:23] go to scale up is to go decentralized. [12:26] So we need them to learn a distributed [12:28] policy. the distributed policies for [12:30] each agent but all of them together will [12:33] have to accomplish one goal. So they [12:35] have to jointly optimize one cost [12:37] function or maximize one objective [12:40] function or reward function. They are [12:42] equivalent here subject to safety [12:45] constraints. So the safety constraint [12:47] here I say I have a way of saying uh all [12:51] the agents will only have their local [12:53] observations and when using their local [12:55] observation there's a function to [12:57] describe what it mean by safe and uh [13:00] here I still assume that safety can be [13:02] described as some sort of a function [13:03] over observation although that function [13:05] can be really flexible it can be like [13:07] even a [13:09] a human labeling what you mean by safe [13:11] or unsafe and then there are system [13:15] dynamics [13:16] uh here it is unknown. Now if I were a [13:20] um RL person solving this problem, the [13:23] straightforward way to go is to flip my [13:26] hard constraints as soft constraints to [13:29] be penalized or using these larger [13:31] engineering methods like lender duality [13:33] methods. And the consequence of this is [13:36] it will change your hard constraint to a [13:38] soft constraint and you are also ended [13:41] up with a objective function or reward [13:44] cost function with multiple pieces. And [13:47] if you ever tuned a RL method, you will [13:51] find a difficult time balancing these [13:53] different coefficients. Some may work, [13:55] some set of coefficients may work for [13:57] one thing, but when something changed [14:00] during the environment, it will not [14:01] work. So this is a very tedious and [14:03] there's not really good way to balance [14:06] the different objectives, especially [14:08] when there are safety considerations [14:10] because in many cases safety is strictly [14:13] conflicting with mission. The best way [14:15] to be safe is to not move. That's [14:18] particularly true for the self-driving [14:20] cars. If you penalize a lot of the [14:22] collisions, they will just stay still or [14:24] drive very slowly. Well, as as a result, [14:26] your performance of getting there [14:28] quickly or finishing the task will be [14:30] compromised. So, we don't want to use [14:33] this soft constraint idea or using this [14:35] lender duality idea. How would we [14:38] enforce this hard constraint here? So uh [14:41] we have shown that there is a particular [14:44] con uh value function called constraint [14:46] value function. In this particular case [14:48] this value function is to take the [14:50] minimum of h over infinite horizon time. [14:53] It is a control barrier function for [14:55] your system. And for the distributed [14:58] multi- aent case it is actually a graph [15:00] control barrier function for your [15:02] partially observable multi- aent system. [15:04] It is theoretically proved. If you have [15:07] never heard about control error [15:08] function, don't worry. In one minute, I [15:10] will be an pro of control error function [15:13] after I tell you what it is. Now, if I [15:16] really visualize what is this value of [15:18] the constraint value function. Now, here [15:20] because it's a value function, we can [15:22] find a balma equation for it. There are [15:24] clear ways of solving that Bman equation [15:26] through either if you have a model the [15:28] traditional optimal control approach or [15:30] you don't have a model RL approach to do [15:32] the value iteration. So if you have this [15:34] value function if you plot it you can [15:36] see that either for a multi- aent case [15:38] for a single agent case there are [15:40] actually the ground the the the [15:42] background is a contour of some function [15:44] that tell you where the robot should [15:46] move to. So what is a control barrier [15:48] function then? Um control barrier [15:50] function is from control theoretical [15:52] approach. They are a uh function that [15:55] taking a high uh dimensional input could [15:58] be our state including the environment [16:00] and output a scalar value. So in this [16:02] case it's like a super super simplified [16:04] case where you want to control this [16:06] helicopter to avoid the unsafe area [16:09] which is a volcano area. Then the [16:11] control barrier function will take in [16:13] all the state information and output uh [16:17] a scalar value that is positive for safe [16:20] and negative for unsafe values. And the [16:22] reason it is called a control barrier [16:24] function is because it actually inform [16:26] us how to pick the input. In this case, [16:29] assume that I can control the velocity [16:32] of this helicopter. Then whatever below [16:34] this red line is what the CBF, the [16:37] control barrier function will be able to [16:39] compute and tell us as long as your [16:41] velocity is within this range and then [16:43] you can accomplish your task, then [16:44] you're guaranteed to be safe or there [16:46] exist a safe action to keep you safe. [16:50] And of course this is not a fixed [16:52] function because when environment [16:54] changes when the uh environment kind of [16:56] like have a new area that's windy you [16:58] want it to get into you need to have [17:00] another contribarial function that do [17:02] the same thing in form safe versus [17:04] unsafe and being able to tell you what [17:06] is allowed input. Now this is you know [17:09] now you should be a pro of CBF and what [17:11] I just said is you don't have to [17:13] construct this CBF or come up with a [17:15] CBF. The constraint value function has [17:18] been theoretically proved to be a CBF [17:20] and for a multi- aent case it is a graph [17:23] version of it. Meaning each agent can [17:25] only uh will need only to read the [17:28] surroundings using the local observation [17:30] and together your entire multi- aent [17:32] system will have the global contribution [17:36] for safety. So as long as we are using [17:39] or enforcing this constraint value [17:41] function, safety is already embedded [17:43] with a mathematical object that we can [17:45] understand. Now let's say my task is to [17:48] have multiple drones. They are tiny [17:51] drones but they need to carry a pretty [17:53] heavy payload. So they cannot do it by [17:55] themsel but they have to work together. [17:57] Now these things uh the the safety [17:59] considerations would be they'll be able [18:00] to move things around. So uh avoid [18:03] obstacles and also all of these drones [18:05] they cannot be too far away from each [18:07] other. They cannot be too close to each [18:09] other. They have to maintain a safe [18:10] distance and also trying to avoid the uh [18:14] wind disturbance caused by each other. [18:16] And if I enforce the uh constraint value [18:18] function in this process and I if I [18:20] compute the control value uh the [18:23] constraint value function from the plot [18:25] here this on the right it is the uh [18:28] value of the constraint value function [18:29] which is the GCBF for the agent with a [18:32] star. You can see that it is oh this is [18:34] a flipped but it's like it can clearly [18:37] satisfy safe from unsafe and we know why [18:39] this policy is not chosen to in work in [18:42] this way to accomplish automation and [18:45] also keep everything safe because we [18:48] designed everything to be in a [18:49] decentralized way it can generalize. So [18:52] in training we only did three, four, [18:55] five agent transportation of the same [18:57] object. It can work seamlessly on six [18:59] agents with like a different object. [19:01] They can still move things around in a [19:03] safe manner. It can really scale up [19:06] because theoretically there's no limit. [19:09] We in simulation we have tried to [19:12] simulated this delivery task with [19:14] thousands of agents only training with [19:16] eight of them and they never saw the [19:18] obstacles uh in training because they [19:21] are they have their local observation [19:23] they can use camera or they can use [19:24] lighter to see around and because of the [19:27] GCBF that's embedded in the process [19:29] training with eight agents theoretically [19:31] you can go up to arbitrary large number [19:33] of them but here we tested up to like a [19:37] thousand of them and you can see we [19:38] remain the state-of-the-art safety and [19:41] task successful rate. This can have a uh [19:45] can be applied to higher dimensional [19:46] cases where we have uh here there's like [19:50] the inspection robot where two of them [19:52] have to work together to make sure the [19:54] target is always being observed within a [19:57] certain inspection region. bottom here [20:00] uh we have a two F-16 they are high [20:04] fidelity the full scale F-16 airplanes [20:06] trying to accomplish different tasks in [20:08] this case if you ever watched the top [20:10] gun one it is the one there you uh [20:13] Maverick was supposed to follow their [20:15] their teammate but because they got too [20:17] close there was an accident so there's a [20:19] safe region to follow it but do not get [20:21] too close to the jet or snow we don't [20:23] have a version the top gun too I don't [20:25] have the video here and all different [20:26] type of tasks Because of the uh safety [20:31] barrier function as a abstraction of [20:34] robustness, it can tolerate a lot of um [20:38] gap or uh inaccuracy in the model. So we [20:41] actually train everything in simulation. [20:42] We never collect real data to do [20:44] training. Everything was trained in [20:46] simulation. Of course, the model will [20:47] not be accurate. But when we deploy them [20:50] on hardware, the robustness that we're [20:52] able to build will be able to handle [20:54] like the wind disturbance or other [20:57] adversarials here there these robots [20:59] will be able to navigate in the [21:02] environment uh taking off and landing on [21:04] the on the moving platform etc. [21:06] accomplishing all these tasks. So that [21:09] is the first first piece. Uh we have [21:12] talked about how to enforce safety [21:15] stability at hard constraints. The way [21:17] we do it is to figure out the right ab [21:20] representation of a certificate and [21:23] knowing how it exist in the machine [21:25] learning process. So you can now you can [21:28] guide your machine learning process make [21:29] use of all the powerful RL approaches [21:32] but being able to enforce all the hard [21:34] constraints while you actually as a [21:36] product this value function you can have [21:38] them at hand as a safety certificate for [21:41] your system. You can use it for another [21:42] system if you need. But I haven't really [21:45] talked about the complex objects. I kind [21:47] of like by default said there's a way of [21:50] describing the mission goal. But if we [21:52] want to think about our original [21:55] delivery task, it's still not really [21:57] solved. How to how do we understand [22:00] these very complex objectives like do we [22:03] use classical control? They there in [22:06] classical control there are languages we [22:07] can use to describe these tasks like [22:10] temporal logic. But we know that these [22:12] classical approaches cannot go with high [22:14] dimensional case. Do we use directly [22:16] standard RL or MPC that require a lot of [22:20] reward or cost tuning which means a lot [22:22] of dollar amount you have to spend on [22:25] the tuning and it may po pose some [22:27] misalignment in terms of what you really [22:30] want to do as with respect to your what [22:33] your reward function is describing. [22:35] Well, I know a lot of you work on VAS or [22:37] large models. Do we use large models? [22:39] Yes, you could, but you need data, [22:41] right? Like a lot of the missions, I [22:43] don't even have data. What if you don't [22:44] have data at all? How should I start? [22:47] Then I at least need have something to [22:49] generate the data for me. So our idea is [22:53] continuing this idea of understanding [22:55] what is the mathematical object we are [22:57] trying to achieve in this whole training [23:00] process or learning process. It is a [23:02] value. So can we decompose this value [23:04] here? Now, now coming back to my toy [23:07] example, I actually describe this this [23:10] whole mission as this thing called [23:12] temporal logic. If you never heard about [23:14] it, uh it's okay. It's a systematic [23:16] symbolic language to describe a lot of [23:19] different missions that can be infinite [23:21] horizon that can have timing, temporal [23:24] and logical dependencies. It can [23:26] describe recurrent things like things [23:28] that have to happen forever like your [23:31] whenever there are package it has to be [23:32] delivered things like this. And this can [23:35] precisely describe my tasks like the [23:38] agent need to revisit the locations, the [23:41] ground suppliers need to revisit the [23:43] supply, go to the warehouse, there are [23:45] safety, there's no fly zone, etc. And [23:47] everything is here to be precisely [23:50] described as temporal logic. Now you may [23:52] wonder, I don't know how to write it [23:53] down. Well, luckily you don't have to. [23:55] GPT6 can do a perfect job for you to [23:58] give you a a perfect temporal logic. [24:00] three years ago I have a work on like [24:03] how to use larger language models to [24:05] translate it from English to temporal [24:07] logic um and because at that time JPT [24:10] 3.5 was not able to do a perfect job but [24:13] at that time I already knew that that [24:15] that word probably wouldn't have any [24:17] long-term meaning because the newer [24:18] generation of the model would be more [24:20] powerful and now I think you can pretty [24:22] confidently ask large language model to [24:24] do the translation for you now assume [24:27] that we have this [24:29] uh tempor ologic description of my [24:32] mission already. What do we do? The way [24:34] we approach is called value [24:36] decomposition. It's making use of the [24:39] fact that the temporal logic language is [24:41] a rigorous system language with its [24:44] clear grammar. It has syntactic it has [24:47] syntactic syntactic and semantic [24:49] meanings and they they follow all the [24:51] grammar rules. So we can look at all the [24:53] grammar that is used to construct this [24:55] temporal logic and tell you how to [24:57] decompose it. So we have proved that uh [25:01] any temporal logic tasks can be [25:04] basically either like we can of course [25:06] the decomposition will happen uh uh [25:09] recursively up to some atomic [25:11] proposition but they were eventually [25:13] some combinations of multiple ritual [25:16] avoids or multiple recurrent tasks. [25:18] Eventually they will be decomposed to [25:20] this fundamental tasks. So rich avoid [25:22] meaning you want to reach some goal [25:25] while avoiding certain things. Recurren [25:27] means something will have to repeatedly [25:28] happen and eventually any temporal logic [25:31] task will be able to be decomposed in [25:32] that way. Let me give you an example. [25:34] Let's say I want you to reach a reach b [25:37] never hit the wall. Now from the [25:40] original description there's a using the [25:44] uh value decomposition rule we can [25:46] translate this into a disjunction of two [25:48] because they are disjunction. If [25:50] anything is disjunction one of them [25:52] happening is fine. So you can do a [25:54] parallel computation for both. Of course [25:57] they are not the end and each of these [25:59] child node will have to according use [26:01] the rule to translate them into the the [26:04] more bottom level of the uh the [26:08] descriptions. But eventually every [26:10] temporal logic is going to be a graph of [26:12] certain rules like reach avoid until [26:15] avoid or globally or globally until this [26:18] repeated roots. Basically every value [26:21] eventually the child node are atomic HJ [26:25] values with nonboman equations. That [26:27] means every child of them can be learned [26:31] or can be um searched depending on your [26:34] scenario but every one of them have a [26:36] bioman equation. You can use any of your [26:38] favorite RL algorithm to solve them. And [26:41] together all of these atomic values will [26:44] form a decomposed value graph. Now once [26:47] we have those graph the node the nodes [26:51] we can actually learn them [26:52] simultaneously because they are all [26:53] completely in parallel. Now we can learn [26:56] them simultaneously and um the implicit [26:59] value relationship are bootstrapped [27:01] across the different nodes. In execution [27:04] they will just read the graph and [27:06] execute the policy and there we have the [27:09] guarantee that your reach A reach B [27:12] always avoid will be always forever [27:16] satisfied. Using this way we'll be able [27:18] to handle very interesting tasks in [27:21] simulation and that can scale pretty [27:23] well. Here we have the agents trying to [27:26] visit a number of tasks, number of [27:28] targets and they can go up to like a [27:30] hundred with very high uh success rates [27:33] across many different tasks. They remain [27:35] a very high success rate. Now let me [27:37] give you uh two examples I personally [27:39] find very interesting. We have talked [27:41] about delivery. I will show how it [27:43] looks. But there is also a hering thing. [27:45] Thinking about our quadripad as real [27:47] dogs to do hering example. So we have [27:50] the sheep in this case. They are still [27:53] drones. We we cannot have the real sheep [27:55] in our lab. They are not controlled. All [27:57] they do is run away from dogs. And we [28:00] have the bigger dogs. One of them is a [28:02] ground robot. Is a slower dog. One of [28:05] them is a faster drone. It's a faster [28:07] dog. Their goal is to just push the [28:11] sheep all the way through the gates and [28:13] get back to their pen and stay there [28:14] forever. So we can see the the the [28:18] active constraint here are highlighted. [28:20] You can see how they are actually [28:21] working seamlessly together. You need a [28:23] distributed policy here to squish [28:25] everyone back in the pen which is the um [28:29] this circle here. And because they are [28:31] looking at from different direction they [28:32] keep the ship perfectly within the pen [28:35] and you can repeat the test many times. [28:37] They're all very successful. Now coming [28:39] to my hardware task. [28:42] Um we have the bigger uh ground robot [28:46] here going into the warehouse area and [28:49] we have the smaller drones. They have to [28:51] constantly meet the bigger guy, land and [28:54] pick things up and take off from there, [28:56] deliver packages to their goals and this [28:58] will continue forever. And we also you [29:01] know cross test across many different [29:03] configurations and parameters and show [29:06] this is very robust to the changes in [29:08] the environment. Another example I would [29:10] like to mention is self-driving because [29:13] it has been proved that every single [29:16] traffic rule can be perfectly described [29:18] by a temporal logic specification. There [29:20] are papers telling you how to translate [29:22] every single um traffic rule into a [29:24] temporal logic formula. Now now we can [29:27] what we can do is we can actually train [29:29] these self-driving algorithms together [29:31] with the hard constraints. These are [29:33] traffic rules. We can just you know use [29:35] one car train them on different road [29:38] segments. As a result they really learn [29:40] all of them learn to follow the traffic [29:42] rule. There will be stop sign there will [29:45] be traffic lights and believe it or not [29:47] stop sign is actually a pretty [29:48] complicated rule to enforce. You have to [29:51] stop. have to uh look at all your [29:53] surrounding and decide when you are safe [29:56] to pass. But you enforce this rule on [29:58] each of them. They collaboratively know [30:00] how to drive. We can give different [30:03] level of you know different behaviors. [30:06] It can model aggressive behaviors, [30:08] conservative behaviors or behaviors that [30:11] you know other surrounding agents that [30:13] do not strictly follow the same rule. [30:15] But our agents will always follow the [30:17] rule and they learn and they know which [30:20] rule to look up to when it comes to [30:22] different traffic scenarios. Something [30:24] interesting is they can actually adapt [30:27] to things they have never seen before. [30:28] We never use a traffic circle to train [30:31] these agents but they learned because of [30:34] the traffic rule of rear end collision [30:36] and some sort of like the stop sign they [30:38] learned how to cooperate around traffic [30:40] circles. [30:42] So that is the conclusion of like the [30:45] the the last this is the last piece of [30:47] my first part. So we talked about how to [30:49] enforce all these mission uh [30:52] specifications, mission requirements, [30:54] safety, stability as hard constraints [30:56] and formulate them as clear value [30:59] functions and how to handle them as very [31:01] complex value functions to decompose as [31:03] something everything that is solvable [31:06] because we know every one of them exists [31:08] a a known biomman value function. So as [31:11] a result we are able to finish the task [31:14] with a guarantee and satisfy safety with [31:16] a guarantee with a clear mathematical [31:18] object to look up to. Now then you may [31:22] ask is that the end of the story? Uh in [31:24] terms of providing some sort of [31:26] guarantee we can have uh let's say [31:30] control barrier functions leapon [31:31] functions temporal logic satisfaction to [31:33] show they do satisfy the satisfy [31:36] whatever we want them to do. However, [31:38] it's not the end of the story because no [31:41] matter how hard we try, failures will [31:43] happen. I don't think there is a system [31:45] that never fail. And our approach to to [31:50] look at the to look at how to build a [31:52] safe autonomy or guarantee safe autonomy [31:54] from another perspective is to [31:57] understand when they fail, what has [31:59] caused the failure. So how to formulate [32:02] this problem? Now if I need a if I need [32:05] use another mathematical object to [32:07] describe the problem we're given this [32:10] system it could be a subsystem it could [32:11] be a system of subsystem doesn't matter [32:13] you could have a simulator you could [32:15] have a hardware but eventually what the [32:17] system is do is they take in two set of [32:20] parameters design parameter these are [32:22] the parameters we actually we can tune [32:26] we can change the value and we design [32:28] them for example using the approach that [32:30] I just talked about and The goal is to m [32:35] the goal is to find the design parameter [32:36] to minimize your cost. And there's [32:39] another set of parameters called [32:41] exogenous parameters or external [32:43] parameters. These are things like the [32:45] teran, the collecting, the weather, [32:48] other human who do not want to listen to [32:51] you. They can be wild. We can enforce [32:53] all the constraints into the system when [32:56] we know how to describe them. But [32:58] there's no way to force safety with [33:00] respect to someone who wouldn't listen [33:02] to your safety rules. Like if someone [33:04] want to break my all the specification [33:06] there's no way for me to ensure it. So [33:08] these are the extortionous parameters. [33:10] So my system will be have like I would [33:13] assume that there exist a j which is my [33:17] cost function. It it could be really [33:19] broad. It could be my goal, my cost, my [33:22] constraint, the limits etc. Then the [33:25] design is to find the design parameter [33:28] to minimize this cost while testing is [33:32] the problem of finding the exogenous [33:34] parameters to break the cost or have a [33:36] high cost. So this high cost could be [33:38] violating a safety constraint or [33:40] breaking a certain limit not finishing [33:43] your goal. And here uh the the two [33:46] perspective is they are really looking [33:47] at two set of parameters. When we [33:50] design, we assume what could happen at [33:52] the exogenous parameter. But our [33:54] assumption will never be perfect. And [33:57] the testing is looking at given a [33:59] design, how to find the parameters that [34:01] I ignore that could cause a failure. [34:03] Okay, I hope that that is clear. Now the [34:06] second part is about testing. There are [34:09] many approaches to do testing. Other [34:11] people call it verification. So VMV, if [34:15] you ever heard about name, it's called [34:16] verification and validation. TE is [34:19] testing and evaluation. These are key [34:22] methods engineer use to understand the [34:25] performance of their system. And when I [34:27] look at the literature of the broad VMV [34:30] and TNE problem, they are really trading [34:33] a different considerations robustness, [34:37] flexibility and efficiency. If we are [34:40] looking at the traditional formal [34:42] methods like the reachability the [34:43] optimization based approaches they are [34:46] very robust robust in the sense that [34:48] they do give you a precise over [34:51] approximation of the behavior of the [34:53] system. So if we can use these [34:54] approaches to prove our systems safe, [34:56] they're pretty safe robustly. However, [34:59] they are not very flexible because they [35:01] only can be used on a limited set of [35:05] system typically like a small scale [35:07] polomial dynamics. They cannot work on [35:10] blackbox systems and they all often [35:13] computitionally very expensive. And when [35:16] I go to blackbox learning and testing, [35:19] this is normally what the large model [35:21] people like do testing in the blackbox [35:23] way trying to use RL to figure out [35:25] adversarial behavior or blackbox [35:27] optimization etc. So they are on the [35:30] other side they are very flexible [35:32] because it's not making any assumption [35:34] on the system but in terms of robustness [35:38] it is less because [35:41] these are best effort approaches meaning [35:44] if I use approach to find a failure or [35:46] find the uh case that doesn't work I may [35:50] be lucky but if I don't find anything [35:52] there's not too much I can say about the [35:54] robustness of my own system and there [35:57] are of are domain specific tools. I call [36:00] it white box learning or testing because [36:02] they use domain specific simulators like [36:05] people develop all different type of [36:06] simulators. A lot of them are made to be [36:09] differentiable. So we can deploy a lot [36:11] of differentiable approaches to [36:13] accelerate the process. They are making [36:16] a good tradeoff but our goal is here our [36:19] goal is to improve flexibility. We want [36:22] to generate the right text test case for [36:26] very complex blackbox systems without [36:28] model assumption of it. I said a quote [36:31] unquote blackbox is is because [36:33] eventually if you have a simulator it's [36:35] not really a black box. And we want to [36:38] improve efficiency in terms of [36:40] generating high coverage test causes [36:43] test cases at a low cost. And we want to [36:45] improve robustness in terms of being [36:48] able to say we can quantify the risk. we [36:51] can diagonal uh diagonalize the failures [36:54] instead of saying I found something I'm [36:55] lucky if I don't I would just keep [36:57] trying. Well, if you don't have a [37:00] robustness, you ended up driving a [37:02] self-driving car forever on the road [37:04] hoping that you will see a a tricky [37:06] case. And now with that objective, there [37:10] are different levels of failure that we [37:12] have looked at so far. The first level [37:15] is called distributional. We want to [37:17] answer the question of where does it [37:19] fail? So that produced a failure [37:22] distribution. I will talk about a few [37:24] approaches we have taken to answer the [37:26] distributional question. The second is [37:28] level is reality. It failed in [37:31] simulation or it failed on this lower [37:33] fidelity system. Does it really fail in [37:36] real because there are simulation seem [37:38] to real gap or sim to real discrepancy. [37:41] The third level is what we call [37:43] contextual failures. It answer the [37:46] question of what counts as failure [37:48] because it's actually a pretty hard [37:50] problem if your robot is not performing [37:52] as you thought like what do you mean by [37:54] failure to some people failure means [37:57] they're not finishing their task other [37:58] people said failure means they bump to [38:01] something they're not supposed to so [38:02] what call that failure what is a failure [38:04] criteria and the next level is looking [38:06] at a group everyone have their own [38:09] understanding of what they want what [38:11] they don't want they how would we [38:13] calibrate who is valued to decide on [38:15] what should be tested, what should be [38:17] the performance of your system. It's [38:20] called a normative level of failure. And [38:22] finally, it's called retrospective [38:24] failure because no matter what we do, [38:27] believe it or not, your system will [38:29] fail. No matter what we do, when failure [38:32] happened, we want to understand what has [38:34] caused it. What is the hidden factor [38:37] that I can monitor next time before an [38:40] actual failure happen again? I can [38:42] prevent it or maybe I can use this idea [38:44] this hidden factor to generate more test [38:47] cases and due to time limit I will be [38:51] not be able to tell you everything we [38:53] have done but I I hope I can show you a [38:55] little bit of what we have done to [38:57] understand the distributional failure [38:58] what is the contextual failure and the [39:01] retrospective failure and for others [39:03] again if you are interested in it I'd be [39:05] happy to spend more time offline the [39:07] first is where does a system fail now [39:11] Coming back to my mathematical [39:13] description, I pretty much answer the [39:15] question where does the system fail? We [39:17] find the exogenous parameter Y that [39:20] maximize my cost. That's how they fail. [39:23] Then the natural thought is can I just [39:25] solve this optimization problem to find [39:27] a failure. So why is testing not simply [39:29] solving an optimization problem? The [39:31] fundamental reason is it hard it is very [39:35] difficult to find the different failure [39:37] modes. Failure is a multiode case. [39:40] failure could be caused by many [39:42] different reasons and they they can [39:43] appear in different ways and if I look [39:46] at this optimization problem to generate [39:49] test cases I'm really having a [39:51] non-convex like a super non-convex with [39:53] multiple optima if I use an optimization [39:56] based approach even if there are hyper [39:59] heristics to help you get rid of the [40:01] getting stuck at local optima you will [40:03] eventually get this what we call the [40:05] region of attraction meaning where you [40:07] start to test will always land to that [40:09] particular ular failure and you will be [40:11] bland about the other failures that [40:13] could happen. And we propose that maybe [40:17] we can reccast this failure discovery [40:20] problem or testing problem from an [40:22] optimization problem to a sampling [40:25] problem because sampling has a unique [40:27] strength of not trapping at the local [40:30] optimal. So if I look at the same toy [40:32] example where if I use the sampling [40:34] based approach the region of attraction [40:36] is really messed up because wherever you [40:38] start with a certain probability you [40:40] will land at one of the optima. So [40:42] that's the hope. What do I mean by [40:45] testing as a probabilistic evidence [40:48] generation process or sampling process. [40:50] We want to reccast the search for [40:52] failure as a sampling from a posterior [40:55] distribution. So what is this [40:57] probability distribution? is a posterior [40:59] distribution that identify the region of [41:01] the parameter where failure most likely [41:04] going to happen. And if you work on [41:07] inference, you know that posterior [41:09] depend on prior and likelihood. So what [41:12] is a prior? Prior represent the [41:14] designer's initial belief of what [41:16] regions are to search whether they are [41:19] safe or risky. And likelihood is the s [41:23] is the data collection process. we can [41:25] quantify how likely a specific set of [41:28] parameters is going to cause a system [41:29] failure. Now [41:32] uh so going from there where what should [41:35] we do? Let's say that suppose that we do [41:39] have a clear cost function that J [41:42] remember that J describe my task goal my [41:46] mission my physical limits my [41:48] constraints and uh etc. If I do have a [41:52] uh J then I can already approximate that [41:56] likelihood. So that likelihood using a [42:00] very standard approach is can be [42:01] approximated as this exponential [42:04] function using the the J. So in that way [42:07] what we're doing is starting from a [42:10] prior trying to go through a sequence of [42:13] uh MCMC sampling to get the higher [42:15] probability and the higher cost failures [42:18] of a posterior. We don't just want to [42:20] rely on the belief original belief but [42:23] being able to sample from the high cost [42:24] of failure. And this can be done easily [42:27] using MCMC sampling where you if you [42:30] have a good simulator with gradient [42:32] information, there are versions to [42:34] accelerate the process using the [42:36] gradient. If there's no gradient [42:38] information, there are also versions of [42:40] the sampling of the model free versions [42:42] we can use to do the sample. So if we do [42:45] this approach, we have tested across a [42:48] cluster of different applications with [42:50] so X is the design parameter, Y is the [42:53] exogenous parameter, they can go up to [42:56] like thousands or sometimes close to a [42:59] quarter million um dimensions and able [43:02] to see that our method can achieve a 10 [43:05] times lower cost compared to other [43:08] approaches to generate the diverse [43:10] failure cases. And if I if we repair the [43:13] system using the failures we have [43:15] generated, it can give you a five time [43:17] improvement in terms of the system [43:19] robustness. If you give you a more [43:21] concrete example here, so one testing [43:24] question would be let's suppose you are [43:26] designing a racing car. This is a racing [43:29] car using a sampling based controller. [43:31] So you know that sampling based [43:32] controller there are a stoastic [43:34] controller. There's no way to get the [43:35] gradient information back propagation to [43:38] do any type of optimization based [43:39] sampling. But we want to ask the [43:41] question of where does a uh obstacle [43:46] will cause a collision of your [43:48] well-designed sampling based controller. [43:50] And using this approach, we not only [43:52] tell you the region the corresponding [43:54] probability, we can also design the [43:57] different cases. For example, in this uh [44:00] right case, there are two obstacles. And [44:03] because the car was trying to avoid the [44:06] first obstacle, it caused an in [44:08] unavoidable clash to the wreck for the [44:11] second obstacle. And each of these [44:13] position now comes with a probability of [44:16] failure. And overall, we can use this to [44:18] quantify whatever the risk you care [44:20] about the racing algorithm. However, is [44:23] this the end of the story? A lot of [44:25] people will immediately say that um [44:28] well, I don't know a J, right? There are [44:30] a lot of problem there, a lot of issues. [44:32] So far we have assumed that we are [44:34] solving this problem through sampling [44:37] through the posterior. There are already [44:39] a lot of problems. We don't know the [44:41] prior. What if the prior is not [44:43] accurate? what if I don't have a [44:45] complete knowledge of the graph in the [44:47] sense that there's a significant same to [44:50] real gap and collecting failure sample [44:53] itself is a very expensive process for [44:57] physical systems and more importantly [45:00] I don't even know how to write down the [45:02] cost function that's a very typical case [45:04] we met when we work with real world like [45:07] real world problems or working with [45:09] engineers it would be like there the [45:11] system design is a very very complex [45:13] document there's not a single J function [45:15] I can optimize or even sample against [45:17] for example for a mobile manipulator [45:19] what balance the task success the safety [45:22] clearance the handling asking for help [45:25] all these things how do I even define a [45:27] failure out of it and uh not to say [45:30] every every uh person who participate in [45:33] this approach may have their own [45:35] priority in terms of what they want to [45:36] see and the reason we want to turn this [45:40] test case generation from a search [45:42] process to inference process is because [45:45] classical testing assume that we already [45:48] know what constitute as a failure [45:50] meaning we have a clear description of J [45:52] and it will ask for what we call an [45:55] contra example or witness what you're [45:57] ending up with is a fixed set of things [46:00] like today's regular racing process it [46:03] give you a fixed set of cases you have [46:04] to run and if you pass you say the [46:06] system is robust but we know passing [46:09] those tests does not mean that you are [46:11] guaranteed to be [46:13] Instead an inference process or [46:15] inference based testing is going to [46:17] treat the search of failure as a [46:19] sampling from a posterior distribution [46:21] where the sampling itself should [46:24] condition on what you know about the [46:26] system what you know about the failure. [46:28] It will output instead of witnesses it [46:30] will output a risk landscape and using [46:33] the risk landscape we have a better idea [46:35] of where the failures concentrate what [46:37] have cost them. So to address this [46:40] challenge what we are proposing is an [46:43] adaptive scenario generation framework [46:46] where this really system is working in [46:48] the loop to actively and sequentially [46:51] generate what we call the maximum [46:54] informative test cases. So we have a [46:57] system and you can query it. It it's a [46:59] simulator. It doesn't have to be a [47:01] robot. It can be a large model. I can [47:03] show you examples of like just testing [47:04] the large language model. And when once [47:07] you send a query or simulate the system, [47:09] you get an outcome. It could be a [47:11] trajectory, it could be an answer, it [47:12] could be anything. And we'll be able to [47:14] provide assessment and this assessment [47:17] is how you evaluate the outcome. It can [47:20] be objective, it can be subjective. [47:23] People can express their own opinions [47:25] about what I mean, what I like about [47:27] safe, what I mean by risk. And then this [47:31] assessment will be used to uh fit a [47:35] failure what we call failure prediction [47:37] model probability of the [47:41] uh of the risk given this particular [47:43] exogenous uh parameter combination. The [47:46] risk prediction model will be used to [47:49] generate the next most informative test [47:51] case and this approach is called active [47:55] inference. Now more detail because we [47:58] don't want to be constrained to a prior. [48:00] It's very likely that we don't have a [48:02] good prior to overcome that we can use [48:05] variational inference. I won't go have [48:07] time to go deep into the varational [48:09] inference but you can look it up. It's a [48:10] very um powerful approach to get rid of [48:13] this approximation of a prior and to [48:16] generate the cases what we need is to [48:19] use our risk model to design a right [48:21] acquisition function. And this [48:23] acquisition function should come with [48:25] two part. One is called information [48:27] gain. The second part is called user [48:30] utility. And I will show you why you [48:32] need both. Information gain is to reduce [48:35] what you call uncertainty about [48:37] understanding the failure of the system [48:40] and user utility is what as user they [48:43] want to see and what they want guide as [48:45] failure cases. If I summarize, this is [48:48] really a loop where we do test, assess, [48:51] learn, and generate in the loop until we [48:54] get what we want to see where the next [48:56] test is always selected to optimize the [49:00] information gain and mission utility [49:02] with a goal of turning from very limited [49:05] evidence to deployable evidence. The [49:08] limited evidence could be your [49:09] simulator, your historical failure, your [49:12] limited hardware trials and or your [49:15] objective uh subjective assessment to [49:18] deployable evidence of answering where [49:21] can the system fail? Does it fail in [49:24] reality? Does it fail persist in [49:27] uh reality? What count as a failure? [49:29] Whose value? And what has caused the [49:31] failure? So this is a loop to answer [49:34] these questions and I will give you [49:36] maybe a few example to show why and that [49:39] is the contextual failure. So as I said [49:43] failure in many cases are very very [49:46] subjective and we don't even know how to [49:49] clearly write down an function to [49:52] describe if I feed in this case it can [49:56] tell me if it is a failure or not. for [49:57] collisions is clear but for example do I [50:00] optimize securely grasping something or [50:03] have the potential of damaging that [50:05] object. So these type of failures are [50:08] very difficult to anal analytically [50:11] write down because the reasons could be [50:13] multiple and the knowledge of where it [50:15] rise could be from many different [50:17] reasons. To overcome this actually we [50:19] use the same remember our loop right in [50:23] now we have the testers or the engineers [50:26] as the one who provide assessment and [50:29] this in reality could be a person and [50:31] could be large models. Actually in all [50:33] of our work we replace that human with [50:35] large models because we think they are [50:37] pretty good at uh providing assessment [50:40] about if this is a failure they want to [50:42] see or if you there are particular [50:45] things about the failure they want to [50:46] talk about. Using this this um [50:51] uh evaluation or assessment, we'll be [50:53] able to train surrogate models for the [50:56] different failure modes. And when we [50:59] design, what we do is to optimize the [51:02] coverage of all possible failure modes [51:04] across different severity level. Right [51:07] now, we want to generate cases failure [51:09] cases not only caused by a single [51:11] failure, but could be from multiple [51:14] failure sources or causes. and each of [51:17] them could contribute to it in a [51:18] different way and this will be give us [51:21] more experiments or more data used for [51:25] further evaluation. That's a whole [51:26] process. Using this we can generate [51:29] cases about uh detection like detection [51:32] failure cause some collisions but we can [51:35] get to know maybe this is a lighting [51:37] condition or the noise or the [51:39] misinterpretation due to distance caused [51:42] at the perception level. We can [51:44] consistently generate test cases across [51:46] these different modes and could be [51:48] combining different modes or [51:50] self-driving case. I can give you a few [51:52] examples that are I find interesting. So [51:54] we can learn from historical failures. [51:58] So all of these failures they are real [52:01] failures caused by different reasons and [52:03] we can actually learn and generate a [52:05] case that combine the information from [52:07] five actual failures but they were they [52:10] never happened in real world. they will [52:12] fail most of the self-driving uh [52:15] algorithms that that available today and [52:17] like this is a generated test case that [52:20] we learned from historical case. This [52:23] can help us understand the real cost of [52:26] the system and more importantly we can [52:28] do more than just um than the robotics [52:32] testing. So here we take a look at large [52:35] language model. In this particular case, [52:37] we are looking at the problem where [52:39] large models are suggesting actions [52:42] after a disaster. So they will read [52:44] tweets, they will read satellite images [52:47] and suggest what you should do to [52:49] mitigate the disaster because there are [52:51] limited resources or limited things you [52:54] can do as a disaster response. And here [52:57] we actually do not really call it a [52:59] failure. We call that difficult. When [53:01] can we trust a LM output? We can we not [53:04] trust it. And the utility here is a [53:07] reported difficulty with the external [53:10] assessment of hardness. For example, we [53:13] can generate hard decisions and easy [53:15] decisions. Easy decisions will be the [53:17] low difficult case with high confidence. [53:20] This is because these type of tweets [53:22] provide a lot of relevant information [53:24] and LLM is very confident in terms of [53:27] getting to output the actions to get mid [53:30] of the disaster. And we also have the [53:33] difficult case where it's highly [53:35] difficult, low confidence because the [53:37] information show that rescue actions is [53:40] really needed but it's not clear which [53:42] is the actionable thing that should be [53:44] done. We can read the pre- disaster and [53:48] post- disaster satellite images and [53:50] figure out both low difficult and high [53:53] confidence cases. This is particularly [53:55] from the hurricane Florence case where [53:57] the pre and post disaster images can [54:00] provide a high confidence on action [54:02] suggestions which are the suggestions in [54:04] purple and we can have the opposite and [54:08] this case could be selected from a real [54:10] data set or we can artificially generate [54:12] these cases. We can generate pre and [54:15] post satellite images to tell you this [54:18] will really stress test your LLM and in [54:21] this case you shouldn't trust what LLM [54:23] is going to say. We can use this to [54:26] understand the different modality [54:28] different actions. For example, we see [54:30] that like GPT 5 uh I think 5.2 actually [54:35] as the more advanced model they're not [54:38] really trustworthy because the actions [54:40] can be very sensitive to the input. they [54:42] spread out everywhere versus GPT 4.1 [54:46] meaning you can see their their [54:48] suggestions are more have a lower [54:50] variance and they consistently provide [54:52] the same type of suggestions given the [54:55] different type of input and I think I'm [54:57] really running short on time I just use [54:59] one minute to finish this up when it [55:01] comes to retrospective failure we are [55:04] looking at the cases where you we don't [55:07] have any access to run the system but [55:09] there are failures for example something [55:11] I feel most of us experience that and [55:14] get suffered with is flight cancellation [55:16] delays like for no reason my flight just [55:19] got delayed and for a very long time I [55:21] don't even know who made the decision to [55:23] cancel this flight. So we were looking [55:25] at this particular case of 2022 [55:28] Southwest scheduling crisis where if you [55:32] were here in the US you probably heard [55:34] uh more than thousands of flight got [55:36] cancelled during the Christmas week. two [55:38] million people got stranded at the [55:40] airport and it all started from a snow [55:44] winter storm um happened at Denver but [55:47] somehow within three four days Southwest [55:50] has to cancel every single part of their [55:53] their their flight across the US and [55:56] there's as of today no one was claiming [55:59] responsibility southwest would say it's [56:01] the winter storm we were delayed by [56:03] deicing but it's it can't be true [56:06] because only Denver had a winter storm [56:08] other where else it was completely okay [56:10] the swapa there are their pilot [56:13] association have other complaints about [56:15] their leadership where CNN will complain [56:18] about network so what is the root cause [56:20] here a we are actually deploying exactly [56:22] the same process but here the difficult [56:25] is we don't really have a model we don't [56:27] even have a simulator we only have data [56:30] I mean maybe uh I I won't have time to [56:32] go to the details but maybe you're [56:34] curious about what actually has caused [56:36] the southwest um constellation we [56:39] identify that the one important hidden [56:42] factor here is the airplane reserve. [56:45] It's a number of airplane each airport [56:47] reserve overnight for their flight next [56:50] day. And we can see that although the [56:52] winter storm indeed disrupted um Denver, [56:56] this is a Denver airplane reserve short [56:58] like shortage compared to the required [57:01] and by the way all the value here are [57:03] infer because they were never public [57:04] information. We can see that the [57:07] airplane reserve actually recovered [57:09] pretty quickly after the winter storm [57:10] and Denver. However, other headquarters, [57:14] a big airports like Las Vegas and uh [57:16] Dallas, they were not infected by the [57:19] winter storm, but their airplane reserve [57:21] continues to get worse over the week. [57:24] And that is a very obvious uh at least [57:27] factor we can keep observing. So here we [57:30] can actually plot over that week what's [57:33] the relative airplane reserve and the [57:35] amount of cancellations that happening [57:38] during the during the week across [57:39] different cities and clearly you can see [57:42] um [57:44] Denver got recovered pretty quickly but [57:46] Las Vegas and Dallas got pretty [57:49] significantly impacted by by the whole [57:51] scheduling process. So to summarize, we [57:54] talked about building safe and [57:56] intelligent autonomy from two [57:58] complimentary aspects. Safe and mission [58:00] satisfaction by design versus generating [58:03] evidence through active testing. And [58:05] they are looking at different set of the [58:08] parameters of your system and the [58:10] environment. And I think that they [58:12] together can uh bring some of the [58:14] rigorous mathematical methodology from [58:17] our classical approach into using [58:20] datadriven approaches and enable us to [58:23] to build systems at large scale that are [58:27] safe by design, scalable by architecture [58:30] and reliable by proof. And that's um all [58:33] I want to talk about today. I know I'm [58:35] running a little longer and I be I will [58:37] stay around for uh the after seminar [58:40] event. If you want to discuss anything [58:42] I'm happy to [58:45] [applause] [58:46] thank you for the talk. Maybe we have uh [58:49] make time for one or two questions quick [58:51] questions. Yeah. [58:53] >> Yeah. Thank you very much. [58:56] >> Thank you very much for the great talk. [58:58] I just want to ask that you mentioned [59:00] that safety constraints cannot be like [59:02] compromised like it should not be soft [59:05] or should be hard but sometimes like [59:07] under like extreme cases for example [59:09] like like we may these kind of safety [59:11] constraints may be contradictory to each [59:13] other [59:14] >> like for example like in the for example [59:16] in the driving scenario like one car may [59:19] just go to your lane so that you may [59:21] need to go to the opposite lane order to [59:22] avoid the car that is of course like not [59:25] uh hold to the safety constraint but you [59:27] need to do that in order to avoid the [59:29] car. So I just wonder like under this [59:31] kind of cases like the safety [59:33] constraints cannot be like um hold all [59:35] the all of them and we have to sacrifice [59:38] some of them like how would you deal [59:39] with this kind of situations? Yeah, [59:41] that's a very good question about like [59:43] you know there are there are cases first [59:46] of all when we say the safety are hard [59:49] constraints there are hard constraints [59:51] on whatever you define as safety right [59:53] like as I said why the reason we need [59:55] testing is there are always cases we [59:57] cannot imagine at the design phase so we [60:00] have to understand when they fail [60:02] because certain certain assumptions we [60:04] make on the design phase got break broke [60:07] so when we enforce a hard constraint [60:08] they can only enforce the ones that we [60:10] kind of like describe as hard [60:12] constraints they will be satisfied but [60:14] in your in your case it will be the [60:16] adversarial that will just cause you [60:19] know for collision avoidance a simple [60:21] case would be you have adversarial [60:24] traveling at the light speed to to hit [60:25] you there's no way for you to get rid of [60:27] it so that would be I would say like [60:29] that's why we were also looking at the [60:32] other perspective like what we want to [60:34] fight figure out that adversary maybe [60:35] they exist maybe they not um but what [60:39] like There will be domains we can [60:41] constrain on but like in the particular [60:44] case for example if your safety [60:45] constraint is strictly collision [60:48] avoidance then collision avoidance will [60:50] be respected but if you didn't if you [60:53] did put stay in the len as a strictly [60:55] safe constraint it will be there and in [60:57] this particular case collision is not [60:59] avoidable at all. Well, maybe through [61:02] testing we figure out this could be a [61:04] case. We could, you know, relax some [61:07] some of it like staying in the land as a [61:10] secondary safety consideration that can [61:12] be relaxed when they're strictly not [61:15] possible to satisfy both and that we can [61:18] encourage some you know behavior that [61:20] that may avoid violate certain [61:23] constraints to satisfy other more higher [61:25] priority constraints. So those are I [61:28] guess design choices but mathematically [61:30] if you put it there enforce it there [61:33] they will be uh they will be kind of [61:35] like yielding our approach will be kind [61:37] of like you know encouraged and to some [61:39] extent enforced during the dur in the [61:41] policy and you know for those [61:43] adversarials that cannot be avoided they [61:45] cannot be avoided.