Is your feature request related to a problem? Please describe.
MoveIt 2's TrajectoryCache uses warehouse_ros to apply fuzzy structured filters to cached trajectories and ranks matching results using metadata such as execution_time_s. This behavior should remain the default.
Some database backends can use caller-provided scene and trajectory descriptors to rank the same candidate trajectories more appropriately. However, TrajectoryCache currently has no generic candidate-ranking extension point, and its database connection is not externally extensible. The standard warehouse_ros::Query interface also has no vector-query or Top-K ranking semantics.
As a result, a database backend cannot provide context-aware candidate ranking for TrajectoryCache without creating a separate retrieval path.
Describe the solution you'd like
I would like TrajectoryCache to provide an optional, backend-agnostic candidate-ranking extension point.
The extension point could receive the existing structured query and caller context and return ordered candidate trajectory IDs. When no extension is configured, the existing retrieval and ranking behavior would remain unchanged. The exact interface can be discussed based on maintainer feedback.
The intended boundaries are:
- Keep the existing API and default ranking behavior unchanged.
- Do not introduce a seekDB or other database-specific dependency into MoveIt.
- Only rank candidates that already satisfy the existing fuzzy-matching conditions.
- Do not treat the ranking result as a collision-free guarantee.
- Keep subsequent
PlanningScene collision validation under the caller's control.
Two external prototype repositories are available:
In the current deterministic planar PlanningScene smoke benchmark, both methods use the same structured candidate set:
- Sorting by
execution_time_s passes the subsequent collision check for 15/35 Top-1 results (42.86%).
- seekDB vector ranking passes it for 30/35 Top-1 results (85.71%).
- Both methods achieve 30/35 Valid@3.
This result only validates the retrieval path and evaluation method. It is not yet evidence for real robots or production scenes.
If this direction is accepted, I will prepare the corresponding PR. The PR will contain only the minimal generic interface, tests, and documentation. It will not introduce a seekDB dependency into MoveIt or change the default behavior of existing database backends.
Describe alternatives you've considered
No response
Additional context
No response
Is your feature request related to a problem? Please describe.
MoveIt 2's
TrajectoryCacheuseswarehouse_rosto apply fuzzy structured filters to cached trajectories and ranks matching results using metadata such asexecution_time_s. This behavior should remain the default.Some database backends can use caller-provided scene and trajectory descriptors to rank the same candidate trajectories more appropriately. However,
TrajectoryCachecurrently has no generic candidate-ranking extension point, and its database connection is not externally extensible. The standardwarehouse_ros::Queryinterface also has no vector-query or Top-K ranking semantics.As a result, a database backend cannot provide context-aware candidate ranking for
TrajectoryCachewithout creating a separate retrieval path.Describe the solution you'd like
I would like
TrajectoryCacheto provide an optional, backend-agnostic candidate-ranking extension point.The extension point could receive the existing structured query and caller context and return ordered candidate trajectory IDs. When no extension is configured, the existing retrieval and ranking behavior would remain unchanged. The exact interface can be discussed based on maintainer feedback.
The intended boundaries are:
PlanningScenecollision validation under the caller's control.Two external prototype repositories are available:
warehouse_ros_seekdb: a seekDB-backedwarehouse_rosplugin with a vector Top-K retrieval extension.moveit_trajectory_cache_seekdb: the MoveIt caller-side adapter, vector-ranking logic, and benchmark.In the current deterministic planar
PlanningScenesmoke benchmark, both methods use the same structured candidate set:execution_time_spasses the subsequent collision check for 15/35 Top-1 results (42.86%).This result only validates the retrieval path and evaluation method. It is not yet evidence for real robots or production scenes.
If this direction is accepted, I will prepare the corresponding PR. The PR will contain only the minimal generic interface, tests, and documentation. It will not introduce a seekDB dependency into MoveIt or change the default behavior of existing database backends.
Describe alternatives you've considered
No response
Additional context
No response