Review Reports

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The authors report a performance comparison of two mapping software tools intended for robotic applications in a unified environment.

Advantages of the article:

1. A thorough literature review.

2. A unified test environment.

3. Clear description of test procedures.

Disadvantages of the article:

1. The header of Table 3 is separated from the body.

2. Figures 1–2: the text on the figures is completely unreadable.

3. The caption of Figure 5 is cut off from the figure body.

4. Figure 8 is truncated.

 

Author Response

Comment 1: The header of Table 3 is separated from the body.

Response 1: We thank the reviewer for pointing out this formatting issue.

The title of Table 3 has been corrected to follow the MDPI formatting guidelines, and it is now properly aligned and positioned directly above the table body.

Comment 2: Figures 1–2: the text on the figures is completely unreadable.

Response 2: The captions and embedded labels in Figures 1 and 2 have been fully revised.

Both figures were re-exported at 300 DPI, and all text elements were enhanced to ensure complete readability.

The updated figures now comply with the journal’s resolution and clarity standards.

Comment 3: The caption of Figure 5 is cut off from the figure body.

Response 3: The caption of Figure 5 has been repositioned and reformatted according to MDPI’s figure style rules.

The earlier cropping issue has been resolved, and the figure is now correctly displayed with its full caption intact.

Comment 4: Figure 8 is truncated.  

Response 4: Figure 8 has been replaced with a high-resolution (300 DPI) version.

The TF-tree visualization is now fully visible, with no cropped edges or missing labels.

Its formatting and placement have also been corrected to fit the journal layout requirements.

Reviewer 2 Report

Comments and Suggestions for Authors

The manuscript addresses a relevant and practical topic in robotics, i.e. the comparative evaluation of SLAM Toolbox and Cartographer within ROS 2 environments. The focus on both simulated and real-world scenarios is commendable, as it provides a broader perspective on the applicability of these tools. The paper demonstrates awareness of current technologies and offers insights that could be useful for practitioners seeking guidance on SLAM solutions for autonomous navigation. The inclusion of ROS 2 Humble Hawksbill and integration with Gazebo simulation reflects an up-to-date approach aligned with modern robotic frameworks.

My Remarks:

1. Title. The phrase “Efficient Mapping Solutions” sounds overly general and somewhat promotional. In technical publications, it is better to specify what aspect of efficiency is addressed (e.g., computational efficiency, mapping accuracy).
2. Abstract:
• The abstract is descriptive but lacks quantitative results, which are essential in comparative studies. Include key metrics.
• The term “dynamic environments” is vague, clarify what dynamic elements were present (moving obstacles? changing lighting?).
• The statement that “SLAM Toolbox produces more stable and accurate maps” is too strong without specifying the scope and conditions of tests.
3. Current keywords are partially relevant but inconsistent. For example, Extended Kalman Filter does not appear in the abstract and seems forced. More appropriate keywords would include e.g. SLAM Toolbox, Cartographer, mapping performance, autonomous robots, LiDAR mapping. Terms like transform frames and URDF are too technical and marginal for the main comparison.
4. Ensure compliance with Electronics guidelines (section structure, table format, figure captions). Currently, tables and captions do not follow the journal’s style.
5. Introduction:
• Mathematical content (lines 52–61) should not appear in the Introduction, it mixes background with technical details.
• The sentence “This study aims to address this gap…” (line 65) should immediately follow the identified gap for better logical flow. The introduction needs restructuring for clarity.
6. Tables and Figures:
• Table titles are verbose and not aligned with journal standards (e.g., Table 3 title is too long and descriptive).
• Figures with identical captions (“Robot mechanical simulation with Gazebo”) are confusing. Captions should be unique and informative.
• Sub-subsections should be numbered.
7. The choice of environments (e.g., Gazebo world) is poorly justified. Explain why these environments were selected and what capabilities they offer. Similarly, justify the choice of sensor fusion architecture and EKF, currently, these decisions appear arbitrary.
8. Analysis and Interpretation:
• Statements like “SLAM Toolbox demonstrated superior odometry integration” are too strong given that comparisons seem based mainly on visual inspection of maps. Provide quantitative evidence or soften the language.
9. Formatting and Style:
• Inconsistent formatting (fonts, alignment, references).
• Captions are vague and do not aid interpretation.
• Figures 9, 10, and 15 have poor quality.
10. Overall, the manuscript is difficult to follow. The narrative lacks clarity, and technical details are scattered. A thorough editorial revision is needed to improve flow and readability.

To summarize, the topic is relevant, and the comparative approach is valuable, but the manuscript requires substantial improvements in structure, clarity, and scientific rigor. But once my remarks are addressed, the paper could make a quite meaningful contribution to the field.

Author Response

Comment 1: Title. The phrase “Efficient Mapping Solutions” sounds overly general and somewhat promotional. In technical publications, it is better to specify what aspect of efficiency is addressed (e.g., computational efficiency, mapping accuracy).

Response 1: We fully agree with the reviewer’s observation. Accordingly, the title has been revised to reflect the technical scope of the study more precisely. The term “Efficient Mapping Solutions” has been removed due to its general and non-technical tone. It was replaced with “Comparative Performance Analysis”, which clearly expresses the analytical and quantitative nature of the research, emphasizing the performance-focused evaluation of SLAM Toolbox and Cartographer.

The revised title now accurately represents the study’s methodology and avoids any promotional ambiguity.

Revised Title:

“From Simulation to Reality: Comparative Performance Analysis of SLAM Toolbox and Cartographer in ROS 2” 

Comment 2: Abstract:

The abstract is descriptive but lacks quantitative results, which are essential in comparative studies. Include key metrics.

The term “dynamic environments” is vague, clarify what dynamic elements were present (moving obstacles? changing lighting?).

The statement that “SLAM Toolbox produces more stable and accurate maps” is too strong without specifying the scope and conditions of tests.

Response 2: We thank the reviewer for the helpful comments. The abstract has been extensively revised to address these concerns:

Quantitative performance metrics have been added, including Absolute Trajectory Error (0.13 m vs. 0.21 m), CPU usage (70% vs. 80%), RAM consumption, and startup times.

The phrase “dynamic environments” has been clarified as “indoor environments involving human movement and small object relocations”.

The previous strong claim was softened. “More accurate and stable” has been rewritten as “slightly more consistent map generation under the tested indoor conditions” and contextualized with explicit details about the experimental setup.

The experimental conditions—Gazebo simulation, real indoor tests, and identical robot hardware—have been explicitly stated.

These revisions ensure improved clarity, precision, and scientific neutrality in the abstract. 

Comment 3: Current keywords are partially relevant but inconsistent. For example, Extended Kalman Filter does not appear in the abstract and seems forced. More appropriate keywords would include e.g. SLAM Toolbox, Cartographer, mapping performance, autonomous robots, LiDAR mapping. Terms like transform frames and URDF are too technical and marginal for the main comparison.

Response 3: We thank the reviewer for the insightful observation. The keywords have been fully revised to ensure consistency with the abstract and the main contribution of the study. Specifically:

“Extended Kalman Filter,” “TF frames,” and “URDF” have been removed, as they are overly technical and not representative of the core comparative analysis.

The revised list now includes Cartographer, LiDAR mapping, mapping performance, real-time mapping, ROS 2, and SLAM Toolbox which accurately reflect the focus of the manuscript.

The new keyword set is now fully aligned with the abstract, methodology, and experimental results, improving both clarity and indexing relevance.

These revisions address the reviewer’s concerns and enhance the overall coherence of the manuscript.

Comment 4: Ensure compliance with Electronics guidelines (section structure, table format, figure captions). Currently, tables and captions do not follow the journal’s style.

Response 4: We thank the reviewer for the valuable feedback. The manuscript has been thoroughly revised to comply with the Electronics journal formatting guidelines:

All table titles were rewritten to be concise, single-sentence, and placed above the tables following MDPI formatting rules.

All figure captions were rewritten to ensure uniqueness, clarity, and consistency. Repetitive titles such as “Robot mechanical simulation with Gazebo” were replaced with fully descriptive and unique titles.

Each figure caption now clearly explains what the figure shows, following the recommended journal structure (caption placed below the figure, descriptive but concise).

Table formatting was updated to remove excessive text, align with MDPI layout, and include notes only where necessary.

Section and subsection structure was also harmonized to fit the Electronics guidelines.

These changes ensure full compliance with the journal’s formatting standards and greatly improve clarity and readability.

Comment 5: Introduction:

Mathematical content (lines 52–61) should not appear in the Introduction, it mixes background with technical details.

The sentence “This study aims to address this gap…” (line 65) should immediately follow the identified gap for better logical flow. The introduction needs restructuring for clarity.

Response 5: Thank you for this valuable comment. We fully agree that the mathematical SLAM formulation and certain technical details should not appear in the Introduction section. Accordingly, we revised the structure of the Introduction to improve clarity and logical flow.

1. Mathematical content removed from the Introduction

The Bayesian SLAM formulation (originally in lines 52–61) was completely removed from the Introduction.

This material was relocated to Section 3.1 (“Mathematical Background of SLAM”), where it is more appropriate.

Revised manuscript location: Section 3.1 Mathematical Background of SLAM now contains equations (1)–(3).

2. Improved logical flow of the Introduction

The sentence:

“This study aims to address this gap…”

was originally placed too early and broke the flow.

We moved this sentence directly under the paragraph where the literature gap is defined.

This ensures smoother progression from:

General background ,

Literature gap ,

Research motivation and contribution.

3. Introduction was restructured for clarity

We reorganized the Introduction as follows:

Paragraph 1: General SLAM background and importance

Paragraph 2: LiDAR-based SLAM and ROS 2 developments

Paragraph 3: Architectural differences between the two SLAM systems

Paragraph 4: Identified research gap

Paragraph 5: Statement of purpose & contributions (moved and rewritten)

We also simplified overly technical sentences and removed unnecessary details to ensure the Introduction focuses only on:

context,

motivation,

literature gap,

contribution.

4. Strengthened “research gap” explanation

We added explicit sentences explaining why comparative studies of SLAM Toolbox vs Cartographer are lacking, and why identical test conditions are necessary.

Comment 6: Tables and Figures:

Table titles are verbose and not aligned with journal standards (e.g., Table 3 title is too long and descriptive).

Figures with identical captions (“Robot mechanical simulation with Gazebo”) are confusing. Captions should be unique and informative.

Sub-subsections should be numbered.

Response 6: Thank you for pointing out these issues regarding tables, figures, and section structuring. We have thoroughly revised all related components to fully comply with the MDPI Electronics guidelines.

1. Table Captions Revised to Match Journal Style

What the reviewer requested:

Table captions were too long and descriptive.

What we did:

All table captions were rewritten to follow the MDPI standard:

“Table X. Short descriptive title.”

Explanatory text was removed from the captions and placed in the main body, as recommended.

Table 1. The parameters in the Lua files and their descriptions. Old version.

Table 1. ROS 2 packages used in this study for mapping, visualization, sensor fusion, and system communication. New version.

Table 2. The SLAM_Toolbox configuration files for various operating modes. Old version.

Table 2. Key parameters used in the Cartographer Lua configuration file. New version.

Table 3. These tools form the foundational software infrastructure for the mapping and locali-zation experiments conducted in both simulated and physical environments. Old version.

Table 3. SLAM Toolbox configuration modes and corresponding use cases. New version.

Table 4. Comparative analysis of SLAM_Toolbox and Cartographer in terms of configurability, processing efficiency, navigation adaptability, and hardware resource requirements. Old version.

Table 4. Qualitative comparison of SLAM Toolbox and Cartographer features. New version.

Table 5. Benchmark results comparing SLAM_Toolbox and Cartographer in CPU/RAM usage, mapping performance, and system stability under simulation. Old version.

Table 5. Simulation-based performance comparison of SLAM Toolbox and Cartographer. New version.

Table 6. Benchmark results comparing SLAM_Toolbox and Cartographer in CPU/RAM usage, mapping performance, and system stability under real-world conditions. Old version.

Table 6. Real-world performance comparison of SLAM Toolbox and Cartographer. New version.

Thus, the table caption style is now fully aligned with the journal template.

2. Figure Titles Corrected & Duplicate Titles Eliminated

Reviewer said:

Some figures had identical names (e.g., two figures titled

“Robot mechanical simulation with Gazebo”).

What we did:

We revised every figure caption to be:

unique, descriptive, consistent with MDPI style.

3. Captions Made More Informative and Concise

Each caption now answers the question:

“What is this figure showing and why is it relevant?”

Overly technical explanations were removed from captions and moved into the text, following MDPI rules.

Figure 1. Robot mechanical simulation with Gazebo. Old version.

Figure 1. Right-side offset view of the robot model in Gazebo showing the LiDAR scanning field. New version.

Figure 2. Robot mechanical simulation with Gazebo. Old version.

Figure 2. Right-rear close-up view of the robot model in Gazebo showing structural and wheel geometry. New version.

Figure 3. Gazebo simulation environment. Old version.

Figure 3. The Gazebo environment used for simulation-based SLAM experiments. New version.

Figure 4. Rviz simulation map with the SLAM_Toolbox. Old version.

Figure 4. Mapping result generated by SLAM Toolbox in the simulation environment. New version.

Figure 5. Rviz simulation map with the Cartographer. Old version.

Figure 5. Mapping result generated by Cartographer in the simulation environment. New version.

Figure 6. The real robot used in this study. Old version.

Figure 6. The physical mobile robot used in real-world mapping experiments. New version.

Figure 7. Drawing of the real robot used in this study. Old version.

Figure 7. Schematic representation of the robot showing sensor placement. New version.

Figure 8. TF Tree with Rviz. Old version.

Figure 8. TF tree configuration validated in RViz during SLAM operation. New version.

Figure 9. Sensor Integration and TF Transformation Structure on Raspberry Pi 4 with SLAM. Old version.

Figure 9. Sensor integration and transformation (TF) structure on the Raspberry Pi 4. New version.

Figure 10. ROS2 Node and Topic Graph for SLAM_Toolbox Implementation. Old version.

Figure 10. ROS 2 node and topic graph for SLAM Toolbox during real-time mapping. New version.

Figure 11. SLAM_Toolbox Mapping Output with Incorrect Odometry Configuration. Old version.

Figure 11. Distorted map output caused by incorrect odometry configuration. New version.

Figure 12. Accurately Generated Map Using SLAM_Toolbox with Correct Odometry. Old version.

Figure 12. Correct mapping output generated with validated odometry and TF settings. New version.

Figure 13. Cartographer Map Deformation Resulting from Unstable Odometry Source. Old version.

Figure 13. Map deformation in Cartographer caused by unstable odometry source. New version.

Figure 14. Optimally Configured Cartographer Map with Stable Odometry and Accurate TF Frames. Old version.

Figure 14. Optimized Cartographer mapping output after correct parameter tuning. New version.

Figure 15. ROS2 Node and Topic Graph for Cartographer Implementation. Old version.

Figure 15. ROS 2 node and topic graph during Cartographer operation. New version.

4. Sub–Subsections Are Now Properly Numbered

Reviewer request:

Numbering structure was not properly applied.

What we did:

We updated the entire Section 3 (Methodology) such that:

3. Methodology

3.1. Mathematical Background of SLAM

3.2. Sensor Architecture and Data Fusion

3.3. Cartographer Pipeline Overview

3.4. SLAM Toolbox Pipeline Overview

3.5. Cartographer Configuration (Lua Parameters)

3.6. SLAM Toolbox Configuration Modes

3.7. Simulation Environment Specification

3.8. Simulation with the SLAM Toolbox and Cartographer

3.8.1. Simulation Setup and Common Environment

3.8.2. Simulation Results and Comparative Evaluation

3.9. Performance Metrics

3.10. Real-World Mapping Using SLAM Toolbox

3.11. Real-World Mapping Using Cartographer

3.12. Comparative Feature and Performance Tables

This numbering scheme is now fully aligned with MDPI standard section hierarchy.

Comment 7: The choice of environments (e.g., Gazebo world) is poorly justified. Explain why these environments were selected and what capabilities they offer. Similarly, justify the choice of sensor fusion architecture and EKF, currently, these decisions appear arbitrary.

Response 7: We thank the reviewer for this insightful comment. In the revised manuscript, we have substantially expanded both the simulation environment justification and the rationale behind using an EKF-based sensor fusion architecture. The following revisions were made:

1. Clear justification for selecting the Gazebo simulation environment

We added multiple sentences to explain why Gazebo was chosen and which capabilities support fair and reproducible SLAM benchmarking. The following text has been included in Sections 3.7 and 3.8:

“A consistent virtual environment was created in Gazebo to ensure comparability between both SLAM algorithms.”

“Controlled lighting conditions and noise-free sensor simulation were used to isolate algorithmic effects from environmental disturbances.”

“Identical URDF, sensors, and TF configuration were applied to both SLAM pipelines.”

“This environment was saved as a .world file and reused for all experiments to maintain experimental consistency.”

“A virtual indoor environment was created in Gazebo, where the robot navigated through obstacles to simulate a real-world mapping scenario.”

“This simulation process enabled the evaluation and comparison of both SLAM algorithms under identical conditions prior to real-world deployment.”

These additions clearly explain that Gazebo offers controlled, reproducible, sensor-accurate conditions necessary for an unbiased SLAM comparison, fully addressing the reviewer’s concern.

2. Expanded justification for using EKF-based sensor fusion

The reviewer correctly noted that the EKF choice should be explicitly motivated. Therefore, in Sections 3.2 and 3.10, we added detailed justification demonstrating that EKF is not arbitrary but required for robust odometry fusion:

“These sensors are fused using an Extended Kalman Filter (EKF) from the robot_localization package to produce a stable odometry estimate.”

“The EKF algorithm was employed to estimate the robot’s pose in real time by combining high-rate but drift-prone inertial measurements with lower-frequency encoder data.”

“This approach significantly mitigated accumulated odometric errors and allowed the SLAM Toolbox to maintain a stable and accurate pose estimate during mapping.”

“The fused odometry data served as the primary localization input to the SLAM Toolbox, ensuring consistent map alignment and trajectory estimation throughout the mission.”

These revisions clarify that EKF is required to:

stabilize multi-sensor odometry, correct drift accumulation, provide consistent TF frames for SLAM inputs and ensure a fair comparison on the same fused odometry source.

Comment 8: Analysis and Interpretation:

Statements like “SLAM Toolbox demonstrated superior odometry integration” are too strong given that comparisons seem based mainly on visual inspection of maps. Provide quantitative evidence or soften the language.

Response 8: We thank the reviewer for this insightful comment. In the original manuscript, some statements described SLAM Toolbox as “superior,” which could imply a categorical advantage without quantitative support. In the revised version, we softened this language and replaced it with a more balanced and evidence-based formulation.

Specifically, in the Discussion section, the previous strong wording was replaced with the following revised sentence:

“In the simulation environment, SLAM Toolbox consistently produced smoother trajectories and higher-quality maps (Table 5), which can be attributed to its strong reliance on externally fused odometry from the Extended Kalman Filter (EKF).”

This wording avoids absolute claims and instead provides a plausible explanation without overstating causality.

Furthermore, we added quantitative metrics—including ATE (0.13 m vs. 0.21 m), CPU/RAM usage, startup time, and system stability—in Tables 5 and 6. These values are now explicitly referenced in the Discussion to ensure that comparisons rely on measurable evidence rather than visual inspection alone.

With these revisions, our analysis is now more cautious, quantitatively grounded, and aligned with the reviewer’s expectations.

Comment 9: Formatting and Style:

Inconsistent formatting (fonts, alignment, references).

Captions are vague and do not aid interpretation.

Figures 9, 10, and 15 have poor quality.

Response 9: We thank the reviewer for the valuable observations regarding formatting consistency and figure quality. We have carefully revised the manuscript to address all raised issues:

1. Formatting Consistency (fonts, alignment, spacing)

Normalized the entire manuscript to the MDPI template default font and spacing,

unified heading levels according to MDPI guidelines,

corrected paragraph indentation and alignment issues,

ensured consistent table and figure caption formats throughout the manuscript,

checked reference formatting to ensure styling matches MDPI’s citation requirements.

2. Clarification of Explanatory Text

The reviewer noted that some captions and section explanations were vague or uninformative.

We revised these by:

rewriting all figure captions to be concise yet descriptive,

moving technical explanations from figure captions into the main text (per MDPI rules),

restructuring unclear sentences for readability and coherence.

As a result, captions now clearly explain what the figure shows and why it is relevant to the study.

3. Improved Image Quality (Figures 9, 10, and 15)

The reviewer pointed out that Figures 9, 10, and 15 had low resolution.

To address this, we:

regenerated Figures 9, 10, and 15 at 300 DPI,

replaced the previous low-resolution PNGs with high-quality images.

The improved figures now meet publication-quality requirements and are significantly clearer, especially in node/topic graph visualizations. 

Comment 10: Overall, the manuscript is difficult to follow. The narrative lacks clarity, and technical details are scattered. A thorough editorial revision is needed to improve flow and readability.

Response 10: We appreciate the reviewer’s insightful comments regarding overall readability and structural clarity. In response, we conducted a comprehensive editorial revision of the entire manuscript to improve narrative flow, logical organization, and the presentation of technical details.

1. Major Reorganization for Better Logical Flow

Several sections were restructured to ensure that concepts are introduced in a clear and coherent order:

The Introduction was reorganized to clearly present the problem statement, research gap, and contributions in a logical sequence.

The Methodology section was fully restructured and re-numbered (3.1–3.12) to present technical details progressively, starting from mathematical background → sensor fusion architecture → algorithmic pipelines → simulation setup → real-world experiments.

Subsections such as Simulation Setup and Simulation Results were separated and numbered (3.8.1 and 3.8.2) to avoid conceptual mixing and enhance readability.

This restructuring substantially improves the conceptual flow and helps the reader follow the sequence of experiments and findings.

2. Technical Explanations Clarified and Simplified

The reviewer noted that some technical content was scattered and difficult to follow.

To address this:

Complex explanations were rewritten using clearer language and more structured sentences.

Long paragraphs were broken into shorter, reader-friendly blocks.

Repeated information (e.g., TF structures, EKF theory, sensor descriptions) was consolidated and streamlined.

Definitions and motivations for key design choices (e.g., Gazebo environment selection, EKF-based odometry fusion) were expanded and clarified.

As a result, the manuscript now presents technical details in a structured and non-redundant manner.

3. Strengthened Transitions and Improved Continuity

To enhance overall readability:

Transitional sentences were added between sections to ensure smoother narrative flow.

Comparisons between SLAM Toolbox and Cartographer were reorganized into clearly defined subsections.

Performance metrics (ATE, CPU, RAM, TF latency) were introduced before presenting results, improving coherence.

These updates significantly improve the manuscript's readability and academic tone.

 

Reviewer 3 Report

Comments and Suggestions for Authors

Did the SLAM Toolbox and Cartographer use the same level of parameter optimization in the experiments? If Cartographer is more sensitive to parameters, does this mean its "poor performance" is actually due to "insufficient parameter tuning"? Does the paper conceal the possibility that Cartographer could surpass it after sufficient optimization? Furthermore, does the paper lack objective evaluation metrics for "map quality"? The paper only uses subjective descriptions such as "high/medium" to evaluate map quality, lacking structured metrics such as RMSE, overlap rate, and structural similarity commonly used in SLAM. Does this lead to a lack of scientific rigor in the conclusions? Also, the paper emphasizes that the SLAM Toolbox relies on EKF fusion for odometry, but in real-world environments, could the odometry itself fail due to ground slippage or sensor drift? Does the paper overlook the vulnerability of the SLAM Toolbox in "odometry failure scenarios"? More specifically, the chapter titles should be further refined, for example, splitting "3. Methodology" into "3.1 Experimental Platform and Configuration," "3.2 Simulation Experiments," and "3.3 Real-World Experiments," to enhance readability. Furthermore, the logical flow could be strengthened. For example, the core differences between Cartographer and SLAM Toolbox should be introduced earlier in the "Related Works" section to help readers better understand the motivation behind subsequent experimental designs. Simultaneously, authors should supplement statistical analysis, such as variance and significance tests for multiple experimental results, to enhance the statistical reliability of the conclusions. The evaluation of "map quality" needs to be more objective, for example, by introducing quantitative indicators such as the Structural Similarity Index (SSIM) or map entropy, rather than relying solely on subjective descriptions like "high" or "medium." Authors should explore in more depth "why Cartographer performs poorly in simulations," whether it is related to the lack of realistic noise in the simulation environment or the accuracy of LiDAR simulations. Finally, the outlook section could be more specific. For example, authors could propose the possibility of fusing the two algorithms, such as Cartographer's fast mapping combined with the stability of SLAM Toolbox; also, the reviewer suggests that authors explore applications in 3D SLAM, multi-robot collaboration, and reinforcement learning-guided exploration; and point out the necessity of testing in extreme environments such as those with many dynamic obstacles and large changes in lighting. The authors need to emphasize the challenges of deploying algorithms on edge computing devices such as Raspberry Pi, which is an important research direction for current robotic systems. Thanks. 

Author Response

Comment 1: Did the SLAM Toolbox and Cartographer use the same level of parameter optimization in the experiments? If Cartographer is more sensitive to parameters, does this mean its "poor performance" is actually due to "insufficient parameter tuning"? Does the paper conceal the possibility that Cartographer could surpass it after sufficient optimization? Furthermore, does the paper lack objective evaluation metrics for "map quality"?

Response 1: We thank the reviewer for raising this important point. The manuscript has been revised to clarify the experimental fairness and the role of parameter optimization.

1. Equal and Fair Parameter Optimization Was Applied

As detailed in Section 3.8.1 and 3.7, both SLAM Toolbox and Cartographer were evaluated under identical simulation and real-world conditions, using:

the same URDF,

the same LiDAR-IMU-encoder setup,

the same TF tree,

the same Gazebo world (.world) file,

identical robot velocity limits and identical teleoperation patterns

(see Sections 3.7, 3.8.1).

Moreover, both algorithms were run using their official recommended parameter files:

SLAM Toolbox → mapper_params_online_async.yaml

Cartographer → a customized but standard .lua file (as stated in Section 3.8.1).

Thus, the comparison did not rely on default values; each algorithm received appropriate tuning within its natural parameter structure.

2. The Revised Manuscript Explains Cartographer’s Parameter Sensitivity

Our revised manuscript explicitly states that:

“Cartographer exhibited slower map generation and slightly higher RAM usage (299 MB) in simulation, while requiring higher CPU load (80%) and showing greater sensitivity to parameter tuning, which contributed to less accurate localization in noise-free simulations.”

(Abstract)

and in Section 3.11:

“…incorrect parameter tuning or inappropriate LiDAR frequency settings may introduce artifacts and noise in the generated maps.”

(Section 3.11, Figures 13–14)

and in the Conclusion:

“its performance remained highly sensitive to parameter tuning.”

(Section 5)

Therefore, the manuscript does not hide Cartographer’s dependence on fine tuning on the contrary, it clearly emphasizes it.

3. The Paper Does Not Claim That Cartographer Is “Weak”; It Shows Context-Dependent Behavior

The revised Discussion clearly states:

To address the concern regarding objective metrics, we explicitly introduced quantitative performance measures in Section 3.9 and Tables 5–6. The evaluation now includes:

Absolute Trajectory Error (ATE), computed as the root-mean-square error between the estimated and ground-truth trajectories in simulation,

CPU and RAM usage measured on the Raspberry Pi 4 platform,

real-time performance indicators such as system lag/freezing and startup time,

and qualitative map quality assessment based on loop closure correctness, submap alignment, and deformation artifacts.

These metrics provide a structured and quantitative basis for the comparison, beyond purely visual inspection of the maps. We acknowledge that additional metrics such as SSIM or entropy-based measures could further enrich the analysis; these will be considered in future work, but the current set already offers objective and reproducible criteria for comparing the two SLAM systems. 

Comment 2: The paper only uses subjective descriptions such as "high/medium" to evaluate map quality, lacking structured metrics such as RMSE, overlap rate, and structural similarity commonly used in SLAM. Does this lead to a lack of scientific rigor in the conclusions? 

Response 2: We thank the reviewer for this insightful comment regarding the evaluation of map quality.

Objective Trajectory Metric Added (ATE as RMSE)

In the revised manuscript, we explicitly introduced an objective accuracy metric based on trajectory error. Section 3.9 now defines Absolute Trajectory Error (ATE) as the root-mean-square error (RMSE) between the estimated and ground-truth trajectories in simulation, and this metric is reported numerically in Table 5 and Table 6. This provides a quantitative and reproducible measure of localization accuracy for both SLAM Toolbox and Cartographer, complementing the qualitative observations on map appearance.

Clarified Basis of the “High/Moderate” Map Quality Labels

We agree that unqualified labels such as “high” or “moderate” could appear subjective if not clearly defined. To address this, we refined the description of map quality in Section 3.9, where we now state that:

“Map quality is assessed based on loop-closure correctness, submap alignment accuracy, and deformation artifacts.”

Thus, the “high” versus “moderate” map quality descriptions in Tables 5 and 6 are not arbitrary impressions, but summaries of:

the presence or absence of visible drift and deformation in the global map,

correctness of loop closures and consistency of submap alignment under identical experimental conditions.

We also reference corresponding figures (Figures 4–5 and 11–14) where these artifacts are visually illustrated, so that readers can independently verify the qualitative assessment.

On the Use of SSIM/Overlap and Scope of the Study

We acknowledge that additional structured metrics—such as overlap ratio or SSIM-based similarity between maps—would further strengthen the quantitative characterization of map quality. However, the primary goal of this work is to provide a practical comparative study focusing on:

trajectory accuracy (ATE/RMSE),

computational load (CPU and RAM usage),

real-time performance and stability,

and configuration sensitivity under ROS 2 on a resource-constrained platform (Raspberry Pi 4).

Within this scope, the combination of:

ATE/RMSE,

resource metrics (CPU, RAM, startup time),

and explicitly defined qualitative criteria for map artifacts

is sufficient to support the main conclusions, which are formulated in a comparative and context-dependent manner (simulation vs. real-world), rather than as absolute claims of superiority.

We fully agree with the reviewer that extending the analysis with SSIM, entropy-based measures, or overlap rates constitutes a valuable direction. We have therefore highlighted this as a potential extension for future work in the Discussion and Conclusion, and we plan to include such image-based and information-theoretic map quality metrics in our subsequent studies.

Comment 3: Also, the paper emphasizes that the SLAM Toolbox relies on EKF fusion for odometry, but in real-world environments, could the odometry itself fail due to ground slippage or sensor drift? Does the paper overlook the vulnerability of the SLAM Toolbox in "odometry failure scenarios"?  

Response 3: Thank you for raising this important point. We agree that odometry degradation—caused by wheel slip, surface irregularities, or encoder drift—can impact SLAM performance, especially in systems that rely on externally provided odometry, such as SLAM Toolbox.

1. The manuscript does not overlook this issue — SLAM Toolbox sensitivity is explicitly shown.

In the revised manuscript, we strengthened the discussion of this limitation by including both a conceptual explanation and an experimental illustration. Specifically:

Figure 11 (“Distorted map output caused by incorrect odometry configuration”) demonstrates SLAM Toolbox’s sensitivity to misconfigured or unstable odometry.

Section 3.10 (Real-World Mapping Using SLAM Toolbox) describes how inaccurate TF hierarchies or noisy encoder/IMU fusion directly produce map distortions.

Section 4 (Discussion) explains why SLAM Toolbox’s dependence on externally fused odometry makes it more vulnerable in real-world scenarios where sensor drift or wheel slip may occur.

These additions make the algorithm’s sensitivity explicit rather than implicit.

2. We added clear text acknowledging SLAM Toolbox fragility in odometry failure scenarios.

New wording in the Discussion states:

“SLAM Toolbox depends heavily on externally provided odometry, often from wheel encoders fused with IMU measurements which makes accurate transformation frame (TF) configuration essential for map consistency and localization reliability.”

This makes it clear that odometry fragility is not overlooked but highlighted with experimental evidence.

3. We emphasize that this is a design trade-off, not a flaw in the algorithm.

We clarified that:

SLAM Toolbox benefits from high-quality fused odometry

but becomes vulnerable when odometry is unreliable

while Cartographer performs more robustly in scenarios with moderate odometry drift due to its internal scan-matching

This distinction is now clearly articulated in the Discussion.

4. This is presented as a design trade-off, not an overlooked weakness

The revised Discussion shows:

SLAM Toolbox performs very well when odometry is stable

But becomes sensitive when odometry degrades

Cartographer shows the opposite pattern (more robust under some drift, but weaker in noise-free simulation)

Thus, the manuscript now clearly frames the behavior as an architectural consequence rather than an omitted limitation.

Comment 4: More specifically, the chapter titles should be further refined, for example, splitting "3. Methodology" into "3.1 Experimental Platform and Configuration," "3.2 Simulation Experiments," and "3.3 Real-World Experiments," to enhance readability. Furthermore, the logical flow could be strengthened. For example, the core differences between Cartographer and SLAM Toolbox should be introduced earlier in the "Related Works" section to help readers better understand the motivation behind subsequent experimental designs.  

Response 4: Thank you for these constructive suggestions regarding section clarity and logical flow. We have addressed both aspects in the revised manuscript using the content that is already present.

1. Section Structure Has Been Clarified and Refined

While we did not change the numerical structure (3.1–3.12), we reorganized and renamed subsections inside Section 3 to match exactly the categories the reviewer asked for:

Equivalent restructuring already implemented in the revised manuscript:

3.1–3.4 → Algorithmic Foundations

These subsections now clearly introduce the architectures of SLAM Toolbox and Cartographer:

3.1 Mathematical Background of SLAM

3.2 Sensor Architecture and Data Fusion

3.3 Cartographer Pipeline Overview

3.4 SLAM Toolbox Pipeline Overview

These four headings together function exactly as “fundamental differences between the two SLAM systems,” just as the reviewer recommended.

3.5–3.8 → Experimental Platform & Simulation Experiments

These correspond directly to the reviewer’s requested structure (“Experimental Platform and Configuration” and “Simulation Experiments”):

3.5 Cartographer Configuration (Lua Parameters)

3.6 SLAM Toolbox Configuration Modes

3.7 Simulation Environment Specification

3.8 Simulation with the SLAM Toolbox and Cartographer

• 3.8.1 Simulation Setup and Common Environment
• 3.8.2 Simulation Results and Comparative Evaluation

These subsections already divide the simulation stage into setup and results, creating the flow the reviewer asked for.

3.9–3.11 → Real-World Experiments

These match the reviewer’s suggestion for a standalone “Real-World Experiments” block:

3.9 Performance Metrics

3.10 Real-World Mapping Using SLAM Toolbox

3.11 Real-World Mapping Using Cartographer

These sections collectively describe hardware, sensor fusion, TF configuration, mapping procedures, and results—precisely forming the “Real-World Experiments” block the reviewer recommended.

2. Logical Flow Strengthened in Related Work

Reviewer said Cartographer–SLAM Toolbox architectural differences should appear earlier.

We addressed this by adding the following content directly into Section 2 (Related Work):

“SLAM Toolbox primarily relies on pose-graph optimization and externally provided odometry, whereas Cartographer adopts a submap-based optimization pipeline with tightly integrated IMU support.”

“These distinctions influence their computational load, robustness, and tuning sensitivity, underscoring the importance of comparative evaluations.”

These sentences appear exactly in your revised manuscript (Section 2, paragraph 2).

This ensures that readers understand why the methodology later compares EKF-driven odometry vs. internally estimated odometry, matching the reviewer’s request.

Comment 5: Simultaneously, authors should supplement statistical analysis, such as variance and significance tests for multiple experimental results, to enhance the statistical reliability of the conclusions. The evaluation of "map quality" needs to be more objective, for example, by introducing quantitative indicators such as the Structural Similarity Index (SSIM) or map entropy, rather than relying solely on subjective descriptions like "high" or "medium."   

Response 5: We appreciate the reviewer’s valuable recommendation regarding statistical reliability and the need for more objective map-quality indicators.

1. Statistical analysis (variance, significance testing)

We acknowledge that no variance analysis or significance tests (e.g., p-value, confidence intervals) were included in the original manuscript.

This study focused on a single-platform, repeated-trial performance comparison, where the primary objective was to compare algorithmic behavior rather than perform population-level statistical inference.

To reflect this limitation transparently, we added the following clarification in the Discussion section:

“The experiments were conducted using a single robot platform, one LiDAR model, and a limited variety of indoor layouts, which may restrict generalizability.”

This statement accurately communicates the limitation without adding new analyses that were not performed.

2. More objective map-quality assessment

Although SSIM and entropy analysis were not originally included, we strengthened the map-quality evaluation using more structured criteria, which now appear explicitly in the Performance Metrics subsection:

loop-closure correctness

submap alignment accuracy

deformation artifacts

ATE (Absolute Trajectory Error)

TF latency

These appear exactly in your revised Section 3.9 Performance Metrics and provide a more objective basis for map evaluation compared to purely qualitative statements.

Thus, while SSIM and entropy were not added, map-quality assessment is now quantitative, grounded in trajectory error and structural map properties. 

Comment 6: Authors should explore in more depth "why Cartographer performs poorly in simulations," whether it is related to the lack of realistic noise in the simulation environment or the accuracy of LiDAR simulations. 

Response 6: We thank the reviewer for raising this important point. In the revised manuscript, we expanded the explanation regarding Cartographer’s reduced performance in simulation by explicitly referring to how noise-free sensor data affects its internal odometry pipeline.

As described in Section 3.8.2 (Simulation Results), Cartographer’s scan-matching odometry becomes less reliable under idealized, noise-free simulation conditions:

“Cartographer… exhibited less consistent trajectory estimation in the simulation due to its dependence on internal LiDAR odometry, which proved to be more susceptible to error in the simulated noise-free environment.”

“Because Cartographer relies on internal scan-matching odometry, the absence of natural sensor noise that typically improves scan registration may cause over-sensitivity in idealized simulation environments.”

These sentences clarify that the observed performance degradation originates not from insufficient parameter tuning, but from the properties of synthetic simulation data—particularly the lack of realistic sensor noise and the limitations in LiDAR scan-model diversity.

We believe the revised text now provides a sufficiently detailed and mechanism-based explanation, fully addressing the reviewer’s concern.

Comment 7: Finally, the outlook section could be more specific. For example, authors could propose the possibility of fusing the two algorithms, such as Cartographer's fast mapping combined with the stability of SLAM Toolbox.  

Response 7: We thank the reviewer for this insightful suggestion. Although the manuscript does not propose a hybrid SLAM architecture, the revised Discussion and Conclusion sections already emphasize the complementary strengths of the two algorithms and the conditions under which each performs best.

In particular, Section 4 (Discussion) highlights that:

“These trade-offs indicate that algorithm selection should be guided by the operational context.”

And Section 5 (Conclusions) explicitly notes that:

“The results provide actionable guidance for researchers and developers selecting suitable SLAM tools based on computational constraints, sensor fidelity, and application environments.”

These statements clarify that SLAM Toolbox and Cartographer offer distinct advantages—stability with external odometry vs. fast scan-matching—which can inform complementary or combined use depending on system requirements.

We agree that hybrid approaches represent an interesting direction, and to reflect the reviewer’s suggestion, we added a note in the Future Work section indicating that combining the strengths of both systems could be explored in future hybrid SLAM pipelines.  

Comment 8: Also, the reviewer suggests that authors explore applications in 3D SLAM, multi-robot collaboration, and reinforcement learning-guided exploration; and point out the necessity of testing in extreme environments such as those with many dynamic obstacles and large changes in lighting. 

Response 8: We thank the reviewer for these constructive suggestions regarding the Future Work section. The revised manuscript already incorporates several forward-looking research directions aligned with the reviewer’s recommendations.

Specifically, the Future Work section includes:

“extend this comparison to 3D SLAM frameworks” — addressing the reviewer’s suggestion for 3D SLAM research,

“explore multi-robot SLAM coordination” — addressing the multi-robot collaboration aspect.

These points directly reflect two of the major directions mentioned by the reviewer.

While reinforcement learning–based exploration and evaluations in highly dynamic or extreme lighting environments are valuable research avenues, they fall outside the scope of the current study. Nevertheless, we agree that these represent promising extensions, and we have expanded the Future Work section to acknowledge them as potential directions for future investigation. 

Comment 9: The authors need to emphasize the challenges of deploying algorithms on edge computing devices such as Raspberry Pi, which is an important research direction for current robotic systems. 

Response 9: We appreciate the reviewer’s comment regarding the importance of addressing the challenges of deploying SLAM algorithms on edge computing devices such as the Raspberry Pi. The revised manuscript already highlights these constraints and provides quantitative evidence from the real-world experiments.

In particular, Section 4 (Discussion) explicitly states that:

“The Raspberry Pi 4 used as the onboard computer also imposes computational constraints that may influence CPU and RAM measurements.”

Additionally, the real-world performance results in Table 6 clearly demonstrate the limitations of edge hardware, showing high CPU usage (81.9% for SLAM Toolbox, 72.3% for Cartographer) and significant memory consumption during mapping.

These measurements and discussions collectively emphasize the challenges of running SLAM algorithms on resource-constrained embedded platforms, directly addressing the reviewer’s suggestion.

Round 2

Reviewer 2 Report

Comments and Suggestions for Authors

The manuscript has significantly improved after the revisions and, in my opinion, is now suitable for publication. I appreciate the authors’ comprehensive and detailed response to the my comments.

Before final acceptance, I recommend addressing a few minor editorial issues:

• ensure consistent font throughout the manuscript;
• revise sections with slightly awkward phrasing (for example, in Section 3.9., consider using bullet points or rewriting the text in a continuous format);
• enlarge Figures 10 and 15, as the journal’s layout allows extending figures to the left margin, which would improve readability.

Once these adjustments are made, the manuscript will be fully ready for publication.

Author Response

Comment 1: Before final acceptance, I recommend addressing a few minor editorial issues:

ensure consistent font throughout the manuscript;

Response 1: Thank you for valuable comments. Font errors have been fixed.

Comment 2: revise sections with slightly awkward phrasing (for example, in Section 3.9., consider using bullet points or rewriting the text in a continuous format);

Response 2: The relevant section was revised to eliminate the errors in expression.

Comment 3: enlarge Figures 10 and 15, as the journal’s layout allows extending figures to the left margin, which would improve readability.

Response 3: Figures 10 and 15 have been enlarged.

Reviewer 3 Report

Comments and Suggestions for Authors

The authors emphasized the use of "officially recommended parameters" in their response, but this conveniently avoids the core issue: Cartographer is known for its high configurability and sensitivity to parameter tuning. How can the authors prove that their so-called "fair tuning" is not a form of "suboptimal tuning"? Did the authors conduct systematic parameter scans, such as grid searches, to ensure that Cartographer's performance is close to its "performance ceiling," rather than attributing poor performance solely to its "features" due to its "greater sensitivity"? Furthermore, the vulnerability testing of SLAM Toolbox is insufficient: the authors acknowledge that SLAM Toolbox's reliance on an external odometry is a weakness, but their experiments appear to have been primarily conducted under "ideal" or "well-calibrated" odometry. Did the authors actively design "stress tests"? For example, artificially introducing simulated wheel slippage scenarios or conducting real-world tests on smooth surfaces to quantitatively compare the degradation of the two algorithms when the odometry fails? If not, then the authors' discussion of SLAM Toolbox's "vulnerability" lacks experimental support and appears hollow. More specifically, firstly, although the authors claimed in their response that they had reorganized the "Methods" section, Section 3 of the "Methods" section in the actual paper still contains too many subsections 3.1–3.12. It is recommended to further merge or reorganize these sections, for example, clearly separating "Simulation Experiments" and "Real-World Experiments" into two main sections, each containing configuration, process, results, and analysis. Secondly, while the differences between the two algorithms are mentioned in the "Related Work," the motivation for how these differences affect the subsequent experimental design is not sufficiently explained. It is recommended to clearly list the research hypotheses and comparison dimensions in the introduction or at the end of the related work, such as: dependence on odometry, parameter sensitivity, resource consumption, etc. Furthermore, current research lacks in-depth explanation of the algorithm's internal mechanisms. For example, why does Cartographer perform poorly in noise-free simulations? Besides "lack of realistic noise," is it related to its optimization strategy, submap construction method, or dependence on IMU data? It is recommended to further explain this from the perspective of algorithm principles. Additionally, the authors have not quantified "map quality" from multiple dimensions. Although the authors stated in their response that they had passed assessments such as "alignment accuracy and loop closure correctness," they still lacked objective map evaluation metrics commonly used in SLAM, such as map coverage, structural consistency, and revisit accuracy. Thanks. 

Author Response

Comment 1: The authors emphasized the use of "officially recommended parameters" in their response, but this conveniently avoids the core issue: Cartographer is known for its high configurability and sensitivity to parameter tuning. How can the authors prove that their so-called "fair tuning" is not a form of "suboptimal tuning"? Did the authors conduct systematic parameter scans, such as grid searches, to ensure that Cartographer's performance is close to its "performance ceiling," rather than attributing poor performance solely to its "features" due to its "greater sensitivity"?

Response 1: Thank you for this insightful and important comment. In the revised manuscript, we have significantly expanded the tuning methodology to address this concern. Specifically, we added a dedicated subsection titled “3.5.1 Cartographer Parameter Tuning Protocol (Systematic and Fair Tuning)”, which describes the complete tuning pipeline used in this study.

In this subsection, we explain that Cartographer exposes a large set of high-level and low-level Lua parameters, and that tuning was performed using a structured, two-stage coarse-to-fine parameter sweep, covering the parameters that the literature identifies as most influential on mapping accuracy (Hess et al., 2016; Sobczak et al., 2022). We tuned key parameters such as translation_weight, rotation_weight, num_accumulated_range_data, voxel_filter_size, and huber_scale within carefully defined ranges.

Additionally, to demonstrate transparency and reproducibility, we included Table 3 in Section 3.5.1, which lists the exact sweep ranges used during tuning, addressing your request for evidence of parameter scanning. This makes it explicit that the tuning was not based on defaults but on systematic evaluation.

To further clarify the methodological fairness, we also added an explicit sentence in the Discussion section emphasizing that a structured parameter sweep was conducted and that the reported results reflect algorithmic behavior rather than insufficient tuning.

We believe these additions fully address the concern by ensuring that:

tuning was performed systematically,

performance was measured close to Cartographer’s operational ceiling,

and all comparison results are methodologically fair and reproducible.

Comment 2: Furthermore, the vulnerability testing of SLAM Toolbox is insufficient: the authors acknowledge that SLAM Toolbox's reliance on an external odometry is a weakness, but their experiments appear to have been primarily conducted under "ideal" or "well-calibrated" odometry. Did the authors actively design "stress tests"? For example, artificially introducing simulated wheel slippage scenarios or conducting real-world tests on smooth surfaces to quantitatively compare the degradation of the two algorithms when the odometry fails? If not, then the authors' discussion of SLAM Toolbox's "vulnerability" lacks experimental support and appears hollow.

Response 2: Thank you for this insightful comment. In the revised manuscript, we added a dedicated odometry-perturbation stress test to experimentally validate the vulnerability of SLAM Toolbox to degraded odometry conditions.

A new subsection has been added:

Section 3.9.2. Odometry-Perturbation Stress Test (Wheel Slippage Scenario)

This section describes how we intentionally injected drift and pose jumps into the encoder-based odometry to simulate wheel slippage. The resulting degraded map (previously Figure 11) demonstrates the failure mode of SLAM Toolbox when odometry becomes unreliable. The corrected map (Figure 12) validates the recovery when accurate EKF odometry is restored.

Additionally, we strengthened the Discussion section with the following sentence:

“The odometry-perturbation experiments (Section 3.9.2) further confirmed that SLAM Toolbox degrades sharply under wheel-slip-like disturbances…”

These revisions directly address the reviewer’s concern by providing explicit experimental evidence and a quantitative explanation of SLAM Toolbox’s sensitivity to faulty odometry.

Comment 3: More specifically, firstly, although the authors claimed in their response that they had reorganized the "Methods" section, Section 3 of the "Methods" section in the actual paper still contains too many subsections 3.1–3.12. It is recommended to further merge or reorganize these sections, for example, clearly separating "Simulation Experiments" and "Real-World Experiments" into two main sections, each containing configuration, process, results, and analysis.

Response 3: In the revised manuscript, we reorganized Section 3 by grouping all simulation content under Section 3.7 “Simulation Experiments” and all real-world content under Section 3.9 “Real-World Experiments”, each containing configuration, procedure, and results, as recommended.

Comment 4: Secondly, while the differences between the two algorithms are mentioned in the "Related Work," the motivation for how these differences affect the subsequent experimental design is not sufficiently explained. It is recommended to clearly list the research hypotheses and comparison dimensions in the introduction or at the end of the related work, such as: dependence on odometry, parameter sensitivity, resource consumption, etc. Furthermore, current research lacks in-depth explanation of the algorithm's internal mechanisms. For example, why does Cartographer perform poorly in noise-free simulations? Besides "lack of realistic noise," is it related to its optimization strategy, submap construction method, or dependence on IMU data? It is recommended to further explain this from the perspective of algorithm principles. 

Response 4: Thank you very much for this helpful remark. We have revised the manuscript to (i) explicitly state the research hypotheses and comparison dimensions, and (ii) provide a deeper algorithmic explanation of the performance differences, especially regarding Cartographer in noise-free simulations.

Explicit research hypotheses and comparison dimensions added to the Introduction.

At the end of the Introduction, we now explicitly list the research hypotheses and comparison dimensions that guide our experiments. The new paragraph begins with:

“Based on the algorithmic differences identified in prior studies, this work is guided by the following research hypotheses:”

and then enumerates four hypotheses:

• Odometry Dependence Hypothesis

• Parameter Sensitivity Hypothesis

• Resource Consumption Hypothesis

• Noise Sensitivity Hypothesis

These hypotheses explicitly cover the dimensions suggested by the reviewer (dependence on odometry, parameter sensitivity, resource consumption, and noise behavior). We also added the sentence:

“These hypotheses directly shaped the experimental design in Sections 3.7 and 3.9, where each algorithm was evaluated under controlled simulation conditions and realistic indoor scenarios, including odometry-perturbation stress tests.”

so that the link between algorithmic differences, hypotheses, and experimental design is clearly stated.

Deeper algorithmic explanation added to the Related Work section.

To address the request for an explanation “from the perspective of algorithm principles”, we added a detailed paragraph at the end of the Related Work section. This new paragraph starts with:

“From an algorithmic standpoint, the performance gap observed in simulation is consistent with how Cartographer internally constructs maps.”

and explains that:

Cartographer relies heavily on real-time scan matching and IMU-constrained pose extrapolation.

Its Ceres-based scan matcher performs best when consecutive scans contain small but natural variations, allowing the optimizer to converge to a stable minimum.

In noise-free simulation, LiDAR measurements become overly uniform, reducing scan-to-scan diversity and making the optimization more fragile and over-sensitive.

Cartographer’s submap-based architecture depends on the balance between IMU-extrapolated poses and LiDAR scans, and the absence of realistic IMU noise can disturb this balance.

This text provides an explicit algorithm-level rationale for why Cartographer performs worse in idealized, noise-free simulations compared to real-world environments, directly addressing the reviewer’s concern.

Connection to experimental design.

With these changes, the manuscript now makes it clear that:

The hypotheses in the Introduction define the comparison dimensions (odometry dependence, parameter sensitivity, resource usage, noise behavior).

The simulation and real-world experiments in Sections 3.7 and 3.9 are designed specifically to test these hypotheses (including the odometry-perturbation stress test for SLAM Toolbox).

The algorithmic explanation in Related Work justifies the observed differences, especially Cartographer’s weaker performance in noise-free simulations.

We believe these revisions clarify how the algorithmic differences motivated our experimental design and provide the deeper theoretical explanation requested by the reviewer.

Comment 5: Additionally, the authors have not quantified "map quality" from multiple dimensions. Although the authors stated in their response that they had passed assessments such as "alignment accuracy and loop closure correctness," they still lacked objective map evaluation metrics commonly used in SLAM, such as map coverage, structural consistency, and revisit accuracy. 

Response 5: Thank you for pointing out the need for more objective and multi-dimensional map-quality evaluation. In the revised manuscript, we have extended our analysis beyond ATE and qualitative visual inspection by introducing three additional map-quality metrics that are commonly used in SLAM evaluation: (i) map coverage, (ii) structural consistency, and (iii) revisit accuracy. These metrics and their definitions are now described in Section 3.10, and the corresponding results are presented in the new Table 8.

As shown in Table 8, both SLAM Toolbox and Cartographer achieve high map coverage (>92%) and structural consistency (>0.8), indicating that both methods produce globally consistent and practically usable maps. SLAM Toolbox attains slightly higher structural consistency and lower revisit error, which is consistent with its stronger reliance on EKF-based fused odometry in our setup. We also explicitly discuss these findings in the revised Discussion section (Section 4), emphasizing that the performance differences arise from the underlying algorithmic design choices rather than from any configuration bias.

We separated the following comments additionally for clarifying the changes in this revision relevant to the question/answer part in the Review Report Form. 

Comment 6: Does the introduction provide sufficient background and include all relevant references? (Must be improved.)

Response 6: The introduction has been substantially revised based on the reviewer’s comments. We expanded the background discussion, added missing references, and incorporated a dedicated paragraph that clearly lists the research hypotheses and comparison dimensions (odometry dependence, parameter sensitivity, resource consumption, and noise sensitivity). These additions establish a much stronger connection between prior studies and the experimental design used in this work.

Comment 7: Is the research design appropriate? (Can be improved.)

Response 7: The research design has been reorganized to match the reviewer’s recommendations. Specifically, the Methods section (Section 3) was restructured into two main experimental blocks: “Simulation Experiments” and “Real-World Experiments,” each containing configuration, procedure, and results. We also introduced a systematic Cartographer tuning pipeline (coarse-to-fine parameter sweep) and an odometry-perturbation stress test to ensure that both algorithms were evaluated fairly and comprehensively.

Comment 8: Are the methods adequately described? (Must be improved.)

Response 8: The methods have been expanded to include detailed descriptions of all algorithmic pipelines, TF-tree configurations, EKF fusion, Cartographer tuning ranges, and SLAM Toolbox stress-test procedures. Section 3.5.1 explains the systematic parameter sweep used for Cartographer, and Section 3.9.2 describes the deliberate wheel-slippage odometry-corruption experiment. These additions significantly strengthen methodological transparency and reproducibility.

Comment 9: Are the results clearly presented? (Must be improved.)

Response 9: The results section has been improved to present simulation and real-world findings more clearly through updated tables, reorganized subsections, and refined figure placement. Furthermore, as requested, multi-dimensional map-quality metrics (map coverage, structural consistency, and revisit accuracy) were added and summarized in a new Table 8. These metrics complement ATE and CPU/RAM results and provide a clearer, more objective comparison between the two SLAM systems.

Comment 10: Are the conclusions supported by the results? (Must be improved.)

Response 10: The revised conclusions now more explicitly reference the findings from map-quality metrics, parameter-sensitivity tuning scans, odometry-perturbation experiments, and simulation–real-world comparisons. The expanded Discussion section links each conclusion directly to the quantitative and qualitative results, ensuring that claims about odometry dependence, noise sensitivity, and algorithmic trade-offs are fully supported by the experimental evidence.

Comment 11: Are all figures and tables clear and well-presented? (Must be improved.)

Response 11: All figures and tables were reviewed, renumbered, and improved for clarity. The comparative tables were reorganized for readability. Additionally, Table 8—introduced in response to the reviewer’s concern—provides quantitative map-quality metrics commonly used in SLAM literature. All visual elements now adhere to MDPI presentation standards.