Hardware testing

[shubham-shahh]

Hi, thanks for making this awesome project open-source. I was curious if this has been tested on the hardware.

I have a few questions related to the implementation: 1) The max_iter in non-formation optimization is set to 60 Vs 200 set here how much performance difference does it make?

2) In the current Implementation I see that if one of the UAVs is stuck somewhere, the others keep moving ahead, which I believe is a good thing in terms of a decentralized system but once it is able to navigate again, and since other agents are far away, its formation cost would go super high, would it generate any abnormal behaviors?

3) Behaviour-wise speaking, rather than moving ahead if one of the agents is stuck, if I am willing to enable a "stick together" sort of behavior, where the rest of the agents can slow down for it to catch up (the whole point of the collaborative swarm) is it possible with this approach?

4) The paper mentions, that formation is decoupled, but if the use_formation_ flag is enabled, it's part of the same optimization

thanks again

[SamuraiChamploo]

This project has been validated through real-world experiments and can be reviewed in the youtube.

For Q1. Performance difference of max_iter The impact of 'max_iter' is somewhat intricate to articulate directly. In simpler optimization scenarios, setting it to 60 or 200 might yield no significant difference, as the optimizer is likely to finish its task before reaching either of these max iterations. However, in more complex situations, a setting of 200 could enhance the quality of optimization to a certain extent, albeit at the cost of increased optimization time and a consequent impact on system responsiveness. Therefore, it's advisable to tailor this setting based on the specific conditions and requirements of your system.

For Q2 and Q3. Regarding the scenario where a drone deviates from the formation. It's important to note that this project was primarily designed to fulfill academic research purposes and did not extensively consider more intricate situations. The issue you mentioned indeed exists and has not been thoroughly addressed. In practice, when a drone diverges from the swarm, the rest of the group remains unaware of this separation. Consequently, they attempt to maintain formation during subsequent optimization processes. This can lead to certain undesirable effects on the optimization progress. As for the solution you proposed, I believe it is feasible.

For Q4. Regarding the explanation of the decoupled formation. The article defines decoupling in the context of a distributed framework. In this system, each drone independently executes trajectory optimization to maintain the overall formation. Hence, the formation is described as decoupled in the text. The 'use_formation' parameter is included to facilitate comparison. It allows you to observe the difference in overall performance when drones, operating under the same distributed framework, conduct trajectory optimization with and without considering formation.

[shubham-shahh]

This project has been validated through real-world experiments and can be reviewed in the youtube.

For Q1. Performance difference of max_iter The impact of 'max_iter' is somewhat intricate to articulate directly. In simpler optimization scenarios, setting it to 60 or 200 might yield no significant difference, as the optimizer is likely to finish its task before reaching either of these max iterations. However, in more complex situations, a setting of 200 could enhance the quality of optimization to a certain extent, albeit at the cost of increased optimization time and a consequent impact on system responsiveness. Therefore, it's advisable to tailor this setting based on the specific conditions and requirements of your system.

For Q2 and Q3. Regarding the scenario where a drone deviates from the formation. It's important to note that this project was primarily designed to fulfill academic research purposes and did not extensively consider more intricate situations. The issue you mentioned indeed exists and has not been thoroughly addressed. In practice, when a drone diverges from the swarm, the rest of the group remains unaware of this separation. Consequently, they attempt to maintain formation during subsequent optimization processes. This can lead to certain undesirable effects on the optimization progress. As for the solution you proposed, I believe it is feasible.

For Q4. Regarding the explanation of the decoupled formation. The article defines decoupling in the context of a distributed framework. In this system, each drone independently executes trajectory optimization to maintain the overall formation. Hence, the formation is described as decoupled in the text. The 'use_formation' parameter is included to facilitate comparison. It allows you to observe the difference in overall performance when drones, operating under the same distributed framework, conduct trajectory optimization with and without considering formation.

Hi, thanks for such an elaborate response, this clears a lot of my doubts. a few things to add, as you mentioned it is possible to slow down UAVs in case one of the UAVs is stuck, can you point out a possible approach I can use/implement on the planner to ensure, that they are allocated slower trajectories in case the single or few UAVs are out of formation?

for Q4, my understanding is based on flag_relan_astar_ flag use_formation will be triggered in case I am willing to use formation. Please correct me if there are any gaps in my understanding

[shubham-shahh]

Hi @SamuraiChamploo I am unable to find the code for (GRLR) and (ALAS)

[SamuraiChamploo]

The code for GRLR and ALAS relates to our latest work, which has not yet been open-sourced.

Please be patient for a while, as I am currently completing my PhD thesis and temporarily do not have the capacity to open-source the code for our latest work.