RTD-RAX: Fast, Safe Trajectory Planning for Systems under Unknown Disturbances

MECC 2026 · Tempe, Arizona
Path Planning and Motion Control I · 08.27.26

Evanns Morales-Cuadrado

School of ECE

Long Kiu Chung

School of ME

Shreyas Kousik

School of ME

Samuel Coogan

School of ECE

Background

Robots Must Plan Safely, in Real Time

Robots now share our roads, sidewalks, warehouses, and skies, and must replan safely as the world changes.

Waymo autonomous vehicle on a city street — Autonomous drivingrobotsguide.com

Serve Robotics sidewalk delivery robot in Atlanta — Sidewalk deliveryserverobotics.com

Amazon warehouse robot carrying a shelf — Warehouse logisticsqz.com

Drone flying a search-and-rescue mission — Search & rescueaerosociety.com

What we want from a planner

FastReplan in milliseconds

Dynamically feasiblePlans the robot can actually track

SafeAvoids every sensed obstacle

Recursively feasibleA certified fail-safe is always ready

Not overly conservativeNo avoidable fail-safes

Disturbance-awareRobust to a priori unknown disturbances

We introduce RTD-RAX

~0:55 + 0:20 title · clock 1:15.

Robots are showing up everywhere: on roads, sidewalks, in warehouses, in the air. Every one of them has to keep replanning its motion as it sees new obstacles, and that gives us six things we want from a planner. It has to be fast, because it replans constantly. It has to produce motions the robot can actually follow. It has to avoid every obstacle it sees, and it needs a fail-safe ready if planning ever fails. It shouldn’t be so cautious that it brakes when it doesn’t need to. And it has to stay safe under disturbances we didn’t know about in advance: a gust of wind, an icy patch, a slippery floor.

Existing work, Reachability-based Trajectory Design, gives you the first four with guarantees, but it is conservative and it has no way to handle disturbances that show up at runtime. (advance: the RTD-RAX line appears) That’s what RTD-RAX is for, and it’s what the rest of the talk is about.

Reachability-based Trajectory Design (RTD): Safe Receding-Horizon Planning

1Sensecurrent obstacles

→

2Planfind a safe k* within τ_plan

→

3Executefollow it for τ_plan, then switch

execute & plan the next segment

failsafe maneuver

0τ_planT

Each plan lasts T s, with a fixed planning time τ_plan ∈ (0, T): while following the first τ_plan s, RTD plans the next segment. The rest, [τ_plan, T], is a failsafe maneuver: if no new plan is found in time, the trajectory terminates safely.

Offline For a family of simple trajectories indexed by a parameter $k$ , compute a forward reachable set (FRS): everywhere the robot could end up [1]

Online Rule out every $k$ whose FRS touches an obstacle, then pick the best remaining $k$

$k^\star = \arg\min_{k \,\in\, K_{\text{safe}}} \; J(k)$ $K_{\text{safe}}$ : parameters whose FRS avoids all obstacles · $J$ : progress toward the goal

~1:40 · clock 2:55. (Video plays from the start, ~51 s, while you talk.) RTD is a receding-horizon planner. Each plan lasts T seconds, but the robot only follows the first tau-plan seconds of it, half a second here. Tau-plan is fixed ahead of time and enforced at runtime: planning gets cut off when it runs out. During that time it senses the obstacles around it and plans the next segment, then switches to it and does it all again. (Point at the bar.) The rest of each plan, from tau-plan to T, is a failsafe braking maneuver. So if the robot ever fails to find a new plan within tau-plan, it just keeps following the current trajectory, which terminates safely.

What makes this fast enough is that RTD splits the work in two. Offline, you pick a family of simple trajectories, each described by a couple of numbers, k, and for every k you compute a forward reachable set: all the places the robot could be while following that trajectory. Online, the robot only checks which k’s would hit a sensed obstacle, throws those out, and picks the best of the rest. That’s a small optimization, so it runs in milliseconds.

In the video: the robot at the origin, an obstacle, a goal. The shaded cone is the reachable set for the whole trajectory family, and each value of k picks out one trajectory in it. The planner keeps only trajectories whose reachable set misses the obstacle. Notice the band around the chosen trajectory at the end; that’s the padding, and it’s where the next slide picks up.

What RTD Gets Right, and What We Want to Improve

What RTD gets right

Fastonline it only solves a small optimization over k

Dynamically feasibleplans come from a family the robot can track

Safesensed obstacles become constraints on k

Recursively feasibleevery plan ends in a certified fail-safe

1Reachability is slowParameterized FRS tools can be intractable for complex, high-dimensional systems

→

2Simplified modelSo, the FRS is computed for a simple planning model, not the high-fidelity model

→

3Worst-case boundThe mismatch is treated as a bounded disturbance at its worst case

→

4Inflated FRSEvery reachable set is padded by that bound

Sampled tracking errors (blue) stay well below the worst-case bound (green) used to pad the FRS

Worst-case bound (green) vs. actual tracking errors (blue). Reproduced from Kousik et al. 2020.

Overly conservative Safe passage gets constrained away

Standard RTD in a narrow gap: the padded reachable set overlaps both obstacles, so the problem is infeasible

RTD does not find the safe passage.

Blind to runtime disturbances

Every FRS is pre-computed offline, so disturbances that show up at runtime (wind, slip, a push) cannot be accounted for.

What if we drop the padding, and check each plan online with a reachability method fast enough for real time?

~1:40 · clock 4:35. So RTD gets a lot right: it’s fast, its plans are ones the robot can actually follow, it’s safe against everything it senses, and it always has a fail-safe ready. (Click: the card is replaced by what we want to improve.) But remember that band around the chosen trajectory: that’s padding. So where does that padding come from? Computing parameterized reachable sets is slow: for some systems these tools take hours offline. That forces RTD to compute the reachable set for a simplified planning model instead of the real robot dynamics. To stay safe anyway, the gap between the planning model and the real robot is treated as a bounded disturbance, and the reachable set is padded by its worst case.

On the left: the green curve is that worst-case bound; the blue curves are the tracking errors the robot actually has. The bound is well above almost all of them, and every reachable set gets padded by it.

That makes RTD overly conservative. (Talk through the roundabout example: RTD swings wide around the padded obstacle instead of taking the direct path.) And sometimes there’s safe passage available that RTD can’t find at all: this gap is wide enough for the robot, but the padded sets overlap both obstacles, so every trajectory is constrained away and RTD just brakes.

There’s a second limitation, in the strip along the bottom. All of RTD’s reachable sets are computed offline, before the robot ever runs. So if a disturbance shows up at runtime, like wind or wheel slip, RTD has no way to account for it: the sets are fixed.

(Click: “What if we drop the padding…” rises from the bottom.) So what if we drop the padding and check each plan online instead?

RTD-RAX

RTD-RAX: Plan → Verify → Repair

RTD planning core

Online verification & repair layer

RTD planner Offline FRS without padding + fast optimization over k

⟶candidate k*

Mixed-monotone verification Reachable tube of this plan under current uncertainty & disturbance bounds

⟶safe

Execute Run the certified plan, then replan

↓unsafe re-verify↑

Repair Nearby candidate: slow down, steer, or tighten constraints

⟶nothing certified in time

Fail-safe Brake along the last certified plan

RTD’s new job: propose a good plan fast from the FRS without the worst-case padding. High-performing plans are no longer thrown out, but unsafe ones may now be proposed

The verifier’s job: prove a proposed plan is safe with a reachability method tailored for real-time computation along specific trajectories with the true system dynamics.

And a bonus: because the check runs online, it can also account for disturbances measured at runtime. Standard RTD’s pre-computed reachable sets cannot account for such disturbances.

~1:10 · clock 5:45. So here’s RTD-RAX: RTD with a Runtime-Assurance eXtension. We get rid of the conservative planning: RTD now uses a reachable set without the worst-case padding, and its only job is to propose a good candidate trajectory, quickly.

Safety now comes from a second step. The candidate goes to an online verifier built on mixed-monotone reachability, a reachability method fast enough to run every planning cycle. It computes a reachable tube for this specific plan. If the tube is clear of obstacles, we execute. If not, we repair the candidate and check again. And if nothing gets certified in time, the robot follows the braking part of its last certified plan.

(Click: the “And a bonus” strip appears.) Not only does this fix the conservatism; because the check happens online, it can also use disturbances we measure at runtime, something RTD’s offline reachable set could never account for.

Certifying a Plan with Mixed-Monotone Reachability

Every trajectory, under every bounded disturbance, stays inside the box.

$x(0) \in [\underline{x}_0, \overline{x}_0],\; w(t) \in W(t) \;\Longrightarrow\; x(t) \in [\underline{x}(t), \overline{x}(t)]$ mixed-monotone reachability [2], computed with immrax [3]

Start boxCurrent state ± ε: robot footprint, estimation error, margin

Disturbance boundsW(t) = [ŵ − δ, ŵ + δ] from an online estimate

Reachable tubeLower and upper bounds follow one ODE, integrated once over the whole plan, braking included

Collision check Position boxes $\mathcal{B}_j$ at each sample, plus swept hulls $\mathcal{S}_j$ between consecutive samples, must miss every obstacle

$\mathcal{B}_j \cap X_{\text{obs}} = \varnothing \;\text{ and }\; \mathcal{S}_j \cap X_{\text{obs}} = \varnothing \;\; \forall j \;\Longrightarrow\;$ certified

~1:20 · clock 7:05. How do we check a plan quickly? With mixed-monotone reachability. Rather than simulating thousands of trajectories, we keep just a lower and an upper bound on every state. Those bounds obey their own differential equation, twice the size of the robot model, and we integrate it once. In the animation, every trajectory under every bounded disturbance stays inside the box. The immrax toolbox builds these bound dynamics automatically and JIT-compiles them, so a check takes milliseconds.

The check itself is four steps. We start with a box around the current state that covers the robot’s footprint, the estimation error, and any safety margin. We take disturbance bounds from an online estimate: the estimate plus or minus its error. We propagate the bounds over the whole plan, braking included. Then we check the position boxes, call them B-j, and the hulls swept between consecutive boxes, S-j, against every obstacle. That’s the line at the bottom: if every B-j and every S-j misses the obstacles, the plan is certified.

(Not on the slide, say it:) the guarantee holds as long as the true disturbance stays inside the bounds we supplied. Wider bounds are more conservative but still valid.

(If asked: the swept hull assumes a small time step, 10 ms in our experiments; picture in backup.)

When a Candidate Fails: Repair, Then Re-Certify

1Speed backoffSlow down so the maneuver is less aggressive

→

2Lateral pushSteer against the estimated disturbance

→

3Tighten constraintsAdd obstacle buffer, re-solve RTD

Guarantee (safe & recursively feasible). The robot only executes plans certified over their full horizon, braking included. At every moment it is either following a new certified plan or its last plan’s safe termination maneuver.

Repair is a heuristic — it may not find a safe plan. Every repaired candidate is re-certified before it runs, and the certified failsafe maneuver is always available if the planning window closes.

What the RAX layer buys Standard RTD failsafes as soon as a planning cycle comes up empty. Repair keeps looking — it extends the window in which a safe trajectory can still be found, so the robot keeps making progress instead of stopping. A failed repair costs progress, never safety.

Angled obstacle scenario: unsafe candidate tubes in pink are rejected, repaired tubes in green are certified and executed — Two repairs in Case 2: rejected (pink) → repaired (green)

~1:00 · clock 8:05. What happens when the verifier says no? We try a short sequence of fixes. First slow down, which makes the maneuver less aggressive. If that isn’t enough, steer against the estimated disturbance. If that still fails, add buffer around the obstacles and re-solve the RTD problem. On the right you can see this happen twice: pink tubes are rejected candidates, green tubes are the repaired plans we actually ran.

Two points. First, the guarantee: we only ever switch to a plan that’s certified over its full horizon, braking included, so we’re always on a certified plan or its certified braking tail. That keeps RTD’s safety and recursive-feasibility guarantee. Second, repair is a heuristic. It can fail. But safety never depends on it, because everything it produces is re-checked and the braking fallback is always there.

Results

Case 1: A Narrow Gap

Setup for all cases: Turtlebot-scale ground robot · unicycle model (position, heading, speed) · RTD plans with a Dubins-car model and 2 parameters k = (yaw rate, speed)

Green ellipse: non-padded RTD reachable set · blue: online mixed-monotone tube.

Parameter space for RTD-RAX: a white region of safe parameters exists, with the chosen parameter marked in green — RTD-RAX parameter space: safe k exist (white); chosen k* in green. With padding, every k is unsafe.

Standard RTDPadding closes the gap → no feasible plan → fail-safe braking

RTD-RAXNon-padded FRS proposes going straight through → tube certifies it → goal reached

Same robot, same obstacles. Conservatism is reduced by where the safety is certified: offline or online.

~1:15 · clock 9:20. Now the results. All three cases use a Turtlebot-sized ground robot with a unicycle model, and RTD plans with a simple car model described by two numbers: yaw rate and speed.

Case one isolates the conservatism problem. Two obstacles, a gap the robot fits through. On the left, standard RTD: the padded reachable set closes the gap, there’s no feasible plan, and it brakes immediately. On the right, RTD-RAX: without padding, the planner proposes driving straight through. The blue mixed-monotone tube certifies that exact plan, and the robot reaches the goal.

Next to the video is the parameter space. With padding, every parameter is unsafe. Without it, there’s a white pocket of safe parameters, and the chosen one is in green. Same robot, same obstacles: the only difference is where safety is checked.

Case 2: Catching and Repairing Unsafe Plans

Close-up of the two repairs: the unsafe candidate tube (pink) is rejected, the repaired tube (green) is certified and executed.

CatchWithout model error inflation, RTD proposes a plan that the verifier determines to be unsafe, so it is rejected before it runs.

RepairSmall adjustments (slow down, steer, tighten constraints) give a nearby plan, which is re-certified before it is used.

ResultTwo repairs over 10 planning steps; the robot reaches the goal and never executes an uncertified plan. While standard RTD can also find a safe trajectory for this scenario, it inefficiently avoids the obstacle and takes a longer route.

Note: the video is paused at each repair step so we can see the process. In the real run, verification and repair take only milliseconds, far too fast to follow.

Case 3: Disturbances Nobody Planned For

Setup6 m course, three offset gates; before each gate a disturbance patch (blue) pushes the robot toward an obstacle

Standard RTDThe offline FRS can’t see the patches: collides on planning cycle 3

RTD-RAXRejects & repairs 3 unsafe plans, reaches the goal in 19 cycles

+1.2 msRTD-RAX is only about 1.2 ms slower per planning cycle than standard RTD on average (9.4 vs. 10.6 ms, mean of 20 trials)

~1:30 · clock 11:30. Case three is the setting standard RTD can’t handle. A six-meter course with three gates, and before each gate a patch that pushes the robot toward an obstacle. RTD’s offline set knows nothing about these patches.

Standard RTD, on the left, gets pushed into the first obstacle on its third planning cycle. RTD-RAX, on the right, sees the disturbance bounds along each candidate, rejects three unsafe plans, repairs them, and reaches the goal in 19 cycles.

And it’s cheap: averaged over 20 trials, RTD-RAX takes only about 1.2 ms more per planning cycle than standard RTD, 10.6 versus 9.4 ms. (If asked why so little: without padding the RTD solve itself gets much faster, 6.5 down to 0.5 ms, which pays for most of the 6.4 ms of verification and repair.)

To be upfront: in this study the verifier measures the disturbance exactly. With a real estimator, the guarantee holds as long as its bounds contain the true disturbance.

(Full table, if asked: constraint setup 2.15 → 2.41; RTD solve 6.48 → 0.54; reference rollout 0.73 → 1.22; immrax verify 0 → 2.23; repair loop 0 → 4.20; total 9.39 ± 0.56 → 10.63 ± 0.72 ms.)

Conclusion

Takeaways

RTD-RAX builds upon what RTD already does wellFastDynamically feasibleSafeRecursively feasiblewhile making it:

Less conservative

A non-padded FRS plus an online check recovers maneuvers standard RTD rejects, like the narrow gap.

Disturbance-aware

The first RTD-based planner certified safe under disturbances not known ahead of time.

Still real-time

About 1.2 ms added to a ~10 ms planning cycle, thanks to JIT-compiled mixed-monotone reachability.

RTD proposes, fast mixed-monotone reachability certifies,
and clever repairs turn rejected plans into continued mission progress

~0:45 · clock 12:15. RTD-RAX builds on everything RTD already does well: it’s fast, its plans are trackable, it’s safe, and it always has a fail-safe. On top of that, three takeaways. RTD-RAX is less conservative: dropping the padding and checking online recovers maneuvers RTD rejects. It’s disturbance-aware: to our knowledge it’s the first RTD-based planner certified safe under disturbances that weren’t known ahead of time. And it runs in real time, adding about a millisecond per cycle. (Point at the icons: these are the wants from the opening slide, now checked off.) In one line: RTD proposes, fast reachability certifies, and when a plan fails, repair gives us another chance to make progress instead of stopping.

(Not on the slide; the Future Work backup slide has this if it comes up:) Next we want learned disturbance bounds, for example from Gaussian processes as in prior work from our group [Cao & Coogan, ICRA 2024], instead of perfect measurements; smarter gradient-based repair; hardware experiments on a ground robot and then a quadrotor; and a direct comparison with robust and tube MPC.

Thank You

RTD-RAX: Fast, Safe Trajectory Planning for Systems under Unknown Disturbances

Evanns Morales-Cuadrado · Long Kiu Chung · Shreyas Kousik · Samuel Coogan · Georgia Tech

Paperarxiv.org/abs/2603.21635

Projectevannsmc.github.io/ws_RTD

Codegithub.com/evannsmc/rtd-rax

Dockerdocker pull evannsmc/rtd-rax

Contactegm@gatech.edu

QR code linking to evannsmc.github.io/ws_RTD

Project site: code, docs, animations

Supported in part by the National Science Foundation under Awards #2333488 and #2219755 and by the Air Force Office of Scientific Research under Grant FA9550-23-1-0303. L. K. Chung was supported by NSF Award #2449160.

Backup

Backup. RTD — Planning Model & Trajectory Parameters

High-fidelity model (unicycle, state $(x, y, h, v)$ ): $\dot x = v\cos h, \quad \dot y = v\sin h, \quad \dot h = \omega, \quad \dot v = a$ inputs: yaw rate $\omega$ , longitudinal acceleration $a$ .

Planning model (Dubins car on shared states $z = (x, y, h)$ ): $\dot x = v_{\text{des}}\cos h, \quad \dot y = v_{\text{des}}\sin h, \quad \dot h = \omega_{\text{des}}$

Full 4-state dynamics are too expensive for the offline SOS reachable-set computation [1]
$(\omega_{\text{des}}, v_{\text{des}})$ are held constant over each plan, so one $k$ fixes one trajectory

Parameters $k = (k_1, k_2) \in [-1, 1]^2$ decode as $\omega_{\text{des}} = \omega_{\max}\, k_1, \qquad v_{\text{des}} = \tfrac{v_{\max}}{2}\,(k_2 + 1)$

Two-phase trajectory, horizon $T = t_{\text{plan}} + t_{\text{stop}}$ :

cruise for $t_{\text{plan}}$ , then scale $\omega$ and $v$ linearly to zero over $t_{\text{stop}}$
the braking tail is part of every certified plan, so it is the fail-safe

Implementation values: $t_{\text{plan}} = 0.5$ s · $t_{\text{stop}} = v_{\text{des}}/a_{\max}$ with $a_{\max} = 2$ m/s² · $\omega_{\max} = 1$ rad/s · FRS speed range 0.25–1.25 m/s · robot radius 0.175 m

Backup. RTD — Tracking Error & the Forward Reachable Set

Trajectory-tracking model. Tracking-error bound $g$ and any $d \in L_d = L^1([0,T], [-1,1]^{n_Z})$ : $\dot z_i(t) = f_{\text{des},i}(t, z(t), k) + g_i(t, k)\, d_i(t), \qquad i = 1, \dots, n_Z$ Every high-fidelity trajectory tracking $k$ is matched by some $d \in L_d$ [1, Lemma 16].

FRS (over-approximated offline): $X_{\text{FRS}} = \bigl\{ (\hat z, \hat k) \mid \exists\, t \in [0,T],\, z_0 \in Z_0,\, d \in L_d : z(0) = z_0,\; z(t) = \hat z \bigr\}$

Safe parameters for obstacles $X_{\text{obs}}$ : $\pi_K(X') = \{ k \mid \exists z \in X' : (z, k) \in X_{\text{FRS}} \}, \qquad K_{\text{safe}} = K \setminus \pi_K(X_{\text{obs}})$

RTD-RAX: use the non-inflated FRS ( $g \equiv 0$ ) only to propose $k^\star$ ; certification moves online.

Sampled lateral tracking-error trajectories enveloped by a polynomial worst-case bound — Worst-case envelope g_x(t) (green) over sampled tracking errors (blue dashed). Reproduced from Kousik *et al.* 2020, Fig. 3a.

Backup. Mixed-Monotone Reachability: One Box Holds Every Trajectory

Every sampled trajectory, under every disturbance w ∈ [−1, 1], stays inside the box.

Instead of simulating every possible trajectory, track just a lower and upper bound on each state [2]
The bounds follow their own ODE, twice the size of the robot model, integrated once per candidate
Boxes are conservative, but much less than standard RTD, and fast: immrax builds and JIT-compiles the bound dynamics automatically [3]

$x(0) \in [\underline{x}_0, \overline{x}_0],\;\; w(t) \in [\underline{w}, \overline{w}] \;\;\Longrightarrow\;\; x(t) \in [\underline{x}(t), \overline{x}(t)] \quad \forall\, t \ge 0$ start anywhere in the box, suffer any bounded disturbance, and the true state is still inside the propagated box

Backup. Mixed Monotonicity — Inclusion Function & Embedding System

For $\dot x = f(x, u, w)$ , an inclusion function $\mathcal F = [\underline{\mathcal F}, \overline{\mathcal F}]$ satisfies, for all $x \in [\underline x, \overline x]$ , $u \in [\underline u, \overline u]$ , $w \in [\underline w, \overline w]$ : $f(x, u, w) \in \mathcal F\bigl([\underline x, \overline x], [\underline u, \overline u], [\underline w, \overline w]\bigr)$

Embedding system ( $2n$ states; $x_{[i:y]}$ replaces the $i$ -th entry of $x$ with $y_i$ ): $\begin{aligned} \dot{\underline x}_i &= \underline{\mathcal F}\bigl([\underline x, \overline x_{[i:\underline x]}], [\underline u, \overline u], [\underline w, \overline w]\bigr)_i \\ \dot{\overline x}_i &= \overline{\mathcal F}\bigl([\underline x_{[i:\overline x]}, \overline x], [\underline u, \overline u], [\underline w, \overline w]\bigr)_i \end{aligned}$

Monotone w.r.t. the southeast order $(x, x') \preceq_{\text{SE}} (y, y') \iff [y, y'] \subseteq [x, x']$ [2].

Enclosure guarantee for all $T \ge 0$ : $\phi(T; x_0, u, w) \in \bigl[\!\bigl[ \Phi^{\mathcal E}(T; [\underline x_0, \overline x_0], [\underline u, \overline u], [\underline w, \overline w]) \bigr]\!\bigr]$

Exists for any vector field locally Lipschitz in state and disturbance [4, Thm. 1]
immrax derives $\mathcal F$ by JAX tracing + interval arithmetic and JIT-compiles $\mathcal E$ [3]

Backup. Certifying a Candidate Online

1Start boxCurrent state ± ε: robot footprint, estimation error, margin

→

2Disturbance boundsW(t) = [ŵ − δ, ŵ + δ] from an online estimate

→

3Reachable tubePropagate the bounds over the whole plan, braking included

→

4Collision checkPosition boxes + swept hulls between samples vs. obstacles

$\mathcal{B}_j \cap X_{\text{obs}} = \varnothing \;\text{ and }\; \mathcal{S}_j \cap X_{\text{obs}} = \varnothing \;\; \forall j \;\Longrightarrow\;$ certified

(Backup.) Here’s the check itself, in four steps. We start with a box around the current state that covers the robot’s footprint, the estimation error, and any safety margin. We take disturbance bounds from an online estimate: the estimate plus or minus its error. We propagate the bounds over the whole plan, braking included. Then we project onto position and check against obstacles.

One subtlety: the tube is computed at sample times, so we also check the hull that spans each pair of consecutive boxes. In this exaggerated picture, neither box touches the obstacle, but the hull does, so the candidate is rejected, and we record the earliest collision time for the repair step.

(Not on the slide, say it:) the guarantee holds as long as the true disturbance stays inside the bounds we supplied. Wider bounds are more conservative but still valid; if the disturbance leaves them, the tube no longer guarantees safety.

(If asked: the hull also assumes the time step is small enough, 10 ms in our experiments.)

Backup. Verification — Uncertainty, Tube & Swept Hulls

Verification dynamics for candidate $k^\star$ : $\dot x = f(x, u_{k^\star}(t), w)$ , full state $x$ .

Initial set: $x(0) \in [\hat x_0 - \varepsilon,\; \hat x_0 + \varepsilon]$ (estimation error + footprint + margin)

Disturbance set: $w(t) \in W(t) = [\hat w(t) - \delta(t),\; \hat w(t) + \delta(t)]$ , where $|w_i - \hat w_i| \le \delta_i$ ; $\delta$ may also absorb model mismatch and delay. GP confidence bounds give a probabilistic certificate [5].

Tube: $\mathcal R_j = [\underline x(t_j), \overline x(t_j)]$ , position boxes $\mathcal B_j = [\underline x_{\text{pos}}(t_j), \overline x_{\text{pos}}(t_j)]$

Swept interval hull between samples: $\mathcal S_j = \bigl[ \min(\underline x_{\text{pos}}(t_j), \underline x_{\text{pos}}(t_{j+1})),\; \max(\overline x_{\text{pos}}(t_j), \overline x_{\text{pos}}(t_{j+1})) \bigr]$ assumes $\Delta t$ small enough that inter-sample deviation is covered.

Implementation (immrax_verify.py)

Additive disturbance on $(\dot x, \dot y, \dot h, \dot v)$ ; interval radii carried in the embedding state
$\varepsilon_{\text{pos}} = r_{\text{robot}} + \varepsilon_{\text{add}}$ with $r_{\text{robot}} = 0.175$ m; $\varepsilon_h = \varepsilon_v = 0.2\,\varepsilon_{\text{pos}}$
$\varepsilon_{\text{add}} = 0.01$ m (Cases 1, 3), $0.03$ m (Case 2)
Natural inclusion (irx.natemb), RK45, $\Delta t = 0.01$ s over the full $T$
Check boxes first, then hulls; report the earliest collision time for repair
Case 2: fixed bound $|w| \le (0.017, 0.060, 0.043, 0.017)$ on $(\dot x, \dot y, \dot h, \dot v)$
Case 3: symmetric bound from the patches along the candidate’s reference path

Backup. Repair Procedure & Safety Theorem

Repair order (each candidate re-verified before execution):

Speed backoff: $k_2 \leftarrow k_2 - \Delta_v$
Lateral push: $k_1 \leftarrow k_1 \pm \Delta_\omega$ , trying the direction opposing the estimated lateral disturbance first
Constraint tightening: obstacle buffer $b \leftarrow b + \Delta_b$ , re-solve the RTD program

Settings in the paper’s runs (docker/makefile)

Case 2: $\Delta_v = 0.08$ , $\Delta_b = 0.01$ m, up to 2 rounds
Case 3: $\Delta_v = 0.08$ , $\Delta_b = 0.015$ m, up to 4 rounds
Lateral push is implemented but disabled in both runs

Repair is a candidate-generation heuristic: not complete, not assumed convergent. Failure costs progress, never safety.

Theorem (safety & recursive feasibility). Let each executed candidate have horizon $T = t_{\text{plan}} + t_{\text{stop}}$ whose last $t_{\text{stop}}$ seconds are a fail-safe stop. If the initial candidate is certified over its full horizon, the system only switches to candidates certified over their full horizons, and it executes the current fail-safe whenever no new candidate is certified within $t_{\text{plan}}$ , then RTD-RAX is safe and recursively feasible.

Proof sketch. Certification gives $\operatorname{proj}_{\text{pos}}(\mathcal R_k(t)) \cap X_{\text{obs}} = \varnothing$ for all $t \in [0, T]$ , covering both cruise and braking. At the next planning instant the system either switches to a newly certified candidate or continues the certified stop. Apply recursively. $\square$

Backup. Future Work

Method

Tighter coupling between the RTD optimization and the online reachable tube, so replanning can take gradient steps instead of guess-and-check repair
Learned disturbance bounds in place of measured ones: Gaussian-process confidence bounds give a tube that holds with a prescribed probability [5]
Richer disturbance and uncertainty descriptions generally

Validation

Hardware: port the case studies to a ground robot, then a quadrotor, where the tube grows faster in higher dimensions
Head-to-head against robust and tube-based MPC under common models, disturbance assumptions, safety specifications, and compute budgets

RTD-RAX and robust/tube MPC split the work differently: MPC folds dynamics, uncertainty and constraints into one receding-horizon optimization, while RTD-RAX generates candidates from a precomputed FRS and verifies each one online.

References

[1]

S. Kousik, S. Vaskov, F. Bu, M. Johnson-Roberson and R. Vasudevan, “Bridging the gap between safety and real-time performance in receding-horizon trajectory design for mobile robots,” The International Journal of Robotics Research, 2020.

[2]

S. Coogan, “Mixed monotonicity for reachability and safety in dynamical systems,” 59th IEEE conference on decision and control (CDC), 2020.

[3]

A. Harapanahalli, S. Jafarpour and S. Coogan, “Immrax: A parallelizable and differentiable toolbox for interval analysis and mixed monotone reachability in JAX,” IFAC-PapersOnLine, 2024.

[4]

M. Abate, M. Dutreix and S. Coogan, “Tight decomposition functions for continuous-time mixed-monotone systems with disturbances,” IEEE Control Systems Letters, 2020.

[5]

M. E. Cao and S. Coogan, “Trajectory tracking runtime assurance for systems with partially unknown dynamics,” IEEE international conference on robotics and automation (ICRA), 2024.