A* Stuck Detection Result Is Discarded, Causing Repeated Planning Failure Until Timeout

Summary

When multiple drones block each other, the A* search may fail because the open list becomes empty or no feasible path can be found. In this case, OctopusSearch can compute that the planner is stuck through is_stuck.

However, this stuck status is not properly received or handled by the upper-level planning logic in rmader.cpp. As a result, the planner only returns false, while the drone continues to rely on the endpoint of the previous trajectory. The next planning attempt then starts from essentially the same blocked configuration, causing the same failure to repeat until timeout.

Relevant Code

The stuck detection is computed in:

rmader/rmader/src/octopus_search.cpp:1288

At this point, the lower-level search can determine that A* is stuck or unable to find a feasible path.

Problem

The current failure flow is:

drones block each other
        ↓
A* open list becomes empty or no feasible path is found
        ↓
OctopusSearch computes is_stuck
        ↓
rmader.cpp does not receive or handle the stuck result
        ↓
planning returns false
        ↓
the drone continues toward the endpoint of the previous trajectory
        ↓
the next planning attempt starts from the same blocked state
        ↓
the same failure repeats until timeout

The key issue is that is_stuck is treated only as a lower-level search result, but it does not trigger any upper-level recovery behavior.

Expected Behavior

When A* determines that the drone is stuck or no feasible path exists, the upper-level planner should explicitly handle this condition.

A safer behavior would be:

A* stuck condition detected
        ↓
propagate stuck status to the upper-level planner
        ↓
trigger recovery behavior, target reset, emergency stop, yielding, or replanning from a different state
        ↓
avoid repeatedly planning from the same blocked configuration

Actual Behavior

The current behavior is:

A* stuck condition detected
        ↓
stuck result is not consumed by rmader.cpp
        ↓
planning simply returns false
        ↓
the drone keeps relying on the previous trajectory endpoint
        ↓
the same planning failure repeats
        ↓
the task may eventually timeout

Impact

This can cause the planner to enter an ineffective repeated-failure loop when drones mutually block each other. Since the stuck condition is detected but not propagated to a recovery mechanism, the system may continue retrying from the same infeasible state instead of actively resolving the blockage.

This may lead to task timeout or persistent planning failure in dense multi-drone scenarios.

Start by tracing the stuck result at rmader/rmader/src/octopus_search.cpp:1288 into the upper-level planning flow in rmader.cpp. Determine where the result is discarded and how planning currently returns false. Done means the stuck condition reaches upper-level logic and a recovery behavior prevents repeated planning from the same blocked configuration; the specific recovery choice is not defined in the issue.