Review Reports

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

Review Comments for drones-3906163

Title: A Tactile Feedback Approach to Path Recovery after High-Speed Impacts for Collision-Resilient Drones

 

This paper has a complete overall structure and novel methods, especially making clear contributions in the aspects of haptic feedback path recovery and vector field path representation. However, there are still some issues regarding academic expression, logical consistency, experimental rigor and format details. The following are the main issues and suggestions I have sorted out:

1. Some sentences are lengthy or structurally unclear, such as "Meanwhile, the latter strategies struggle to recover in flight from high-speed collisions and often have computational requirements similar to the object avoidance strategies to adapt their path post-collision".
2. The physical prototype only has two tactile sensors (located at the front), but the model assumes that all 12 vertices can detect collisions, which may lead to a mismatch between the experiment and the model.
3. The sample size of "Monte Carlo simulations (10 trials each)" in Table 2 is relatively small. Especially for high-speed collisions (such as 8 m/s), there are only 10 trials, and the statistical significance is questionable.
4. There seems to be a clerical error in line 207 on page 8. See: "matching the intuition given in Section 4.2.2.2".
5. Some references lack years or page numbers, such as References [3], [4], and [5].
6. It might be more standard to write "8.5 × 6 × 5 cm" as "8.5 cm × 6 cm × 5 cm" in line 234 on page 9.

 

Author Response

1. Some sentences are lengthy or structurally unclear, such as "Meanwhile, the latter strategies struggle to recover in flight from high-speed collisions and often have computational requirements similar to the object avoidance strategies to adapt their path
post-collision".

We have broken up the sentence into two parts to increase clarity. We have further evaluated the manuscript for other sentences that are lengthy or structurally unclear and have similarly adapted them.

2. The physical prototype only has two tactile sensors (located at the front), but the model
assumes that all 12 vertices can detect collisions, which may lead to a mismatch
between the experiment and the model.

We have added clarification to section 5.2 Collision Resilient MAV and Section 6.3 Model Mismatch that acknowledges this discrepancy. We have also added an explanation that, although this discrepancy is indeed significant (especially for
ceiling and ground collisions), by mounting the two present contact sensors on the front of the MAV and orienting it with the velocity vector, most collisions are still captured as most collisions do happen at the front of the vehicle.

3. The sample size of "Monte Carlo simulations (10 trials each)" in Table 2 is relatively small. Especially for high-speed collisions (such as 8 m/s), there are only 10 trials, and the statistical significance is questionable.

We have re-run the monte carlo experiments with 100 trials per controller, per velocity. The data is available here
(https://drive.google.com/drive/folders/1WNm9-q96Ursf6ND77o3hiX2D9OHTicBc?usp=drive_link) or via our project page (https://antbre.github.io/Projects/colliding_drone.html). The results remain indistinguishable, with identical success and failure  patterns across all simulation cases. Table 2 and Section 6.1.2 have been updated accordingly.

4. There seems to be a clerical error in line 207 on page 8. See: "matching the intuition
given in Section 4.2.2.2".

We have fixed the clerical error by referencing the right paragraph.

5. Some references lack years or page numbers, such as References [3], [4], and [5].

We added years and page numbers to all references where it was missing.

6. It might be more standard to write "8.5 × 6 × 5 cm" as "8.5 cm × 6 cm × 5 cm" in line 234
on page 9.

We have used the more standard writing as proposed.

Reviewer 2 Report

Comments and Suggestions for Authors

The research is very innovative, interested, and well presented in the manuscript. However, there are some feedback to be addressed by the author to improve the manuscript:

1. It is better to put only the title in the caption of a figure. The detail explanation should be in the text.
2. Add structure of the manuscript at the end of chapter 1.
3. Place the figure on the same page with the text mentions it if possible.
4. Give detail on the simulation environments use.
5. Missing comparison results with another research in chapter 6. You should compare the result with another research in the same topic such as:

10.1109/RoboSoft55895.2023.10121952, 10.1109/ICRA48506.2021.9561089, 10.1109/TMECH.2023.3277811, etc.

6. Mention the result of simulation in the conclusion for comparison with the test flight result.

Author Response

1. It is better to put only the title in the caption of a figure. The detail explanation should be in the text.

We appreciate the feedback and have shortened some Figure captions accordingly. However, for readability’s sake we intend for every figure to be able to be understood standalone with its caption alone. Therefore we maintain the caption as minimal as possible, however with sufficient information to understand the overall figure.

2. Add structure of the manuscript at the end of chapter 1.

We have added the structure of the paper to the end of chapter 1.

3. Place the figure on the same page with the text mentions it if possible.

We have adjusted the figure and table placement throughout the manuscript where possible, in order to have them be on the same page as the mentions. When not possible, e.g., due to a large amount of figures being mentioned within a short paragraph, we have placed the figures as close as possible.

4. Give detail on the simulation environments use.

We have added more details on the simulation scheme in section 6.1. In particular we have added the information that the simulation is a custom C++ program that uses a fixed step explicit second-order integration scheme. Additional details can also be acquired from the code repository linked on the project page (https://github.com/BioMorphic-Intelligence-Lab/colliding-drone)

5. Missing comparison results with another research in chapter 6. You should compare the result with another research in the same topic such as: 10.1109/RoboSoft55895.2023.10121952, 10.1109/ICRA48506.2021.9561089, 10.1109/TMECH.2023.3277811, etc.

We have added the citation to the paper SCoReR (10.1109/RoboSoft55895.2023.10121952) in the introduction. We have also
pointed out that we go beyond this significant work as we not only detect but use the contact to improve state estimation and collision resilience at even higher speeds than what this work introduces. We have further added subsection 6.4 in which we compare our approach to conventional quadrotors and related work. Although direct comparisons are difficult as much of the related as well as our work relies on specific hardware implementations, we showcase that our proposed approach achieves recovery from the highest collision velocity while being one of the smallest and lightest overall systems. See the new manuscript for the comparison table.

6. Mention the result of simulation in the conclusion for comparison with the test flight result.

We have added a comparison between the simulation results and real results in the conclusion. In particular we have added the maximum recovery velocity in simulation and highlighted the model mismatch that we observe to the physical
experiments.

Reviewer 3 Report

Comments and Suggestions for Authors

The article submitted for review describes an interesting touch-based solution for path recovery after high-speed impacts in collision-resistant drones.
 
The article is well structured in formal terms, with the authors including clear sections describing successive issues such as modeling, estimation, control, and validation.

In my opinion, the integration of touch-based estimation with vector field planning presented by the authors in the article is an important and original contribution to the subject.
 
The experiments described by the authors are interesting and confirm the significance of the work performed.
Nevertheless, in my opinion, the authors should consider some improvements to the article. First of all, there is no comparison of the solution with previous works so that the authors' new contribution can be clearly observed.
This is not exactly my area of expertise, but it seems to me that there is a lack of analysis of the scalability of the solution and a discussion of the hardware limitations that will inevitably arise when scaling to more sensors.
In my opinion, there is also a lack of a more detailed analysis of the solution's operating time. Perhaps the results of measurements of the time from collision detection to device response would be useful?
In my opinion, there is a clear lack of emphasis on where such a solution would find good practical application (agriculture, rescue drones?).
In my opinion, the article is generally interesting but requires some corrections.

Author Response

1. First of all, there is no comparison of the solution with previous works so that the authors' new contribution can be clearly observed.

We have added subsection 6.4 comparison in which we rigorously compare our approach to related work and conventional MAVs. Although direct comparisons are difficult as much of the related as well as our work relies on specific hardware implementations, we showcase that our proposed approach achieves recovery from one of the highest collision velocities while being one of the smallest and lightest overall systems. Furthermore, our work is the only work that relies on simple binary tactile data for recovery instead of a more complex compliance allowing the additional required hardware to be very light-weight. See the new manuscript for the comparison table.

2. This is not exactly my area of expertise, but it seems to me that there is a lack of analysis of the scalability of the solution and a discussion of the hardware limitations that will inevitably arise when scaling to more sensors.

We have added clarification on where the limitations for the touch sensors stem from, in section 6.3. In particular we clarify that the limitations stem entirely from the hardware used, i.e. the limitations on the I2C bus of the Crazyflie Board. Furthermore, additional sensors would not increase the computational complexity as each additional sensor would only add 1 additional bit of data that would be transferred, but would not influence the computation. Therefore, in future iterations, with optimized hardware it is straightforward to add additional sensors.

3. In my opinion, there is also a lack of a more detailed analysis of the solution's operating time. Perhaps the results of measurements of the time from collision detection to device response would be useful?

We have added information about the response time of the system to the end of section 5. In particular, we explain that given its computational complexity of O(1), the entire chain from contact detection to response initiation runs on-board within a single logic cycle, therefore allowing the system to respond to collision within 2 milliseconds.

4. In my opinion, there is a clear lack of emphasis on where such a solution would find good practical application (agriculture, rescue drones?).

We have added additional use-cases of the proposed methodology to the introduction. In particular, the methodology allows MAVs to move faster in cluttered environments, even without remote sensing modalities, or under failure of these modalities, as collisions no longer pose a significant risk. This enables e.g., improved, faster search and rescue operations.

Reviewer 4 Report

Comments and Suggestions for Authors

1) Paper clearly argues that tactile sensing can help with recovery, but we need to see a stronger discussion of why this matters in practice. In other words, where exactly would drones benefit most from tactile-based recovery versus just using vision or LiDAR?

2) You say the system works up to 3.7 m/s in real flights. How does this compare to the speed range where drones usually fail?

3) Hardware prototype only has two sensors at the front, and this may heavily bias the recovery!! So, how confident are you that the approach generalizes to collisions from other angles?

4) Paper acknowledges a sim-to-real gap, however the sim assumes ideal sensor coverage (all 12 vertixes). Thus, this may overstate the results compared to your limited hardware implementation. We need some elaboration here.

5) You mention battery sag leading to brownouts at high impact speeds. I believe this this should be considered a core limitation of the approach!! (after all, if recovery only works in theory but the drone powers down, the method’s utility is limited.)

6) Moreover, you assume collisions only happen at the vertices. Realistically, the structure would hit edges or faces too. So, how much error does this simplification introduce?

7) The model assumes sliding friction only. Did you ever observe sticking contacts or multiple contact points at once in practice? And if so, how did the estimator handle that?

8) Although the KF is a key piece here, the tuning is described as heuristic. You should provide more systematic guidance or even experimental sensitivity analysis on how the results depend on tuning..

9) Expand the discussion on UAV system constraints and computational efficiency by citing the following recent studies on swarm UAV architectures that address communication limits, onboard processing, and energy-aware task distribution: [10.18280/ts.400524] by Bakirci and [10.3390/rs13061059] by Yasin et al. This would help position your tactile-feedback approach as a novel method for collision recovery, and also as part of a broader trend toward making UAVs more resilient and efficient under hardware and mission constraints.

10) Reflexive recovery moves the MAV along the surface normal. But what if the assumed normal is wrong (angled obstacles, curved surfaces, and so on...)?

11) You argue the method is computationally light, but much of it runs offboard with motion capture. Have you profiled how it would actually run on a small onboard processor?

12) Repulsive potential in the vector field grows from single collision points. This may risk under-representing larger obstacles. What do you say about this? (for example, one contact point on a wall might not be enough to model the wall as an obstacle)

13) You compare against accelerometer-based recovery. What about vision-based re-initialization or tactile odometry approaches? 

 

Author Response

1. Paper clearly argues that tactile sensing can help with recovery, but we need to see a stronger discussion of why this matters in practice. In other words, where exactly would drones benefit most from tactile-based recovery versus just using vision or LiDAR?

We have modified Section 1 to include a discussion of particular use cases where contact-based sensing is most beneficial. In particular we highlight that LiDAR is very power hungry and tends to be very heavy (upwards of 10 Watt and 500g) which makes it unsuitable for small drones. Furthermore LiDAR is also unable to detect transparent obstacles or operate in dusty and smoky environments. These limitations make tactile sensing particularly helpful for small MAVs operating in confined or visually degraded environments. This can enable applications such as improved and faster search and rescue with small MAVs.

2. You say the system works up to 3.7 m/s in real flights. How does this compare to the speed range where drones usually fail?

We have added section 6.4 where we compare our proposed approach to conventional MAVs as well as related literature. Here we add the information that from our monte carlo evaluation, collision-agnostic MAVs do not recover from collisions at speeds higher than 0.5 m/s. This is also supported by additional citations that we have added.

3. Hardware prototype only has two sensors at the front, and this may heavily bias the recovery!! So, how confident are you that the approach generalizes to collisions from other angles? Paper acknowledges a sim-to-real gap, however the sim assumes ideal sensor coverage (all 12 vertixes). Thus, this may overstate the results compared to your limited hardware implementation. We need some elaboration here.

We have added more details regarding these two points in section 5.2 and 6.3. In particular we add the information that while indeed the lack of sensors at the top and bottom are a shortcoming, with respect to detecting ceiling and ground collisions, the two front sensors cover a majority of the collisions. Since collisions tend to happen approximately in the direction of travel and the MAV always aligns the sensors with its velocity vector we are confident that within this proof of concept this setup covers nearly all collisions. To be more specific, also obstacles that are only vaguely aligned with the direction of travel are covered by these sensors as they will still collide even with obstacles displaced by large angles along multiple axes.

Furthermore, we point out that the limitation is purely because of non-optimized hardware, meaning that with new hardware the inclusion of additional sensors is straightforward. 

4. You mention battery sag leading to brownouts at high impact speeds. I believe this this should be considered a core limitation of the approach!! (after all, if recovery only works in theory but the drone powers down, the method’s utility is limited.)

We have added more clarification of this limitation to section 6.3. We acknowledge this limitation, which occurs only with low-charge batteries and can be mitigated by using larger batteries. While this would reduce maximum recovery speed, our goal is to explore the limits of the approach. Therefore, we optimized for minimal battery weight, accepting potential brownouts at low charge to maximize recovery velocity.

5. Moreover, you assume collisions only happen at the vertices. Realistically, the structure would hit edges or faces too. So, how much error does this simplification introduce?

We have added justification for this assumption in section 3. We acknowledge that this indeed introduces a simplification as in theory the strings connecting the edges of the icosahedron could indeed collide with very thin obstacles. However, these strings are very soft and do not significantly contribute to collision. Furthermore, the vertices form a convex structure around the rest of the body. I.e. These are the points with maximal distance from the CoM. Therefore they are the most likely points of contact. By assuming the vertices as the only possible contact points we achieve a tremendous reduction in computation requirements while only making a small sacrifice on accuracy as in most cases these nodes are indeed the contact points. Therefore we consider this a worthwhile tradeoff.

Lastly, the icosahedron does not have physical faces (they are defined by their three vertices), therefore these are not considered for collisions. 

6. The model assumes sliding friction only. Did you ever observe sticking contacts or multiple contact points at once in practice? And if so, how did the estimator handle that?

We have added an explanation for sticking vs sliding friction to section 6.3. In particular we acknowledge that the model assumes only sliding friction, while in reality sticking friction can occur. In practice, however, the contact time during collisions is very short such that both types of friction behave similarly, albeit exhibiting different friction coefficients. However, since the friction coefficient is estimated from data this effect is captured by the system identification process. 

We have also added a clarification with respect to multiple contact points in the end of section 3. In particular we explain that they are naturally handled by the summation of impulses. In experiments we observe that they occur in almost all simulations and experiments and are also handled explicitly in the filter without problems. 

7. Although the KF is a key piece here, the tuning is described as heuristic. You should provide more systematic guidance or even experimental sensitivity analysis on how the results depend on tuning..

We add additional information on how we tune the KF in section 4.1. In particular we explain that the KF measurement noise matrix is tuned to reflect the system’s measurement accuracies and the process noise matrix is tuned to allow for a fast convergence without amplifying the sensor noise. 

We further consider a sensitivity analysis outside the scope of this paper as tuning a KF is a very standard procedure, and a simple approach like the one above was sufficient for our purposes. 

8. Expand the discussion on UAV system constraints and computational efficiency by citing the following recent studies on swarm UAV architectures that address communication limits, onboard processing, and energy-aware task distribution: [10.18280/ts.400524] by Bakirci and [10.3390/rs13061059] by Yasin et al. This would help position your tactile-feedback approach as a novel method for collision recovery, and also as part of a broader trend toward making UAVs more resilient and efficient under hardware and mission constraints.

We appreciate the reviewers’ suggestions and have reviewed the suggested studies. We have added both works in the introduction section to position our work within the broader context of making MAVs more resilient.

9. Reflexive recovery moves the MAV along the surface normal. But what if the assumed normal is wrong (angled obstacles, curved surfaces, and so on...)?

We have added further justification of this assumption in section 4.2.1. In particular we acknowledge that this assumption might not be true as the MAV might strike an obstacle obliquely, however since each of the contact sensors covers surfaces with large angular offsets along two axes, the reactive behavior still achieves its purpose. By following the assumed normal, the MAV is still driven towards free space which allows it to recover. 

10. You argue the method is computationally light, but much of it runs offboard with motion capture. Have you profiled how it would actually run on a small onboard processor?

We have added details on which parts run onboard and offboard in section 4.2.2. In particular the trigger for the recovery maneuver is executed on board. 

Furthermore, since the method runs in O(1) it is suitable for a microcontroller. The reason it runs offboard is simply due to the historical setup of the architecture. As can be seen in this paper:

Wu, Xiangyu, et al. "Perception-aware receding horizon trajectory planning for multicopters with visual-inertial odometry." IEEE Access 10 (2022): 87911-87922.

in the past the baseline controller has also been run on-board without any issues. 

11. Repulsive potential in the vector field grows from single collision points. This may risk under-representing larger obstacles. What do you say about this? (for example, one contact point on a wall might not be enough to model the wall as an obstacle)

We have added clarifications for this in section 6.1. In particular we highlight that this is exactly what is being demonstrated in the experiment with the concave obstacle. Since the MAV is collision resilient larger obstacles can be represented by multiple repulsive potentials from multiple collisions. In the experiment we observe that indeed the MAV must collide multiple times with the obstacle until an escape path emerges. However, in all trials the MAV eventually has a sufficient representation of the model to avoid further collisions.

12. You compare against accelerometer-based recovery. What about vision-based re-initialization or tactile odometry approaches? 

We have added additional discussion about vision-based approaches during collisions to the introduction. In particular we explain that vision-based approaches are often too slow for collisions and diverge when discontinuous jumps in velocity occur. When trying to re-initialize during the collision additional problems occur, such as limited features, as the FoV of the camera is filled entirely with the obstacle, limited feature reliability due to larger motion blur in the recovery process. 

Regarding tactile odometry approaches we consider our proposed approach to be a low-fidelity tactile odometry approach as we exploit contact information to improve state estimation. However we consider more conventional tactile odometry approaches that use optical tactile sensors outside the scope of our work as the sensors are much heavier with very different computational and power constraints than our proposed approach.

 

Round 2

Reviewer 3 Report

Comments and Suggestions for Authors

The authors' responses to my suggestions and the changes made to the article are satisfactory, and I have no further substantive comments.

Reviewer 4 Report

Comments and Suggestions for Authors

Good job on the revision.