MoveIt Task Constructor (MTC)

repository·ros2·Indexed 43 days ago

https://github.com/moveit/moveit_task_constructor

A framework for task-level motion planning that decomposes complex robotic tasks into a hierarchy of interdependent planning stages. MTC uses Generators, Propagators, and Connectors to solve subproblems via MoveIt's planning capabilities and PlanningScene interface. It supports hierarchical organization through serial and parallel containers (Alternative, Fallback, Merger) and provides Python bindings via the moveit.task_constructor, pymoveit_mtc.core, and pymoveit_mtc.stages modules.

Tokens
10.1K
Snippets
31
Records
55
Agent score
54%

What's inside MoveIt Task Constructor

  1. What is the MoveIt Task Constructor (MTC) framework?

    ros2

    The MoveIt Task Constructor (MTC) is a framework designed to define and plan complex actions composed of multiple interdependent subtasks. It leverages MoveIt's planning capabilities to solve individual subproblems within 'black-box' planning stages.

    Key features include:

    • Interdependent Subtasks: Define sequences or parallel compositions of actions.
    • PlanningScene Interface: Uses MoveIt's PlanningScene as a common interface to pass solution hypotheses between different stages.
    • Hierarchical Organization: Uses containers to organize basic stages into complex task pipelines, supporting both sequential and parallel execution.
  2. What is the MoveIt Task Constructor Framework?

    ros2

    The MoveIt Task Constructor (MTC) framework is a tool for defining and planning complex actions composed of multiple interdependent subtasks. It works by breaking down a high-level task into individual planning stages that solve subproblems using MoveIt's planning capabilities.

    Key features include:

    • Black-box planning stages: Individual subproblems are solved independently.
    • PlanningScene interface: Uses MoveIt's PlanningScene to pass solution hypotheses between stages.
    • Hierarchical organization: Uses containers to organize stages, supporting both sequential and parallel compositions.
  3. How stage types and data flow work in MTC

    ros2

    MTC stages are categorized by how they handle data flow. Understanding these types is critical for building a valid planning pipeline:

    1. Generators: Compute results independently of neighbors and pass them in both directions (forwards and backwards). They act as 'seeds' for the pipeline.
      • Examples: CurrentState (provides the starting robot state), ComputeIK (computes IK for Cartesian targets), or pose generators for grasping/placing.
    2. Propagators: Receive a result from one neighboring stage and plan towards a goal state to pass the result to the opposite interface. The direction of flow is determined by the input interface.
      • Example: A stage computing a Cartesian path from a start or goal state.
    3. Connectors: Attempt to bridge the gap between the resulting states of two neighboring stages. They receive input states from both the 'begin' and 'end' interfaces and attempt to connect them via a motion plan.

    Compatibility Rules:

    • Two Generators cannot be in sequence (both try to write, neither reads).
    • Two Connectors cannot be in sequence (both try to read, neither writes).
    • Compatibility is automatically verified by Task::init() before planning begins.
  4. How to handle dependent sub-solutions using MonitoringGenerators

    ros2

    In complex tasks like 'pick and place', the second part of the task (placing) depends on the state left by the first part (grasping), such as having an object attached to the gripper.

    To link these non-linear pipelines, use a MonitoringGenerator. Instead of being completely independent, a MonitoringGenerator monitors the solutions of another stage in the pipeline and 'fast-forwards' them so the dependent stage can continue processing from that specific state.

  5. Organize stages using MTC containers

    ros2

    To reuse sub-pipelines or organize complex logic, you can encapsulate stages within containers. Stages without children are called primitive stages.

    Wrappers

    Encapsulate a single subordinate stage to modify or filter its results.

    • Example: A filter stage that only accepts solutions satisfying a specific constraint, or an IK wrapper that generates solutions based on annotated planning scenes.

    Serial Containers

    Hold a sequence of subordinate stages. The container only considers end-to-end solutions as valid results (e.g., a multi-step picking motion).

    Parallel Containers

    Consider the solutions of all children as feasible. There are three subtypes:

    • Alternative: Processes all children simultaneously (e.g., planning for a left and right arm in parallel where the choice doesn't matter).
    • Fallback: Processes children sequentially. It only moves to the next child if the current one fails to produce a feasible solution (e.g., try grasping with the right arm, fall back to the left arm if necessary).
    • Merger: Processes children simultaneously and combines their solutions into a single joint solution. This assumes children operate on disjoint joint groups (e.g., an arm and a hand) so trajectories can be executed in parallel.
  6. Define and use Properties in stages

    ros2

    Properties are named attributes of a stage used to configure behavior and control substages. A property maintains two values: a current value and a default value.

    To work with properties, you can define them with a name, a description, and an initial value. Before using a property, it is good practice to check if a current value has been defined. You can then safely retrieve the value using the property object.

    # Example of defining and using a property
    # (Note: Actual implementation details are in the demo scripts)
    # property = stage.property("name", "description", value)
    # if property.has_value():
    #     val = property.get_value()
  7. Understand the core abstractions of MoveIt Task Constructor (MTC)

    ros2

    MoveIt Task Constructor (MTC) decomposes complex motion planning problems into a hierarchical structure of Tasks and Stages.

    • Task: The top-level planning problem container.
    • Stages: The individual subproblems that compose the task. Stages can be arranged in arbitrary hierarchies and orders, provided their data flow is compatible.

    Planning follows a specific lifecycle: processing starts at Generator stages, expands through Propagator stages, and is finalized by Connector stages that bridge the gaps between states.

  8. Connect two stages with a motion plan

    ros2

    Use the Connect functionality to bridge two stages by finding a valid motion plan that transitions from the state of the first stage to the state of the second stage.

    # Example of connecting stages
    # (Refer to pickplace.py for full implementation details)
    initAndConfigConnect()