Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

Inspiration

How can the behavior of interacting atoms help a fleet decide where to go?

That question brought us to the capacitated vehicle routing problem: serve every customer, respect each vehicle’s capacity, return to the depot, and minimize total travel. It connects a difficult optimization problem with a familiar task—delivering things efficiently.

For the DuQuantum Pasqal challenge, we wanted to follow that problem through the entire quantum workflow: from delivery constraints to binary decisions, atom arrangements, laser pulses, measured outcomes, and validated routes. We also wanted people to see what happens along the way. That became Atlas Route Lab, with an Earth-based delivery visualization and Atlas Orbit, an interactive planetary walkthrough.

What it does

Our project combines a hybrid quantum-classical routing solver, reproducible experiments, mathematical documentation, and interactive visualizations.

The solver follows a cluster-first, route-second approach:

  1. Assign customers to vehicles using quantum-sampled subset proposals and classical capacity checks.
  2. Determine the visit order within each group using routing QUBOs and the documented classical rules.
  3. Validate that every customer is served exactly once, every vehicle stays within capacity, and every route returns to the depot.
  4. Compare the resulting distance with an independently computed exact optimum.

Track A focuses on capacity-feasible clustering. Track B extends the pipeline with two traveling-salesperson encodings and measured routing evidence.

Atlas makes these decisions inspectable. The Earth demo replays a delivery experiment across fifteen illustrative US city locations. Atlas Orbit takes the same ideas into a fictional three-dimensional setting: ten planets, three ships, and a depot. Users can explore coordinates, replay assignments and rejected proposals, inspect measured route candidates, and view the final tours.

The browser replays saved experimental evidence. Each displayed result connects back to the solver’s recorded outputs.

How we built it

We built the optimization pipeline in Python using Pasqal’s Pulser ecosystem and local quantum emulation. All quantum evolution in our reported experiments runs on a classical CPU.

We began with single-atom and nine-atom examples to understand state preparation, Rydberg interactions, and measurement. We then formulated optimization objectives as quadratic unconstrained binary optimization problems:

$$ E(\mathbf b)=c_0+\sum_i h_i b_i+\sum_{i<j}J_{ij}b_i b_j, \qquad b_i\in{0,1}. $$

Here, each bit represents a decision. Linear terms score individual choices, and pair terms score combinations.

For clustering, the executed sampler considers at most eight candidate customers per call. Its energy favors nearby customers and balances group size against the remaining fleet. Classical checks reject assignments that violate capacity. We also derived a full assignment-and-slack formulation as a mathematical reference, documenting how it differs from the smaller implemented heuristic.

For routing, we implemented two encodings: edge encoding, where bits select connections, and position encoding, where bits assign customers to visit positions. A four-customer group requires ten edge bits or sixteen position bits. Both encodings have strict decoders that reject invalid outcomes.

We mapped these models onto atom registers and pulse sequences. Detuning controls individual excitation costs, while atom separation determines pair interactions proportional to inverse distance to the sixth power. We compared global controls with a separately labeled emulated detuning-map variant.

To evaluate the pipeline, we generated reproducible, certified-feasible instances with four, ten, and fifteen customers, including uniform and heterogeneous demands. We used CPLEX and independent exact methods based on Held–Karp tours and partition dynamic programming to check solution quality.

For the visual experience, we built Atlas with browser-based interfaces and Three.js for the planetary scene. Saved measurements drive the walkthrough, connecting the mathematical model to something users can explore.

Challenges we ran into

A valid QUBO does not automatically become a faithful physical model. Moving one atom changes several interactions simultaneously, and unwanted long-range interactions remain. Across 797 recorded target/native model pairs in our comparison, none shared a lowest-energy bitstring. Useful solutions could still appear in the sampled outcomes, but this exposed a concrete limitation in our embeddings.

Good clusters do not always produce short routes. Our clustering score rewards compact, balanced groups, but it does not directly include depot travel. A lower clustering score can therefore lead to a worse delivery plan. We separated decomposition, clustering, and routing losses to understand where excess distance entered.

Capacity makes sequential decisions difficult. An early assignment can leave customers that the remaining vehicles cannot accommodate. Heterogeneous demands made this especially visible. We retained failed trajectories and reported feasibility alongside solution quality.

Visualization required careful interpretation. We had to distinguish clustering from routing, measured candidates from animation, and application coordinates from physical atom positions. Clear labels and evidence-driven replay became part of the engineering work.

Accomplishments that we’re proud of

Our strongest demonstration is the updated Atlas Orbit run. Using four seeded customer-window orders, 512 clustering attempts, and 16,000 routing shots per ship, the pipeline produced a total distance of 428.127519 fictional space units, matching the independently computed global optimum for that fixed instance.

Every ship’s selected tour appeared in its measured routing bank. No classical route fallback or reference plan was inserted. Compared with the previous planetary run, total distance fell by 17.34%.

We also completed a broader twelve-instance comparison with three repeats per instance:

  • CPLEX proved optimal solutions in 36/36 runs.
  • Our baseline hybrid pipeline returned feasible routes in 33/36 runs.
  • Its mean instance-level route gap was 20.59% across the eleven instances with successful runs.

The broader benchmark favors CPLEX. The planetary result is a separate, higher-budget experiment on one fixed instance; it does not establish quantum speedup or general superiority.

We are proud that the project preserves enough evidence to examine both outcomes: raw measurement counts, pulse sequences, atom layouts, validation checks, exact references, reports, and interactive replays.

What we learned

We learned to distinguish four questions: Is the mathematical model correct? Does the atom register represent it faithfully? Does the pulse sample useful states? Does the final plan solve the original routing problem well?

Those questions can have different answers.

A separate tuning pilot reinforced this lesson. Across six held-out cases, mean feasible trajectory fraction improved from 58.85% to 60.42%, and mean best clustering-model gap fell from 8.41% to 7.57%, while computation time increased. Better sampling quality has a cost, and small improvements need broader evaluation.

We also learned how much clear presentation matters. Watching a rejected assignment or inspecting a measured route can explain a limitation more effectively than an aggregate score alone.

What’s next

We want to incorporate demand and depot distance more directly into clustering, improve the fidelity of native embeddings, and evaluate across more independent instances and sampling seeds. We also want to extend routing beyond the current small-group execution limits and make Atlas support additional experiments.

Our goal is a routing platform where people can trace every result from the original problem through the quantum model to the final validated journey.

AI tools assisted with modeling, implementation, analysis, documentation, and presentation preparation.

What's next for Pasqal Challenge: Objective Chances

Built With

Share this project:

Updates

Submission history