Synchronization-based control for a collaborative robot

This article introduces a new control scheme for controlling a robotic manipulator in a collaborative task, allowing it to respond proactively to its partner’s movements. Unlike conventional robotic systems, humans can operate in an unstructured, dynamic environment due to their ability to anticipate changes before they occur and react accordingly. Recreating this artificially by using a forward model would lead to the huge computational task of simulating a world full of complex nonlinear dynamics and autonomous human agents. In this study, a controller based on anticipating synchronization, where a ‘leader’ dynamical system is predicted by a coupled ‘follower’ with delayed self-feedback, is used to modify a robot’s dynamical behaviour to follow that of a series of leaky integrators and harmonic oscillators. This allows the robot (follower) to be coupled with a collaborative partner (leader) to anticipate its movements, without a complete model of its behaviour. This is tested by tasking a simulated Baxter robot with performing a collaborative manual coordination task with an autonomous partner under a range of feedback delay conditions, confirming its ability to anticipate using oscillators instead of a detailed forward model.

The choice to use a simulated Baxter robot as a testbed is perplexing given the fact that Baxter arm appears to be reduced to a 2 DOF planar robot. The authors should discuss their choice (or limited ability) to utilize all available degrees of freedom.
It is odd to me that the paper concludes with discussion of this work's "potential" relevance to exoskeleton control when this is not what was examined in the paper, nor was it mentioned anywhere else. It should be moved to the introduction or discussion. Again, the authors should keep in mind that there is a whole body of literature of describing exoskeleton control (even using delayed output feedback -e.g., Lim et al., (2019) Delayed Output Feedback Control for Gait Assistance with a Robotic Hip Exoskeleton) and human adaptation to exoskeletal devices. The authors should again put their proposed method in the context of this prior research.

Are the interpretations and conclusions justified by the results? No
Is the language acceptable? Yes

Do you have any ethical concerns with this paper? No
Have you any concerns about statistical analyses in this paper? No

Recommendation?
Major revision is needed (please make suggestions in comments)

Comments to the Author(s)
This paper designs a controller to make a robot proactively collaborate with a human partner. This topic is important and the authors try to address a challenging problem of complicated master model. The reviewer appreciates the authors' attempt in this direction, but has several comments for the authors to address/explain: -The reviewer could not understand if the internal model is for the robot or the master. From figure 4, it seems the it is for the robot, but then how can you predict the master's target when using the slave's model? -Also in figure 4, why do you use the output of the internal model as the input of the controller u_{couple}? Why not use the target directly? -u_{couple} and u_{slave} only appear in figure 4, but are not explained in the main context. What do they correspond to in the equations, e.g. u? -The problem is formulated by considering d=0, then it becomes a trajectory tracking problem. Does this formulation make sense and if yes, can we apply any controller for trajectory tracking in the literature, which has been extensively studied? What's the challenge of trajectory tracking for human-robot collaboration? -The introduction needs to better reflect the state of the art in the field of Synchronisation-Based Control for a Collaborative Robot. Also other proactive controllers need to be compared in the experiment part, instead of just comparing with a PD controller.
-The system stability needs to be analysed in rigor instead of just explaining in text. This may also help the readers understand how the proposed method really works.
-The variables need to be explained and checked. For example, in equation 1 f is the master's dynamics but in 5 f is the slave's kinematics. For another example, how do you choose x_T in your experiment, in joint space? The reviewer encourages a resubmission, but with clear explanations to address the above comments.

Review form: Reviewer 3
Is the manuscript scientifically sound in its present form? Yes

Recommendation?
Accept with minor revision (please list in comments)

Comments to the Author(s)
This paper proposes a synchronization-based control paradigm for collaborative human-robot interactions. The method is interesting and of value to the community. Overall, the paper is well written and organized. However, several critical issues should be addressed before publication.  Fig.4 to Eq. 3 and Eq.5-6. None of the symbols in the figure are used in the equations. I suggest the authors simplify the notation and be consistent across the entire manuscript (including the fig). For example, functions f(.) and g(.) in Fig.4 are not equivalent to those in Eq.1-2, however, a reader could be easily confused. What do the C(err) in the controller blocks represent? Where does Eq. 3 live in Fig. 4? In Eq. 3 what is symbol v(t), velocity of the robot joints? How is Eq.3 a PD loop and is this K the same K in Fig.4 Can the author's elaborate on how accurate implementations of delay \tau was accomplished, given the asynchronous nature of ROS? E.g., in Fig.8 can you guarantee that the delay time remained 0.01 (or 0.2) for the extend of the 30 s trial? Some clarification is necessary in the following exert: "This means that anticipation/lag is relative to the time the master signal is received by the slave, rather than its 'transmission', and the output of the system is compared to the input that caused it." When the authors refer to "anticipation/lag" is that the parameter \tau? Or the cross correlation reported in the results? What is "transmission" in this context? The output of what? And input of what?
The trouble is that the master, slave controller, and robot all have an outputs, and the slave controller, and robot have inputs. I'd recommend a careful rewrite of the above exert.

Sect. 2.5
Why is Eq.7 a PD controller?
The equation states that the velocity command is proportional to the error term with delayed feedback. There is no derivative term. Isn't this just a proportional velocity controller?

Sect. 3
Additional clarification and rational is needed explain the use of the delayed feedback model as a comparison. Why do the authors compare AS to a controller which uses delayed feedback? In my understanding, AS uses delayed feedback in order to "anticipate" the reference signal, not because the signal itself is necessarily delayed (e.g., because of communication transmission, etc.). Thus, what is the value in comparing a delayed feedback control to AS?
In what scenario would robot pose be delayed? Why is this a "good" alternative to AS? If it is not, can you provide another model for comparison? (maybe PD controller without delay?) In the introduction the authors state "while classical control becomes unstable and fails if the feedback from the plant is delayed…", however this not an equal comparison to the AS approach since the delayed "feedback" in AS is actually beneficial and of a different nature.
Please clarify why/why not the comparison of AS to a delayed feedback system is warranted. 5. Generalizing the results on hardware would strength the paper. If this is not possible, please outline what are the necessary steps and challenges to realize the AS approach on hardware. E.g., sensing of the reference signal, physical coupling with human, etc. Minor: 1. "group of 'slave' oscillators" in the abstract, is misleading, just use "slave oscillators" 2. "over the range of 0 < t < 0:2 and K > 5." From Fig7.a when K=13 0 < \tau < 0.2 doesn't seem smooth to me. Fig. 3 would help conceptualize the coordinate system. 4. "This is preferable to using inverse kinematics because, in particular, the use of a Jacobianbased methods becomes difficult when information on the robot's pose is delayed, as in the scenario of this experiment." Isn't the "delay" leveraged to anticipate the master? Presumably accurate Jacobians could be computed, while simultaneously storing "delay" copies for AS? Can the authors comment on this.

A reference frame in
5. I would recommend succinctly outline the main contribution of this work in the final paragraph of the introduction. How is this work different than Ref.7? What is new?

19-Dec-2019
Dear Dr Eberle: Manuscript ID RSOS-191762 entitled "Synchronisation-Based Control for a Collaborative Robot" which you submitted to Royal Society Open Science, has been reviewed. The comments from reviewers are included at the bottom of this letter.
In view of the criticisms of the reviewers, the manuscript has been rejected in its current form. However, a new manuscript may be submitted which takes into consideration these comments.
Please note that resubmitting your manuscript does not guarantee eventual acceptance, and that your resubmission will be subject to peer review before a decision is made.
You will be unable to make your revisions on the originally submitted version of your manuscript. Instead, revise your manuscript and upload the files via your author centre.
Once you have revised your manuscript, go to https://mc.manuscriptcentral.com/rsos and login to your Author Center. Click on "Manuscripts with Decisions," and then click on "Create a Resubmission" located next to the manuscript number. Then, follow the steps for resubmitting your manuscript.
Your resubmitted manuscript should be submitted by 17-Jun-2020. If you are unable to submit by this date please contact the Editorial Office.
We look forward to receiving your resubmission. While the reviewers see merit in the article, they have provided a number of suggestions for revisions and raised a few critical issues.
Reviewer 1 suggests substantially expanding the introduction to better place this article in the context of the available literature. Two of the reviewers felt that it was hard for them to understand how the control flow was structured and how the figures related to the equations. In general, more complete information regarding the technical aspects and the models used (e.g., the oscillator to be tracked) should be provided. It may be good to outline why the task selected is a worthwhile goal in collaborative robotics, what the specific application context is: show how the proposed anticipatory tracking algorithm may perform when the human reacts to the robot motion as well, as reviewer 1 implicitly suggests.

Reviewers' Comments to Author:
Reviewer: 1 Comments to the Author(s) OVERALL In this paper, the authors are extending their work on predictive tracking controllers ("Anticipation from sensation: using anticipating synchronization to stabilize a system with inherent sensory delay") to applications in human-robot collaborative tasks. However, there are several shortcomings in their approach that make it difficult to see how the authors can meaningful transition this prior work to application. Moreover, the description of the controller is almost incomprehensible due to the lack of definition of the terms used.

GENERAL COMMENTS
The description of the controller is very hard to decipher. The block diagram presented in Figure  4 does not follow the typical notation. For instance, I assume that outputs of the "Plant" blocks in Figure 4 are q, not q_dot, but as written, the diagram conveys that q_dot is the output. I was able to rewrite the diagram and track the inputs and outputs, but I cannot definitively say that I know the input/output relationship of each block because the terms in the diagram of Figure 4 (1) do not match those found in the equations and (2) lack definitions. This section needs to be cleaned up.
The relevance of this control policy to human-robot physical collaboration is questionable. The fundamental challenge of human-robot collaboration is that the physical interaction is bidirectional. As the human acts upon the robot, the robot simultaneously acts on the human. In the model system tested, the simulated robot adapts to the simulated human, but the behavior of the simulated human is unaffected. The authors should be very explicit about this limitation and adjust their statements to downplay the relevance of this work human-robot physical interaction, unless it can be demonstrated otherwise.
Following the concern stated above, the authors describe the trajectory tracking task used in this study as being similar to "moving a piece of furniture, or operating one half of a saw" (e.g., page 4, lines 33-35). However, this is not quite true. In these tasks, a kinematic constraint is imposed. When two operators (be them humans or robots) are rigidly coupled through mutual object (also assumed to be rigid here), the distance between the operators' endpoints is always fixed. Because of this kinematic coupling, errors in the robot tracking will impact the behavior of the human (i.e., the master). Again, this is not accounted for in the presented model system. Hence, the authors should refrain from referring to this as a "sawing" task, but rather a rhythmic trajectory tracking task.
The authors should put their work in the context of other prior research on human robot physical interaction during collaborative tasks (e.g., see work by Luka Peternel). Otherwise, it is hard to see how this advances the state of the art of human-robot collaboration.
The statement that the results of the simulated experiments can be "generalized to the physical robot" (page 4, line 3) needs to be substantiated. The authors state that the "robot is replaced with an accurate dynamical model" (page 3, line 56), but given that all models are wrong, the authors should further elaborate on what it is and is not included in the dynamic Baxter model (e.g., motor dynamics, noise, etc.). As stated in the paper, AS "relies on the fact that a deterministic dynamical system's current state is strongly determined by its past" (page 1, lines 46-47). This begs the questions, would adding uncertainty in model or implementing this on hardware?
The advantage of using simulation over real hardware to test a wide range of coupling and delay terms is clear. However, the authors need to further demonstrate that their results in software translate onto real hardware. For instance, the authors should validate that the stable regions in parameter space observed in simulation are similar when implemented in hardware. And if they are not, the difference should be documented.
The choice to use a simulated Baxter robot as a testbed is perplexing given the fact that Baxter arm appears to be reduced to a 2 DOF planar robot. The authors should discuss their choice (or limited ability) to utilize all available degrees of freedom.
It is odd to me that the paper concludes with discussion of this work's "potential" relevance to exoskeleton control when this is not what was examined in the paper, nor was it mentioned anywhere else. It should be moved to the introduction or discussion. Again, the authors should keep in mind that there is a whole body of literature of describing exoskeleton control (even using delayed output feedback -e.g., Lim et al., (2019) Delayed Output Feedback Control for Gait Assistance with a Robotic Hip Exoskeleton) and human adaptation to exoskeletal devices. The authors should again put their proposed method in the context of this prior research.
Reviewer: 2 Comments to the Author(s) This paper designs a controller to make a robot proactively collaborate with a human partner. This topic is important and the authors try to address a challenging problem of complicated master model. The reviewer appreciates the authors' attempt in this direction, but has several comments for the authors to address/explain: -The reviewer could not understand if the internal model is for the robot or the master. From figure 4, it seems the it is for the robot, but then how can you predict the master's target when using the slave's model? -Also in figure 4, why do you use the output of the internal model as the input of the controller u_{couple}? Why not use the target directly? -u_{couple} and u_{slave} only appear in figure 4, but are not explained in the main context. What do they correspond to in the equations, e.g. u? -The problem is formulated by considering d=0, then it becomes a trajectory tracking problem. Does this formulation make sense and if yes, can we apply any controller for trajectory tracking in the literature, which has been extensively studied? What's the challenge of trajectory tracking for human-robot collaboration? -The introduction needs to better reflect the state of the art in the field of Synchronisation-Based Control for a Collaborative Robot. Also other proactive controllers need to be compared in the experiment part, instead of just comparing with a PD controller.
-The system stability needs to be analysed in rigor instead of just explaining in text. This may also help the readers understand how the proposed method really works.
-The variables need to be explained and checked. For example, in equation 1 f is the master's dynamics but in 5 f is the slave's kinematics. For another example, how do you choose x_T in your experiment, in joint space? The reviewer encourages a resubmission, but with clear explanations to address the above comments.
Reviewer: 3 Comments to the Author(s) This paper proposes a synchronization-based control paradigm for collaborative human-robot interactions. The method is interesting and of value to the community. Overall, the paper is well written and organized. However, several critical issues should be addressed before publication.  Fig.4 to Eq. 3 and Eq.5-6. None of the symbols in the figure are used in the equations. I suggest the authors simplify the notation and be consistent across the entire manuscript (including the fig). For example, functions f(.) and g(.) in Fig.4 are not equivalent to those in Eq.1-2, however, a reader could be easily confused. What do the C(err) in the controller blocks represent? Where does Eq. 3 live in Fig. 4? In Eq. 3 what is symbol v(t), velocity of the robot joints? How is Eq.3 a PD loop and is this K the same K in Fig.4? What is symbol B?

Sect. 2.4
Can the author's elaborate on how accurate implementations of delay \tau was accomplished, given the asynchronous nature of ROS? E.g., in Fig.8 can you guarantee that the delay time remained 0.01 (or 0.2) for the extend of the 30 s trial?
Some clarification is necessary in the following exert: "This means that anticipation/lag is relative to the time the master signal is received by the slave, rather than its 'transmission', and the output of the system is compared to the input that caused it." When the authors refer to "anticipation/lag" is that the parameter \tau? Or the cross correlation reported in the results? What is "transmission" in this context? The output of what? And input of what?
The trouble is that the master, slave controller, and robot all have an outputs, and the slave controller, and robot have inputs. I'd recommend a careful rewrite of the above exert.

Sect. 2.5
Why is Eq.7 a PD controller?
The equation states that the velocity command is proportional to the error term with delayed feedback. There is no derivative term. Isn't this just a proportional velocity controller?

Sect. 3
Additional clarification and rational is needed explain the use of the delayed feedback model as a comparison. Why do the authors compare AS to a controller which uses delayed feedback? In my understanding, AS uses delayed feedback in order to "anticipate" the reference signal, not because the signal itself is necessarily delayed (e.g., because of communication transmission, etc.). Thus, what is the value in comparing a delayed feedback control to AS?
In what scenario would robot pose be delayed? Why is this a "good" alternative to AS? If it is not, can you provide another model for comparison? (maybe PD controller without delay?) In the introduction the authors state "while classical control becomes unstable and fails if the feedback from the plant is delayed…", however this not an equal comparison to the AS approach since the delayed "feedback" in AS is actually beneficial and of a different nature.
Please clarify why/why not the comparison of AS to a delayed feedback system is warranted.
5. Generalizing the results on hardware would strength the paper. If this is not possible, please outline what are the necessary steps and challenges to realize the AS approach on hardware. E.g., sensing of the reference signal, physical coupling with human, etc. Minor: 1. "group of 'slave' oscillators" in the abstract, is misleading, just use "slave oscillators" 2. "over the range of 0 < t < 0:2 and K > 5." From Fig7.a when K=13 0 < \tau < 0.2 doesn't seem smooth to me. Fig. 3 would help conceptualize the coordinate system. 4. "This is preferable to using inverse kinematics because, in particular, the use of a Jacobianbased methods becomes difficult when information on the robot's pose is delayed, as in the scenario of this experiment." Isn't the "delay" leveraged to anticipate the master? Presumably accurate Jacobians could be computed, while simultaneously storing "delay" copies for AS? Can the authors comment on this.

Recommendation?
Major revision is needed (please make suggestions in comments)

Comments to the Author(s)
The reviewer appreciates the authors' effort to address some of my comments in the first round of review. Especially the authors have clearly discussed the importance of prediction of the master's movement to make the slave's action proactive. However, there are still some issues that need to be further addressed: -The major issue is how the internal models (5) and (6) provide prediction capabilities is not clear. The prediction is only shown by simulation results but why it works is not explained, e.g. using theoretical analysis.
-This work claims contributions to the field of human-robot collaboration, but the simulations do not include any kind of 'human'. Therefore, whether the internal models can be used to predict human movements is questionable.
- Figure 8 is a wrong figure, as it's not related to the caption.
-What is u in equation 5?

Comments to the Author(s)
The authors have adequately addressed my original concerns.

Decision letter (RSOS-201267.R0)
We hope you are keeping well at this difficult and unusual time. We continue to value your support of the journal in these challenging circumstances. If Royal Society Open Science can assist you at all, please don't hesitate to let us know at the email address below.

Dear Dr Eberle
The Editors assigned to your paper RSOS-201267 "Synchronisation-Based Control for a Collaborative Robot" have now received comments from reviewers and would like you to revise the paper in accordance with the reviewer comments and any comments from the Editors. Please note this decision does not guarantee eventual acceptance.
We invite you to respond to the comments supplied below and revise your manuscript. Below the referees' and Editors' comments (where applicable) we provide additional requirements. Final acceptance of your manuscript is dependent on these requirements being met. We provide guidance below to help you prepare your revision.
We do not generally allow multiple rounds of revision so we urge you to make every effort to fully address all of the comments at this stage. If deemed necessary by the Editors, your manuscript will be sent back to one or more of the original reviewers for assessment. If the original reviewers are not available, we may invite new reviewers.
Please submit your revised manuscript and required files (see below) no later than 21 days from today's (ie 22-Oct-2020) date. Note: the ScholarOne system will 'lock' if submission of the revision is attempted 21 or more days after the deadline. If you do not think you will be able to meet this deadline please contact the editorial office immediately.
Please note article processing charges apply to papers accepted for publication in Royal Society Open Science (https://royalsocietypublishing.org/rsos/charges). Charges will also apply to papers transferred to the journal from other Royal Society Publishing journals, as well as papers submitted as part of our collaboration with the Royal Society of Chemistry (https://royalsocietypublishing.org/rsos/chemistry). Fee waivers are available but must be requested when you submit your revision (https://royalsocietypublishing.org/rsos/waivers). The author has mostly addressed the reviewer concerns. One reviewer has additional concerns. which I encourage the authors to address, by providing additional clarifications, fixing the typos/omissions, providing appropriate caveats, and/or appropriately weakening the claims made.
I have another suggestion/concern with the use of the traditional robotic terminology, specifically, the "master and slave system". See, for instance, concerns below: https://en.wikipedia.org/wiki/Master/slave_(technology)#Terminology_concerns I would recommend that you consider either modifying the terminology or consider acknowledging the problematic aspects of the terminology in the article.

Reviewer comments to Author:
Reviewer: 2 Comments to the Author(s) The reviewer appreciates the authors' effort to address some of my comments in the first round of review. Especially the authors have clearly discussed the importance of prediction of the master's movement to make the slave's action proactive. However, there are still some issues that need to be further addressed: -The major issue is how the internal models (5) and (6) provide prediction capabilities is not clear. The prediction is only shown by simulation results but why it works is not explained, e.g. using theoretical analysis. -This work claims contributions to the field of human-robot collaboration, but the simulations do not include any kind of 'human'. Therefore, whether the internal models can be used to predict human movements is questionable.

===PREPARING YOUR MANUSCRIPT===
Your revised paper should include the changes requested by the referees and Editors of your manuscript. You should provide two versions of this manuscript and both versions must be provided in an editable format:<ul><li>one version identifying all the changes that have been made (for instance, in coloured highlight, in bold text, or tracked changes);</li><li>a 'clean' version of the new manuscript that incorporates the changes made, but does not highlight them. This version will be used for typesetting if your manuscript is accepted.</li></ul> Please ensure that any equations included in the paper are editable text and not embedded images.
Please ensure that you include an acknowledgements' section before your reference list/bibliography. This should acknowledge anyone who assisted with your work, but does not qualify as an author per the guidelines at https://royalsociety.org/journals/ethicspolicies/openness/.
While not essential, it will speed up the preparation of your manuscript proof if accepted if you format your references/bibliography in Vancouver style (please see https://royalsociety.org/journals/authors/author-guidelines/#formatting). You should include DOIs for as many of the references as possible.
If you have been asked to revise the written English in your submission as a condition of publication, you must do so, and you are expected to provide evidence that you have received language editing support. The journal would prefer that you use a professional language editing service and provide a certificate of editing, but a signed letter from a colleague who is a native speaker of English is acceptable. Note the journal has arranged a number of discounts for authors using professional language editing services (https://royalsociety.org/journals/authors/benefits/language-editing/).

===PREPARING YOUR REVISION IN SCHOLARONE===
To revise your manuscript, log into https://mc.manuscriptcentral.com/rsos and enter your Author Centre -this may be accessed by clicking on "Author" in the dark toolbar at the top of the page (just below the journal name). You will find your manuscript listed under "Manuscripts with Decisions". Under "Actions", click on "Create a Revision".
Attach your point-by-point response to referees and Editors at Step 1 'View and respond to decision letter'. This document should be uploaded in an editable file type (.doc or .docx are preferred). This is essential.
Please ensure that you include a summary of your paper at Step 2 'Type, Title, & Abstract'. This should be no more than 100 words to explain to a non-scientific audience the key findings of your research. This will be included in a weekly highlights email circulated by the Royal Society press office to national UK, international, and scientific news outlets to promote your work.

At
Step 3 'File upload' you should include the following files: --Your revised manuscript in editable file format (.doc, .docx, or .tex preferred). You should upload two versions: 1) One version identifying all the changes that have been made (for instance, in coloured highlight, in bold text, or tracked changes); 2) A 'clean' version of the new manuscript that incorporates the changes made, but does not highlight them. --If you are requesting a discretionary waiver for the article processing charge, the waiver form must be included at this step.
--If you are providing image files for potential cover images, please upload these at this step, and inform the editorial office you have done so. You must hold the copyright to any image provided.
--A copy of your point-by-point response to referees and Editors. This will expedite the preparation of your proof.

At
Step 6 'Details & comments', you should review and respond to the queries on the electronic submission form. In particular, we would ask that you do the following: --Ensure that your data access statement meets the requirements at https://royalsociety.org/journals/authors/author-guidelines/#data. You should ensure that you cite the dataset in your reference list. If you have deposited data etc in the Dryad repository, please include both the 'For publication' link and 'For review' link at this stage.
--If you are requesting an article processing charge waiver, you must select the relevant waiver option (if requesting a discretionary waiver, the form should have been uploaded at Step 3 'File upload' above).
--If you have uploaded ESM files, please ensure you follow the guidance at https://royalsociety.org/journals/authors/author-guidelines/#supplementary-material to include a suitable title and informative caption. An example of appropriate titling and captioning may be found at https://figshare.com/articles/Table_S2_from_Is_there_a_trade-off_between_peak_performance_and_performance_breadth_across_temperatures_for_aerobic_sc ope_in_teleost_fishes_/3843624.

At
Step 7 'Review & submit', you must view the PDF proof of the manuscript before you will be able to submit the revision. Note: if any parts of the electronic submission form have not been completed, these will be noted by red message boxes. We hope you are keeping well at this difficult and unusual time. We continue to value your 1. The description of the controller is very hard to decipher. The block diagram presented in Figure  4 does not follow the typical notation. For instance, I assume that outputs of the "Plant" blocks in Figure 4 are q, not q_dot, but as written, the diagram conveys that q_dot is the output. I was able to rewrite the diagram and track the inputs and outputs, but I cannot definitively say that I know the input/output relationship of each block because the terms in the diagram of Figure 4 (1) do not match those found in the equations and (2) lack definitions. This section needs to be cleaned up.
We have redesigned the block diagram to be more visually readable, and made sure its symbols and terms are consistent with the text. [Page 6] 2. The relevance of this control policy to human-robot physical collaboration is questionable. The fundamental challenge of human-robot collaboration is that the physical interaction is bidirectional. As the human acts upon the robot, the robot simultaneously acts on the human. In the model system tested, the simulated robot adapts to the simulated human, but the behavior of the simulated human is unaffected. The authors should be very explicit about this limitation and adjust their statements to downplay the relevance of this work human-robot physical interaction, unless it can be demonstrated otherwise.
In human-human interaction the physical interaction constitutes a form of tacit communication because both agents can reason about the other's intentions. Rather than attempt to simulate this communication, which would require a specialised platform to sense the human's movements, we aimed to make the robot's behaviour as predictable as possible. Hence, a control framework where the robot behaves in the same way as if it is reacting to the user, but with a much smaller latency than would be possible without anticipation. Within the limited context of the chosen task the correct response is always to maintain constant distance from the partner, and as long as the anticipation is robust to varied input, it can be considered successful. We have clarified that this study pertains to this specific circumstance, and not the wider problem of human-robot cooperation.
"The experimental can be tailored to the intrinsic timescale and capabilities of the Baxter platform: a back-and-forth coordinated motion in which the robot must follow a moving target representing its partner without lagging or becoming unstable. This simulates the timing aspect of bimanual handling (e.g. moving one end of a piece of furniture) without mutual physical interaction that would require a specialised platform to investigate. "[Page 3, paragraph 5] 3. Following the concern stated above, the authors describe the trajectory tracking task used in this study as being similar to "moving a piece of furniture, or operating one half of a saw" (e.g., page 4, lines 33-35). However, this is not quite true. In these tasks, a kinematic constraint is imposed. When two operators (be them humans or robots) are rigidly coupled through mutual object (also assumed to be rigid here), the distance between the operators' endpoints is always fixed. Because of this kinematic coupling, errors in the robot tracking will impact the behavior of the human (i.e., the master). Again, this is not accounted for in the presented model system. Hence, the authors should refrain from referring to this as a "sawing" task, but rather a rhythmic trajectory tracking task.
We agree that this is a reasonable criticism, and have replaced all references to 'sawing'.

The authors should put their work in the context of other prior research on human robot physical interaction during collaborative tasks (e.g., see work by Luka Peternel). Otherwise, it is hard to see how this advances the state of the art of human-robot collaboration.
We have added additional citations to the introduction and included more explanation of how we believe this work fits into the context of the field.
"A common approach is to attempt to infer the human partner's intentions from their behaviour so that the robot can 'preempt' their future actions. However, while many stereotypical human movements are well characterised (such as simple reaching motions, by the minimum-jerk model [1]), there is no accepted complete model of human behaviour. Various methods have been used to work around this limitation, such as in work by Thobbi  5. The statement that the results of the simulated experiments can be "generalized to the physical robot" (page 4, line 3) needs to be substantiated. The authors state that the "robot is replaced with an accurate dynamical model" (page 3, line 56), but given that all models are wrong, the authors should further elaborate on what it is and is not included in the dynamic Baxter model (e.g., motor dynamics, noise, etc.). As stated in the paper, AS "relies on the fact that a deterministic dynamical system's current state is strongly determined by its past" (page 1, lines 46-47). This begs the questions, would adding uncertainty in model or implementing this on hardware?
The simulator encompasses the robot's kinematics, dynamics and the real-time control loop that implements its safety constraints. Given that the simulator was designed by the robot's manufacturers for the express purpose of allowing users to develop control schemes that would generalise onto the physical robot, we believe this is a reasonable assumption. If the uncertainty in the model was large enough that its controllability was significantly reduced this would have an effect. The model does not encompass noise), but neither did the robot exhibit a level of noise large enough for this to represent a qualitative difference.
"During the testing phase, in order to evaluate the control under an appropriate range of conditions within a reasonable time, and without risking wear-and-tear to the robot's components, the motion of the robot can be simulated by an accurate dynamical model, simulated in Gazebo [18] (see Fig.2). This replicates all of Baxter's software interfaces as well as its characteristic dynamical behaviour, allowing the results of the simulated experiments to be generalised to the physical robot [22]" [Page 4, paragraph 2] 6. The advantage of using simulation over real hardware to test a wide range of coupling and delay terms is clear. However, the authors need to further demonstrate that their results in software translate onto real hardware. For instance, the authors should validate that the stable regions in parameter space observed in simulation are similar when implemented in hardware. And if they are not, the difference should be documented.
Due to the limited availability of the robot, the system was prototyped in hardware, then moved into simulation for in-depth testing. The differences between hardware and software are a valid concern, but we are confident that the simulation encompasses all the salient features that significantly influence the results. We hope that our clarifications about the simulation in our other responses address this concern.
7. The choice to use a simulated Baxter robot as a testbed is perplexing given the fact that Baxter arm appears to be reduced to a 2 DOF planar robot. The authors should discuss their choice (or limited ability) to utilize all available degrees of freedom.
The primary reason for using the Baxter robot was that its series elastic actuators gave it a more complex dynamical behaviour than a standard manipulator arm. While our preference would have been for a simpler robot with these properties, at the time we did not have the option of building or acquiring one, and making use of the additional degrees of freedom added little to the experiment (in our opinion).
"Rather than creating a special-purpose robot that could call into question the broader applicability of this study, the Baxter collaborative robot was chosen as a testing model. Baxter's hardware and software safety features provide a reasonable estimate of the constraints which a collaborative control rule can be expected to have, and it has a high-quality simulator that can be used for repeated experiments [16]. The experimental can be tailored to the intrinsic timescale and capabilities of the Baxter platform: a back-and-forth coordinated motion in which the robot must follow a moving target representing its partner without lagging or becoming unstable. This simulates the timing aspect of bimanual handling (e.g. moving one end of a piece of furniture) without mutual physical interaction that would require a specialised platform to investigate." [Page 2, paragraph 5] 8. It is odd to me that the paper concludes with discussion of this work's "potential" relevance to exoskeleton control when this is not what was examined in the paper, nor was it mentioned anywhere else. It should be moved to the introduction or discussion. Again, the authors should keep in mind that there is a whole body of literature of describing exoskeleton control (even using delayed output feedback -e.g., Lim et al., (2019) Delayed Output Feedback Control for Gait Assistance with a Robotic Hip Exoskeleton) and human adaptation to exoskeletal devices. The authors should again put their proposed method in the context of this prior research.
In light of the changes made due to the other comments in this review, we felt it more sense to remove this theme from the conclusion.