{"id":"89ac341d-a08f-44d2-a538-5172181d1132","arxiv_id":"1908.01539","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"Two new synchronization nodes for parallel Behavior Tree composition, absolute and relative, plus progress-distance and predictability metrics, demonstrated on synthetic and real robot experiments.","lead":"Behavior Trees are a popular way to program robot behavior, but running several behaviors in parallel can cause timing conflicts. This paper proposes two synchronization techniques that pause fast actions until slower ones catch up, plus metrics to measure how synchronized and predictable the execution is.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Synchronization assumes monotone progress, but Definition 2 does not state this and Experiment 3 uses non-monotonic binary progress; the barrier semantics are therefore not well-defined for the admitted class of progress functions.","rationale":"The reader's weakest assumption correctly identified that progress must be available and comparable, but the more specific and load-bearing issue is monotonicity. The algorithms' tick-stalling logic implements barrier semantics only if progress never decreases; otherwise a child that has already crossed a barrier can be ticked again, and the claimed synchronization guarantee fails. The paper neither states this assumption in Definition 2 nor restricts the class of progress functions, and it even uses a non-monotonic binary progress signal in Experiment 3. This is an internal gap rather than a mere disagreement with external consensus: the formal definition permits functions that break the algorithm's own stated behavior. The fix is straightforward: explicitly require non-decreasing progress in Definition 2, or augment the algorithms to track which barriers have been passed. The main contribution is algorithmic and the synthetic experiments would still illustrate the intended behavior under a monotonicity caveat, but the perpetual-action experiment would need reinterpretation. Since the claim of generality is weakened and a precise assumption is missing, the appropriate outcome is conditional acceptance rather than outright rejection. This is consistent with the reader's CONDITIONAL verdict, but with a sharper and more specific technical condition attached.","tokens_in":10392,"tokens_out":5741,"duration_ms":60374,"concrete_test":"Implement Algorithm 1 with two synthetic actions: action A has non-monotonic progress p_A = 0 -> 0.6 -> 0.3 -> 1 over successive ticks, and action B has monotonic progress p_B = 0 -> 0.1 per tick, with a single barrier B = {0.5}. Record which children receive ticks each tick. Under the barrier semantics stated in Section IV-A, after A first reaches 0.6 it should never be ticked again until B reaches 0.5. If the implementation instead resumes ticking A when its progress drops to 0.3, the algorithm violates its own synchronization guarantee, demonstrating that non-decreasing progress is a hidden necessary condition.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central mechanism of both synchronized nodes is tick-stalling based on the current progress value p_i. Definition 2 defines p: R^n -> [0,1] as 'the progress of the BT's execution at each state' without requiring monotonicity. Algorithm 1 (lines 4-10) selects the current barrier as the smallest b in B with b > minProgress and then ticks children with p_i <= current-barrier. This implements a 'once a child has crossed barrier b it waits' policy only if progress never decreases; if p_i can later drop below the barrier, the child is ticked again, so the statement in Section IV-A that a node 'no longer receives ticks until all the other nodes... have the progress equal to or greater than the barrier' is false for non-monotonic progress. The same issue afflicts Algorithm 2: 'exceeds the minimum progress by Delta' is ill-defined when the minimum can regress. The problem is not only formal: Experiment 3 (Section VI) deliberately defines progress for the cart-holding action as 1 when the reference error is within a boundary and 0 otherwise, a non-monotonic binary signal, and then runs the relative synchronized node on it. Thus the paper's own experimental setting falls outside the regime in which the algorithm's semantics are guaranteed. A secondary algorithmic gap is that Algorithm 1 does not initialize minProgress and does not define the behavior when minProgress >= max(B), leaving current-barrier undefined when all children reach the final barrier.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes two synchronized parallel node designs for Behavior Trees: an absolute node that ticks children only until they reach a pre-specified progress barrier (Algorithm 1), and a relative node that withholds ticks from children whose progress exceeds the current minimum by a threshold Delta (Algorithm 2). It defines a progress-distance measure (Eq. 5) and a predictability-distance measure (Eq. 6), presents sensitivity analyses over the number of barriers, noise level, and threshold, and reports simulations and R1 robot experiments to support the claim that synchronization improves behavior predictability.","tokens_in":10729,"tokens_out":4637,"duration_ms":51027,"significance":"If the definitions were made precise, the paper would be a useful step toward principled parallel composition in Behavior Trees: the proposed nodes are simple, the progress-distance measure is natural, and the real-robot experiments give the work an applied anchor. The paper also gives explicit credit to prior work and includes a public video of the experiments. However, the formal gaps described below currently affect the central algorithmic claims and the quantitative evaluation, so the significance is contingent on those fixes.","major_comments":[{"comment":"Algorithm 1 is not well-defined as written. The variable minProgress is used at Lines 2-3 but is never initialized, so on the first tick min(minProgress, pi) is undefined unless an external convention is assumed. In addition, if no barrier b in B satisfies b > minProgress, which occurs for the baseline |B| = 0 used in Figures 1 and 3 and for any execution that has reached the largest barrier, current-barrier remains undefined and Lines 8-10 cannot be evaluated. The pseudocode should specify initialization and define the behavior when all barriers have been crossed.","section":"Section IV-A, Algorithm 1"},{"comment":"The synchronization semantics implicitly require monotone progress, but Definition 2 only states that p maps states into [0,1] and does not require monotonicity. For a non-monotonic progress function, a child that has crossed a barrier can later fall below it and be ticked again, contradicting the statement in Section IV-A that a node 'no longer receives ticks until all the other nodes... have the progress equal to or greater than the barrier.' The same issue affects Algorithm 2, where 'exceeds the minimum progress by Delta' is not a persistent condition if the minimum can regress. Experiment 3 deliberately uses a binary, non-monotonic progress signal, so the paper's own experimental scenario falls outside the regime where the stated semantics hold. The authors should either restrict the framework to monotone progress functions or redefine the synchronization condition to handle decreasing progress explicitly.","section":"Section IV, Definition 2"},{"comment":"The synthetic progress models in Eqs. (7)-(9) do not respect the codomain [0,1] imposed by Definition 2. With alpha values of 1, 2, and 5, the progress values exceed 1 after a single tick unless additional saturation or termination semantics are specified, and no such specification is given. Since the sensitivity analysis and Figures 1-3 are based on these equations, the quantitative conclusions are currently not supported by a valid progress model. The update rules need to be clamped or redefined so that p(x_k) always lies in [0,1].","section":"Section V-C, Eqs. (7)-(9)"},{"comment":"Definition 5 is not mathematically well-defined. The expression tk = argmin(p(x(tk)) - pbar) is missing a minimization domain and an absolute value; it should presumably be 'tk minimizes |p(x(tk)) - pbar| over the sampled time instants.' The set T_pbar is then described as a set of such time instances, but taking a mean of argmin results is not a standard operation, and the expected time tbar_k is not defined anywhere. Without a precise definition of T_pbar and tbar_k, Eq. (6) cannot be computed, which undermines the predictability experiments in Example 7, Experiment 4, and Figure 3.","section":"Section V-B, Definition 5"},{"comment":"The abstract and Section VI claim that the experiments yield 'statistically-significant data,' but no statistical test, p-value, confidence interval, or effect-size measure is reported. The boxplots in Figures 1-4 and 6-8 are descriptive only, so the significance claim is unsupported. The authors should either state the hypothesis being tested and report the corresponding test results, or soften the claim to 'descriptive statistics from repeated runs.'","section":"Section VI and abstract"}],"minor_comments":[{"comment":"Line 6 of Algorithm 2 contains a typo: 'minProgrees' should be 'minProgress'.","section":"Section IV-B, Algorithm 2"},{"comment":"The caption of Figure 5 says 'BT for Experiment 3,' but the figure and surrounding text describe Experiment 4 (Predictability). The caption should refer to Experiment 4.","section":"Section VI, Figure 5 caption"},{"comment":"The text says 'We observe worse performance with larger ¯ω and Δ' in the discussion of how the number of barriers affects predictability, but the experiment varies |B|, not Δ; the sentence should refer to the number of barriers.","section":"Section V-C.3"},{"comment":"There are several typos and grammatical slips, including 'Predictabity' in the Section IV-C heading, 'for we ran each experiment' in Section VI, and 'diaogues' in Section I. A careful proofreading pass is needed.","section":"Throughout"}],"recommendation":"major_revision","confidential_remarks":"The paper's own Related Work states that the relative synchronized node was already defined and theoretically validated in the authors' prior IROS 2018 paper [13]. The incremental contribution here appears to be the absolute node, the performance measures, and the experiments, and the manuscript should be read with that framing in mind. The formal issues in Definition 5 and the missing monotonicity assumption are substantial enough that I cannot recommend acceptance in the current form, but they appear fixable within the scope of a revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"What you should know: this is a legitimate incremental contribution to Behavior Tree concurrency. The absolute synchronized parallel node (Algorithm 1) is new, the relative node is carried over from the authors' IROS 2018 paper, and the two proposed measures (progress distance and predictability distance) are genuinely useful for thinking about design choices. The central idea is sound and the real-robot examples are easy to follow.\n\nWhat the paper does well: it gives a clear pseudocode formulation of both nodes, shows how an artificial reference action can impose a desired progress profile, and provides a sensitivity analysis plus several experiments. The observation that more barriers or a smaller Delta reduce progress distance is a direct consequence of the algorithms, but it is still worth stating quantitatively for designers. The R1 experiments are plausible and the video links help.\n\nSoft spots, in rough order of importance. First, Definition 2 does not require progress to be monotone, yet the prose around both algorithms says a node that has crossed a barrier or exceeded the minimum by Delta “no longer receives ticks.” As written, the algorithms use the current progress each tick, so a non-monotone progress function can cause a child to be ticked again after it drops below the barrier. For the binary perpetual-action experiment this is actually the desired behavior, but the text overstates the guarantee. That is a formal framing issue, not a fatal one. Second, Algorithm 1 has a real bug: minProgress is used before initialization, and the behavior when minProgress >= max(B) is undefined. Minor, but needs fixing. Third, the predictability distance in Definition 5 is ambiguous: argmin over what set, and what is the expected time t_k_bar? It needs a precise definition. Fourth, the paper claims “statistically-significant data” without any p-values, confidence intervals, or test names; 100 or 1000 runs are fine, but the claim is unsupported. Fifth, the novelty statement in Related Work overreaches—there is prior work on BT parallel composition and their own prior relative node.\n\nWho this is for: researchers working on Behavior Tree semantics, robotic task coordination, or predictable action execution. It deserves a serious peer review: the algorithms are simple but useful, and the issues are fixable. I would send it to review with a request to tighten the formal definitions, fix the pseudocode, and soften the statistical and novelty claims.","headline":"A solid, incremental BT-synchronization paper whose core ideas are usable, but it needs a cleaner formal definition, a fixed pseudocode bug, and weaker statistical claims.","tokens_in":11197,"tokens_out":3075,"would_cite":true,"duration_ms":36340,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper defines two synchronized parallel nodes for Behavior Trees—an absolute node with predefined progress barriers and a relative node with a threshold—and shows they reduce progress drift and improve execution predictability.","keywords":["Behavior Trees","parallel composition","concurrency","synchronization barriers","progress function","predictability","robot behavior control","progress distance"],"falsifier":"Run two actions whose progress is not monotonic, for example a re-grasp that must release and re-approach and therefore reports progress decreasing below a barrier already reached by the other child; if the measured progress distance (Eq. 5) with synchronization is not smaller than without it, or if the parallel node stalls permanently, the claim that these nodes reduce drift fails for that action class.","tokens_in":10168,"feed_emoji":"🤖","tokens_out":8112,"duration_ms":78610,"temperature":0.7,"pith_summary":"Behavior Trees compose robot behaviors by ticking sub-behaviors in a hierarchy, and parallel composition is attractive but rarely used because concurrent actions can race, drift, or conflict. This paper tries to make parallel composition usable by adding two synchronization control-flow nodes: an absolute node that holds all children at pre-set progress barriers until every child reaches that barrier, and a relative node that stops any child more than a threshold $\\Delta$ ahead of the slowest child. It claims these nodes reduce a defined progress distance between concurrently running actions, and that placing an artificial reference action inside an absolute node can impose a desired progress profile, improving the predictability of execution time. The intended payoff is a concrete mechanism for writing synchronized parallel robot behaviors without solving concurrency by hand, and for narrowing the gap between simulated and real robot execution.","feed_headline":"Two new nodes synchronize concurrent robot Behavior Tree actions","feed_subtitle":"Progress barriers stop fast children from racing ahead, shrinking drift and making execution time predictable","key_machinery":"The mechanism that carries the argument is the progress function $p:\\mathbb{R}^n\\to[0,1]$ (Definition 2), which maps the robot state to a measure of how far each child action has advanced. The absolute synchronized parallel node (Algorithm 1) uses a finite ordered set of progress barriers $B$, ticks only children whose progress has not passed the current barrier, and thereby converts a designer's barrier choices into enforced waiting points. The relative synchronized parallel node (Algorithm 2) replaces the barrier set with a single threshold $\\Delta$, holding back any child that is more than $\\Delta$ ahead of the minimum progress. A third device, the artificial reference action with a desired progress profile, is placed as a child of an absolute node to act as an upper bound that slower real actions must chase; since actions can only be stopped, not sped up, the reference must be an ideal upper bound. The performance measures in Eqs. (5) and (6) are what turn these node designs into quantitative claims about synchronization quality and predictability.","core_discovery":"The paper's central claim is that parallel Behavior Tree nodes can be made concurrency-safe by giving each child a progress value $p(x_k)\\in[0,1]$ (Definition 2) and using that value to stall ticks: a fast child is simply not ticked until the others catch up. Algorithm 1 implements absolute synchronization by keeping a pre-defined ordered set of barriers $B$, finding the smallest barrier below the current minimum progress, and ticking only children at or below that barrier; Algorithm 2 implements relative synchronization by ticking only children whose progress is at most $\\min_i p_i + \\Delta$ for a threshold $\\Delta\\in[0,1]$. The paper defines progress distance $\\pi(k_1,k_2)$ (Eq. 5) as the time-accumulated pairwise difference of child progress, and predictability distance $P(\\bar p)$ (Eq. 6) as the deviation between the time a desired progress $\\bar p$ is reached and the time it was expected. Its experiments on the R1 robot support the conclusion that more barriers and smaller $\\Delta$ reduce progress distance, and that an artificial reference action can make a real action follow an imposed straight-line or sigmoid progress profile.","pith_inferences":["If progress functions from different actions are measured in incompatible units, the pairwise comparisons in Eq. (5) require a normalization choice the paper does not address; defining per-action unit-aware progress or a learned rescaling would make the synchronization applicable across heterogeneous actuators.","The sensitivity analysis suggests an online tuning loop: adjust the barrier set $B$ or the threshold $\\Delta$ based on the observed covariance of progress noise, rather than fixing them a priori, to trade off progress distance against intermittent stalling.","The predictability result implies a direct test of sim-to-real transfer: measure the time at which a real action crosses each $\\bar p$ both with and without an artificial reference action; if the reference bounds the real progress, the predictability distance should shrink, which is a measurable claim the paper's experiments only partially exercise.","A weighted version of progress distance, giving more weight to safety-critical children, would let designers allow slack in unimportant actions while keeping critical motion tightly aligned; the current measure weights all children equally."],"forward_implications":["Larger barrier sets in an absolute node, and smaller thresholds $\\Delta$ in a relative node, tighten the progress distance between concurrently running actions, at the cost of a slower overall execution.","Because actions are only stopped, never accelerated, absolute synchronization can impose a desired progress profile only when the reference profile is an upper bound; the real action is held to match it.","The predictability measure $P(\\bar p)$ gives designers a numeric way to compare design choices, such as the number of barriers, before running on hardware.","Synchronization extends to perpetual actions by defining progress as a binary value (1 when a state error is within bounds, 0 otherwise), so a relative node can pause base motion while an arm realigns a cart.","In simulated-versus-real transfer, an artificial reference action can make a robot that is too fast wait, reducing the difference between simulated and real progress profiles."],"supporting_citations":[{"why":"Supplies the state-space Behavior Tree formulation and the safeguarding definition used to frame progress and safety.","marker":"[12]"},{"why":"Defines the progress function and the concurrent-BT setting that this paper's two synchronized nodes extend.","marker":"[13]"},{"why":"Introduces a motion-generator alternative for parallel actions sharing a state space, the main comparator for the proposed approach.","marker":"[14]"},{"why":"Provides the barrier-based synchronization concept that both nodes implement at the task level.","marker":"[23]"}],"fun_headline_variants":["Progress barriers tame parallel robot Behavior Trees","Stall fast children: new sync for Behavior Trees","Synchronized parallel BT nodes shrink execution drift","Absolute and relative sync for Behavior Tree concurrency","Predictable parallel actions with progress-stall nodes"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole construction assumes every action can report a reliable, comparable progress number in $[0,1]$ to its parent; if progress is missing, non-monotonic, or measured in units that cannot be compared across actions, the barrier calculations in both algorithms cannot run as specified.","fun_headline_variants_meta":{"raw":{"variants":["Progress barriers tame parallel robot Behavior Trees","Stall fast children: new sync for Behavior Trees","Synchronized parallel BT nodes shrink execution drift","Absolute and relative sync for Behavior Tree concurrency","Predictable parallel actions with progress-stall nodes"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000148,"raw_usage":{"total_tokens":1189,"prompt_tokens":943,"completion_tokens":246,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":559,"completion_tokens_details":{"reasoning_tokens":176}},"tokens_in":559,"tokens_out":246,"duration_ms":2904,"temperature":1.0,"reasoning_tokens":176,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T15:09:26.100153+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run two actions whose progress is not monotonic, for example a re-grasp that must release and re-approach and therefore reports progress decreasing below a barrier already reached by the other child; if the measured progress distance (Eq. 5) with synchronization is not smaller than without it, or if the parallel node stalls permanently, the claim that these nodes reduce drift fails for that action class.","supporting_citations":[{"cited_title":"Colledanchise and P","cited_arxiv_id":null,"evidence_quote":"Supplies the state-space Behavior Tree formulation and the safeguarding definition used to frame progress and safety."},{"cited_title":"Improving the Parallel Execution of Behavior Trees,","cited_arxiv_id":null,"evidence_quote":"Defines the progress function and the concurrent-BT setting that this paper's two synchronized nodes extend."},{"cited_title":"Motion Generators Combined with Behavior Trees: A Novel Ap- proach to Skill Modelling,","cited_arxiv_id":null,"evidence_quote":"Introduces a motion-generator alternative for parallel actions sharing a state space, the main comparator for the proposed approach."},{"cited_title":"Taubenfeld, Synchronization Algorithms and Concurrent Program- ming","cited_arxiv_id":null,"evidence_quote":"Provides the barrier-based synchronization concept that both nodes implement at the task level."}],"review_version":1}