Improving Motion Safety and Efficiency of Intelligent Autonomous Swarm of Drones
Christoph Steup
Round 1
Reviewer 1 Report
This paper presents a novel approach in drone swarm optimisation using the EA algorithm ICA. The paper has shown a good contribution methodologically and experimentally. There are some corrections and structural comments for improving the paper, which I have explained in the attaced pdf.
Comments for author File: 
Comments.pdf
Author Response
Dear reviewer,
We earnestly appreciate the comments made by Reviewer #1, which help us to improve the quality of the manuscript, especially typos and grammatical mistakes. According to the suggestions, we have revised the manuscript carefully and correct all the mentioned typos and grammatical mistakes. In addition, we add two new subsections, section 6.5 and section 6.6, to analyze the reproducibility of the results and computational time complexity of the studied methods, respectively. We also update the figures and their corresponding captions.
Best regards, Amin Majd
Author Response File: 
Author Response.docx
Reviewer 2 Report
My thoughts about this paper can be best captured by one word: chaotic. I understand the problem, I understand the method, yet (after reading) I still do not understand how one matches the other. It is not helped by generally poor language that often stopped me in my tracks.
The paper itself deals with the safety-aware route planning with an addition of a coordinated collision avoidance manoeuvring. The former is described reasonably well (albeit with mistakes), the latter received much less attentions.
The paper itself seems to be the continuation of authors' earlier research [3]. The improvements lie in the consideration for dynamic obstacles and on-line re-scheduling.
The problem starts with assumptions, or rather with the lack of them. It starts with line 7 stating that the efficient implementation of the mission means the short travelling distance. Which is probably all right, assuming that the mission is about flying from A to B, the assumption that appears late in the text. There are other kinds of mission as well, one of them being stationary above the given location.
Another assumption, not stated in the text is that all this reasoning applies to a copter kind of drones, not e.g. to planes (used as an illustration on Fig.?), unless 'locations' are rather large.
Formalisation and simulation reinforced my observation. Locations form a regular grid. Note that this may invalidate some of the formalisations regarding collision. Requirement 2 states that they cannot occupy the same location simultaneously, but it still allows them e.g. to occupy adjacent locations and cross into the other one, colliding mid-flight. Thus the requirement 2, as formalised here, does not assure safety.
Line 27 (and later in the text) introduce five components, but neither critical instruction nor decision center are described in the text.
Line 104 introduces the concept od a preferential treatment, without indicating what form of a treatment it may be.
Line 109 introduces safety levels that relate to the number of crossing points and time gaps. It may require a form of evidence that indeed those two elements (and only those elements) decrease safety.
Lines 134-137 introduce the part of the proposed controlled mode, as well as the traffic controller. It assumes a lot: the existence of a two-way communication, the ability to manage the swarm remotely, the existence of the said traffic controller. Noe of them explicitly stated in the text. Further, it is not enough for the drone not to enter the potentially occupied air space, it is important that the drone leaves the space that it occupies as well.
Line 160: there is a promise that the proposed algorithm _guarantees_ the desired responsiveness. Without any statement of what is desired it is hard to judge whether it is true, and without any results that can demonstrate the validity of this statement I cannot accept is as a truth.
Line 257 and Fig.1. There is no match between a description and the diagram, i.e. is d1 red, green or blue? (after some effort, I figured out that it s - illogically - blue. Further, there is no 'travelled path' on Fig.1. at all, but it is in the legend.
Line 260 introduces the notion of a turning point, one per path. It is an unusual simplification that may prevent some paths from being constructed at all. Why not having several turning points on the path? Is there a reason for it? This limitation makes the whole algorithm very unrealistic, yet it is formalised as equation 5.
Line 279. Cross points. These are missing formalisation. Intuitionally these are situations where two paths include the same location, but there may be also situations where paths cross without such condition. Again, it makes an algorithms either constrained or unrealistic.
Equation 7. I am always weary of parameters appearing somehow from nowhere to optimise the optimisation function. The question here is: what are the conditions to choose one or other value of those parameters? Is there an algorithm to optimise it? How to measure the complexity of the flight zone?
Line 239: I would like to distinguish between experiments and simulation. Experiment, in my opinion, should include actual drones. So it is a simulation.
line 316: I would like to see the evidence that such recalculation is fast enough to catch up with the drone before it hits the other one. Specifically, that any calculation of this kind is either preformed centrally (hence it must be also sent to all the drones) or calculated by the warm itself (that may requires some form of a consensus).
line 321: The whole section about experimental results is missing several important pieces of information. For example: what is the origin of the implementation of other algorithms? What are the criteria used to formulate benchmarks?
Table 3 and 4. It seems at this point that the whole experiment was about running once two crafted benchmarks on seven implementations of which six are of unknown origin. It assures neither much validity to the simulation nor to its results.
section 6.4: I do not understand the impact of the dynamic obstacle, as shown on fig. 5. Convergence usually means that the algorithm converges to a stable solution over a defined support. During the run of the algorithm there is no space for taking into account new obstacles. Therefore I do not know what this section is all about.
line 398: .. the ability to foresee a risk of a collision.. This is indeed a distinctive feature. Shame that this statement appears only in conclusions and is not supported by the text. For example, it has no bearings for dynamic or unforeseen obstacles discussed in the text, as they - by definition - cannot be foreseen.
Language and notation problems, but only those that stopped me for a moment
line 1: mission-Physical: probably the capitalisation is wrong, but even so, I do not understand what is the mission-physical and how it differs from e.g. mission-logical or mission-virtual, if those exist.
line 21: good - probably goods.
line 26: to ensuring - probably 'to ensure'
line 93+7 (the line numbering went wrong). The union over one obstacle only? Probably instead of i1=1 there should be simply i=1
line 93+ 10 there is a capital J, should be small j
line 128: I am not sure what the two-way arrow is supposed to indicate: if and only if? convergence? A word of explanation will a long way.
line 129: priory - prior?
line 129: possibilistic? Is that so? Probably probabilistic.
line 141: overcome? One can overcome problems, not solutions.
line 160: prominent? Probably efficient.
line 205: EA - abbreviation without explanation
line 253: from a location to location. I guess 'from one location to another' or similar.
Fig.1 seems to be copy-pasted from [3] without a reference
line 310. drone2 - capitalisation
line 336: 1 dynamic obstacles - probably 'one dynamic obstacle'
Figure 3: 'suddenly obstacle' - probably 'unpredicted'
Author Response
Dear reviewer,
We highly appreciate the comments of Reviewer #2, which help us to improve the quality of the manuscript. According to the suggestions, we tried to apply all the comments one-by-one.
Best regards, Amin
Author Response File: Author Response.docx
Reviewer 3 Report
- The paper uses a very restrictive motion model, which prevents efficient solutions for diagonal flight to be even considered. Additionally, the inherent 3D motion capability if UAVs is ignored. The authors should justify the choice of this specific motion model
- The motion model uses a 4-Neighbourhood. This is essential for the collision freeness condition to be correct. However 8-Neighbourhood may generate much shorter paths. A discussion of the trade-offs between these neighborhoods and possibly their 3D extensions is necessary for the reader to assess the effects of the motion model
- The trade-off between a solution of the discretized solution and a solution of the underlying continuous problem is
neither discussed nor evaluated. Comparison against a typical continuous solution like single drone a* with reactive obstacle avoidance would help the reader in understanding the trade off - The used time model is not specified. Is the time also discrete like the locations? The effect of using a discretized
time is not discussed. - The approach is not multi-objective in the classical sense as the objectives are combined through weighted averaging to
a single objective and then a single objective EA is executed. The authors should correct this. - Visualization is good and should be kept
The example iterations are good, however the state of iteration 2 should also be fully included (route length,
collisions, fitness
...) - In the evaluation part the configuration of the EA is omitted. The population size, termination criterion need to be
specified to asses the complexity of the EA. - The effect of the amount of locations (the size of the flying zone) is not discussed and not evaluated. However, this has a
large impact on the run-time of the algorithm and is also a configuration parameter, which needs to be chosen by the user. - EAs are inherently randomized algorithms and need a stochastic evaluation, which is missing in this paper. The
benchmarks should be randomized and repeated multiple times to gather stochastically sound results.
Author Response
Dear reviewer,
We highly appreciate the comments of Reviewer #3, which help us to improve the quality of the manuscript. According to the suggestions, we tried to apply all the comments one-by-one.
Best regards, Amin Majd
Author Response File: Author Response.docx
Round 2
Reviewer 2 Report
I am not satisfied with changes made and I will try to address my concerns in a series of observations.
- Liberal use of promises that are not up-kept in the paper. For example, abstract promises the novel integrated approach that _ensures_ motion safety, only to drop it down in line 31 to claim that it _maximises_ safety. Frankly, neither is true (of which more below), but the authors have to decide which claim is a valid one: to ensure or to maximise. The same goes for a promised 'whole design process' (line 13) or 'solving' the NP-hard problem (line 44). It turns out that the problem is not solved, but only that the sub-optimal solution is provided.
- Line 37 brings an interesting note about how the algorithm ensures the safety: in case of conflict it stops all drones in their tracks and recalculates. It is of course not a great solution if there is a foreign object (be it a plane or a stone) flying into the drone, as the drone becomes a sitting duck. I would only say that the author's perception of safety may be different from mine, but as it is not defined anywhere, I will not elaborate on it.
- As for the formalisation, requirement 2 became a bone of contention. If anything, the modification made the constraint worse. First, there is an obvious mistake, as now t belongs to SWARM _and_ to [0..tmax]. Second, it still does not prevent collisions. Let's consider two adjacent locations x and y. Let's say that A is at x and plans to fly to y while B is at y and plans to fly to x. No location is occupied simultaneously by two drones (so requirement 2 holds), yet they will apparently hit each other in-between x and y. Granted, there is a further consideration of 'safe proximity distance, but (1) it is not designed to prevent this kind of collisions, and (2) it is not included in the pseudocode, so I am not sure whether it went to the actual algorithm. Same goes for the 'higher preference' (line 128) or for 'dangerous level' (Algorithm 1)
- Of less important mistakes, 4-neighbourhood is 2D, 8- neighbourhood is also 2D, 6- neighbourhood or 26- neighbourhood are 3D (line 156)
- Convergence. I still do not get the convergence analysis. Does it mean that the algorithm takes so long to calculate that the drone is allowed to fly with the algorithm not finished? Or does it mean that the dynamic obstacle can appear before the calculation ends, making the algorithm to re-calculate to a _new_ solution? Either way, it means that the algorithm does not seem to be real-time.
- Reproducibility. Running 10 times assures that results are the average taking into account inherently probabilistic nature of the algorithm itself, it does not assure that that the algorithm will behave reasonably under different condition - i.e.. that these are not the only two, carefully crafted scenarios where it behaves. So there is not an improvement here.
- Line 422 made me think whether the submission compared apples with pears. If other algorithms were allowed to generate collisions, then they are not really comparable. If collision avoidance is really a constraint, then comparing those that allow collisions with the one that does not allow collisions may not be correct.
- Performance. I understand that the algorithm runs two benchmarks in the stated time, but it does not make it fast or efficient. I expected some estimation of its complexity, to see whether adding another drone or another area will make the time skyrocket.
As for language errors, there are some still lingering in the text, e.g. the strange capitalisation in line 1 and line 30, but there is nothing critical. Note that the reference to the chromosome (line 153) appears too early in the text.
Author Response
We highly appreciate the comments of Reviewer #2, which help us to improve the quality of the manuscript. According to the suggestions, we tried to apply all the comments one-by-one.
Author Response File: Author Response.docx
Reviewer 3 Report
Even though the chosen neighborhood is discussed, the discussion is lacking.
- Firstly, 4 neighborhood and 8 neighborhood do not relate to 2D and 3D:
- Find below an illustration of 4 neighborhood and 8 neighborhood
4 Neighborhood:
o o o
|
o - x - o
|
o o o
8 Neighbourhood
o o o
\ | /
o - x - o
/ | \
o o o
- The authors answer regarding the algorithm complexity in 3D is understandable, but as visible above has nothing to do with the chosen neighborhood of the grid.
- It still needs to be discussed what changes of the results are to be expected if another neighborhood is used, because this is very relevant for practical applications.
- Additionally, it is unclear how the hyper-parameters of the used EA-based route planner were derived. If these are expert knowledge, the authors should give some hints to possible users of their algorithm. If these are found using some automated methods, please indicate them. Also please discuss the influence of these parameters on the results and on the convergence of the results.
Author Response
We highly appreciate the comments of Reviewer #3, which help us to improve the quality of the manuscript. According to the suggestions, we tried to apply all the comments one-by-one.
Author Response File: Author Response.docx
