Multi-UAV collision avoidance capabilities of the MPC tracker: reasons for observing several collisions

[bconvens]

Hi,

I would like to compare your collision avoidance algorithms in a fair way with the ones I have developed. I am specifically pointing to your paper, where you show to have extensively tested the approach in simulation and in practice and that collisions never occurred.
That’s why I have some questions on the current capabilities and limitations of your collision avoidance strategy as I observe quite some collisions.

For benchmarking, I am using your mpc_tracker and se3_controller with the default settings your code comes with (these seem a bit different than the table in the paper above, but I found out it does not really help to increase the cylinder radius for example). The only changes I made are that I use RTK GPS odometry and disable the rangefinder. I use a point-to-point transitioning task where N (2-14) UAVs in 3D are requested to fly to the other side of a sphere. This creates high swarm densities in the sphere center.
I observe with your approach that the more agents used, the more inter-UAV collisions occur. Also, in the 3D task, I obtain more collisions compared to a similar 2D task in the horizontal plane.

As explained in your paper the UAVs move over the other UAVs based on their priority. I understand this sometimes requests UAVs to go so high in Z trying to get over all the other UAVs with higher priority that they still collide even though they move at a reduced horizontal speed. So, I conclude that this heuristic does not guarantee collision avoidance and wanted to check with you if I did not overlook something. So, if you could confirm that you observe the same as I and hence I did not use any wrong settings. Also, any task/parameter settings where your approach should generally work without collisions is also useful as I also want to compare the performance of the approaches in cases where no collisions occur. For example, I did tests with medium tracker gains, but do you consider the faster tracker gains safe enough for swarms too?

So, is this the reason why in the abstract it was stated that the priority-based collision resolution strategy performs sufficiently in experiments with up to 5 UAVs (and is not safe anymore with more UAVs)?
Correct me if I am wrong, but I also think that the reason your random flier task over 24h with 10 UAVs had no collisions came because this task intrinsically never forces a high swarm density?

Btw, I will also open source my projects (tested in simulation and on F450 hardware) once the paper is accepted so in case you are interested to use or improve that will be possible for sure.

Thanks for the discussion!
Bryan

[klaxalk]

Hey Bryan, you are correct. Our collision avoidance is not bulletproof and it is not that hard to create a situation which it can not handle. And that is exactly what you achieved. A fully 3D swarm where you intentionally cause a collision in multiple UAVs at the same time is something very difficult for the distributed approach, which relies on communicating relative altitudes and priorities. Moreover, sudden changes of the reference from a feasible into an infeasible can cause harm when the UAVs are close to each other. What happens is that the role of the UAVs is not decided/communicated fast enough in that situation. Moreover, the experiments I did for the paper are more 2D-like, where the collisions are not happening in arbitrary 3D for more UAVs at the same time. Moreover, there is a more to it:

• Our avoidance is NOT supposed to be used as the first tool in your toolbox to deal with complex situations like this. Contrary to that, it is supposed to be used as a "safety catch" for saving a user from occasional mishaps in his own dedicated trajectory generation mechanism. Most of the time, it does not need to deal with an all-to-all collision in arbitrary 3D. If that happens, the user is first to blame.
• A user, who's work is to generate desired trajectory references/velocity commands for each drone is supposed to provide a collision-free reference. This is where your work can potentially fit. Our approach is there as an underlying mechanism that is there always, however, users of the system should always act "like it is not there".
• The uniqueness of the approach is in its "transparency". It does not limit the users from supplying the common forms of reference (goto, trajectory, velocity) and it can intervene in the rare occasion that a user supplies an infeasible reference. However, if somebody provides a better mechanism for resolving collisions, I am all for it.
• However, a potential substitute should allow the user to continue with the flight, not just to stop the whole experiment (that is quite easy, but would lead to a lot of scrapped experiments for us).

Sincerely, Tomas

[bconvens]

Hi Tomas,
Thanks for confirming this behavior.
As follow up, I went in more depth though the mpc_tracker code and noticed that the inflation_radius in the mpc_tracker.yaml is not used in the mpc_tracker.cpp. It seem to be a hardcoded to a value of 1.0m that is used in the function checkCollisionInflated(). I don’t know if you prefer to keep it hardcoded to 1.0m, or use the inflation_radius yaml parameter instead?
Best, Bryan