Anytime Algorithms Support landed in v1.1.0

Anytime Algorithms: Better Answers When the World Gives You Time

Autonomy workloads can change dramatically from one moment to the next. An empty street may require only a few detections and a simple path. Outside a major concert, the same robot must process dense crowds, occlusions, uncertain motion, and many possible routes.

This affects machine-learning workloads as much as classical planning. An early-exit detector such as AnytimeYOLO can produce an initial set of detections quickly, then run deeper stages when the scene or deadline allows. Tracking, prediction, localization, and motion planning all have similar opportunities to improve an answer incrementally.

Anytime algorithms formalize this approach. They produce a usable result early, then spend available computation improving its quality. Easy scenes finish quickly. Difficult scenes receive more work while explicit limits keep the robot responsive and safe.

Anytime computation becomes integral part of copper-rs scheduler

Applications have always been able to write an iterative algorithm and stop it after some internal deadline. From the runtime’s perspective, however, that work appears as one opaque task invocation. The scheduler cannot see the intermediate opportunities to pause, resume, interleave, or terminate refinement.

Copper v1.1 introduces the first scheduler-level anytime model in a robot operating system. Called CuAnytimeTask, it divides its work into two operations:

• base() produces the minimum valid result for a new input.

• refine() performs exactly one bounded improvement quantum.

The task reports whether the result improved, converged, or had to abort. The runtime applies the policy that determines whether another refinement quantum should run.

This separation gives each side a clean responsibility. The algorithm understands its search space and quality measure. Copper understands the complete task graph, execution order, timing policy, data age, and available refinement positions.

For a foreground task, Copper expands the task into a base step followed by a statically bounded number of refinement steps. The generated scheduler weaves those steps into the execution plan between independent work and the first consumer of the result. With several anytime tasks, their quanta can be interleaved while respecting graph dependencies. The exact placement can be inspected through Copper’s plan rendering tools.

That is the larger architectural step. Computation quality is now visible at the same level as latency, dependencies, resources, and task placement.

Anytime algorithms running in copper-rs

Toward globally optimized robot computation

Once refinement is visible to the scheduler, the robot’s compute budget can be considered across the whole graph.

A robotics pipeline may contain several algorithms that can use additional time: perception refinement, trajectory optimization, map updates, object association, state estimation, and prediction. Each one can usually consume more computation than the machine can provide. Optimizing them independently encourages every component to spend as much as its local deadline permits.

A scheduler has a broader view. It knows which results are consumed next, which work is independent, where slack exists, and which tasks have already reached acceptable quality. Copper’s current model already uses that information to place bounded refinement quanta into the generated schedule and stop them according to declarative policies.

This also creates the foundation for richer scheduling strategies. A future scheduler could distribute spare capacity among several anytime tasks according to deadlines, data age, achieved quality, or the marginal value of another quantum. It could decide that an additional perception pass is more useful than another path optimization, or that a nearly stale planning request should yield to fresher localization work.

The key enabler is structural visibility. A refinement loop hidden inside a task cannot participate in global scheduling decisions. A sequence of explicit, bounded quanta can.

Declarative bounds in RON

Copper exposes the refinement policy in the task graph:

(
    id: "planner",
    type: "cu_rrt_star::RrtStarPlanner",
    resources: {
        "rng": "planner_rng.rng",
    },
    anytime: (
        max_refines: 16,  // sets a hard limit on the number of refinement quanta. Foreground tasks require this value because Copper generates a static execution plan and must know the maximum number of steps at compile time.
        
        time_budget_ms: 30.0, //  limits the wall-clock refinement window for one job, starting with the base computation. Time is checked between quanta, so every individual `refine()` call must itself be bounded.


        max_stall: 4, // stops after a configured number of quanta without improvement. It prevents a search from consuming its full allowance after reaching a plateau.


        quality_floor: 0.05,  // defines the minimum acceptable final result. If the job ends below that level, Copper clears the output payload. This supports systems whose safe response to an inadequate plan is to wait, stop, or use a fallback.


    ),
)

Deterministic refinement and replay

Anytime behavior can sound inherently variable because the amount of work depends on convergence, quality, age, and time. Copper keeps those decisions inside its deterministic execution and replay model.

Foreground refinement steps are generated as part of the static plan. Their order and maximum count are fixed. During replay, recorded inputs and Copper time drive the same base calls, refinement calls, quality checks, age checks, and stop decisions. Task state is frozen and restored through the normal keyframe mechanism.

Randomized algorithms also need deterministic randomness. The RRT* component receives a seeded `CuRng` resource, and each planning job derives a reproducible stream from that state. Replaying the same job therefore rebuilds the same search tree and improvement sequence.

Copper’s regression coverage verifies this directly. Anytime tasks are executed again during resimulation, including their refinement quanta. The resulting CopperLists and keyframes must match the recording byte for byte. Replay is recomputation under the recorded timeline, rather than a convincing playback of previously saved outputs.

That property makes anytime computation practical for serious robotics work. Engineers can inspect why a job stopped, how many refinements ran, what quality was published, and whether a result was suppressed. They can then replay the same scene and obtain the same decisions.

A scheduler that understands useful work

Anytime support gives Copper a vocabulary for computation whose value changes with time. The scheduler now understands a mandatory result, optional improvement quanta, quality thresholds, freshness limits, and hard bounds.

That vocabulary fits the physical world unusually well. Real scenes do not arrive with uniform complexity, and robots cannot size every computation around an imaginary average case. They need to finish easy work quickly, spend more effort when the scene demands it, preserve safety under pressure, and reproduce the entire decision process afterward.

Conclusion

Copper v1.1 brings anytime algorithms as a first class support. Our RRT* example demoes you the basics but we cannot wait for you to create on top of this new concept!

If you need any of those classes of algorithms ported to copper-rs: AnytimeYOLO, Anytime-Lidar, Monte Carlo Tree Searches, etc etc… Feel free to reach out!