IoRT-Based Middleware for Heterogeneous Multi-Robot Systems

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The submitted paper proposes an IoRT (Internet of Robotic Things)-based middleware designed for heterogeneous multi-robot systems.

This middleware is intended to facilitate smooth communication among robots operating on different operating systems and hardware platforms, thereby supporting effective real-time collaboration across diverse robotic systems.

However, several limitations in the proposed approach are noted.

1. Communication speed is dependent on each robot’s hardware specifications, with delays particularly affecting robots with lower processing capabilities.

2. The reliance on a stable internet connection for cloud-based control modes poses potential challenges for real-time operations, as network disruptions could impact task execution.

To address these concerns, I suggest the following potential improvements.

1. Consider implementing additional optimization measures to mitigate the impact of hardware performance disparities across robots on overall system performance.

2. To minimize the impact of network outages on real-time applications, it may be beneficial to include features that can be executed locally.

These adjustments could enhance the robustness and scalability of the middleware across a range of operational environments.

Author Response

We are very grateful for the comments and suggestions of reviewers that help us improve our research and work.

Comment 1: 

However, several limitations in the proposed approach are noted.

1. Communication speed is dependent on each robot’s hardware specifications, with delays particularly affecting robots with lower processing capabilities.
2. The reliance on a stable internet connection for cloud-based control modes poses potential challenges for real-time operations, as network disruptions could impact task execution.

To address these concerns, I suggest the following potential improvements.

1. Consider implementing additional optimization measures to mitigate the impact of hardware performance disparities across robots on overall system performance.
2. To minimize the impact of network outages on real-time applications, it may be beneficial to include features that can be executed locally.

These adjustments could enhance the robustness and scalability of the middleware across a range of operational environments.

 

Authors’ response: We appreciate these comments and suggestions. 

As we explain in Section 5.2 (related to Figure 11), we have pointed out that the communication overhead depends on the robot's hardware specifications and processing capabilities.  Actually, we currently consider local and remote storage of the data shared among robots to allow local processing in the case the remote access to the Server Cloud is not possible or can incur in high overhead (Section 4. Middleware Implementation and Section 5.1). We plan as future work, not only to incorporate additional measures to detect the aspects that impact the most in the communication overhead, but to integrate additional strategies to mitigate such an impact by considering the real status of the whole system. We appreciate your suggestions to improve our system, and we will consider them as future work.

Authors’ action: To consider the suggestions, we have added more explanation to clarify these aspects in the abstract, introduction, and Section 5.1 and explicitly indicated in Section Conclusions the future plan to improve our system. 

 

Reviewer 2 Report

Comments and Suggestions for Authors

The paper presents the development of a middleware for the communication of heterogenous multi-robot systems.

The paper addresses a highly relevant problem, namely the crucial challenge of interoperability and communication in heterogeneous multi-robot systems. The paper is well-structured and well explained.

Nevertheless, there are a few limitations:

-        Paper novelty is not well understood or defined. The paper’s contribution is related to the implementation and integration of the commercially available components. Please try to increase the unique aspects of the research.

-        Although the paper mentions several existing solutions, a detailed comparative analysis is not provided, which again negatively influences the overall quality of the paper.

-        It would be nice if the author could provide a short discussion regarding the scalability potential of the proposed middleware.

Minor issues:

The figures text is unreadable

Figure 3 might need a reference

Sub-section 5.1 (the robot description) is not entirely needed. Too many known details are presented. A reference would suffice and would be required.

Comments on the Quality of English Language

English should be improved. Some examples:

There exist

Another studies

Once the communication between the client and the Server has been established, the  program requests the client’s IP and connection port, and then receives the messaging package containing the client’s query. Then, the message is decoded and analyzed to determine if it is a request that meets the characteristics of the communication protocol created. If the received package does not comply with the protocol, it may be that the client is sending a disconnect message, so the Server must close the connection with the client, but if is not, that package is only discarded, for example, a bad package delivered due to the network.

Author Response

We are very grateful for the comments and suggestions of reviewers that help us improve our research and work.

Comment 1:  Paper novelty is not well understood or defined. The paper’s contribution is related to the implementation and integration of the commercially available components. Please try to increase the unique aspects of the research.

Authors’ response: We appreciate these comments and suggestions. We agree to emphasize the contribution to point out the novelty.

Authors’ action: To clarify the contribution of this research we have modified the abstract and introduction.

Comment 2: Although the paper mentions several existing solutions, a detailed comparative analysis is not provided, which again negatively influences the overall quality of the paper.

Authors’ response: We appreciate these comments and suggestions. We agree to add a comparative analysis.

Authors’ action: We have added a comparative table (Table 2) in Section 3 (Related Work) to highlight the differences of existing studies compared with our solution.

Comment 3: It would be nice if the author could provide a short discussion regarding the scalability potential of the proposed middleware.

Authors’ response: We appreciate these comments and suggestions. We agree to improve this discussion.

Authors’ action: We have added a new section called General Discussion, in which we present insights regarding several aspects of our solution, including the scalability potential.

Comment 4: Minor issues:

The figures text is unreadable

Authors’ response: We appreciate these comments and suggestions. 

Authors’ action: We have changed the font size in all figures.

Comment 5: Figure 3 might need a reference

Authors’ response: We appreciate these comments and suggestions. 

Authors’ action: We have added the corresponding reference in the title of Figure 3 (Section 2).

Comment 6: Sub-section 5.1 (the robot description) is not entirely needed. Too many known details are presented. A reference would suffice and would be required.

Authors’ response: We appreciate these comments and suggestions.  However, we consider that robots’ characteristics regarding the sensing capacity are important to mention, since all of them represent a topic in the system and show the heterogeneity supported by the middleware. 

Authors’ action: We did not eliminate the detailed description but we summarized some of the aspects. We have eliminated the aspects related to the shape of the robots and only kept the characteristics related to their sensing capacity.

Comment 7: Comments on the Quality of English Language 

English should be improved. Some examples:

• There exist
• Another studies
• Once the communication between the client and the Server has been established, the  program requests the client’s IP and connection port, and then receives the messaging package containing the client’s query. Then, the message is decoded and analyzed to determine if it is a request that meets the characteristics of the communication protocol created. If the received package does not comply with the protocol, it may be that the client is sending a disconnect message, so the Server must close the connection with the client, but if is not, that package is only discarded, for example, a bad package delivered due to the network.

Authors’ response: We appreciate these comments and suggestions.  

Authors’ action: We have performed a deep-proofreading to improve the writing style and  correct these grammar errors and other typos in the whole manuscript.

Reviewer 3 Report

Comments and Suggestions for Authors

1.     Many abbreviations are used without providing a definition, consider adding abbreviation table or add abbreviation next to the first appearance of abbreviations.

2.     Figure 11, 12 and 13 all display measurement results but figure 13 has a different color palette. Consider using the same palette to make paper more homogenous and improve readability.

3.     Section 5, application case, doesn’t provide any real-world example of how the heterogenous robotic system will be implemented in urban tourism.

4.     While tests that conducted in section 5.2 are well documented, no data or tests about the intercommunication and data sharing between the robots is described. Since paper aims to showcase Middleware as a tool for IoTR, data sharing between robots should be one of the main areas of testing. Regarding lines 466-474 communication between different robotic systems is only implied and not shown. Consider adjusting conclusions based on the actual provided test results.

5.     It is suggested that the use and review of works similar to the following ones could be beneficial for the authors:

a.     Lee, K. D., Lee, B. H., & Ko, M. S. (1995).’ A comparison of interconnection methods for multi-robot systems’. Control Engineering Practice, 3(3), 337-346. Available at: https://doi.org/10.1016/0967-0661(95)00005-F

 

b.     Stavropoulos, P., Alexopoulos, K., Makris, S., Papacharalampopoulos, A., Dhondt, S., & Chryssolouris, G. (2024). ‘AI in manufacturing and the role of humans: Processes, robots, and systems’. In Handbook of Artificial Intelligence at Work (pp. 119-141). Edward Elgar Publishing. Available at: https://doi.org/10.4337/9781800889972.00015

Author Response

We are very grateful for the comments and suggestions of reviewers that help us improve our research and work.

Comment 1: Many abbreviations are used without providing a definition, consider adding abbreviation table or add abbreviation next to the first appearance of abbreviations.

Authors’ response: We appreciate these comments and suggestions.  

Authors’ action: We have reviewed the whole manuscript to add the extension of each acronyms and abbreviation used in the paper. Now all of them have their definition the first time they appear.

Comment 2:  Figure 11, 12 and 13 all display measurement results but figure 13 has a different color palette. Consider using the same palette to make paper more homogenous and improve readability.

Authors’ response: We appreciate these comments and suggestions.  

Authors’ action: We have changed the color palette of the three figures to have the same colors  on all of them.

Comment 3: Section 5, application case, doesn’t provide any real-world example of how the heterogenous robotic system will be implemented in urban tourism.

Authors’ response: We appreciate these comments and suggestions. Since the current implementation of the middleware is a proof-of-concept, we performed simple tests that show the feasibility and potential benefits of its deployment as the core for the RUTAS project. We have added examples of how   the heterogeneous robotic system will be implemented in urban tourism in the RUTAS project.

Authors’ action: We have added a new section called General Discussion, in which we present insights regarding several aspects of our solution, including examples of how   the heterogeneous robotic system will be implemented in urban tourism in the RUTAS project. 

Comment 4: While tests that conducted in section 5.2 are well documented, no data or tests about the intercommunication and data sharing between the robots is described. Since paper aims to showcase Middleware as a tool for IoTR, data sharing between robots should be one of the main areas of testing. Regarding lines 466-474 communication between different robotic systems is only implied and not shown. Consider adjusting conclusions based on the actual provided test results.

Authors’ response: We appreciate these comments and suggestions.  We intended to show this aspect in Section 5.2, Table 4, Figure 10. However, we agree to add more examples to clarify how the data sharing is performed.

Authors’ action: We enlarged Figure 10 to let readers appreciate the messages exchanged in each case. We also added more explanation and examples about the messages shown in Figure 10 in Section 5.2.

Comment 5:  It is suggested that the use and review of works similar to the following ones could be beneficial for the authors:

Lee, K. D., Lee, B. H., & Ko, M. S. (1995).’ A comparison of interconnection methods for multi-robot systems’. Control Engineering Practice, 3(3), 337-346. Available at: https://doi.org/10.1016/0967-0661(95)00005-F

 Stavropoulos, P., Alexopoulos, K., Makris, S., Papacharalampopoulos, A., Dhondt, S., & Chryssolouris, G. (2024). ‘AI in manufacturing and the role of humans: Processes, robots, and systems’. In Handbook of Artificial Intelligence at Work (pp. 119-141). Edward Elgar Publishing. Available at: https://doi.org/10.4337/9781800889972.00015

Authors’ response: We appreciate these suggestions. We do not have access to the first paper, so we could not verify the appropriateness to include it in our research. The second one is not directly related to our research, but  we can cite it in the introduction as a reference of Industry 4.0.

Authors’ response: We have added the second reference in the first paragraph of  the introduction.

Round 2

Reviewer 2 Report

Comments and Suggestions for Authors

The authors have improved the paper according to the indicated issues and comments, so the paper can be published 

Reviewer 3 Report

Comments and Suggestions for Authors

The comments have been addressed and the paper can be accepted.