[Proposal] Standardized robot fault injection for robustness evaluation

Proposal

Add a reusable, vectorized fault-injection layer for Isaac Lab so policies can be trained and evaluated under persistent and intermittent robot failures, not only stochastic noise and parameter randomization.

A first version could support sensor dropout/freeze and bias drift, actuator degradation or loss of authority, stuck joints, command dropout, and deterministic onset/duration/recovery per environment. It should compose with the existing NoiseModel, DelayBuffer, and EventManager abstractions rather than replace them.

Motivation

Isaac Lab already has strong domain-randomization, noise, delay, and actuator-parameter tools, but there is no common abstraction for stateful failures such as a camera freezing for two seconds or one actuator losing 70% of its authority halfway through an episode.

Today these tests require task-specific state machines. A shared fault lifecycle would make robustness training and evaluation reproducible across locomotion and manipulation tasks, while also allowing evaluation tooling to inspect the active fault state without exposing it to the policy.

Alternatives

The behavior can be implemented with custom event terms, noise models, action wrappers, and buffers, but each task then reimplements onset, persistence, recovery, logging, and reproducibility. A small shared stateful abstraction would avoid that duplication.

Build Info

• Isaac Lab Version: current release/3.0.0-beta2
• Isaac Sim Version: intended to work across supported Isaac Lab backends where the affected boundary is available

Additional context

I searched current issues for fault injection, actuator/sensor dropout, persistent failure models, and robustness fault evaluation and did not find an equivalent proposal.

If this direction is useful, I would be happy to prototype the core fault lifecycle, one observation/sensor fault, one actuator/action fault, tests, documentation, and a small example.

Checklist

• I have checked that there is no similar issue in the repo

Acceptance Criteria

• Common seeded/stateful lifecycle for onset, duration, recovery, and per-environment activation
• At least one sensor/observation fault and one actuator/action fault
• Fault state is inspectable for evaluation/logging without being exposed to the policy
• Vectorized environments and deterministic replay from seed/config are supported
• Documentation includes one nominal-vs-faulted policy example