An ARCore-Based Augmented Reality Campus Navigation System
Round 1
Reviewer 1 Report
I have previously reviewed the same paper and many comments made at that time are not addressed in this version.
- The choice of using ARCore should be justified. Why did the authors choose this SDK over other alternatives? For example, ARKit is much better (has more features) than ARCore.
- What are the features supported by the ARCore that the authors used in their system? What other features the authors implemented on their own to include in this system? The distinction should be made clear.
- Figure 9 shows many problems in its UI/UX. For example, colors of the real-world background and imposed AR are confusing. Why not use surface geometry detection and tracking provided by ARCore?
- This study only compares two scenarios of the proposed approach. What contributions this paper provides in the area of AR navigation? Any improvements or benefits over other previous AR navigation studies?
Author Response
Dear reviewer,
Thanks for your comment.
For response, please refer to the attached file.
Author Response File: 
Author Response.docx
Reviewer 2 Report
The article presents an interesting research. While it is interesting, sadly, it has some serious flaws. My main gripes are with its English, and incorrect statements (examples are below).
First of all, do not use "my", "you" or "you need" words. Use passive sentences. It would be more scientific.
Line 46: " (...) but the system is designed with fewer human-computer interaction, so the user experience is not good." What does fewer human-computer interaction mean exactly?
I believe a subsection is wrongly formatted in line 167.
Line 268: "ARcoreSDK can be applied to Android system without special hardware support." This is not entirely true. It requires an Android version of at least 7.0; and those phones that do not have the hardware requirements, cannot be updated to 7.0 (or later) correctly.
What are "rich human-computer interaction effects"? You mention these in line 355.
Line 362: "In this paper, the tracking red balls and buildings are all collision objects". In this paper, or in the application? It is not the same.
Line 467: "The second advantage is that the app takes unity as the development platform, (...)" The facts in the latter half of the sentence do not exist because of Unity. These are not Unity-specific advantages. These can be done in other "game engines" as well. These advantages are because the developers implemented them in the presented ARCore-based application.
To increase the scientific value of the paper, use statistical tests to search for differences in the data (subsection 6.2.). Are the results significantly different among groups? Do not forget to conduct normality analyses before using such tests.
Also, a few questions: how does the application superimpose the images? Are the outdoor images taken from e.g. Google Maps or are they self-made?
Author Response
Dear reviewer,
Thanks for your comment.
For response, please refer to the attached file.
Author Response File: Author Response.docx
Round 2
Reviewer 1 Report
I thank the authors for taking their time to improve the paper.
My previous questions are addressed adequately in the revised paper.
For clarification, the "Gaode" navigation system used in the comparison, should be concisely explained to give readers (besides Chinese readers) a sense of its capability. As a non-Chinese reader, I was not familiar with the Gaode system. The authors could make simple analogies to Google Maps or Apple Maps when explaining the capabilities of the Gaode system.
Author Response
Thank you for the comments. Please see the attached file for the response.
Author Response File: Author Response.docx
Reviewer 2 Report
The authors took the remarks into account, thus, the article improved considerably.
I have only one small remark left: between lines 539-544, the authors should indicate the exact p-values to see the significance/insignificance levels.
Author Response
Thank you for the comments. Please see the attached file for the response.
Author Response File: Author Response.docx
This manuscript is a resubmission of an earlier submission. The following is a list of the peer review reports and author responses from that submission.
Round 1
Reviewer 1 Report
I have several questions and comments about the presented work.
- Choice of using ARCore should be justified. Why did the authors chose this SDK over other alternatives?
- What are the features supported by the ARCore that the authors used in their system? What other features the authors implemented in their own to included in this system? The distinction should be made clear.
- Readability of Figure 5 should be improved. The authors may use this Figure to elaborate features of ARCore and authors' implementation.
- I don't see the need for including Figure 8. If there is a specific need, please elaborate.
- Figure 9 shows many problems in its UI/UX. For example, colors of the real-world background and imposed AR are confusing. Why not use surface geometry detection and tracking provided by ARCore?
- Please provide details of questionnaire. The details can be submitted as an appendix. I can't see how Likert rating scale results are converted to Figure 10 and Figure 11 results. Were there specific questions about each factors(efficient, usable, aesthetic?) How is 70.67% of Group A (Efficient) is scored?
- This study only compares two scenarios of the proposed approach. What contributions this paper provides in the area of AR navigation? Any improvements or benefits over other previous AR navigation studies?
Reviewer 2 Report
|
Comments to the article |
|
The abstract should contain more information from the conducted research. The information contained in point 3) regarding scalability was not covered in the article. |
|
I do not see any connection between the information contained in section 3.1 – mathematical formulas and what is described in subsection 3.2. If such links exist, they should be described better. Why is the term robot used? The navigation system created is to serve students. The terminology should be consistent. Please explain that. |
|
The chapter on testing navigation is poorly described. Much information is missing that should be included. There are no defined research goals. The questions of the survey were not clearly stated (they can be guessed by analysing the graph in Fig. 10 and Fig. 11). There were no tasks to be performed by the respondents. Not a single photo from the research is provided. There is no information on the timing of the task, or whether everyone has completed the task (if it was defined), etc. Thus the research methodology should definitely be improved. This is important if another research team wanted to conduct similar research by creating their own navigation, not only on the campus. |
|
Lack of information about the campus (size, number of facilities, vegetation, existing roads, paths, etc.). |
|
The description of the research in the library is not very representative as the library system is differently organised in other universities. In the case of conducting these studies, a little more information was provided, but still too little from the point of view of the research methodology. |
|
Providing percentage values with such accuracy is an error (Fig. 10), because with a group of 30 students we get a part of a student, which does not make sense. It is safer to enter raw data. And the applications used reasonably rounded percentages, e.g. over 70%, which looks much better and is correct. It is easy to calculate that 28 students from a group of 30 is 93.33%, 29 from a group of 30 is 96.66%, 27 from that group is 90%. I do not understand where the following values came from: 90.67; 93.67; 92.33; 94.33; 95.67. These comments also apply to Fig. 11 (there are other values there that should be checked). |
|
It is unclear how students could compare the AR system to another (traditional) system. Is it certain that they have used it? |
|
The authors use the term 'immersive', which in the literature on the subject is used for VR, not AR. Please explain this in the article. |
|
Not all of the statements in the Conclusions section are valid, they do not result from the conducted research, e.g. 1 and 2. |
|
Defining further research and application work is too general. |
|
Fig. 5 is not readable due to its quality, but also the connections between individual elements / levels are not clear. The levels are listed in the text but not logically shown in the diagram. The colour variation is not convincing and maybe even confusing. |
Reviewer 3 Report
This is an interesting work for combined outdoors and indoors navigation in campus sites using AR technology. It is based on the ARCore platform to provide route planning and localisation using the mobile phone odometer.
The related work section discusses other works in the area however it also ignores some of the literature about combined indoor and outdoor route planning ( e.g. 10.1007/978-3-642-24198-7_19, 10.3390/s18072100, 10.1109/ACCESS.2019.2955046, https://doi.org/10.1049/cp.2011.0795). The methodology is well presented in overall, although it can be improved by its review by a fluent English speaker. The testing section would also benefit by introducing an example of the system's ability for localisation along with a comparison with the baseline.
However the great flaw of the paper is that a quantitative evaluation of the methodology for the localisation is completely missing. Quantified experimental results are not presented at all, neither any kind of comparison with the established methods for localisation, not even with a baseline method. The only relevant mention in the paper is that "the application will track the user's location on the map very accurately", which is of course a quite arbitrary statement supported by no proof.
The qualititative evaluation results by themselves provide no evidence of the system's innovation, since they are not coupled with any quantified technical evaluation.
