Director Tools for Autonomous Media Production with a Team of Drones

Round 1

Reviewer 1 Report

The paper continues the authors' previous work. A set of tools for mission description in media production is proposed: (1) a novel language for mission description, and (2) a graphical tool (director’s Dashboard) for creating and managing XML-based shooting missions. The tools have been integrated into a real system with multiple drones within the framework of Horizon 2020 MULTIDRONE project. Results of example missions are shown.

Related work is profoundly described. The overview of the system is clearly presented and illustrated with 3 tables and 14 figures. On-line sources describing the system are given (incl. web links and videos).

The paper can be accepted in present form.

Author Response

Dear Editor and reviewers,

First, we would really like to thank the reviewers for their positive feedback and evaluation of our work. Second, we reply to reviewers' comments and suggestions one by one and explain how we addressed them in our revised version. 

Reviewer 2 Report

The concepts presented in the paper are very interesting from the perspective raised. All sections are fully explained and referenced. The use of XML as a language to define the missions makes the same an understandable and standard language, although it is true it would be interesting that the article also shows the structure of the data stored in the proposed database.

Another question regarding how to code the languaje of this mission definition is if exist the possibility of inplementation on JSON instead of XML due to its faster processing, although it is true that its structure is more complex to understand.
The architecture based on REST services is a very good option so that there is possibility to interact from other future interfaces.

The possibility of watching the simulation through a video is very interesting due to its usefulness when checking the operation of the system.

One weak point is that nothing is said about fault tolerance that may exist in the event that any of the actors fails:
Drones, controller, planner. Is there any type of system that allows the situation to be redirected in case of fail?

I want to ask the authors if it is possible using the definition of these tools with general purpose for the control of drones in other types of applications, such as control of fire in example.

Author Response

Dear Editor and reviewers,

First, we would really like to thank the reviewers for their positive feedback and evaluation of our work. Second, we reply to reviewers' comments and suggestions one by one and explain how we addressed them in our revised version. 

Reviewer's comment 1:

"The use of XML as a language to define the missions makes the same an understandable and standard language, although it is true it would be interesting that the article also shows the structure of the data stored in the proposed database."

Authors' reply:

This database model was not included in the first submitted version not to overload the paper too much, but we have compiled a schematic view of the database structure, and we have included it in Section 5.2 of the revised version.

Reviewer's comment 2:

"Another question regarding how to code the language of this mission definition is if it exists the possibility of implementation on JSON instead of XML due to its faster processing, although it is true that its structure is more complex to understand."

Authors' reply:

Actually, the Dashboard internally uses JSON to exchange data between the GUI and its backend. XML is used as the default export format (e.g., to send data to the Mission Controller) because it allows for simpler validation and more flexible extension using the XML schema. Also, the size of exchanged data is negligible (few KB) so the use of XML with respect to JSON does not add any valuable bottleneck. We have clarified this point in Section 5.2 of the revised version.

Reviewer's comment 3:

"One weak point is that nothing is said about fault tolerance that may exist in the event that any of the actors fails: drones, controller, planner. Is there any type of system that allows the situation to be redirected in case of fail?"

Authors' reply:

A paragraph about failure tolerance has been added in Section 3, in the overview of the system. In particular, the Mission Controller runs XML scheme validation in order to detect possible bad formatting in the mission description. Also, the Planner can provide additional feedback when the shooting mission is unfeasible due to the constraints imposed, warning the director. Last, the Dashboard offers the director the possibility to abort the mission if any problem is detected during the execution.

Apart from that, in the final whole system developed in MULTIDRONE project, there was another GUI just for safety management. This was a Supervision Station with a human safety supervisor monitoring the mission execution and also with the possibility to abort the mission. This was not included in the submitted version as it was not part of the scope of this paper. 

Reviewer's comment 4:

"I want to ask the authors if it is possible using the definition of these tools with general purpose for the control of drones in other types of applications, such as control of fire in example."

Authors' reply:

Indeed, the reviewer is right. The XML language could be extended to describe more generic missions for alternative multi-drone applications. We already have ongoing projects for multi-drone inspection and surveillance, where we are trying to use similar concepts. We added this idea as future work.