gatekeeper
A safety filter that runs two controllers (performance and safety driven) and searches for the latest switching time the system can still be safe while remaining on the performance-driven controller.
The idea in one picture
A robot is driving toward a goal with some performance controller that knows nothing about safety. Behind it sits a second controller whose only job is to remain safe. The question gatekeeper asks, over and over, is:
How much longer can I keep running the performance controller and still be certain I can bail out afterwards?
Concretely: simulate "follow the nominal controller for \(T_S\) seconds, then hand over to the backup controller." If that whole simulated trajectory stays safe and ends somewhere the backup controller can ensure safety forever, then \(T_S\) seconds of nominal behaviour are certified. Sweep \(T_S\), take the largest one that passes, and commit to it.
The two policies
Everything rests on having two controllers with completely different jobs.
The nominal policy \(\pi_{\mathrm{nom}}\) is performance-driven. It can be an MPC, an RRT* path with a tracking controller, a learned policy, a human on a joystick. It is not assumed safe, and nothing about it is assumed at all.
The backup policy \(\pi_b\) ensures safety forever. Hover in place, come to a stop, pull up out of the canyon, drive into a known safety pocket, or circle. It is system-specific and task-specific. It is not assumed good at the task.
Formally the backup policy needs to do two things. Assume we have a safe set \(\mathcal{C} = \{x : h_{\mathcal{C}}(x) \ge 0\}\) and a terminal set \(\mathcal{S}_0 \subseteq \mathcal{C}\).
Backup policy. A locally Lipschitz \(\pi_b : \mathcal{X} \to U\) is a backup policy for \(\mathcal{S}_0\) with backup horizon \(T_B\) if
(i) it recovers: from any state in some neighbourhood of \(\mathcal{S}_0\), running \(\pi_b\) stays in \(\mathcal{C}\) over \([0, T_B]\) and lands in \(\mathcal{S}_0\) at time \(T_B\); and
(ii) it stays: \(\mathcal{S}_0\) is forward invariant under \(\pi_b\).
Part (ii) is the piece that reaches to infinity. Everything the algorithm checks online is finite; the "forever" comes from \(\mathcal{S}_0\) being invariant, which you establish once, offline.
A Dubins car: \(\dot p_x = v\cos\psi\), \(\dot p_y = v\sin\psi\), \(\dot\psi = \omega\), with fixed speed \(v\) and \(|\omega| \le \omega_{\max}\). It cannot stop, so "stop and hover" is not available.
Backup policy: \(\pi_b(x) = -\omega_{\max}\), turn right as hard as possible. The closed loop is a circle of radius \(\rho = v/\omega_{\max}\) centred at \(c(x) = p + \rho\,(\sin\psi,\, -\cos\psi)\), and the state returns exactly to where it started after \(T_B = 2\pi/\omega_{\max}\).
Terminal set: \(\mathcal{S}_0 = \{x : \text{the circle } c(x) + \rho\,\mathbb{S}^1 \text{ lies in } \mathcal{C}\}\). Invariance is immediate - the state just goes round and round that circle, and the circle does not move. For a disc obstacle of radius \(r_o\) at \(o\) and a robot of radius \(r_r\), membership is a closed-form test:
$$\big|\,\|c(x) - o\| - \rho\,\big| \ \ge\ r_o + r_r .$$Both ways of satisfying it are real: orbit clear of the obstacle, or orbit tightly around it.
Candidate trajectories
Now the construction. Work at discrete update times \(t_k = t_0 + k\,\Delta t\), with \(x_k = x(t_k)\), and write \(\varphi^\pi_\tau(x)\) for the state reached at time \(\tau\) by running policy \(\pi\) from \(x\).
Candidate trajectory. For a switching time \(T_S \ge 0\),
$$\chi^{\mathrm{can}}(\tau;\, x_k, T_S) = \begin{cases} \varphi^{\pi_{\mathrm{nom}}}_{\tau}(x_k), & \tau \in [0, T_S], \\[4pt] \varphi^{\pi_b}_{\tau - T_S}\!\big(\varphi^{\pi_{\mathrm{nom}}}_{T_S}(x_k)\big), & \tau \in [T_S,\ T_S + T_B]. \end{cases}$$Nominal for \(T_S\), backup for \(T_B\) after that.
When is a candidate valid?
In plain words, a candidate is valid if you can safely reach the terminal set.
Validity. \(\mathrm{Valid}(x_k; T_S, T_B) = 1\) if and only if
$$\chi^{\mathrm{can}}(\tau; x_k, T_S) \in \mathcal{C} \quad \forall \tau \in [0,\ T_S + T_B], \qquad\text{and}\qquad \chi^{\mathrm{can}}(T_S + T_B;\, x_k, T_S) \in \mathcal{S}_0 .$$The first condition says the rollout never leaves the safe set. The second says it ends in the terminal set, and that is what converts a finite check into an infinite-time guarantee: past \(T_S + T_B\) the state is in \(\mathcal{S}_0\), and \(\pi_b\) keeps it there by assumption (ii). So
$$\underbrace{\text{safe on } [0,\ T_S+T_B]}_{\text{checked numerically}} \ +\ \underbrace{\text{in } \mathcal{S}_0 \text{ at the end}}_{\text{checked numerically}} \ +\ \underbrace{\mathcal{S}_0 \text{ invariant under } \pi_b}_{\text{established offline}} \ \Longrightarrow\ \text{safe for all } \tau \ge 0 .$$Write \(\mathcal{V}(T_S) = \{x : \mathrm{Valid}(x; T_S, T_B) = 1\}\) for the set of states from which a given switching time passes.
Committing, and why that is safe forever
At each update, gatekeeper takes the largest switching time that passes, over a search horizon \(T_H\):
$$T_S^\star(x_k) \ =\ \sup\big\{\, T_S \in [0, T_H] \ :\ \mathrm{Valid}(x_k; T_S) = 1 \,\big\},$$and the filter is simply
$$\pi_{\mathrm{GK}}(x_k) = \begin{cases} \pi_{\mathrm{nom}}(x_k), & T_S^\star(x_k) > 0, \\ \pi_b(x_k), & T_S^\star(x_k) = 0 . \end{cases}$$In practice the supremum is a grid search, \(T_S \in \{0, \Delta t, 2\Delta t, \ldots, T_H\}\), scanning down from \(T_H\) and stopping at the first hit. It is a search over a single scalar in a bounded interval, which is the reason the method is cheap.
The recursion
The safety argument is an induction, and the key move is what happens when the search fails. If no \(T_S\) is valid at step \(k+1\), gatekeeper simply takes the previously committed trajectory (switching time). The previously committed trajectory was already certified safe for all future time when it was committed, so falling back to it is always available and always safe.
$$\chi^{\mathrm{com}}_{k+1} = \begin{cases} \chi^{\mathrm{can}}(\cdot\,; x_{k+1}, T_S^\star), & \text{if some } T_S \text{ is valid},\\ \chi^{\mathrm{com}}_{k}, & \text{otherwise.} \end{cases}$$Interactive Demo
The system below is the Dubins car from the example above. The nominal controller is a potential field that steers toward the goal and pushes away from obstacles, which is not necessarily safe. The backup is a hard right turn, so the terminal set is circling.
Notice what the demo does not have: no barrier function, no QP, no constraint gradients, no relative-degree bookkeeping, nothing that needs \(\mathcal{C}\) to be smooth or the dynamics to be control-affine. The safe set is just a collision test, and the only numerical machinery is forward integration.
One honest caveat about dragging. The rollout treats the world as static, so a committed trajectory is a certificate about the obstacles as they were at the last update. Dropping an obstacle directly onto the robot will produce a collision, and no filter could prevent that. This is exactly the assumption the T-RO paper makes explicit: the perceived safe set must only ever shrink in a way the system was warned about, so that a state certified safe at \(t_k\) is not silently reclassified at \(t_{k+1}\). Give the robot room and the guarantee holds - across a few hundred randomized static worlds, with the speed, turn rate, horizon, grid and robot radius all varied, the version above never violates a constraint.
Why maximize the switching time?
gatekeeper is one of three backup-based safety filters that share almost everything. All three assume a backup policy, all three certify safety by showing the system can still bail out, and all three roll out the backup to do it. What separates them is a single design choice: what the online decision variable is.
| Backup CBF | MPS | gatekeeper | |
|---|---|---|---|
| Decision variable | control input \(u \in U\) | accept / reject | switching time \(T_S \in [0, T_H]\) |
| Mechanism | QP with barrier constraints along the backup flow | check validity at \(T_S = \Delta t\) | check validity, take the largest valid \(T_S\) |
| Output | a modified input | \(\pi_{\mathrm{nom}}\) or \(\pi_b\) | \(\pi_{\mathrm{nom}}\) or \(\pi_b\) |
| Smoothness | continuous blend | binary switch | binary switch |
The common flaw: safety evaluated on the backup
Safety gets certified through the feasibility of a backup maneuver. Essentially, we have pushed the safety problem into the problem of finding the backup controller and terminal set.
Pros and Cons
Pros
Easily implementable and computationally efficient. Can handle input constraints and complex dynamics and safety constraints.
Cons
Needs a backup policy and a system model accurate enough to correctly predict its rollout. The backup policy must be able to keep the system in a safe set for a known time horizon. Assumes the environment is static.
References
- Agrawal, Chen, Panagou, “gatekeeper: Online Safety Verification and Control for Nonlinear Systems in Dynamic Environments,” IEEE T-RO 40, 2024 (arXiv:2211.14361). The algorithm, the recursive-safety proof, the robust version with tracking-error tubes, and quadrotor hardware experiments.
- Kim, Menon, Trivedi, Panagou, “Backup-Based Safety Filters: A Comparative Review of Backup CBF, Model Predictive Shielding, and gatekeeper” (arXiv:2604.02401). The unified notation used here, the filter-inactive set comparison, and the two inclusion theorems. Code: tkkim-robot/safe_control.
- Chen, Jankovic, Santillo, Ames, “Backup Control Barrier Functions: Formulation and Comparative Study,” CDC 2021. The implicit safe set \(\mathcal{R}^{\pi_b}(T_B; \mathcal{S}_0)\).
- Bastani, “Safe Reinforcement Learning with Nonlinear Dynamics via Model Predictive Shielding,” ACC 2021. The original MPS.
- Agrawal, Panagou, “Online Safety Under Multiple Constraints and Input Bounds Using gatekeeper,” IEEE L-CSS 9, 2025. Multiple simultaneous constraints.
- Cherenson, Lee, Kim, Panagou, “Distributionally Robust Safety Under Arbitrary Uncertainties: A Safety Filtering Approach” (arXiv:2605.12974). Replaces the single deterministic rollout with sampled rollouts and a Wasserstein-inflated failure threshold, keeping the one-dimensional search over \(T_S\).