The Study on Real-Time RRT-Based Path Planning for UAVs Using a STM32 Microcontroller

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The authors have significantly improved the manuscript. They have addressed all my suggestions.

Author Response

Comments 1: The authors have significantly improved the manuscript. They have addressed all my suggestions.

Response:
We sincerely thank the reviewer for the positive evaluation and for the time invested in reviewing our work. We are very glad that the revised manuscript has addressed your previous suggestions. In this new version, we have also made a few additional minor refinements (language polishing, clarification of units, and explicit pseudocode for the improved RRT pipeline) to further improve readability, while keeping the technical content unchanged.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

This study presents a refined RRT algorithm implemented within an onboard embedded system based  on STM32 microcontroller, demonstrating that real-time autonomous navigation can be achieved under low-power computation constraints.the main contribution of this paper is  proposed an refined RRT algorithm and employed the path planning on the STM 32, thus theory and practical both are considered. Besides,this paper is generally well-structured and addresses a relevant challenge in embedded robotics.

1. This paper proposed an improved RRT algorithm, so,what is the improved part? What is the difference with the traditional RRT? Suggest authors give some more explanationabout the difference.
2. F5, 10 path planning trajectories, so the final path was the shortest one that selected from the 10 runs path? It's important to clarify this. If so ,the results may not the optimal, as when you run 100 times, there would a more better path to choose than just 10 runs.

 

3. In table 1, the column headers may have mistakes, according to the presentation , the second and third column headers need to be changed . Besides, in the text wrote as 0.9 seconds, but in the table 1, wrote as 900(no unit), should be with the same format and with the same unit.
4. Typing mistakes, the title “stm32”, but in the text wrote as “STM32”
5. 7, caption is inconsistent:(c) the STM32 MCU., and (d) mission planning visualization. There is an erroneous period after "MCU".
6. [25], delete the DOI, no need.

Author Response

We are grateful for your positive assessment of the overall structure and practical relevance of our work. Your detailed comments have helped us significantly clarify the contribution and improve the presentation.

 Comments1
This paper proposed an improved RRT algorithm, so, what is the improved part? What is the difference with the traditional RRT? Suggest authors give some more explanation about the difference.

Response:
Thank you for raising this crucial point. We fully agree that the distinction between the “Improved RRT” and the traditional RRT needed to be stated more explicitly. In the revised manuscript, we clarify this at two levels:

1. Conceptual clarification (Section 2):
   At the beginning of Section 2. “An Improved RRT Algorithm”, we now explicitly state that our “Improved RRT” is not a modification of the core sampling theory, but an architectural enhancement tailored for a resource-constrained STM32 microcontroller. The traditional RRT component remains standard; the improvement lies in a lightweight post-processing pipeline that makes the resulting paths suitable for real-time execution on low-power hardware.

   Specifically, we add the following explanation (paraphrased here):

   In this study, the term “Improved RRT” refers to a hybrid architectural optimization designed for constrained embedded systems, rather than a modification of the fundamental sampling theory… our framework integrates the standard RRT for rapid exploration with a lightweight post-processing pipeline: Greedy Path Pruning and Golden-Ratio Bézier Smoothing.

2. Algorithmic clarification (Sections 2.1–2.2 and Algorithm 1):

   • Traditional RRT: Section 2 and Figure 1 describe the classical RRT behavior—random exploration in the configuration space, often yielding zigzag and suboptimal paths with many redundant turning points.

   • Our “Improved RRT” pipeline:

     • Stage 1 – Standard RRT (unchanged sampling): used to rapidly generate candidate paths;

     • Stage 2 – Greedy Path Pruning + Collision Checking (Section 2.1): removes redundant nodes while guaranteeing obstacle avoidance;

       electronics_The study on real-t…

     • Stage 3 – Golden-Ratio Bézier Smoothing (Section 2.2): enforces continuous differentiability and kinematic feasibility using low-order Bézier curves with control points placed at 38.2% and 61.8% of the segment length.

   To make this difference more transparent, we have added Algorithm 1 (“Improved RRT for Embedded UAV”) in Section 2.2, which summarizes the complete three-stage pipeline—from standard RRT exploration, through greedy pruning, to golden-ratio Bézier smoothing, followed by iterative optimization over multiple runs.

   electronics_The study on real-t…

In summary, compared to the traditional RRT, our “Improved RRT” maintains the original sampling mechanism but adds a deterministic, resource-aware post-processing pipeline that (i) removes redundant nodes, (ii) enforces smooth and dynamically feasible paths, and (iii) is implementable within the strict memory and computational limits of the STM32 (20 KB SRAM, no FPU).

 Comments 2
F5, 10 path planning trajectories, so the final path was the shortest one that selected from the 10 runs path? It's important to clarify this. If so, the results may not be optimal, as when you run 100 times, there would be a better path to choose than just 10 runs.

Response:
We appreciate this important question about optimality versus computational cost.

1. Clarification of selection strategy:
   Yes, as you correctly inferred, in Figure 5(b) and Table 1 the final path is indeed the best (lowest-cost) path selected from 10 independent RRT runs. We have clarified this explicitly in Section 2.2, right after Table 1 and Figure 5.

   The text now states that repeated planning is used to explore different homotopy classes and that the shortest path candidate is chosen based on a cost function after each run, as implemented in Algorithm 1.

2. Trade-off between optimality and latency:
   We fully agree that, statistically, running 100 iterations could yield an even better path than 10 iterations. However, the embedded STM32 platform is constrained by real-time requirements:

   • Latency constraints:
     Table 1 shows that 10 planning runs require about 0.90 s, while a single run requires only 0.09 s.
     Extending to 100 runs would increase the planning latency to nearly 9 seconds, which is not acceptable for in-flight replanning on a UAV.

   • Diminishing returns:
     Our experiments in Table 1 also reveal diminishing returns:

     • 1 run → 56% success rate in finding a shortest-class path,

     • 5 runs → 74%,

     • 10 runs → 96%.
       Beyond 10 runs, the incremental gain in success probability is small compared to the 10× increase in latency.

   To make this reasoning explicit, we have added a dedicated paragraph in Section 2.2 explaining that 10 iterations (≈0.90 s total) are chosen as a deliberate engineering compromise between path optimality and real-time constraints on the STM32 platform.

 Comments 3
In table 1, the column headers may have mistakes, according to the presentation, the second and third column headers need to be changed. Besides, in the text wrote as 0.9 seconds, but in the table 1, wrote as 900 (no unit), should be with the same format and with the same unit.

Response:
Thank you for pointing out these inconsistencies.

• We have corrected the column headers in Table 1 to:
  Number of path planning | Success rate | Computation time, which now matches the description in the text.

• We have also standardized the time units in Table 1 and the corresponding text in Section 2.2. Previously, the table used a raw value “900” without units. This is now consistently expressed as 0.9 s, aligned with the current textual description (“0.09 s”, “0.42 s”, “0.9 s”).

Elsewhere in the manuscript, we still use milliseconds (ms) in Table 3 when a finer granularity is needed for profiling (e.g., 855 ms, 41 ms), but within each table and its associated text the units are now fully consistent.

 

 Comments 4
Typing mistakes, the title “stm32”, but in the text wrote as “STM32”... Figure 7 caption inconsistent... [25], delete the DOI.

Response:
We appreciate the reviewer’s careful reading of the manuscript and for highlighting these issues. In the revised version:

1. Capitalization of “STM32”:
   We have unified the use of “STM32” throughout the manuscript, including the title and body text, to ensure consistent terminology.

2. Figure 7 caption:
   The caption for Figure 7 has been corrected for punctuation consistency. The previous erroneous period after “MCU” has been removed, and the sub-captions have been standardized as:
   “(a) … (b) … (c) the STM32 MCU and (d) mission planning visualization.”

3. Reference [25] DOI:
   As suggested, we have removed the DOI from Reference [25], keeping only the standard bibliographic information.

4. Additional minor corrections:
   While addressing these points, we also took the opportunity to correct a few additional minor typographical issues not explicitly mentioned in the reviews (e.g., “UVA” → “UAV” in Figure 10, “lane-change maneuvers”, “long-term operation”), and to slightly refine several sentences in Sections 1–3 for smoother reading and clearer emphasis on the embedded implementation perspective.

We hope these edits improve the overall polish and readability of the manuscript.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

This paper validates a full RRT based smoothing planner implemented onboard on an STM32 microcontroller, achieving real-time UAV path planning with a low cycle time. I think this paper quality is enough to publish.

Author Response

Comments 1: This paper validates a full RRT based smoothing planner implemented onboard on an STM32 microcontroller, achieving real-time UAV path planning with a low cycle time. I think this paper quality is enough to publish.

Response 1:
We sincerely thank the reviewer for their encouraging comments and for recognizing the practical value of our work in implementing RRT on resource-constrained microcontrollers. We appreciate your endorsement of the paper's quality and its suitability for publication.