Discussion - Group 4 - 2018/2019, Semester B, Quartile 3

From Control Systems Technology Group
Jump to navigation Jump to search

<link rel="shortcut icon" href="https://www.tue.nl/favicon-64.ico" type="image/x-icon"> <link rel=http://cstwiki.wtb.tue.nl/index.php?title=PRE2018_3_Group4&action=edit"stylesheet" type="text/css" href="theme.css">

Discussion

Introduction

In the discussion, we want to touch upon some important aspects of the project. We take a step back from the content of the project itself and take a closer look at how the process went and what we can learn from these developments. It is not only the development of the process that can provide useful insights, but also the stumbling blocks encountered on the road towards the final result can provide useful insights.

Process and limitations

The very first thing of the project, namely picking a topic and what to exactly do with that topic proved to be the most difficult part. In the current day and age, where there are millions of exciting topics when it comes to robotics, it is tough to limit oneself to a single topic. While deciding on a rough draft of what to research was still quite doable and only took a few days, explicitly formulating the deliverables was much harder. The first week consisted of doing a literature study regarding drone interceptions, documented in the State of the Art. While meeting with the professors of 0LAUK0 during the first weekly meeting, it quickly became clear that researching `drone interceptions' was not explicit enough and way too broad. This issue resulted in us focusing more on drone interceptions and illegal drone activity surrounding airports in The Netherlands. Choosing all types of airports (commercial airports, airlines, et cetera) was done on purpose, and it was thought if this would be too broad, but everyone thought this would still be feasible.

Now that the research space was limited to illegal drone activity around airports in The Netherlands, the next steps could be taken. What would the deliverables look like? At first, a literature study seemed like the preferable option. We, however, thought this would be too short for the time we had for the course and thus decided to also design a decision model that airports in The Netherlands could use to decide what their `best' solution against illegal drone activity was. This overabundance of time quickly resulted in the group wanting to produce a recommendation report for airports located in The Netherlands.

Researching what types of decision models exist and which one we could use also proved to be quite tricky. There exist numerous types of decision models available, and therefore, it was rather hard to pick one based on the things we wanted to achieve. We thought we found the right type of decision model to use, but after working out the questions, we found that this did not work as well as we thought. Thus, we had to change the type of decision model we used. This change leads us to a different model, which worked significantly better for the idea we had in mind. It was still tough to design propositions based on the attributes of various solutions as most solutions had the same attributes. In parallel, we started working on a Web App that implemented this decision model. When it comes to communication during this process, it was rather rough. It being rough was partly due to planning not stating detailed deliverables for each week. We did try to incorporate the `delivering deliverables each week', but the deliverables were not explicit enough until we realised this issue. After this issue was brought up, it was tackled appropriately.

Main takeaways

The main takeaways from this project that should definitely be kept in mind in future projects are as follows:

  • Make the planning extremely detailed. Note down who should do what and when it should be finished. Make sure that the items in this planning are formulated as detailed deliverables rather than letting them be abstract ideas.
  • Verify the work of others against the deliverables described in the planning. Furthermore, talk about these things if they are not as they should be.
  • Meeting up together to work on certain aspects can be useful, but this should be minimised as much as possible. Using a planning with detailed deliverables and not more than two people on a certain item in the planning is preferable.

Objectives

Let us now consider all of the initially defined objectives in the project setup and if/how we met these.

  • Gaining insight into accidents and incidents involving various forms of drones.

We most definitely obtained insights into accidents and incidents involving various forms of drones in the `State of the Art' section. In short, we found that this number was raising and raising together with the number of customers of drones. Therefore, we can argue that we meet this objective.

  • Identify and specify the currently existing countermeasures and counter mechanisms against drones and UAVs in general.

We researched existing countermeasures against UAVs through literature research and simply looking at the market. We e-mailed various airports and obtained some responses. From the responses and the literature research, we observed that there were still little to no countermeasures against unwanted UAVs in place. Therefore, we can state that we meet this objective.

  • Identify and specify the USE stakeholders of the problem space and their interests regarding possible solutions.

The USE stakeholders of the problem space were analysed in-depth. That is, we considered multiple types of airports, namely commercial airports, recreational airfield, and military airbases. We provided an in-depth analysis of all of these regarding the issues they are specifically facing, a risk analysis, what a solution should provide for them, and what their characteristics are. Therefore, we can argue that we meet this objective.

  • Propose multiple possible solutions to the problem.

We did extensive research on solutions in two (or three) categories when it comes to solutions against unwanted UAVs. These categories are detection (and identification) and neutralisation. We offer many different types of solutions and also many specific solutions from companies that would solve part of the problem. Then, a combination of these solutions can be used as a `final' solution. Therefore, we can state that we meet this objective.

  • Identify the advantages and the disadvantages centered around user interests for each provided solution.

After collecting all solutions, we listed their advantages and disadvantages through filling in all of their attributes and observing how they performed against one another. Therefore, we can argue that we meet this objective.

  • Validate and verify that our proposed solutions solve the discussed problems with respect to the USE stakeholders and their interests.

When noting down each solution, it was heavily thought about if they would actually solve either the detection or neutralisation issue. This has also been described when it comes to all of the solutions. Therefore, we can state that we meet this objective.

  • Design a basic decision model around providing solutions for airports against UAVs.

A basic decision model was designed. The type of this design model was a VAA and it was heavily inspired by the Stemwijzer while making some improvements such as implementing the MoSCoW model in order to make the model fit our situation. Therefore, we can argue that we meet this objective.

Now, as we have met all objectives, we can conclude that we achieved all of the initially defined objectives successfully.

Deliverables

Let us now consider if the proposed deliverables as defined in the project setup have been finished and delivered.

  • A presentation regarding the problem and possible solutions

We have made a presentation regarding the problem description, our literature research, and the decision model we have made that incorporates all the solutions we found. Therefore, we can state that we finished this deliverable.

  • A literature study in the form of coherent Wiki pages in a hierarchical manner

The Wiki page of our group functions as the literature study. This literature study is available in two manners, namely a hierarchical structure of Wiki pages and a single page that incorporates the whole study. This latter was done as an extra based on the behaviour of many other groups. Therefore, we can argue that we finished this deliverable.

  • A Web App that implements a decision model

A Web App that implements the decision model has been finished. This Web App can be observed in the `Web App' section. Therefore, we can argue that we finished this deliverable.

Future development

Most of the areas for future development have been coined in Future.