One control move, many possible futures: a faster way to plan for uncertainty

A controller facing several possible futures has an awkward obligation: it must prepare for each one, yet it cannot take a different action now for every future. FanCyqlone is built around that tension. It lets a computer calculate the branches of a plan in parallel, then brings them together around one shared first move.

That architecture targets a practical bottleneck in model predictive control, a way of steering systems by repeatedly planning ahead, acting for a short interval, and planning again. When the future is uncertain, a controller may need to examine several plausible trajectories: a robot’s changing contact with the ground, another agent’s possible behavior, or a backup route if a preferred one becomes unsafe. Planning all those futures can multiply computation. The authors’ central contribution is a solver designed to exploit the parallel processing already available in modern central processing units (Teuwen et al., 2026).

The paper introduces FanCyqlone, a linear-system solver for multi-horizon optimal control, and FanCyQPALM, which embeds that solver in an optimization method able to handle general linear constraints at each stage. The authors test the approach on spring-mass and quadruped control benchmarks. The provided paper text, however, stops before giving the benchmark tables or numerical results. It therefore supports explaining the method and the evaluation targets, but not quoting a measured speedup or claiming a particular performance margin.

The Science

In ordinary model predictive control, a system predicts what will happen over a finite horizon, chooses a sequence of controls, applies the first one, and solves again with updated information. A single predicted future can be a poor guide when the system model is uncertain or the world has several plausible ways to unfold. Multi-horizon control represents those alternatives explicitly as separate branches.

The branches are not independent at the beginning. The controller has to choose the same immediate action regardless of which future will later occur; otherwise it would be acting on information it does not yet possess. After that shared first stage, each branch can follow a different sequence of states and controls. In the paper’s formulation, this requirement is expressed through a shared root decision, with scenario-specific trajectories thereafter.

The optimization problem assigns costs to actions and states along every branch. It also imposes dynamics: equations describing how a system’s state changes in response to controls. For a spring-mass system, that state might represent positions and velocities; for a quadruped, it could encode aspects of the robot’s motion. The mathematics in the paper is general, but the key structure is intuitive: a common choice now, followed by contingent plans.

The computational opportunity comes from that structure. A naive approach might solve the branches largely as one large coupled problem, or repeat similar work separately. FanCyqlone instead computes each branch’s contribution in parallel, then combines the contributions in a smaller root problem that determines the common first action. Once that shared decision is known, the solver sends it back into the branches and recovers their remaining solutions.

The method extends Cyqlone, an earlier solver that exploits parallelism along the time axis of an optimal-control problem. FanCyqlone adds a second direction of parallelism: it runs calculations for different scenario branches at the same time. Within each branch, the underlying solver also uses structured factorization and parallel calculations over time. This is not simply “run several complete solvers and pick a result.” The branch calculations are designed to produce exactly the information needed for a mathematically consistent shared-root solution.

The paper’s central diagram, Figure 1, depicts the permuted linear system used by Cyqlone: many structured blocks can be processed separately, while their interactions leave a smaller block system to resolve. In the multi-horizon extension, this idea appears at two scales. Each scenario branch has its own structured computation; the shared root then gathers the branch contributions.

A little terminology helps explain why this is not a trivial decomposition. The linear systems arise from Karush–Kuhn–Tucker, or KKT, conditions: equations that characterize an optimum while accounting for constraints. Equality constraints such as system dynamics create a saddle-point matrix, often symmetric but indefinite. Some competing approaches rely on positive-definite matrices and cannot directly handle that KKT structure. The authors emphasize that FanCyqlone can solve the relevant systems directly, a useful property when it is placed inside a constrained optimization algorithm.

That outer algorithm is QPALM, a proximal augmented Lagrangian method. In broad terms, it handles inequality constraints by repeatedly solving regularized subproblems and updating constraint-related quantities. FanCyQPALM keeps the dynamics as equalities and incorporates linear bounds on states and controls into the optimization process. At each inner iteration, the resulting linear system has the optimal-control structure FanCyqlone is designed to exploit.

The authors implement the method in C++ with Python bindings and say the software is open source. That matters because specialized optimization methods can be difficult to assess or reuse if their implementations remain inaccessible. Still, availability of code is not itself evidence of a particular real-world gain; benchmark details and replication are needed to establish where the method is useful.

What They Found

The most concrete result in the supplied text is an algorithmic one: FanCyqlone converts the multi-branch linear solve into independent branch work plus a shared root calculation. The branch factorization and forward solves can run in parallel, as can the later branch back-substitutions. The root calculation is smaller because it carries the coupling needed to make the immediate action consistent across scenarios.

That structure addresses two sources of cost at once. Parallelizing across time can reduce the sequential dependence inherent in planning over a long horizon; parallelizing across branches can reduce the extra burden of considering alternative futures. How much either helps depends on the problem dimensions, processor, implementation, and available parallel capacity. The paper’s supplied excerpt does not provide timing figures, processor specifications, or scaling curves, so the size of the benefit cannot be stated here.

The authors report evaluating FanCyQPALM on spring-mass and quadruped model predictive control benchmarks. These are meaningful demonstrations because a simple mechanical system and a legged robot pose different kinds of control demands. But the text available for this digest contains neither benchmark tables nor plotted values. Accordingly, no chart of runtimes, speedups, or solver iterations can be constructed without inventing data.

The intended comparison is with state-of-the-art solvers, and the abstract characterizes the observed speedups as substantial. That is the authors’ reported conclusion, but the numerical evidence needed to assess its magnitude and conditions is absent from the supplied material. It would be misleading to turn “substantial” into a percentage or to imply that every problem size benefits equally.

Another result is about scope. FanCyQPALM handles general linear stage-wise constraints rather than restricting the formulation to simple box bounds. This matters because real control tasks often include coupled limits: combinations of state and input variables may have to satisfy a safety or actuator constraint. More general constraints increase applicability, though they can also increase the cost of each optimization step.

The solver is designed for CPUs, not just graphics processing units (GPUs). GPUs can excel when there are enormous numbers of parallel tasks, but the authors note that in practical contingency-control settings the number of scenarios may be modest, and GPU data movement and launch overhead can outweigh the advantages. FanCyqlone’s CPU-oriented design aims at that regime: enough parallel work to exploit multiple cores, without assuming an enormous scenario tree.

Why This Changes Things

The larger idea is that uncertainty need not always be handled by a single conservative plan. A controller can represent multiple plausible futures, optimize a response for each, and enforce agreement only where agreement is logically required: at the action taken now. This is a powerful pattern for systems that must react before uncertainty is resolved.

Imagine a robot moving across uneven ground. It might consider different predictions of where contact will be stable, while choosing a single next movement that remains viable across those predictions. Or consider a vehicle anticipating several possible motions by another road user. Scenario-based planning can make those possibilities explicit instead of hiding them inside a single average forecast. In both cases, a faster solve could allow richer planning within the fixed time budget available before the next action.

But faster optimization is an enabling condition, not a guarantee of safer or better behavior. The quality of a scenario-based controller depends on whether its scenarios cover important possibilities, whether the dynamics model is accurate enough, and whether constraints capture the real limits of the machine and environment. A solver can make it less expensive to consider alternatives; it cannot make missing alternatives appear.

The shared-root decomposition also offers a useful way to think about parallel computation. Many problems contain a small common decision coupled to many otherwise separate subproblems. Rather than parallelizing blindly, FanCyqlone identifies what must be shared and postpones that coordination to a compact calculation. This is a broader computational strategy: separate what can be separated, preserve the exact coupling, and reunite the pieces at the smallest necessary interface.

Its CPU focus is practically significant. In research discussions, parallelism often suggests massive GPU workloads. Yet a controller embedded in a robot or vehicle may have a limited number of scenario branches, tight latency requirements, and a processor already integrated into its control hardware. A method tailored to moderate parallel workloads could be more deployable than one that performs best only at enormous scale. Whether FanCyqlone achieves that in a particular application is an empirical question the missing benchmark numbers prevent us from answering.

There is also a distinction between a solver demonstration and a deployed control system. A benchmark measures performance on selected models and configurations. A deployed robot must contend with sensor noise, changing hardware, imperfect predictions, and the consequences of missed deadlines. The paper’s spring-mass and quadruped tests are a step toward realistic control problems, but the supplied text does not establish performance under those broader operational conditions.

What's Next

The most immediate next step is a transparent performance account: the benchmark problem sizes, hardware, solver settings, runtime distributions, and comparisons with competing methods. Scaling tests should vary both the number of branches and the horizon length. That would show when parallelism across scenarios pays off, when time-parallelism dominates, and where synchronization or memory costs become limiting.

A second question is how the solver behaves when scenarios become large or uneven. Branches may differ in their computational demands, and real systems may need to add or remove scenarios as new information arrives. Dynamic workloads could expose bottlenecks that balanced benchmark branches do not. It would also be useful to test whether the approach can meet strict worst-case timing requirements, not merely improve average runtime.

Finally, the method’s value should be measured in closed-loop outcomes as well as computation. Does it let a robot maintain stability in conditions where a single-horizon controller fails? Can it improve safety margins without making control excessively cautious? How sensitive are outcomes to the scenarios chosen? Those are questions for experiments that connect optimization speed to what a machine actually does in the world.

FanCyqlone’s contribution is a more efficient route through a distinctive planning problem: many futures, one decision now. By exploiting parallelism along both branches and time, it aims to make that form of uncertainty-aware control more practical on ordinary multicore processors. The mechanism is clear and promising; the exact scale of its advantage remains a question for the numerical results and real-world tests.