Principle:Haosulab ManiSkill MP Solver Selection
| Field | Value |
|---|---|
| Principle Name | MP Solver Selection |
| Domain | Motion_Planning |
| Overview | Selecting appropriate motion planning solver based on environment task type |
| Date | 2026-02-15 |
| Repository | Haosulab/ManiSkill |
Overview
The MP Solver Selection principle addresses how the ManiSkill framework routes each environment task to its corresponding motion planning solution. Because each manipulation task (e.g., picking a cube, stacking cubes, inserting a peg) requires a different sequence of grasp poses, approach trajectories, and gripper commands, a single monolithic planner cannot handle all tasks. Instead, the framework adopts a registry pattern that maps environment identifiers to task-specific solver functions.
Description
The core idea is to maintain a dictionary (MP_SOLUTIONS) that maps each registered environment ID string (e.g., PickCube-v1, StackCube-v1, PegInsertionSide-v1) to a callable solver function. When a user requests trajectory generation for a particular environment, the system performs a lookup in this dictionary to retrieve the correct solve function. If the environment ID is not found, a clear error is raised listing the available options.
Each solver function follows a common interface: it accepts the wrapped environment instance and a seed, and it returns either a result tuple containing the final info dictionary (on success) or -1 (on failure). This uniform interface allows the top-level runner to treat all solvers identically for trajectory counting, success-rate tracking, and recording.
The registry pattern also enables extensibility. Contributors can add support for new tasks by implementing a new solve function and registering it in the dictionary, without modifying any other part of the pipeline.
Usage
The solver selection is used at the entry point of the motion planning demo generation pipeline. The user specifies the desired environment via the -e / --env-id command-line argument. The runner script looks up the corresponding solver and invokes it in a loop to generate the requested number of trajectories.
Typical invocation:
python -m mani_skill.examples.motionplanning.panda.run -e PickCube-v1 -n 10
The set of currently supported environments is determined entirely by the keys present in the MP_SOLUTIONS dictionary.
Theoretical Basis
The registry pattern is a well-established software design pattern (sometimes called Strategy or Plugin pattern) that decouples the selection of an algorithm from its execution. In the context of robotic manipulation:
- Task decomposition: Different manipulation tasks have fundamentally different geometric constraints and contact sequences, so a single planner cannot generalize across all of them without task-specific logic.
- Modularity: By isolating each task solver into its own function, the codebase remains maintainable and testable; changes to one solver do not affect others.
- Extensibility: New tasks can be supported by adding a single dictionary entry and a new solver function, following the open-closed principle.