Demo2Code: From Summarizing Demonstrations to Synthesizing Code via Extended Chain-of-Thought

Language instructions and demonstrations are two natural ways for users to teach robots personalized tasks. Recent progress in Large Language Models (LLMs) has shown impressive performance in translating language instructions into code for robotic tasks. However, translating demonstrations into task code continues to be a challenge due to the length and complexity of both demonstrations and code, making learning a direct mapping intractable. This paper presents Demo2Code, a novel framework that generates robot task code from demonstrations via an extended chain-of-thought and defines a common latent specification to connect the two. Our framework employs a robust two-stage process: (1) a recursive summarization technique that condenses demonstrations into concise specifications, and (2) a code synthesis approach that expands each function recursively from the generated specifications. We conduct extensive evaluation on various robot task benchmarks, including a novel game benchmark Robotouille, designed to simulate diverse cooking tasks in a kitchen environment. The project's website is available at https://portal-cornell.github.io/demo2code/

Paper

References (77)

Scroll for more · 38 remaining

Similar papers

Peer review

Reviewer yYo26/10 · confidence 3/52023-06-15

Summary

This work presents a recursive method to summarize demonstrations into programs through LLM. The idea is interesting in that it uses spec as the bottleneck to connect complex demonstrations and complex robot task code, encoded and decoded through chain of thoughts. The method is evaluated on three different benchmarks involving table-top manipulation, novel kitchen text tasks, and EpicKitchen. The method outperforms naive language-to-code baselines and can generalize to longer-horizon tasks as well as learning user intents.

Strengths

1. The problem is challenging in that demonstrations and codes are both complex: demonstrations have lots of details and multimodality, yet codes are abstract and need to follow strict requirements. 2. The method is sound: it uses divide and conquer to tackle some limitations of the current LLM. 3. The new benchmark can be interesting to researchers that want to attempt the high-level planning problem in kitchen tasks. 4. The figures and the pseudo codes are helpful 5. The method generalize to longer-horizon tasks as well as learning user intents.

Weaknesses

1. Have several concerns on the evaluation metrics 2. Need more details on discussing the tabletop benchmark, the EpicKitchen experiment and the new proposed benchmark. Looks like epic kitchen is closer to diverse raw data such as Youtube and yet the new kitchen simulator and the table-top tasks has more predicates as well as low-level relationships

Questions

1. The formulation of MDP seem a bit unnecessary to me. 2. The spec is called “latent” multiple times in the paper, but shouldn’t it be clearly defined for each task? 3. To confirm on the evaluation metric: Is the unit-test pass rates the same as task success rates? I.e. does the generated code satisfy a set of instructions (task) defined with the demonstrations? Or is it more narrowed? 4. What is the quality of the spec2code, and why matching it is a necessary metric? It seems to me that there are many ways to write code for each task. 5. Is hallucination a problem? Because the method introduces such a pipeline instead of end-to-end, is it possible that the LLM introduces unnecessary steps in the instruction summary stage and then introduce more functions to complete those substeps in the expanding stage? 6. What is the reference code in EpicKitchen dataset in line 190. And what is the user scoring process? 7. Given that there could be multiple ways to do the breakdown and the LLM are not deterministic, is stochasty a concern? It seems that variance is not provided in the table for each experiment. 8. Have the authors tried the new GPT3.5 model with longer-context or GPT-4 model?

Rating

6: Weak Accept: Technically solid, moderate-to-high impact paper, with no major concerns with respect to evaluation, resources, reproducibility, ethical considerations.

Confidence

3: You are fairly confident in your assessment. It is possible that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work. Math/other details were not carefully checked.

Soundness

3 good

Presentation

3 good

Contribution

3 good

Limitations

See above.

Reviewer 325h6/10 · confidence 4/52023-07-05

Summary

This paper presents demo2code, a framework that takes as input user's language instructions as well as demonstrations, and outputs synthesized code for completing the tasks. It first iteratively summarizes given demonstrations to a compact task specification, then reasons by incorporating user preferences etc, and lastly output expanded execution code. The method is evaluated on a range of tasks, including table top manipulation, a simple cooking simulator, and real-world epic kitchen dataset.

Strengths

- The framework is novel in that it proposes to summarize demonstrations and language instructions using LLM, which is then used for action generation via code synthesis. - the recursive and hierachical way of summarizing demonstrations and generating code is reasonable - the idea that using LLM to reason about user preferences makes sense

Weaknesses

- Upon reading the introduction i was excited to see how the approach is able to handle both instruction and demonstration: the latter usually comes in a visual space, but then i realize the authors made a big assumption that they can query the simulator to get state-based demonstration. This assumption presents a few issues: 1) such privileged information hinders the application in realistic settings. In fact, the author had to manually densely label the epic kitchen dataset, which leads to the question of how this can be used for real-world settings 2) even in simulation, it's not straightforawrd to obtain these state information. for example, as opposed to `op-top`, relations such as `in(obj, microwave)` is hard to obtain easily. Also, binary spatial relations loses dense geometric informations. 3) if access to step-by-step low-level state is assumed, and the LLM can summarize and generate step-by-step specifications, why not directly use task and motion planning(TAMP) to solve the task? - how does the oracle spec2code works? does it use TAMP? if yes, what's the advantage of demo2code over it? - the experiment which uses epickitchen, but need additional manual annotation, loses the point of evaluating on real-world dataset

Questions

- the authors says the language instruction and demonstration shares a common latent space after summarizing, but i don't see any details on this. Did I miss something? - also see weaknesses.

Rating

6: Weak Accept: Technically solid, moderate-to-high impact paper, with no major concerns with respect to evaluation, resources, reproducibility, ethical considerations.

Confidence

4: You are confident in your assessment, but not absolutely certain. It is unlikely, but not impossible, that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work.

Soundness

3 good

Presentation

3 good

Contribution

2 fair

Limitations

- assumption on access to privileged low-level state and relations - additional annotation on real-world data - other limitations are discussed in the last section

Reviewer ujZb7/10 · confidence 3/52023-07-06

Summary

This paper proposes Demo2Code, a new method for generating code given a natural language description and demonstrations of the task. Demo2Code recursively summarizes demonstrations using a language model (LM) to create a task specification. The task specification is concatenated to the description and then recursively synthesized into code using a LM. Demo2Code is shown to outperform previous SoTA on an object manipulation environment, an author-designed cooking simulator, and the EPIC Kitchens dataset. Finally, qualitative results are shown demonstrating OOD generalization, grounding, and understanding of user preferences.

Strengths

*Originality:* a new long-range sequential decision-making benchmark, Robotouille, was developed that focuses more on high-level actions rather than manipulation and navigation. This may be useful for future work studying agents that learn from task specification. *Quality:* the experiments are comprehensive and cover a range of tasks and domains, suggesting that the method is robust to distributions of tasks. Furthermore, the results show a marked improvement over the previous SoTA on all the tasks, which likely demonstrates the efficacy of leveraging demonstrations. *Clarity:* the paper is well-written and the figures are self-explanatory. *Significance:* generating code from demonstrations is an important step towards developing agents that can efficiently interact with humans. Moreover, this work demonstrates a working end-to-end setup from natural language demonstrations to code, likely encouraging future work in this area.

Weaknesses

There are two implicit assumptions of the method that are not evaluated and may make the method difficult to use in practice. I believe that these assumptions may be hard to overcome, so I am leaning towards giving a 6.5 but am rounding up because of the high-quality execution. 1. *The method assumes that demonstrations are complete descriptions of each state in the trajectory.* I would imagine that in many real-world environments (which is the setting that such a method would likely be deployed in), obtaining a complete description of each state in the trajectory is noisy. Some actions may be occluded or unable to be clearly delineated. Moreover, it may not even be clear a priori how to canonically parse actions from video or a natural language description of the environment. Would it be possible to develop an ablation where some of the actions are noisily parsed or even entirely omitted from the demonstration? I suspect that GPT-3.5 may not be able to handle the perturbation, but GPT-4 may be able to. 2. *The method assumes that the task description is well-specified.* Humans can often provide demonstrations and descriptions of the task that are under-specified or misspecified. For example, when booking airline tickets, a human may forget to describe their preference for red-eye flights and there may not be enough demonstrations to determine their underlying preferences [1]. In its current form, the method appears unequipped to handle such cases and it is unclear what solution it would generate. As mentioned in the work, one possible remedy is to provide feedback to the LM, but it is unclear how successful such an approach would be. [1] Lin, J., Fried, D., Klein, D., & Dragan, A. (2022). Inferring Rewards from Language in Context. In Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) (pp. 8546–8560). Association for Computational Linguistics.

Questions

Questions: * Is there intuition for why the pass performance of DemoNoLang2Code is greater than the pass performance of Demo2Code on the "Make a burger stacking lettuce atop patty immediately" and the "Make two burgers stacking patty atop lettuce after preparation" tasks in Table 2?

Rating

7: Accept: Technically solid paper, with high impact on at least one sub-area, or moderate-to-high impact on more than one areas, with good-to-excellent evaluation, resources, reproducibility, and no unaddressed ethical considerations.

Confidence

3: You are fairly confident in your assessment. It is possible that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work. Math/other details were not carefully checked.

Soundness

3 good

Presentation

3 good

Contribution

2 fair

Limitations

In general the limitations are well-addressed. The following two limitations were also addressed as weaknesses above: * Demonstrations are complete descriptions of low-level actions. In practice it seems difficult to obtain complete descriptions of all actions and state of an environment, as actions are often noisy and difficult to clearly delineate. E.g., given some video of a human washing the dishes, it would be unclear how to appropriately parse the action space (in the paper it was done by hand). * The natural language description of the task may be misspecified by the human. This seems like a fundamental limitation of the current method, and might make the generated code incorrect or misspecified.

Reviewer sxrs6/10 · confidence 3/52023-07-06

Summary

The authors propose an LLM-based completion framework to translate natural language instructions, in addition to transcribed state sequences of demonstrations (as PDDL (or other strips-like) predicates), into code for executing the task with a robot. The method is based on recursively summarizing the demonstrations into a 'specification', and then recursively expanding the 'specification' into python(?) code. The recusrsion stops in the first phase when no further summarization is possible, and in the code expansion loop, when no function is undefined. The authors demonstrate this is three different domains with upto 10 distinct high level actions occuring in each demonstration.

Strengths

Multimodal learning from demonstrations plus language instructions is an important problem that will enable consuming a wider modality of data sources to generate robot/agent programs and behavior. Using the summarization/translation capabilities of LLMs will likely be a key component of such a system.

Weaknesses

**Methodology**: The paper does not define what a task specification is concretely, nor does it define what it means for the demonstrations to be adequately summarized, in particular in Alg 1 the function is_summarized() is not defined, nor is its operationalization defined anywhere in the text of the paper. Specification traditionally refers to a formal statement whose semantics are well known and the satisfaction of the specification with respect to an output is computationally well-defined and consistent. By not having a concrete definition of specification, the evaluations set up in the latter part of the paper suffer from lack of diversity and a lack of quantification of task difficulty. **Code as output language**: This work relies on the output code being interpretable, and this involves providing a set of primitive parametric functions to the LLM to use. The part of sensing the environment, and acting using perception feedback is something that is already programmed into the primitives. Coming up with an adequate and a competent set of parameterized primitives is challenging, and in this case is entirely the responsibility of the system designer. **Claims of generalization** Tthe generalization shown is only generalizing towards named entity substitutions, not to complex control flows and temporal specifications. Specifically, all the tasks shown here are a sequence of subgoals where performing any subgoal out of order will not preclude the agent from completing the subsequent actions. Further, there is no reactivity in the task specifications, and there are no avoidance tasks. All of these task specifications notions are very common in robotics and planning problems that this system has not been evaluated on. Refer to [1] for a survey on robotics mission types (also relevant to symbolic planning). All the tasks here are limited to the visit or sequenced visit type. Further while the submission claims that demo2code can generalize for complex long-horizon tasks, the maximum task length is quite smaller than state of the art for symbolic planning. Automatically translating textual domain descriptions to a formal domain description followed by the use of automated planners has already shown more reliable performance on harder problems [5]. Further there is quite a bit of evidence that LLMs cannot plan beyond the simplest of domains [6], and this line of research is unacknowledged in the submission. **Issues on evaluations of learning from demonstrations:** Generalization from demonstrations and language is a tricky subject. Usually demonstrations and language contain complementary sources of information. Therefore none of the system behaviors are incorrect in Figure 5, the core issue is that inductive learning is by definition an ill-posed problem, and many approaches to inductive learning have relied on Bayesian inference in the past. [2],[3]. Specifically, the issue of where to place the purple block (fig 5a) given the language description is underspecified, and the system had to forcibly ground the placement to any of the valid options to generate a trajectory. Committing to a valid assignment as was done by the lang2code model is one approach, and asking for resolution of referential ambiguity is another approach [4]. One might argue that learning to overconstrain the output based on a single demonstration is an example of overspecification. [1] - Menghi, C., Tsigkanos, C., Pelliccione, P., Ghezzi, C. and Berger, T., 2019. Specification patterns for robotic missions. IEEE Transactions on Software Engineering, 47(10), pp.2208-2224. [2] - Tenenbaum, J.B., 1999. A Bayesian framework for concept learning (Doctoral dissertation, Massachusetts Institute of Technology). [3] - Shah, A., Kamath, P., Shah, J.A. and Li, S., 2018. Bayesian inference of temporal task specifications from demonstrations. Advances in Neural Information Processing Systems, 31. [4] - Williams, Tom, Rafael C. Núñez, Gordon Briggs, Matthias Scheutz, Kamal Premaratne, and Manohar N. Murthi. "A dempster-shafer theoretic approach to understanding indirect speech acts." In Advances in Artificial Intelligence--IBERAMIA 2014: 14th Ibero-American Conference on AI, Santiago de Chile, Chile, November 24-27, 2014, Proceedings 14, pp. 141-153. Springer International Publishing, 2014. [5] - Liu, B., Jiang, Y., Zhang, X., Liu, Q., Zhang, S., Biswas, J. and Stone, P., 2023. Llm+ p: Empowering large language models with optimal planning proficiency. arXiv preprint arXiv:2304.11477. [6] - Valmeekam, K., Olmo, A., Sreedharan, S. and Kambhampati, S., 2022. Large Language Models Still Can't Plan (A Benchmark for LLMs on Planning and Reasoning about Change). arXiv preprint arXiv:2206.10498.

Questions

To strengthen the paper the authors should carefully define the following: 1. The role of the user/system developer. This includes definition of skill primitives that can be executed in the environment, definition of predicates that are sufficient to track the progress of the tasks. Developing perception systems that accurates record the predicate states 2. Quantify task complexity using metrics from logic (expressing instructions in temporal logic, and measuring the size of the automaton). Using number of predicates, and actions and reporting them for each planning domain. 3. Evaluate on diverse set of instructions taking inspiration from Menghi et al. [1] to come up with specification templates beyond sequenced visit. 4. Report comparative performance against state-of-the-art symbolic planners. in comparably sized planning domains.

Rating

6: Weak Accept: Technically solid, moderate-to-high impact paper, with no major concerns with respect to evaluation, resources, reproducibility, ethical considerations.

Confidence

3: You are fairly confident in your assessment. It is possible that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work. Math/other details were not carefully checked.

Soundness

2 fair

Presentation

3 good

Contribution

2 fair

Limitations

Please see above

Reviewer Gc7K7/10 · confidence 3/52023-07-06

Summary

This paper presents a method that can take both demo and language in and teach LLM to perform new tasks. The idea makes sense and the algorithm is easy to understand and works very well. Evaluation results and ablations show improvement over existing works.

Strengths

The paper is well written and the idea is clear and easy to understand.

Weaknesses

It's probably better to define what "task" is. For example, the authors claim "Demo2Code can generalize across complex, long-horizon tasks." However, for real world robotics tasks, I would imagine there will be a lot of corner cases and the code needs to handle it and therefore it won't generalize to those tasks.

Questions

It looks like the method does not involve any network training / fine tuning, right? If so, do you expect to get better performance by training / fine tuning LLM?

Rating

7: Accept: Technically solid paper, with high impact on at least one sub-area, or moderate-to-high impact on more than one areas, with good-to-excellent evaluation, resources, reproducibility, and no unaddressed ethical considerations.

Confidence

3: You are fairly confident in your assessment. It is possible that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work. Math/other details were not carefully checked.

Soundness

3 good

Presentation

3 good

Contribution

3 good

Limitations

As the author said, the ability of this framework is limited by the capability of LLM.

Reviewer ujZb2023-08-10

Thank you for the clarification

.

Reviewer sxrs2023-08-14

Thank you for the response

**User-defined modules**: I appreciate this reflection, and it would be a valuable addition to the paper to better define the user's/systems designer's role **Role of specification patterns**: I believe the authors misunderstood the intent of comparing selected tasks to Menghi's [ref-1 mine] framework. Menghi's framework is a taxonomy of temporal properties present in robotics tasks, and the authors should select tasks that fall into various categories from the hierarchy, and the selected tasks only fall under a few of the temporal properties. I also appreciate the author's efforts to characterize the complexity of the tasks that the system was tested on. **Definition of summarization**: I appreciate the clarification, and would like the authors to clarify if the computation of whether the demonstration is summarized actually leverages the 'explained away' criterion as mentioned (using logits of the LLM), or if it is asking an LLM to evaluate whether the instruction is adequately summarized? Thus I feel the authors have reiterated their position more clearly in the response, the central issue with the lack of diversity of temporal properties in tasks learned from demonstration still remains. As it stands I plan to retain my current score

Authorsrebuttal2023-08-16

Thank you for your feedback (1/2)

## Question **Does the computation of whether the demonstration is summarized actually leverage the 'explained away' criterion as mentioned (using logits of the LLM), or does it ask an LLM to evaluate whether the instruction is adequately summarized?** - At test time, the LLM is asked to evaluate if a trajectory is adequately summarized. - However, when we design the summarization prompt, we validate the prompt by using tasks with short demonstrations to check if concatenating those demonstrations to the beginning of the generated specification changes the code. - If specification alone and specification with demonstrations cause the LLM to generate the same code, we can approximately show that the prompt satisfies the criteria that P(code | spec) = P(code | spec, demo). - Thus, our prompt validation approach essentially examines the arg max of the logits, which is the code, instead of the exact logits whose values may vary. ## Clarification on specification pattern We would like to emphasize that since we are predicting code as output, we must measure the complexity of tasks in terms of their code complexity. We categorize our tasks under a taxonomy of the number of loops, conditionals, functions, code length, and horizon lengths (see Table 4 in the attached pdf). Our tasks do coverage on these different axes. This is also consistent with how prior works [1-4] predicting task code have characterized their set of tasks. The challenge with using a different taxonomy, e.g. Menghi et al.[5], is a potential mismatch in categories in the taxonomy v.s. varying levels of complexity for the code generation model. Notably, two different categories can result in very similar code. For example: - **Avoidance category:** Don’t stack blocks above a certain height results in "while stack_height < X" - **Trigger category:** Wait till patty is cooked results in "while not is_cooked(patty)" - Both are simply while() loops with different conditions. However, we are happy to characterize the current tasks we have in Menghi et al.[5]'s taxonomy as the reviewer requested. We also introduce 3 new tasks to increase the diversity in the new taxonomy. Please see the table below: | Planning Domain | Task Name | global avoidance (Avoidance) | upper restriction avoidance (Avoidance) | lower/exact restriction avoidance (Avoidance) | wait (Trigger) | instantaneous reaction (Trigger) | delayed reaction (Trigger) | patrolling (Surveillance) | |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | Tabletop | Place A on top of B | | | | | X | | | | | Stack all blocks/cylinders | | X | | | | | | | | Stack all objects into two stacks | X | | | | | | | | Robotouille | Cook and cut | | | X | X | X | | | | | Cook two patties | | | | X | X | | | | | Cut two lettuces | | | X | | | | | | | Assemble two burgers | | | | | | | | | | Make a burger | X | | X | X | X | X | | | | Make two burgers | X | | X | X | X | X | | | | **Keep making burgers (new)** | **X** | | **X** | **X** | **X** | **X** | **X** | | | **Keep assembling burgers (new)** | **X** | | | | | **X** | **X** | | | **Cooking multiple patties simultaneously (new)** | | | | **X** | **X** | | **X** | | EPIC-KITCHENS | Washing dishes | | | X | | X | | | For the new "keep making burgers" and "keep assembling burgers" clusters of tasks, we report Demo2Code's execution success rate and unit test pass rate below: | Task Cluster | Requirements | Execution Success Rate | Unit Test Success Rate | |:---:|:---:|:---:|:---:| | Keep making burgers | stacking lettuce atop patty immediately | 0 | 0 | | | stacking patty atop lettuce immediately | 1 | 0 | | | stacking lettuce atop patty after preparation | 0 | 0 | | | stacking patty atop lettuce after preparation | 0 | 0 | | | substitute lettuce with cheese | 1 | 1 | | | substitute patty with chicken | 1 | 1 | | | add tomato | 1 | 1 | | Keep assembling burgers | none | 1 | 1 | | | do the tasks in parallel | 1 | 0 | | Overall | | 0.67 | 0.44 | [1] Jacky Liang, et al. Code as policies: Language model programs for embodied control [2] Ishika Singh, et al. Progprompt: Generating situated robot task plans using large language models [3] Jimmy Wu, et al. Tidybot: Personalized robot assistance with large language models [4] Andy Zeng, et al. Socratic models: Composing zero-shot multimodal reasoning with language

Authorsrebuttal2023-08-16

Thank you for your feedback (2/2)

To clarify how we characterize our tasks, we provide one specific example for each mission specification pattern: - Global avoidance - For the Robotouille "make a burger" tasks, although the language instruction just says "make a burger", the demonstrations show that the user wants to avoid using any burger patty and use chicken instead. - **"Not using burger patty" is an avoidance condition that globally holds throughout the mission.** - Upper restriction avoidance - For the tabletop "stack all blocks/cylinders" tasks, a hidden world constraint (a maximum height for a stack) needs to be inferred from the demonstrations and is not explicitly stated in the language instruction. - **"Only placing a maximum of X number of objects into a stack" is a restriction on the maximum number of occurrences (placing objects into a stack).** - Lower/Exact restriction avoidance - In Robotouille, when the robot needs to cut lettuce, the demonstrations show that the robot needs to keep performing the "cut" action until the lettuce is cut. Currently, the unit test makes sure that the robot at least performs the minimal amount of "cut" actions in order to successfully cut the lettuce. Demo2Code generates a code that even satisfies the stricter requirements of performing the exact amount of "cut" actions because the code keeps calling cut() while the lettuce is not cut. - **"Cut the lettuce at least X amount of time" is a restriction on the minimum number of occurrences (performing cut actions).** - **"Cut the lettuce exactly X amount of time" is a restriction requiring an exact amount of occurrences.** - Wait - In Robotouille, when the robot needs to cook a patty, the demonstrations show that after the robot starts the cooking process, it needs to wait until the patty is cooked. - **"Wait until the patty is cooked" is an example of when inaction (wait) is desired until a stimulus (patty becomes cooked) occurs.** - Instantaneous reaction - For some variants of the "make a burger" Robotouille tasks, when the patty is cooked, the demonstrations show that the robot should immediately pick the patty up for subsequent subtasks (e.g. stacking the patty on top of the rest of the burger). - **"Once the patty is cooked, immediately pick it up" is an example of when the occurrence of a stimulus (the patty is cooked) instantaneously triggered a counteraction (pick up that patty).** - Delayed reaction - For some variants of the "make a burger" Robotouille tasks, instead of immediately picking up the patty once it's cooked, the demonstrations show that the robot should complete some other subtasks (e.g. cutting the lettuce) before returning to pick up that patty. This behavior is applicable to when the user prefers the robot to prepare all the ingredients before assembling the burger. - **"Once the patty is cooked, pick the patty up but it is not necessary to do it immediately" is an example of when the occurrence of a stimulus (the patty is cooked) triggers a counteraction (pick up that patty) some time later.** - Patrolling - Although the surveillance category where the robot needs to keep performing a task is out of the scope of our paper, we adapted some existing tasks to new ones with patrolling patterns to test the Demo2Code pipeline. - The "keep making burgers" and "keep assembling burgers" Roboutille tasks contain demonstrations where the robot would keep working until there are no more ingredients in the environment to use. - Another patrolling task for future work is when the robot is simultaneously cooking multiple patties. - Once the robot starts cooking, the robot needs to continuously patrol each stove to check on the patty. If a patty is cooked, the robot needs to remove that patty from the stove and place it on the table. - **"Keep visiting all the stoves" represents the requirement to keep visiting a set of locations (stoves), but not in a particular order.**

Reviewer sxrs2023-08-16

Thank you for adding this context

Addressing coverages under various taxonomies is a valuable excercise in identifying test cases to stretch system capabilities, using both taxonomies is helpful. This paper can set a great precedent for follow-on works even if past LLM planning papers have not considered the formal specification taxonomy. This alone significantly strengthens the paper. I am willing to raise my score to weak accept. My only holdout would be that evaluation standards in LLM planning papers and classical planning papers are quite divergent. A key principle in classical planning papers is to test the system to failure by progressively increasing task complexity, and while there are elements of it here, the two streams of research seem to be targetting different meanings of complexity, and there is little overlap between accepted evaluation methodologies in these areas despite having overlapping applications. However addressing this gap is best suited for future work, and with the inclusion of this and some additional discussion on how to evaluate LfD approaches in the final version, I will not argue against acceptance. Examples of pipelines going from demo to robot policies in the classical planning domain include works on inferring formal specifications from demonstrations in languages such as LTL and planning with respect to those formulas to generate code, and some examples of the works are provided below. While these are not direct baselines as Demo2Code has complementary strengths and adopts a different solution approach. There are lessons to be learned on evaluating inductive learning problems on complex tasks here. Specification inference from demonstrations (as LTL or automata) (an incomplete list): [1] - Vazquez-Chanlatte, M., Jha, S., Tiwari, A., Ho, M.K. and Seshia, S., 2018. Learning task specifications from demonstrations. Advances in neural information processing systems, 31. [2] - Shah, A., Kamath, P., Shah, J.A. and Li, S., 2018. Bayesian inference of temporal task specifications from demonstrations. Advances in Neural Information Processing Systems, 31. [3] - Toro Icarte, R., Waldie, E., Klassen, T., Valenzano, R., Castro, M. and McIlraith, S., 2019. Learning reward machines for partially observable reinforcement learning. Advances in neural information processing systems, 32. Automated policy generation from specifications (again an incomplete list): [4] - De Giacomo, G., Iocchi, L., Favorito, M. and Patrizi, F., 2019. Foundations for restraining bolts: Reinforcement learning with LTLf/LDLf restraining specifications. In Proceedings of the international conference on automated planning and scheduling (Vol. 29, pp. 128-136). [5] - Icarte, R.T., Klassen, T.Q., Valenzano, R. and McIlraith, S.A., 2022. Reward machines: Exploiting reward function structure in reinforcement learning. Journal of Artificial Intelligence Research, 73, pp.173-208. [6] - Shah, A., Li, S. and Shah, J., 2020. Planning with uncertain specifications (puns). IEEE Robotics and Automation Letters, 5(2), pp.3414-3421.

Authorsrebuttal2023-08-16

Thank you for your suggestions

Thank you for your time and energy to help us improve and strengthen our paper! We appreciate the discussions about the gap in the evaluation standards for LLM-based planners and classical planners. We will incorporate a section discussing this gap and how to evaluate LfD approaches in the final version of the paper.

Reviewer 325h2023-08-19

I appreciate the authors' detailed response. I have increased my scores accordingly.

Authorsrebuttal2023-08-21

Thank you for your feedback

Hello! Thank you again for your review and questions! Since the discussion period is coming to a close, please let us know if any additional clarifications would be helpful in your evaluation.

Authorsrebuttal2023-08-21

Thank you for your feedback

Hello! Thank you again for your feedback and questions! As the discussion period ends soon, please let us know if we can provide any additional clarifications or answers that would help you in your evaluation.

Program Chairsdecision2023-09-21

Decision

Accept (poster)

© 2026 NYSGPT2525 LLC