humanoidsdata.com

Search

Search companies, datasets, articles, and glossary terms for humanoids and embodied AI.

← All glossary terms

Hardware & control

Safety filter

A safety filter is a supervisory component that evaluates a proposed robot action, control input, plan, or reference against declared constraints and passes it through, modifies it, or substitutes a safer alternative before execution. It separates nominal task behaviour from constraint enforcement, but it only protects against hazards represented by its model, observations, and safety specification.

Also known as: runtime safety filter, safety shield, runtime shield

Updated

The nominal controller proposes; the filter supervises

A safety filter sits between a source of behaviour and the controlled system. The source may be a learned policy, motion planner, teleoperator, or generative model. The filter evaluates the proposal using the current state and a safety specification, then passes compliant behaviour through or intervenes before execution.

The predictive safety-filter formulation checks whether a proposed control input can satisfy future state and input constraints. If not, it supplies an alternative input while trying to modify the original as little as necessary. Other filters use reachability, control barrier functions, rule-based shields, or combinations of learned and model-based components.

Filters can act on actions, trajectories, or references

The protected object is part of the definition. A low-level filter may adjust the actuator command at every control step. A predictive filter may assess a short future plan. A motion-generation filter may edit an entire reference before a separate whole-body controller tracks it.

CSF operates at two points. During generation, it filters the motion estimate at each sampling step. During execution, its runtime shield can preserve an already executed prefix and replace the uncommitted remainder when a protected entity enters the scene.

Minimal intervention is a design goal, not automatic proof

Many safety filters optimise for the closest allowed alternative so useful task behaviour survives. That trade-off depends on the distance measure and on which constraints are active. A conservative filter may stop too often; a permissive or poorly observed filter may miss a hazard.

The word “safety” does not imply certification. A filter cannot enforce hazards it does not model or perceive, and a valid filtered command may still be executed incorrectly by the physical system. Evaluation should report false interventions, missed hazards, timing, feasibility failures, task degradation, and hardware outcomes—not only whether an optimisation returned a solution.

Dataset records should keep the nominal proposal, safety specification, state estimate, active constraints, filtered output, reason for intervention, latency, and measured execution separately. Otherwise downstream users cannot distinguish naturally safe behaviour from behaviour made safe only by an external supervisor.

Sources