Lesson 7 of 21 in this unit
Stop when the controller leaves its limits.
Inspect runtime rejection, delayed observations and bounded fallback without equating a stopped task with success.
By the end: Separate operating contracts, fallback dynamics, actual violations and task completion from an accumulated reward.
Prerequisites and path options
Why learn this? Identify when a controller’s assumptions no longer hold and a fallback is needed.
Start with something concrete.
Removing a cart’s push does not instantly remove its momentum. A controller that stops issuing task commands still needs an explicit fallback behavior.
Try the interactive modelA missing action triggers a zero-force fallback while the drag-free cart is moving. What happens next?
Change one thing. Watch what follows.
Loading this browser experiment…
Understand what changed.
A shorter explanation, with the original worked examples available below. Both explain the same experiment and its limits.
The idea in everyday terms
A useful-looking action can violate an operating rule. The contract can limit position, speed, force and observation age separately from the goal. The controller proposes an action; the runtime decides what may be applied.
What to watch in the experiment
Follow the proposal, check, applied force and independent outcome evaluation. Test an old observation or an unreachable target and inspect what the fallback actually does. Rejecting a proposal does not automatically make the remaining motion safe.
What this does not establish
A zero-force fallback may still allow movement because the cart already has velocity. A passing short simulation is not a robust safety invariant or a physical emergency-stop certificate.
Open the full worked examples, calculations and limitations
This is the same reference used in Technical mode. Expand it whenever you need the exact numbers, assumptions or further explanation.
Give the controller a declared operating region
An action can look useful for a target and still violate a constraint. The lab’s contract declares a position interval, a speed limit, a force limit and a maximum observation age. These are separate from the controller’s objective. An outside-region target is an invalid task for this contract, even if the cart could physically travel there.
The controller proposes; the runtime checks; the actuator applies; the independent evaluator records what happened. Keeping those stages visible makes it possible to diagnose which part failed.
Check the information actually available
The runtime receives only an observed position, observed velocity, observation age, target and proposed force. It checks that the observation is fresh enough, that the observed state and target lie inside the declared limits, and that the action is present and in range. It also predicts one short interval from that observation.
It does not secretly use the simulator’s true current state. Delay begins after the cart has been moving for one second, so the freshness failure happens in a meaningful moving situation. A short-horizon check from an old state is not a proof that the real trajectory will remain inside the region.
The external evaluator has a different role. It uses the true state and applied force to check actual motion. Turning runtime checks off does not change this definition of correctness. An observed violation must remain a violation in every ablation.
Check the interval, not just its endpoints
Constant force gives a quadratic position curve and a linear velocity curve. A cart can leave a position bound, reverse direction and return before the next sample. Checking only the endpoints can miss that excursion.
The evaluator checks endpoints and any interior time where velocity is zero. With acceleration a, that candidate turning time is −v/a, provided a is nonzero and the time lies inside the interval. Speed extremes for this constant-acceleration segment occur at its endpoints. This exact calculation applies to the stated one-dimensional model; it is not a general collision algorithm.
A fallback must obey dynamics too
Once a runtime failure triggers fallback, normal task commands stay disabled for the remainder of the run. The braking fallback uses the available measured velocity to request an opposing force. The coasting alternative requests zero force. Both retain the same actuator limit.
Coasting does not stop a drag-free cart. Braking changes velocity over time, and stale velocity measurements can make that fallback perform poorly. Neither option teleports the state to rest. The fallback is bounded to 75 intervals, or 1.5 seconds, and may end earlier if the evaluator observes a breach.
Ending this window means the simulated scenario is over. It does not establish what a physical cart would do afterward. The report therefore keeps final speed, actual violations and task completion separate. A low final speed after fallback is useful evidence about that response, not successful completion of the original target request.
Do not hide failure behind reward
The illustrative reward accumulates negative distance-to-target over the accepted intervals. A prematurely ended run can accumulate less negative reward simply because it has fewer intervals. That number omits failure penalties and must not decide acceptance alone.
The separate normal-completion rule requires an eight-second run with no fallback or actual violation, plus low position error and velocity over the final half-second. The independent evaluator ends a scenario after recording an actual breach; it never erases the violating interval. Missing actions cannot drive numerical dynamics even in the checks-disabled experiment, so they still trigger fallback.
Audit the stop decision
For guided practice, compare the same oversized-action fault under braking and coasting. Then test delayed sensing and an impossible target. For implementation practice, replay the interval equations and construct a case whose interior turning point crosses a bound despite acceptable endpoints.
For a decision brief, state which observations and assumptions the runtime relies on, what fallback was attempted, and what the true trace establishes. A passing short trace is not a robust invariant or a physical emergency-stop certificate. This lesson controls no hardware; independent implementation review and learner pilots remain pending.
A runtime check passes using an old observation. What may the independent evaluator still find?
Take this idea with you.
Rejecting a proposal, invoking fallback, avoiding a violation and completing a task are different events. Preserve those distinctions in both traces and reports.
Explore related topics and the topic map
How this topic connects
Explore this topic on the interactive mapUse these connections to review a foundation or choose where to go next. You can open any topic without completing the others.
What it builds on
- Correct errors using feedback
Understand how repeated correction can reject disturbances or cause oscillation when delayed or too aggressive.
- Choose continuous actions
Explore how action limits and smooth control affect a physical system’s response.
Inspect runtime rejection, delayed observations and bounded fallback without equating a stopped task with success.
What it enables
- Enforce operating limits
Separate a proposed action from the runtime checks that determine whether it may be executed.