Payload-Constrained Path Database

• Payload-Constrained Path Database (PCPD) is a payload-indexed extension of CPD that precomputes first moves to guide minimum-energy paths under varying payload regimes.
• It employs a modified Dijkstra algorithm to build distinct CPDs for each payload bucket, effectively pruning the branching factor and reducing online search complexity.
• Empirical evaluations reveal dramatic runtime improvements with suboptimality below 1%, highlighting its practical efficiency for multi-pickup routing in static terrain.

Searching arXiv for the cited PCPD and closely related constrained-path papers to ground the article. Payload-Constrained Path Database (PCPD) is a payload-indexed extension of the Compressed Path Database (CPD) introduced for energy-aware route planning on uneven terrain, specifically in the Object-Pickup Minimum Energy Path Problem (OMEPP) (Babakano et al., 7 Sep 2025). In this formulation, the database stores first-move guidance for minimum-energy paths under different payload regimes, because carried payload changes both edge feasibility and edge energy. PCPD is therefore not a generic path cache: it is a bank of compressed first-move tables parameterized by payload buckets and used online to restrict successor generation during search. In the literature considered here, this is the explicit meaning of PCPD; adjacent work on resource-constrained shortest paths, compiled order-constrained paths, and constraint path queries addresses closely related constrained-path mechanisms, but not the same database abstraction (Ahmadi et al., 2024, Rotschield et al., 29 Dec 2025, Li et al., 1 Dec 2025).

1. Definition and query model

In the paper that introduces the term, PCPD is defined as an extension of CPD that “precomputes and stores the first move along minimum-energy paths for varying payload levels” (Babakano et al., 7 Sep 2025). Its target problem is OMEPP, where an autonomous mobile robot starts at source $s$, must reach target $t$, and must pick up one object from one of many candidate pickup points $\{p_1,\dots,p_n\}\subseteq V$. The terrain is modeled as a directed graph

$G=(V,E,D,\Theta),$

derived from a DEM, with one vertex per terrain sample and one edge per movement between neighboring cells.

The optimization objective is to choose both a pickup location and two payload-conditioned path segments. The robot begins with initial payload $\rho_{\text{init}}$, and after pickup carries $\rho_{\text{init}}+\rho_{\text{obj}}$. Using the paper’s notation, the intended optimization problem is to minimize

$$ep(\rho_{\text{init}}, s, p_i) + ep(\rho_{\text{init}} + \rho_{\text{obj}}, p_i, t)$$

over all candidate pickup points $p_i$, where $ep(\rho,a,b)$ denotes the minimum-energy path from $a$ to $t$0 under payload $t$1 (Babakano et al., 7 Sep 2025). The paper notes that the displayed formula is typographically malformed, but its intended meaning is explicit in the text and in the baseline algorithm.

This formulation makes PCPD inherently payload-conditional. A path that is optimal before pickup need not remain optimal after pickup, and a path that is feasible for $t$2 may become infeasible for $t$3. The database therefore indexes path guidance by payload bucket, not merely by source and destination. PCPD entries do not encode pickup status internally; rather, the planner queries different payload-conditioned databases on the two segments of the route: one for $t$4 under $t$5, and one for $t$6 under $t$7 (Babakano et al., 7 Sep 2025).

2. Payload-dependent feasibility and energy

The motivation for PCPD is the paper’s explicit payload-sensitive energy model. For an edge from $t$8 to $t$9, the energy term is

$\{p_1,\dots,p_n\}\subseteq V$0

Payload enters multiplicatively through $\{p_1,\dots,p_n\}\subseteq V$1, so the same terrain transition becomes more expensive as the carried load increases (Babakano et al., 7 Sep 2025).

Feasibility is also payload-sensitive. The maximum uphill angle allowed by traction is

$\{p_1,\dots,p_n\}\subseteq V$2

with an additional static-friction-derived limit

$\{p_1,\dots,p_n\}\subseteq V$3

and effective uphill bound

$\{p_1,\dots,p_n\}\subseteq V$4

The downhill braking threshold is

$\{p_1,\dots,p_n\}\subseteq V$5

Accordingly, the edge-energy model is

$\{p_1,\dots,p_n\}\subseteq V$6

A heavier payload can therefore render a steep uphill edge infeasible, or leave it feasible but energetically unattractive (Babakano et al., 7 Sep 2025).

This model explains why a payload-indexed path database is useful. The paper’s point is not merely that route cost changes with load; the graph search itself changes because payload modifies both traversability and edge weights. A geographically short pickup option may be poor if the loaded segment crosses steep terrain, while a farther pickup may lower total energy by avoiding expensive loaded climbs. PCPD is designed to encode this payload-conditioned first-move structure offline rather than rediscovering it repeatedly online (Babakano et al., 7 Sep 2025).

3. Offline construction and representation

PCPD is implemented as a collection of payload-conditioned CPDs: $\{p_1,\dots,p_n\}\subseteq V$7 For each representative payload bucket $\{p_1,\dots,p_n\}\subseteq V$8, the system builds a separate CPD whose edge feasibility and edge energy are computed under that payload (Babakano et al., 7 Sep 2025). “Payload-constrained” therefore means that the stored first move is valid relative to a specific payload-induced cost and feasibility regime.

Construction follows the CPD pipeline, but with a payload-aware modified Dijkstra. The terrain graph uses 8-neighbor connectivity. For a fixed payload $\{p_1,\dots,p_n\}\subseteq V$9, the algorithm computes the payload-dependent slope limit, then for every source vertex $G=(V,E,D,\Theta),$0 runs a Dijkstra-like search in which an outgoing edge is relaxable only if it satisfies the payload-specific slope constraint and is weighted by the payload-specific energy function $G=(V,E,D,\Theta),$1 (Babakano et al., 7 Sep 2025). The resulting first-move table $G=(V,E,D,\Theta),$2 stores, for each destination $G=(V,E,D,\Theta),$3, the first move on the minimum-energy path from $G=(V,E,D,\Theta),$4 to $G=(V,E,D,\Theta),$5 under payload $G=(V,E,D,\Theta),$6.

Compression follows standard CPD practice. Each row $G=(V,E,D,\Theta),$7 is sorted by a DFS ordering of targets and compressed with run-length encoding (RLE). At query time, $G=(V,E,D,\Theta),$8 is obtained by binary search on the compressed row. PCPD replicates this layout for each payload bucket, so the effective access path is: payload bucket $G=(V,E,D,\Theta),$9 source row $\rho_{\text{init}}$0 binary search over compressed target intervals (Babakano et al., 7 Sep 2025).

The practical step that makes PCPD finite is payload discretization. Rather than constructing $\rho_{\text{init}}$1 for every possible payload, the paper partitions the payload range into equal-sized buckets

$\rho_{\text{init}}$2

and builds one CPD per bucket representative. In the reported experiments, eight buckets are used over $\rho_{\text{init}}$3–$\rho_{\text{init}}$4 kg: $\rho_{\text{init}}$5 The paper does not specify an adaptive discretization scheme or a theoretical rule for bucket boundaries; it uses equal-sized buckets (Babakano et al., 7 Sep 2025).

The reported build costs show that PCPD is an offline-heavy structure.

Payload bucket $\rho_{\text{init}}$6	Build time	Compressed size
$\rho_{\text{init}}$7	101 min	1.3 GB
$\rho_{\text{init}}$8	99.9 min	1.3 GB
$\rho_{\text{init}}$9	102 min	1.3 GB
$\rho_{\text{init}}+\rho_{\text{obj}}$0	99.5 min	1.3 GB
$\rho_{\text{init}}+\rho_{\text{obj}}$1	99.3 min	1.2 GB
$\rho_{\text{init}}+\rho_{\text{obj}}$2	102 min	1.1 GB
$\rho_{\text{init}}+\rho_{\text{obj}}$3	107 min	1.0 GB
$\rho_{\text{init}}+\rho_{\text{obj}}$4	103 min	0.81 GB

The observed decrease in memory at higher payloads is attributed in the paper to stronger slope restrictions: higher payload leaves fewer feasible edges, fewer possible first moves, and better compression (Babakano et al., 7 Sep 2025).

4. Online use in concurrent OMEPP search

PCPD does not directly answer the full OMEPP optimization problem. The exact baseline solves OMEPP by running Z* twice for every candidate pickup point: once from $\rho_{\text{init}}+\rho_{\text{obj}}$5 to $\rho_{\text{init}}+\rho_{\text{obj}}$6 under $\rho_{\text{init}}+\rho_{\text{obj}}$7, and once from $\rho_{\text{init}}+\rho_{\text{obj}}$8 to $\rho_{\text{init}}+\rho_{\text{obj}}$9 under $$ep(\rho_{\text{init}}, s, p_i) + ep(\rho_{\text{init}} + \rho_{\text{obj}}, p_i, t)$$0. This is optimal, but it requires $$ep(\rho_{\text{init}}, s, p_i) + ep(\rho_{\text{init}} + \rho_{\text{obj}}, p_i, t)$$1 separate searches for $$ep(\rho_{\text{init}}, s, p_i) + ep(\rho_{\text{init}} + \rho_{\text{obj}}, p_i, t)$$2 pickup points and repeats large amounts of work near $$ep(\rho_{\text{init}}, s, p_i) + ep(\rho_{\text{init}} + \rho_{\text{obj}}, p_i, t)$$3 and $$ep(\rho_{\text{init}}, s, p_i) + ep(\rho_{\text{init}} + \rho_{\text{obj}}, p_i, t)$$4 (Babakano et al., 7 Sep 2025).

The PCPD-based alternative is a concurrent search with a two-level queue structure. A global priority queue $$ep(\rho_{\text{init}}, s, p_i) + ep(\rho_{\text{init}} + \rho_{\text{obj}}, p_i, t)$$5 stores one key per pickup point, namely the current best estimate for that pickup candidate. Each pickup point $$ep(\rho_{\text{init}}, s, p_i) + ep(\rho_{\text{init}} + \rho_{\text{obj}}, p_i, t)$$6 also has a child queue $$ep(\rho_{\text{init}}, s, p_i) + ep(\rho_{\text{init}} + \rho_{\text{obj}}, p_i, t)$$7 containing local states of the form

$$ep(\rho_{\text{init}}, s, p_i) + ep(\rho_{\text{init}} + \rho_{\text{obj}}, p_i, t)$$8

where $$ep(\rho_{\text{init}}, s, p_i) + ep(\rho_{\text{init}} + \rho_{\text{obj}}, p_i, t)$$9 is the current frontier node on the $p_i$0 side and $p_i$1 is the current frontier node on the $p_i$2 side. Their local evaluations are

$p_i$3

$p_i$4

with total key

$p_i$5

Initialization inserts one state per pickup point into its child queue and one corresponding key into the global queue (Babakano et al., 7 Sep 2025).

PCPD intervenes precisely at successor generation. Without PCPD, if the pre-pickup side has $p_i$6 feasible neighbors and the post-pickup side has $p_i$7 feasible neighbors, a joint expansion can generate up to $p_i$8 successor combinations. On an 8-neighbor grid, this can reach $p_i$9 combinations per local state. PCPD reduces this sharply by restricting each side to at most two suggested first moves (Babakano et al., 7 Sep 2025).

For a side with actual payload $ep(\rho,a,b)$0, the algorithm identifies the lower and upper bucket representatives: $ep(\rho,a,b)$1 It then queries

$ep(\rho,a,b)$2

According to the paper’s description, the lower-bucket suggestion is always treated as feasible for the actual payload, while the upper-bucket suggestion is checked and discarded if it violates slope feasibility. The valid suggestions on each side form a set of one or two moves. Taking the Cartesian product of the two sides yields at most four joint successors. If one side has already reached its endpoint, only the other side is expanded (Babakano et al., 7 Sep 2025).

Operationally, PCPD is therefore a successor-pruning oracle, not a heuristic lower bound and not a direct path retriever for the whole OMEPP query. Its online role is directional restriction: it narrows the local branching factor to at most four while leaving path cost evaluation to the concurrent search. This is also the source of its approximation behavior. If the true exact-payload optimal path begins with a move that is returned by neither $ep(\rho,a,b)$3 nor $ep(\rho,a,b)$4, then that path may never be explored. The paper is explicit that concurrent PCPD search “may produce slightly suboptimal solutions,” and it does not provide a theorem of optimality, admissibility, completeness, or bounded suboptimality as a function of bucketization (Babakano et al., 7 Sep 2025).

5. Empirical behavior, trade-offs, and limitations

The evaluation uses a $ep(\rho,a,b)$5 area from Fairfax County, Virginia, represented as a DEM-derived graph with approximately $ep(\rho,a,b)$6 nodes and $ep(\rho,a,b)$7 directed links, 8-neighbor connectivity, and minimum $ep(\rho,a,b)$8 m spacing. The robot parameters resemble a Husky A300 UGV, with $ep(\rho,a,b)$9, constant velocity $a$0, $a$1, $a$2, $a$3, and payload capped at $a$4. The study generates $a$5 random start-target pairs and $a$6 random pickup points; each query is run $a$7 times, the best and worst runs are discarded, and the remaining eight are averaged (Babakano et al., 7 Sep 2025).

The main result is a large runtime reduction with small empirical error. Across ten payload settings, baseline runtimes range from about $a$8 ms to $a$9 ms, whereas concurrent PCPD runtimes range from about $t$00 ms to $t$01 ms. Example settings reported in the paper include:

• $t$02: $t$03 ms vs $t$04 ms, suboptimality $t$05
• $t$06: $t$07 ms vs $t$08 ms, suboptimality $t$09
• $t$10: $t$11 ms vs $t$12 ms, suboptimality $t$13
• $t$14: $t$15 ms vs $t$16 ms, suboptimality $t$17

Suboptimality is defined as

$t$18

where $t$19 is the path found by concurrent PCPD search and $t$20 is the optimal path. The reported average suboptimality is below $t$21 across all tested payload settings (Babakano et al., 7 Sep 2025).

The paper attributes the speedup primarily to PCPD reducing the low-level branching factor to at most four. It also reports that runtime remains stable as the number of pickup points grows, unlike the baseline, whose cost increases sharply because each pickup point is evaluated independently (Babakano et al., 7 Sep 2025). This suggests that PCPD is particularly suited to repeated multi-candidate routing on static terrain.

Several limitations are explicit. PCPD assumes a static or slowly varying terrain, since preprocessing is expensive and tied to a fixed graph. The edge-energy model must be deterministic and known in advance, because both feasibility and cost are baked into the bucket-specific CPDs. Payload must be representable by a manageable number of discrete buckets; the paper gives no formal bound on the error induced by bucket width. PCPD handles only a single pickup event with identical object payloads in the reported work. It does not treat dynamic obstacles, changing terrain, stochastic energy estimation, or multiple-object variants (Babakano et al., 7 Sep 2025).

A common misconception is to treat PCPD as an exact energy-to-go database. The reported structure does not store full value functions, exact energy-to-go tables, or formal admissible bounds. It stores compressed first-move guidance only. Its online function is directional pruning rather than certifiably safe branch-and-bound, and its empirical quality guarantees do not come with a formal worst-case suboptimality theorem (Babakano et al., 7 Sep 2025).

6. Relation to adjacent constrained-path research

PCPD occupies a specific position between precomputed routing indexes and online constrained-path algorithms. The closest neighboring exact algorithm in the materials considered here is the enhanced bidirectional A* framework for the Resource Constrained Shortest Path problem, $t$22, which treats multiple additive resources exactly, uses lower-bound preprocessing, dominance-based state pruning, and meet-in-the-middle matching, but is an online query algorithm rather than a payload-indexed database (Ahmadi et al., 2024). If “payload” is interpreted as one resource dimension, that work is algorithmically close to payload-constrained routing, yet it does not precompute reusable budget-parameterized path summaries.

A different line of work shows how a path payload constraint can be compiled into the graph itself. For strictly increasing edge-property values, the leveled-graph construction replaces a non-expressible order constraint in core GQL with ordinary reachability on an expanded graph. The transformation creates nodes $t$23 recording the last edge value seen and preserves answer existence exactly, with construction time

$t$24

and size bounds

$t$25

(Rotschield et al., 29 Dec 2025). This is directly relevant as a special-case payload-constrained path database idea: compile a path payload predicate into preprocessed data so that standard path querying suffices.

Another neighboring approach extends regular path queries over property graphs with SMT constraints on node and edge attributes, using parametric automata, macro-states, and an SMT solver to prune infeasible partial paths during traversal. That work is highly aligned with payload-constrained path querying as a language and execution problem, but it remains an online evaluation architecture rather than a precomputed path database (Li et al., 1 Dec 2025). For constraints that do compile to regular languages, the product-graph framework for regular path queries provides the relevant complexity baseline and shows that exact evaluation is often already optimal or near-optimal in the fine-grained sense (Casel et al., 2021).

These comparisons clarify the specificity of PCPD. In the literature considered here, PCPD is neither a universal theory of constrained path data nor a synonym for any payload-aware path technique. It is a concrete offline structure: a bank of payload-conditioned compressed first-move databases for minimum-energy routing on static uneven terrain, used to prune successor generation in a concurrent multi-pickup search (Babakano et al., 7 Sep 2025). A plausible implication is that broader PCPD research may evolve along several axes already visible in adjacent work: richer payload-state compilation into graph structure, stronger reusable lower bounds, and tighter integration between database-style precomputation and exact constrained search.