# Humanoid safety filters failed in selected physical tests

> Seven selected filter trials produced collisions; broader search totals conflict.

By BIGCHANGE.AI Editorial

Published: 2026-10-27T02:31:30.964Z
Updated: 2026-10-27T02:31:30.964Z
Canonical: https://bigchange.ai/blog/humanoid-safety-filters-selected-physical-tests

![Humanoid beside a fixed block.](https://bigchange.ai/api/media/file/humanoid-filter-upper-body-obstacle-concept-v2.png)
AI-generated, BIG CHANGE.

Bao and colleagues' October 22 preprint [*Not an Accident*](https://arxiv.org/html/2610.31923v1) reports arm collisions in seven selected humanoid safety-filter trials.

## The big change

- **What changed:** A task change preceded arm contact despite filtering.
- **Why it matters:** A formal safety rule applies only where its assumptions hold and a feasible correction exists. A filter name alone does not establish physical clearance through changing tasks.
- **What to watch:** Systematic physical trials across tasks and environments would help show how far the selected result extends.

## How the safety layer works

The task controller proposes a motion, and a safety filter can revise that command to satisfy a specified constraint. The [SPARK toolkit](https://arxiv.org/html/2502.03132v3) provides configurable safety criteria, simulated tasks and an interface for hardware experiments.

[Control barrier function theory](https://arxiv.org/html/1903.11199v1) describes safety as keeping the system inside a defined set of acceptable states. The guarantee requires a control action that can satisfy the rule under the model and available actuation. If the robot's state leaves no such action, the controller cannot enforce that rule at that state.

## What happened on hardware

One selected upper-body, static-obstacle case per filter yielded a failure. In the illustrated trial, the arm cleared an obstacle without insertion, then contacted it on returning to the original target after an intermediate goal.

The physical tests exclude whole-body movement and moving obstacles. Selected failures cannot establish collision frequency in ordinary operation.

## Where the broader numbers disagree

In simulation, the abstract says Siren found three times as many attacks as random search. Table 3 gives 3,277 versus 1,760 (1.86). Section 7.3 says 35 scenarios; its table uses 40. These conflicts remain unresolved.

An engineer can use this evidence to separate three questions: whether a controller's rule is sound under its assumptions, whether a safe correction remains feasible after a task change, and how often a real system reaches such a state. A stronger frequency estimate would require a specified sample of tasks and environments, with baseline and changed-task outcomes reported for each.

## Sources & further reading

- [Bao et al., *Not an Accident*](https://arxiv.org/html/2610.31923v1): Physical trials and disputed numbers (v1).
- [Ames and colleagues, *Control Barrier Functions*](https://arxiv.org/html/1903.11199v1): Formal safety conditions and feasible control (2019).
- [Sun and colleagues, *SPARK*](https://arxiv.org/html/2502.03132v3): Toolkit and benchmark context (version 3, January 14, 2026).

## Sources

- [Bao et al., Not an Accident](https://arxiv.org/html/2610.31923v1) — Version 1; physical trials and disputed numbers.
- [Ames and colleagues, Control Barrier Functions](https://arxiv.org/html/1903.11199v1) — Defines conditional safe-set invariance and feasible control under actuation limits.
- [Sun and colleagues, SPARK](https://arxiv.org/html/2502.03132v3) — Version 3 describes the configurable benchmark and hardware interface; it does not replicate Bao's collisions.