one_ppt.json

"Human: You are an excellent interpreter of instructions for robotic assembly tasks.\n\n    The input are:\ntarget: The target that you make the sequential plan and construct the behavior tree to achieve.\ninitial_state: The initial state that you start from.\n\nYou analyze the target, refer to the domain knowledge to understand it, make an action sequence and construct a behavior tree based on it.\nYour output should be a json object which follows the regulated format.\n\n    Following is the domain knowledge you need, which includes:\n- the object types in the world,\n- the predicates for describing the states of the world,\n- the actions that the robot can apply, with their precondtions and effects defined.\n\nThe object types are explained as follows:\n\"\"\"\nthing: The base class for all objects in the world. Its subclasses are: hand, tool, part.\nhand: The robot hand. A empty <hand> can only hold one <tool> at a time.\ntool: The tool to manipulate <part>. A empty <tool> can hold one <part> at a time.\npart: The part to be manipulated.\n\"\"\"\n\nThe precidates are explained as follows:\n\"\"\"\n\"PREDICATE_LIST\"\n- is_empty(<tool>): <tool> is empty and can hold something.\n- can_manipulate(<tool>, <part>): <tool> can be used to manipulate <part> (manipulation constraint). This regulates the compatibility between <tool> and <part>.\n- can_insert_to(<part1>, <part2>): <part1> can be inserted into <part2> (insertion assembly constraint)\n- can_screw_to(<part1>, <part2>): <part1> can be screwed into <part2> (screw assembly constraint)\n- can_place_to(<part1>, <part2>): <part1> can be placed into <part2> (placement assembly constraint)\n- hold(<thing1>, <thing2>): <thing1> is holding <thing2>. It can be <hand> holding <tool> or <tool> holding <part>.\n- is_inserted_to(<part1>, <part2>): <part1> is inserted into <part2> (insertion assembly constraint is satisfied)\n- is_screwed_to(<part1>, <part2>): <part1> is screwed into <part2> (screw assembly constraint is satisfied)\n- is_placed_to(<part1>, <part2>): <part1> is placed into <part2> (placement assembly constraint is satisfied)\n\"\"\"\n\nThe actions are explained as follows:\n\"\"\"\n\"ROBOT_ACTION_LIST\"\n- pick_up(<hand>, <tool>, <part>): <hand> use <tool> to pick up <part>. As preconditions, <hand> should be holding <tool> and <tool> should be empty in order to hold the <part>. The <part> will be held by the <tool> as a result of this action.\n- put_down(<hand>, <tool>, <part>): <hand> use <tool> to put down <part>. As preconditions, <hand> should be holding <tool> and <tool> should be holding <part>. The target is to make the tool <tool> empty. The <tool> will be empty and will not hold the <part> anymore as a result of this action.\n- place(<hand>, <tool>, <part1>, <part2>): <hand> use <tool> to place <part1> to <part2> (to satisfy the placement assembly constraint between <part1> and <part2>). As preconditions, <hand> should be holding <tool> and <tool> should be holding <part1>.\n- detach(<hand>, <tool>, <part1>, <part2>): <hand> use <tool> to detach <part1> from <part2> (to lift the existing placement assembly constraint between <part1> and <part2>). As preconditions, <hand> should be holding <tool> and <tool> should be empty to manipulate <part1>, and <part1> should be placed into <part2>.\n- insert(<hand>, <tool>, <part1>, <part2>): <hand> use <tool> to insert <part1> into <part2> (to satisfy the insertion assembly constraint between <part1> and <part2>). As preconditions, <hand> should be holding <tool> and <tool> should be holding <part1>.\n- pull(<hand>, <tool>, <part1>, <part2>): <hand> use <tool> to pull <part1> from <part2> (to lift the existing insertion assembly constraint between <part1> and <part2>). As preconditions, <hand> should be holding <tool> and <tool> should be empty to manipulate <part1>, and <part1> should be inserted into <part2>.\n- screw(<hand>, <tool>, <part1>, <part2>): <hand> use <tool> to screw <part1> into <part2> (to satisfy the screw assembly constraint between <part1> and <part2>). As preconditions, <hand> should be holding <tool> and <tool> should be holding <part1>.\n- unscrew(<hand>, <tool>, <part1>, <part2>): <hand> use <tool> to unscrew <part1> from <part2> (to lift the existing screw assembly constraint between <part1> and <part2>). As preconditions, <hand> should be holding <tool> and <tool> should be empty to manipulate <part1>, and <part1> should be screwed into <part2>.\n- change_tool(<hand>, <tool1>, <tool2>): <hand> change the equipped tool from <tool1> to <tool2> in order to manipulate specific parts. As preconditions, <hand> should be holding <tool1> and <tool1> should be empty.\n\"\"\"\nthe items in <> indicate the type of the instances needed for the predicates and actions.\n\n    Information about world states should be in json dictionary format.\nIt contains three lists: \n    - objects: the objects and their properties (as lists of strings) in the world. The properties can be changed by robot actions.\n    - constraints: the constraint relations that are enforced and should not be changed. They are knowledge about the world or some constraints set by the user.\n    - relations: the relations in the world. They can be changed by robot actions.\nThe properties, constraints and relations should always align with the [PREDICATE_LIST] in the domain knowledge.\n\n    [user]\nThe behavior tree should be in json dictionary format.\nFollowing is a simple example:\n\"\"\"\n{\n    \"summary\": \"Selector to change the tool in the left hand from outwardgripper to defaultgripper\",\n    \"name\": \"selector: change_tool(left_hand, outwardgripper, defaultgripper)\",\n    \"children\": [\n        {\n            \"summary\": \"the target is that the left hand is holding the default gripper\",\n            \"name\": \"target: hold(left_hand, defaultgripper)\"\n        },\n        {\n            \"summary\": \"Sequence to change the tool in the left hand from outwardgripper to defaultgripper\", \n            \"name\": \"sequence: change_tool(left_hand, outwardgripper, defaultgripper)\",\n            \"children\": [\n                {\n                    \"summary\": \"A precondition is that the left hand is holding the outwardgripper\",\n                    \"name\": \"precondition: hold(left_hand, outwardgripper)\"\n                },\n                {\n                    \"summary\": \"A precondition is that the outwardgripper is empty\",\n                    \"name\": \"precondition: is_empty(outwardgripper)\"\n                },\n                {\n                    \"summary\": \"The action to change the tool in the left hand from outwardgripper to defaultgripper\",\n                    \"name\": \"action: change_tool(left_hand, outwardgripper, defaultgripper)\"\n                }\n            ]\n        }\n    ]\n}\n\"\"\"\n1. Every node are described by a summary and a name:\n    - \"summary\": a short interpretive description of the node. \n    - \"name\": includes the node type and the formal form of the node according to the domain knowledge. Legal node types are \"selector\", \"sequence\", \"condition\" (\"target\", \"precondition\"), \"action\".\n2. The control flow nodes, namely \"selector\" and \"sequence\", can have \"children\", which is a list of children nodes.\n3. The \"condition\" nodes that are children of \"selectors\" are targets. Those that are children of \"sequences\" are preconditions.\n4. All the node should always have their corresponding actions/precidates in the domain knowledge.\n5. Control flow nodes in behavior trees don't have memory. Each tick starts from the root and traverses all nodes, regardless of their previous state.\n6. The basic structure template of a unit subtree is:\n    - A selector as the root node. \n    - One target condition node as the first child of the selector to check if the target of this subtree has been satisfied.\n    - A sequence node as the last child of the selector node to achieve the target condition node.\n    - A number of precondition nodes as the first child nodes of the sequence node to check the action's preconditions.\n    - One action node as the last child of the sequence node, whose preconditions are checked in the child condition nodes before.\n    - The action should have effects that can fulfill the target condition node in the selector.\n\n7. If any precondition node will be unsatisfied when it is ticked, a unit subtree should be constructed to replace it, which take that precondition node as its target node and aims to achieve it. You should estimate the world state when the precondition is ticked (checked) according to the initial state and the effects of the actions executed before, then do this replacement repeatedly until all the preconditions are satisfied at the time they are ticked.  \n8. The behavior tree should be constructed based on the action sequence you planned and the action definitions in ROBOT_ACTION_LIST.\n9. Control flow nodes (sequence nodes and selector nodes) don't have memory. Each tick starts from the root and traverses all nodes, regardless of their previous state.\n\n    The output json obejct has the following keys:\n\"\"\"\n- \"thought\": A brief explanation of the thinking process behind the action sequence.\n- \"action_sequence\": A sequential list of robot actions. Only the actions defined in the \"ROBOT_ACTION LIST\" will be used.\n- \"behavior_tree\": A json dictionary form behavior tree constructed according to the \"action_sequence\"\n\"\"\"\n\n    Resume from the input below.\n\"\"\"\ntarget: THIS IS THE TARGET\ninitial_state: THIS IS THE INITIAL STATE\n\"\"\" \n\n    Return a JSON object.\n    "