PRE2020 1 Group3: Difference between revisions
TUe\s164234 (talk | contribs) (→Users) |
(→Week 8) |
||
(197 intermediate revisions by 4 users not shown) | |||
Line 23: | Line 23: | ||
Our objectives for the end of this project are to deliver: | Our objectives for the end of this project are to deliver: | ||
- Central communication and routing system | - Central communication and routing system (the terms 'ground control system' and 'air traffic management system' are used interchangeably for this throughout this Wiki-page) | ||
- Corresponding drone to system communication code | - Corresponding drone to system communication code | ||
- Literature study on the USE impact of | - Literature study on the USE impact of delivery drones | ||
- Literature study on the legal aspects of commercial autonomous drones | - Literature study on the legal aspects of commercial autonomous drones | ||
= User | = User, Society and Enterprise = | ||
==Users== | ==Users== | ||
Line 38: | Line 38: | ||
===Delivery companies=== | ===Delivery companies=== | ||
As mentioned there is no real distinction between delivery companies on behalf of what they deliver. The delivery process will be entirely the same regardless of what is delivered. For convenience we neglect the fact that food can get cold along the way. So for a package delivery to be successful the autonomous drone will have to be equipped with the package, take off from either a truck or a distribution center, fly to the destination without colliding with something and then safely deliver the package. In this project we focus on the part where a drone needs to fly to the destination without colliding. There are multiple things that are important for delivery companies, such as safety, accuracy and | As mentioned there is no real distinction between delivery companies on behalf of what they deliver. The delivery process will be entirely the same regardless of what is delivered. For convenience, we neglect the fact that food can get cold along the way. So for a package delivery to be successful the autonomous drone will have to be equipped with the package, take off from either a truck or a distribution center, fly to the destination without colliding with something and then safely deliver the package. In this project we focus on the part where a drone needs to fly to the destination without colliding. There are multiple things that are important for delivery companies, such as safety, accuracy and delivery time. | ||
===Consumers=== | ===Consumers=== | ||
The group of consumers basically consists of everyone who will make use of this service, whether they specifically ask for this type of delivery or they do not specify this. Since most people in the Netherlands | The group of consumers basically consists of everyone who will make use of this service, whether they specifically ask for this type of delivery or they do not specify this. Since most people in the Netherlands have packages being delivered at home sometimes, this group will consist of the majority of the population. Their biggest interest is, of course, to receive the package undamaged, and as soon as possible. Because we will not take a look at the transfer of the package, the safety of the receiver will not be discussed here as it does not come into dispute. | ||
Several studies have been conducted about consumers acceptance of delivery drones, as acceptance is needed to implement this piece of technology in our society. There are a couple of factors that influence people's attitude towards drone delivery, which in turn influences their intention to use it. These factors consist of the perceived risks, functional benefits and attributes of the technology. <ref> [https://onlinelibrary.wiley.com/doi/epdf/10.1111/ijcs.12487 Khan, R., Tausif, S., & Javed Malik, A. (2019). Consumer acceptance of delivery drones in urban areas. International Journal of Consumer Studies, 43(1), 87-101.] </ref> <ref> [https://doi.org/10.1080/09537325.2016.1242720 Zahy B. Ramadan, Maya F. Farah & Mona Mrad (2017) An adapted TPB approach to consumers’ acceptance of service-delivery drones, Technology Analysis & Strategic Management, 29:7, 817-828] </ref> | |||
Another study shows that individual characteristics play a role as well, and have found a distinction between factors that influence people living in urban and rural areas.<ref> [https://reader.elsevier.com/reader/sd/pii/S0736585318300388?token=58A955B781A013D3B265520E09F1A7A7D95D56404542898A65D600901F953FD16C1EB889E5A36D77C050D7180FDA098F Yoo, W., Yu, E., & Jung, J. (2018). Drone delivery: Factors affecting the public’s attitude and intention to adopt. Telematics and Informatics, 35(6), 1687-1700.] </ref> The relative advantage of environmental friendliness only affected the attitude of the rural residents (positively). Performance risk negatively affected the attitude of only the urban group, while privacy risk negatively affected attitude only in the rural group. Urban residents seemed to be more worried about property damage, missing their goods, or danger due to the malfunction of drone delivery. And since a drone may deliver parcels to the inner space or yard of customers’ house in rural areas, privacy risk might be a more important issue to rural residents. | |||
====Questionnaire==== | |||
For us to gain a better understanding of the current attitude of the public towards delivery drones, and to identify what is needed still, we created a survey. It became clear that most people like the idea of delivery drones, but there are still concerns. | |||
[[File:questionnaire_delivery_drones.PNG]] | |||
We followed up by asking what the most important aspects of the delivery drones would be for them as costumers. Their results are depicted in the table below. Participants could select multiple answers. | |||
{| border=1 style="border-collapse: collapse;" cellpadding = 2 | |||
! | |||
! percentage | |||
|- | |||
| privacy | |||
| 20% | |||
|- | |||
| safety: collisions leading to physical damage to either the drone or the to be delivered good | |||
| 53.33% | |||
|- | |||
| safety: hacking | |||
| 40% | |||
|- | |||
| accuracy in delivering (your neighbour receiving your delivery instead of you) | |||
| 26.67% | |||
|- | |||
| no-drone zones, i.e. nature areas | |||
| 20% | |||
|- | |||
| crowdedness in the air | |||
| 20% | |||
|- | |||
| fast delivery | |||
| 20% | |||
|} | |||
As becomes clear from these percentages, the most important thing is safety. This also came out in the elaboration of their answers. The most important thing for people is that their packages reach their doorstep safely. This implies safety in the air, no collisions taking place, and that the drone should not get hacked or sabotaged in any other way. Some people related the option 'crowdedness in the air' to safety as well: if there are many drones occupying the sky, chances are high that dangerous situations will emerge. The other people who filled out this answer are mainly concerned about the noise and nuisance drones give when present in big numbers. | |||
Therefore, the most important things that people would like to see/guaranteed are that drones can not get hacked, no privacy violations by potential cameras, and no nuisance. | |||
Lastly, when asked about the biggest potential/positive of delivery drones, people were unanimous: drone delivery poses options for (much) faster delivery, and also a few people mentioned they thought it would be better for the environment. | |||
==Society== | ==Society== | ||
For society, there are different stakeholders to be recognized. Firstly the government, who is in charge of the legislation of the delivery drones. Inhabitants of high-density delivery areas are another group of interest here. Animal rights and environmental organizations will also play a role, as they seek to protect sensitive areas from this type of technology damaging it. Lastly, connected to the last group of stakeholders, are the other users of the airspace - mainly birds and other flying wildlife. | For society, there are different stakeholders to be recognized. Firstly the government, who is in charge of the legislation of the delivery drones. Inhabitants of high-density delivery areas are another group of interest here. Animal rights and environmental organizations will also play a role, as they seek to protect sensitive areas from this type of technology damaging it. Lastly, connected to the last group of stakeholders, are the other users of the airspace - mainly birds and other flying wildlife, but also hobby drones. | ||
Most concerns that people have on the user level also apply for society as a whole. As became apparent from previous research and our own survey data, the most important concern is safety, and this does not go for users alone; it is also very important to other stakeholders. Especially the risk that a drone will drop from the sky and hit someone or something is an important situation to consider, and the risk of a drone being hacked and letting it crash deliberately can also not be underestimated. In order to avoid this, the drone itself will have to be very reliable, especially when they are being deployed in big cities. Besides security, the system should work flawlessly to make sure that they do not only avoid other delivery drones but also static objects like electricity lines or high buildings. Also moving objects like birds or recreational drones that are not connected to the system should be avoided. | |||
Besides safety, there is also the problem of nuisance, for example, noise disturbance or invasion of privacy. <ref>[https://fas.org/sgp/crs/misc/delivery.pdf/ Delivery drones: coming to the sky near you? Heerkens, J. (2015)]</ref> | |||
When drone delivery becomes more and more common, fewer humans are needed for the same amount of packages delivered. It could be that some people will lose their job because of this. On the other hand, nowadays the delivery companies have great trouble in handling all deliveries and making sure they arrive on time. This system, therefore, has the potential to relieve the pressure of the deliverers without a loss of job opportunity. How this will evolve mainly depends on what kind of deliveries will be autonomous and at what frequency they will be executed. | |||
When | When the sky will be used more often, there unavoidably arises a threat to wildlife <ref> [https://www.cambridge.org/core/journals/environmental-conservation/article/drones-as-a-threat-to-wildlife-youtube-complements-science-in-providing-evidence-about-their-effect/E433B815520AE5EE10C9168A5CEEEFA8/ Drones as a Threat to Wildlife: YouTube Complements Science in Providing Evidence about Their Effect. Rebolo, N. Grilli, M. Lambertucci, S. (2019)] </ref> Where two drones connected to the same system are relatively easy to guide passed each other, it becomes a lot harder to avoid a bird which could fly at a speed of 70 km/h <ref> [https://www-jstor-org.dianus.libr.tue.nl/stable/4070460?seq=1#metadata_info_tab_contents/ The Speed of Birds. The Auk, 23(4), 479-479. Lucas, F. (1906).] </ref> A good start to tackling this problem would be to prohibit drones from flying over forests, but this does not eliminate the risk. A very sophisticated anti-collision system with radar would be required to exclude this risk. | ||
However, even when all the above problems are dealt with in an appropriate way, it seems impossible that nothing will go wrong. Because these are autonomous systems, it is a difficult task to point out who is responsible. This could give rise to ethical discussions which nowadays are already being held about self-driving cars <ref> [https://www.tandfonline.com/doi/full/10.1080/08839514.2016.1229759/ Responsibility and the Moral Phenomenology of Using Self-Driving Cars. Coeckelbergh, M (2016).] </ref> When, for example, a drone suddenly falls out of the sky and hits a pedestrian without having the certainty that it is a technical failure or a minor collision with a bird that caused it, who is responsible? If this happens more regularly, it is likely that people will change their minds about this technology and do not make use of it at all. In fact, this probably needs to be sorted out before the deployment of delivery drones, so that when accidents do occur, there is no uncertainty and ambiguity. | |||
==Enterprise== | ==Enterprise== | ||
This group is formed by the | This group is formed by the companies developing the air traffic control system and its stakeholders. | ||
Before this system will be available, it will still need to overcome technical challenges as well as some legal requirements. To find out more about these challenges we contacted Avular, a startup company in Eindhoven which, among other things, is doing research about this topic. They mentioned that the three biggest challenges of today were perception, weight and certification. As mentioned before for this project we will mainly focus on the problem of perception, i.e. the ability of these drones to maneuver past static obstacles and avoid moving obstacles. However in order for a company to develop this system all challenges need to be dealt with in an appropriate way. For the problem of weight this means that the capacity of a battery per kilogram will need to increase. Because more and more devices are being equipped with batteries, constant progress is made on this side so in the future this will become less of a problem. In terms of legal requirements there is also some progress (see | Before this system will be available, it will still need to overcome technical challenges as well as some legal requirements. To find out more about these challenges we contacted Avular, a startup company in Eindhoven which, among other things, is doing research about this topic. They mentioned that the three biggest challenges of today were perception, weight and certification. As mentioned before for this project we will mainly focus on the problem of perception, i.e. the ability of these drones to maneuver past static obstacles and avoid moving obstacles. However in order for a company to develop this system all challenges need to be dealt with in an appropriate way. For the problem of weight this means that the capacity of a battery per kilogram will need to increase. Because more and more devices are being equipped with batteries, constant progress is made on this side so in the future this will become less of a problem. In terms of legal requirements there is also some progress (see [[PRE2020 1 Group3#Legal requirements|Legal requirements]]) made for commercial drones to be deployed. | ||
Another reason why weight and battery capacity might not be a big problem, is because the so called ‘last mile delivery’ is the concept that companies seem most interested in <ref> [https://www.semanticscholar.org/paper/Coordinated-Logistics-with-a-Truck-and-a-Drone-Carlsson-Song/23a43524fd5168acfd589e919c143f49a6eeeac3/ Coordinated logistics with a truck and a drone. Carlsson, J. and Song, S. (2017)] </ref>. This means that a truck will drive through a neighbourhood and lots of delivery drones will depart from the truck and only have to fly a relatively small distance to reach their destination. This could make the system potentially more efficient than delivery seen nowadays <ref> [https://doi.org/10.7249/RR1718.2 Xu, Jia, Design Perspectives on Delivery Drones. Santa Monica, CA: RAND Corporation, 2017.] </ref>. | Another reason why weight and battery capacity might not be a big problem, is because the so called ‘last mile delivery’ is the concept that companies seem most interested in <ref> [https://www.semanticscholar.org/paper/Coordinated-Logistics-with-a-Truck-and-a-Drone-Carlsson-Song/23a43524fd5168acfd589e919c143f49a6eeeac3/ Coordinated logistics with a truck and a drone. Carlsson, J. and Song, S. (2017)] </ref>. This means that a truck will drive through a neighbourhood and lots of delivery drones will depart from the truck and only have to fly a relatively small distance to reach their destination. This could make the system potentially more efficient than delivery seen nowadays <ref> [https://doi.org/10.7249/RR1718.2 Xu, Jia, Design Perspectives on Delivery Drones. Santa Monica, CA: RAND Corporation, 2017.] </ref>. | ||
Like mentioned earlier is seems very unlikely that there will never occur an accident. For companies who are going to sell this delivery drone system it is important to have clear laws about when they are responsible, and when they are not. Avular mentioned for example that if it is a certain technical error they are willing to take the blame. However if a delivery company decides to use the drones when weather conditions are not good enough, they will certainly not. This seems fair, but it becomes a lot harder when there is no clear cause and there is a bit of a grey area. To prevent issues like this clear government regulations are needed. | Like mentioned earlier is seems very unlikely that there will never occur an accident. For companies who are going to sell this delivery drone system it is important to have clear laws about when they are responsible, and when they are not. Avular mentioned for example that if it is a certain technical error they are willing to take the blame. However if a delivery company decides to use the drones when weather conditions are not good enough, they will certainly not. This seems fair, but it becomes a lot harder when there is no clear cause and there is a bit of a grey area. To prevent issues like this clear government regulations are needed. | ||
= Use Cases = | |||
The system that will be designed basically consist of two different ways to avoid collision. Besides the ground control system there is an active anti-collision system on each drone. Because of this there could be some situations where it is not entirely clear what the drone should do, therefore we described a few use cases below. As a general rule it can be stated that the active anti-collision system on each drone will always overrule the instructions of the ground control system. | |||
== Use Case 1 == | |||
'''A delivery drone needs to take an avoiding action to prevent a collision with a private drone or a bird, i. e. a moving object which does not communicate with the ground control system. Therefore it is no longer in the desired position and it comes in the path of another delivery drone which is approaching.''' | |||
In this case it depends if the ground control system is able to calculate a new trajectory for this delivery drone before it comes into a distance of 10 meters from the other one. If the system is on time with this, the problem is solved and the drone that was out of direction will receive a new trajectory. If this will not happen on time, so not before the drones come within 10 meters of each other, an avoiding action will need to be taken by either only the drone that is out of position, or by both drones. Which of the two it is going to be depends on the speed and orientation of the two drones. The best solution is the one where both drones will lose as little time and energy as possible to avoid collision, and it depends on the situation if the trajectories of both drones will have to be adjusted for that. | |||
== Use Case 2 == | |||
'''The ground control system fails and cannot send commands to the drones anymore. Some drones will no longer be on their predefined path because of avoiding actions they had to take.''' | |||
In the rare event that the system does not work due to some error, all drones initially connected to the system are to hover in the air. If after 10 minutes no reconnection to the system has been established, they should descend and land using the anti-collision system, which is still fully operational as it operates independently from the ground control system. Drones that are in rural areas should land somewhere in a safe place, for example a grassland, and wait until the system will be able to give them commands again. In urban areas this would be more difficult and specific landing areas on top of roofs would have to be created. Once a drone has landed on such place, the minimum distance of 10 meters towards a drone in the air will be cancelled in order to make sure they can land close to each other. When hovering in the air for 10 minutes is not feasible, for instance due to an almost empty battery, the drone should land immediately. | |||
== Use Case 3 == | |||
'''A private drone which is connected to the system, but operated by a civilian is making weird and unpredicted movements, which makes it very hard to calculate a safe trajectory to pass it.''' | |||
Flying a private drone manually in urban areas will be prohibited, and outside urban areas they will need to be connected to the system. When someone is flying such a private drone in rural areas and a delivery drone comes nearby, the user of the private drone will receive a warning that the delivery drone is coming, and will be asked to hold the drone stationary until it has passed. If the person will not obey this command, the drone can temporarily be taken over by the system and held stationary, until the delivery drone has passed. | |||
When someone will actually break the law and fly a drone that is not connected to the system, the anti-collison system of the delivery drone will prevent an encounter when the drones coming too close. | |||
= Legal Requirements = | = Legal Requirements = | ||
Drones used for recreational goals are already becoming more and more common. Because some of these drones are equipped with cameras, the privacy of people is in danger. Also the noise can be disturbing when they fly too low over residential areas. When delivery drones will be deployed more often in the future, these problems will become even bigger. For this reason the Dutch government already made laws for | ==The Netherlands== | ||
Drones used for recreational goals are already becoming more and more common. Because some of these drones are equipped with cameras, the privacy of people is in danger. Also, the noise can be disturbing when they fly too low over residential areas, and the biggest danger: collisions. When (delivery) drones will be deployed more often in the future, these problems will become even bigger. For this reason, the Dutch government already made laws for the use of drones, divided into recreational and commercial. | |||
Firstly, recreational drones are not allowed to fly higher than 120 meters above land or water. They can't weigh more than 25 kilograms (including cargo) and always need to be visible. This has two implications: you are only allowed to fly a drone during the day and it needs to be in your line of sight. And, maybe even most importantly, there are a lot of areas specified where recreational drones cannot come closer than 50 meters, measured from the ground. Places like this are<ref>[https://www.rijksoverheid.nl/onderwerpen/drone/regels-hobby-drone/ 'Laws concerning drones]</ref>: | |||
• big crowds | • big crowds | ||
Line 77: | Line 143: | ||
• contiguous buildings | • contiguous buildings | ||
• | • harbours | ||
• | • industrial area’s | ||
• | • railways | ||
• | • highways | ||
• | • ships | ||
• | • airports | ||
To make this more clear, a map of the Netherlands with all so-called | To make this more clear, a map of the Netherlands with all so-called 'no-fly zones' is available: | ||
[[File:kaart_drones.PNG]] | [[File:kaart_drones.PNG]] | ||
Line 95: | Line 161: | ||
'''Red''': no-fly zone | '''Red''': no-fly zone | ||
'''Blue''': only when permission | '''Blue''': only when granted permission | ||
'''Purple''': low-fly area | '''Purple''': low-fly area | ||
For now, the commercial use of drones is not allowed in the Netherlands, except when you have the right permit and papers. There are two types of permits in the Netherlands: ROC and ROC-Light. The implications for ROC-light are as follows: the maximum height you can fly with your drone is 50 meters and the maximum distance you can fly (horizontally) is 100 meters and is not allowed in controlled airspace. It always needs to be visible (being both daytime and in line of sight), it needs to weigh less than 4 kilograms and needs to keep a distance of 50 meters from buildings, crowds and obstacles. To be in charge of such a drone you need to be at least 18 years old and in possession of a drone theory certificate. For a ROC permit, the rules are almost the same, with a few exceptions: the maximum height is 120 meters, the horizontal distance is maximum 500 meters and the weight needs to be less than 150 kilograms. For the drone operator, there are also some additional requirements: a medical test is mandatory, as is liability insurance and technical examination of the drone. <ref> [https://www.drone-nieuws.nl/drone-wetgeving-en-regelgeving-in-nederland.html] </ref> | |||
/ 'EU laws drones]</ref>. | |||
Apart from the non-permitted use of commercial drones, delivery by drones is almost impossible, as almost all of the big cities in the Netherlands are covered by no-fly zones and delivery options are scarce when drones are only allowed in the line of sight of an operator. This shows that the law is not completely ready for this technology. Luckily, the rules will change as per December 31rd, 2020, when the European Union will get the same regulations for unmanned aircraft systems. This date was originally July 1st, 2020, but that deemed impossible due to the corona crisis. | |||
==European Union== | |||
According to the regulations laid out by the European Union Aviation Safety Agency (EASA), drones will be divided into three categories: Open, Specific and Certified. This distinction will be based on safety and privacy risks. The first category, the Open category, makes no distinction anymore between recreational or professional usage: it only matters if the flights of the drone impose low risks. There are three subcategories in this Open category, with the criterium being weight. The main difference between these subcategories will be the distance needed to be held from people on the ground. We will not elaborate on this further, as delivery drones won't be classified in the Open category. Another important new requirement is that every drone-operator (being a person or a company) needs to register at an online system (read more at [[PRE2020 1 Group3#U-space|U-space]]), the only exception being drones weighing less than 250 grams without cameras - these are regarded as toys. For the operator: the minimum age is 16 years old and an online training and knowledge test need to be passed. Also, liability insurance is required. The distance requirements about traffic areas, buildings and other objects expire and are replaced by the requirement that these drones are not allowed to fly above crowds, people not involved with the drone operation or near airports and controlled airspace (within 3 kilometres). The height constraint of 120 meters remains, as does the visual line of sight. Lastly, CE marks become mandatory for drones. | |||
The second category is the Specified category. Drone operations fall into this category when there is more risk involved, for instance when wanting to fly higher than 120 meters, flying with a drone of more than 25 kilograms or operations near people. Permission for a flight in this category will be granted after risk analysis is approved. Considering risk management, there are three options: Specific Operations Risk Assessment (SORA), Pre-Defined Risk Assessment (PDRA) and Standard Scenario (STS). A company can get a Light UAS Operator Certificate (LUC), which enables it to assess its own risk analysis. Again, we will not elaborate on these matters, as this is most probably not the category delivery drones will belong to.<ref>[https://www.dronewatch.nl/2019/04/12/dit-is-wat-de-invoering-van-de-europese-drone-regelgeving-medio-2020-voor-nederland-gaat-betekenen/ | |||
/ 'EU laws drones]</ref>. | |||
Then, lastly, the category most probable to contain delivery drones: the Certified category, for operations with high risk. High risk can be heavy drones flying above crowds, delivery drones in urban areas or even passenger transport. Now, the operational requirements are not yet worked out by EASA, but are expected in the course of 2021. This is also because regulations will most likely look like that for manned aviation, and are therefore also partly dependent on the development of [[PRE2020 1 Group3#U-space|U-space]]. <ref> [https://www.dronewatch.nl/2020/09/11/eu-droneregels-de-certified-categorie-uitgelegd/] </ref> | |||
[[File:EASAcategories.PNG|1200px]] <ref> [https://dronerules.eu/sl/professional/eu_regulations_updates] </ref> | |||
= U-space = | |||
Unlike the name suggests, U-space is not another airspace classification, such as Classes A-E for controlled airspace. Rather, it is a collective of services and procedures to secure safe access to the airspace for a large number of drones. A collaboration between the public and the private sectors, it addresses solutions to two fronts: regulatory requirements and practices, and technological solutions. According to their blueprint <ref> [https://www.sesarju.eu/u-space-blueprint Undertaking, S. J. (2017). U-space Blueprint. SESAR Joint Undertaking. Accessed September, 18.] </ref>, these are the key principles of U-space: | |||
- safety of all airspace users | |||
- provide a scalable, flexible and adaptable system | |||
- enable high-density operations with multiple automated drones | |||
- guarantee equitable and fair access to airspace | |||
- enable competitive and cost-effective service provision | |||
- minimise deployment and operating costs by leveraging existing aeronautical services and infrastructure | |||
- accelerate deployment by adopting technologies and standards from other sectors | |||
- follow a risk-based and performance-driven approach when setting up appropriate requirements while minimizing environmental impact and respecting the privacy of citizens | |||
The services of U-space will be rolled out over time in different 'phases', meaning that both automation and connectivity of the drone will increase. | |||
'''U1: fundamental services''' | |||
The foundation services are electronic registration, electronic identification and geofencing. In line with the aforementioned legislation, drones above 250 grams need to register digitally. These registers will also be interoperable and accessible in real time. Of course, electronic registration lays the foundation for electronic identification. Regarding geofencing, for the first phase, it will just be pre-tactical; availability of information prior to take-off. | |||
'''U2: initial services''' | |||
The second phase has its focus on the management of drone operations, as it will include flight planning, flight approval, tracking, dynamic airspace information and interfaces with air traffic control. Therefore, in contrast to the fundamental services of U1, it will aim at tactical geofencing; providing updated information during the flight. | |||
'''U3: advanced services''' | |||
As apparent, by the time phase U3 comes around, the airspace will be a lot more controlled. U3 takes it a few steps further: it will support more complex operations in dense areas and therefore implements detect and avoid functionalities. It will also provide more reliable means of communication. | |||
'''U4: full services''' | |||
The last phase will provide complete integration with manned air traffic and all services provided in the airspace. It will thus support the full operational capability of U-space and will rely on a very high level of automation, connectivity and digitalisation. However vague this sounds, it is for a good reason, as it is not clear - not even in the slightest way actually - how the full integration of drones into the aviation network will look like <ref> [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3408673 Huttunen, M. (2019). The u-space concept. Reprinted from Air & Space Law, 44(1), 69-89.] </ref>. | |||
=Cost Analysis= | |||
Nowadays parcels are delivered by a person who drives around with a heavy truck and goes by all the destinations. Therefore all packages are being taken to every location. Not only is this method inefficient in terms of emissions, it also takes a lot longer than is needed. Not to forget, the roads are already very occupied in the Netherlands and with the expected increase in parcel delivery the coming years this will only get worse if methods of delivering will not change. Besides all this, drone delivery has the potential to be also more cost-effective, which is of course the most important reason for delivery companies to use this new technique. Amazon has done quite some research already on the economics of drone delivery services and the outcome of this study shows huge potential. A standard delivery done by a deliverer from UPS with a truck was compared to an autonomous drone delivery <ref> [https://ideas.repec.org/a/mts/jrnlee/v16y2016i1p1-12.html/ A Cost Analysis of Amazon Prime Air (Drone Delivery). Hutchinson, E. B. Sudbury, A. W. (2016) ] </ref>. All major and important factor were taken into consideration: | |||
* Operating hours | |||
* Traffic/Weather delays | |||
* Labor hours | |||
* Maintenance | |||
* Research & Development | |||
* Manufacturing/purchase | |||
Not all costs mentioned above are applicable to both ways of delivering, but the most important contributions of both ways are treated. A big difference however with Amazon and for example PostNL would also be the fact that PostNL will likely have to buy drones from other companies, while Amazon has the recourses the develop them themselves. Another thing is that Amazon delivers way more packages than PostNL or any other company in the Netherlands. Nonetheless this research gives a good indication about the expected costs. | |||
Besides all the advantages mentioned above, there are also some disadvantages. Weather conditions for example are important for a successful drone delivery and when there is too much wind or rainfall there is still a backup option needed. This will likely be the current system of truck and delivery person. The problem is that it also costs money to have this option available, even when it is unused. This is something that is not taken into consideration in the research. The cost calculations were made with respect to delivery in urban areas, where on one side the distances are shorter, and on the other side traffic is an issue. In rural areas however traffic is not so much of an issue, plus the distance to delivery destinations are much larger. Therefore delivery by truck could still be more profitable in rural areas. | |||
To compare drone delivery with delivery by trucks, only delivery in urban areas is considered here. There are different scenarios mentioned, one of them is that drones will deliver 24 hours a day, seven days a week. The cost per delivery is then estimated at 0.2 dollars. If drones only deliver 12 hours a day, but still seven days a week this would be 0.41 dollars. If you compare this with the costs of delivering a package with a deliverer and a truck, which is 1.20 dollars, the huge business potential immediately becomes clear, despite the differences mentioned earlier. | |||
So as a conclusion it can be stated that from a business perspective, drone delivery has huge potential relative to today’s delivery methods. It should be mentioned however that this potential is mainly hidden in urban areas, at least for now, and there should be a certain amount of deliveries per day. How many this would be in a city like Eindhoven for example, should yet be determined. | |||
= Approach & Milestones= | = Approach & Milestones= | ||
Line 106: | Line 239: | ||
A provisionally planning for the project can be found below. | A provisionally planning for the project can be found below. | ||
[[File: | [[File:planning_project.PNG]] | ||
= Deliverables = | = Deliverables = | ||
Line 120: | Line 253: | ||
===Requirements=== | ===Requirements=== | ||
* All delivery drones will need to communicate with the main system that controls the drones | * All delivery drones will need to communicate at all times with the main system that controls the drones | ||
* The system should be able to calculate trajectories of multiple drones without letting them collide | * The system should be able to calculate trajectories of multiple drones without letting them collide | ||
* The drone itself should make an avoiding action when it perceives another obstacle like a bird or a private drone that is within 10 meters | * The drone itself should make an avoiding action when it perceives another obstacle like a bird or a private drone that is within 10 meters | ||
Line 128: | Line 261: | ||
* The system will need to give each drone such a trajectory that the total energy consumption of all delivery drones is lowest | * The system will need to give each drone such a trajectory that the total energy consumption of all delivery drones is lowest | ||
* When an area is made into a no-fly zone, drones that were planned to fly over this area should be given a new trajectory as soon as possible | |||
===Constraints=== | ===Constraints=== | ||
Line 134: | Line 268: | ||
* Delivery drones should always keep a distance of at least 10 meters towards each other | * Delivery drones should always keep a distance of at least 10 meters towards each other | ||
* Drones should keep a distance of at least 5 meters from buildings or electricity lines | * Drones should keep a distance of at least 5 meters from buildings or electricity lines | ||
=Design considerations= | |||
Although only a small part of the whole delivery drone system will be modelled and simulated, research has been done in other areas that can be helpful with modelling and future studies. In this section, we will discuss some important influences on our communication model. | |||
==Communication== | |||
Firstly, the range is determined by the radio frequency, the amount of obstacles between the drone and the antenna, the transmitter amplifier power and the height of the antenna or receiver, the range can also be extended by using a low noise amplifier. The drone’s transmitter power is of course limited by the battery capacity. The most common frequencies used by small drones today are 900 MHz, 1.2 GHz, 2.4 GHz, and 5.8 GHz. Lower frequencies offer more range and better penetrating power through obstacles such as trees and buildings, however these also require larger antennas. Current high-end portable consumer remote controllers claim a range of 25-50 km using frequencies of 863-950Mhz or 433Mhz. The ground control system(GCS) will use antenna’s placed on tall buildings or on towers to increase the range and reduce the amount of obstacles in the way. | |||
In drone communication, the MAVLink protocol is widely used. It stands for Micro Air Vehicle Communication Protocol and is a very lightweight protocol used for bidirectional communication between a drone and a ground station. There are two types, MAVlink 1 and MAVLink 2. MAVLink 1 has just 8 bytes of overhead per packet and MAVLink 2 has 14 bytes of overhead but is more secure and extensible. It provides methods for detecting packet drops, corruption, and for packet authentication <ref> [https://mavlink.io/en/ / MAVLink Developer Guide ] </ref>. The message structure of MAVLink is as follows: <ref> [https://ieeexplore.ieee.org/document/8425627/ Empirical Analysis of MAVLink Protocol Vulnerability for Attacking Unmanned Aerial Vehicles. Kwon, Y. Yu, J. (2018) ] </ref> | |||
[[File:Table mavlink.PNG]] | |||
==Latency== | |||
Another important factor to consider in the communication is latency. The total latency of a communication system has multiple contributions, like travel time, processing speed and queuing time. Radio waves travel with the speed of light in air, which over the communication distances these drones use comes down to tenths of a millisecond on a round-trip. Processing speed looks to be a bigger contribution, so the algorithms used by the ground-control system need to be as efficient as possible. The last important factor is queueing delay, because when more drones are trying to communicate with the GCS than it is capable of processing, the latency will go up as the data traffic will be placed in a queue, waiting to be processed. If the latency becomes too high, problems can occur when drones need a new trajectory. Also when weather conditions suddenly change and communication takes too long, height measurements of the drones based on pressure can become unreliable | |||
In 2019 German researchers set up a test to determine the so called Round-Trip Latency, which is equal to sum of the travelling time from the ground control system to the drone, the processing time at the drone, and the time back to the ground <ref> [https://ieeexplore.ieee.org/abstract/document/8735265/ Flight Tests of Ranges and Latencies of a Threefold Redundant C2 Multi-Link Solution for Small Drones in VLL Airspace Volkert, A. Hackbarth, H. (2019) ] </ref>. With this test, a multi-radio communication protocol called Hyracom was used. Hyracom uses three different data links, 868 MHz, 2.4 GHz and 4G LTE, which operate in parallel and carry the same data, which are MAVLink packages. Only the signal that reaches the drone first will be processed, the other two packages with the same timestamp will be ignored. This will make the system more redundant to the environment, because the test shows a clear difference in results when testing either at a rural or an urban environment. In rural environments, LTE connection (3G or 4G) can be poor, and when this happens the other two will take over <ref> [https://ieeexplore.ieee.org/abstract/document/8735265/ Flight Tests of Ranges and Latencies of a Threefold Redundant C2 Multi-Link Solution for Small Drones in VLL Airspace Volkert, A. Hackbarth, H. (2019) ] </ref>. Because in this project we mainly focus on urban areas, only the results of this test setting will be shown here. The Round Trip Latency of the three separate signals are visualised, and what immediately stands out is that distance plays a negligible role. | |||
[[File:868_pic.PNG|1200px]] | |||
[[File:24G_pic.PNG|1200px]] | |||
[[File:LTE_pic.PNG|1200px]] | |||
What becomes clear of these results is that the 868 MHz signal does not have a big contribution in urban areas. Nonetheless, it is important not only for the situation where LTE connection is not strong enough, but also for security reasons (see [[PRE2020 1 Group3#Security|Security]] below). | |||
The model of the ground control system that will be created for this project will not incorporate all the necessary hardware to simulate this data communication, only the sending and receiving of MAVLink packages will be simulated. Because of this, latency does not occur in the simulation by itself, but to get a better understanding of how the ground control system would perform in the real world, it will be manually manipulated in order to analyze the effects of it. | |||
==Security== | |||
With all the new smart devices that are made, cybersecurity is becoming more and more important in our society and of course that also holds for these delivery drones. If even one of these drones will be hacked, the consequences could be immense, let alone if they are all hacked at the same time. If they fall into the hands of terrorists, innocent civilians could be attacked. Multiple examples have been shown of drones being hijacked, some of which even led to fatal casualties <ref> [https://ieeexplore.ieee.org/document/8088163/ A Review on Cybersecurity Vulnerabilities for Unmanned Aerial Vehicles. Krishna, L.C.G. Murphy, R. R. (2017) ] </ref>. There are different ways at which terrorists or criminals can manipulate the drone. Sometimes they only steal the data that is sent between the drone and the ground-control system. In this specific case this information can be used to for example steal a package from someone’s home, once it is delivered. In the table below there is an overview given of the possible threats, that are specifically related to data traffic between a drone and a ground-control system using MAVLink packages. | |||
[[File:table_security.PNG]] | |||
Confidential threats are when unauthorized people acquire the data that is sent, like in the example mentioned above. When the integrity is violated, the messages are being changed, or parts are added or removed. This could have severe consequences with lots of potential danger. Availability refers to the possibility of sending and receiving data. Deliberately jamming a signal for example falls under this category. For further explanation of the attack methods mentioned in the table one is referred to the paper <ref> [https://ieeexplore.ieee.org/document/8425627/ Empirical Analysis of MAVLink Protocol Vulnerability for Attacking Unmanned Aerial Vehicles. Kwon, Y. Yu, J. (2018) ] </ref>. | |||
The Hyracom communication protocol that was already discussed in the [[PRE2020 1 Group3#Latency|Latency]] section, comes with an encryption named AES, which stands for Advanced Encryption Standard. This encryption makes it impossible for hackers to retrieve or modify the data that is sent <ref> [https://arxiv.org/pdf/1905.00265.pdf/ MAVSec: Securing the MAVLink Protocol for Ardupilot/PX4 Unmanned Aerial Systems. Allouch, A. Cheikhrouhou, O. (2019) ] </ref>. | |||
Unfortunately the availability of the communication is bit harder to guarantee. Lots of research has been conducted on this topic <ref> [https://scholar.afit.edu/cgi/viewcontent.cgi?article=1613&context=etd/ Vulnerability Analysis of the MAVLink Protocol for Command and Control of Unmanned Aircraft. Marty, J. A. (2014) ] </ref>, but even presently it is very difficult to prevent someone from jamming a certain frequency. Luckily, Hyracom uses three signal all with different bandwidths, which makes it more robust to this problem. However, this does not solve it; if people are trying to disable the communication, they will probably jam all three signals. To fully tackle this problem more sophisticated procedures are necessary, and research on this is ongoing <ref> [https://ieeexplore.ieee.org/abstract/document/5530755?casa_token=WMa2TiStP8MAAAAA:RoVFBtCYahP_bjuxr_Udodf6NQw6Jj0MheOOEou0TTBDV0b5EDNvgnKiFjSEy5JUDeE74jc/ Game-theoretic analysis of an aerial jamming attack on a UAV communication network. Bhattacharya, S. (2010) ] </ref>. | |||
==Spacing== | |||
In order to make sure that drones will keep enough distance towards each other, each drone will have to be able to calculate its own GPS location and height. Only then it can stay within the trajectory that was provided by the ground-control system. These measurements have certain accuracy which must be taken into account. Besides that the weather will also have an influence on this distance. | |||
Today’s most common GPS receivers have an accuracy of 3-5 meters, however, there are newer GPS chips that use dual-frequency receivers, which are supposed to be accurate to 30 centimetres <ref> [https://www.broadcom.com/company/news/product-releases/2302120] </ref>. There are even mentions of accuracies of 3 centimetres <ref> [https://link.springer.com/article/10.1007/s001900000151/ Accurate absolute GPS positioning through satellite clock error estimation. Han, S.C. Kwon, J.H. (2001) ] </ref>, but for this project, we will stick with an accuracy of 30 centimetres. These sensors also do not require a lot of power, so they can be used in drones. | |||
For the height measurement, drones measure the altitude at which they are flying only relative to the altitude at which they took off. They do this by measuring the air pressure and temperature at take-off and comparing this to samples taken in-flight <ref> [https://www.aviassist.com.au/drone-telling-correct-height-operate-legally-safely/] </ref>. Barometric sensors nowadays have an accuracy of about 50 centimeters <ref> [https://www.bosch-sensortec.com/products/environmental-sensors/pressure-sensors/pressure-sensors-bmp380.html#applications] </ref>. As the drones will have different take-off altitudes this means that every drone calculates their height differently. A weakness of this method is that when the atmospheric pressure suddenly changes, for example when a cold front arrives, the calculated altitude can be very inaccurate. A solution to this is to constantly measure the air pressure at a central location and have every drone calculate its altitude relative to the changes measured at that point. | |||
So the measurement errors are relatively small, but a sufficient amount of space between drones is also needed because they will have to take actions to avoid birds or private drones sometimes. In order to accomplish this without the need for the ground-control system to calculate a new trajectory, the drone needs to stay within an imaginary sphere. The centre of this sphere is a point moving through space, representing the predefined trajectory. As long as the drone stays within a certain distance to this point, so inside this imaginary sphere, it will not collide with other delivery drones because the ground-control system will calculate trajectories in which the edges of these bubbles are always at least 2 meters apart. The idea is visualized in a simple sketch: | |||
[[File:drone_bub_2.png|700px]] | |||
Not enough research has been done yet to determine the perfect diameter for this sphere. When this system will be tested in real-time, a more detailed estimation can be given. For now, it is assumed that both the delivery drone and the obstacle have a size of 1.5 meters in all directions. Adding an additional safety factor the diameter is set to 20 meters so that the drone has about 10 meters in each direction to make a manoeuvre. As mentioned, this parameter can be further perfected by conducting more research. | |||
=Model= | |||
As mentioned above, a model will be delivered with a simulation to show that this model functions correctly at the end of the project. We will model the Traffic Management System in Java. This system will receive coordinates of the current location and the destination from multiple drones. It will then calculate 3-dimensional trajectories for all drones simultaneously using breadth-first search, without letting the drones collide. It will receive constant updates of the location by GPS and the height measurement system (see [[PRE2020 1 Group3#Design considerations|Design considerations]]). It also keeps track of certain properties of the drone (see [[PRE2020 1 Group3#Communication between system and drone|Communication between system and drone]]). The drones will only receive information from the system if there is a temporary no-fly zone somewhere, or if the drone had to leave its trajectory to avoid a bird or a private drone which is (illegally) flying and not connected to the system. If the latter occurs, the system will calculate a new trajectory and send this to the drone. The anti-collision and data-traffic themselves are not modelled, as this would require to model all the hardware. This will not fit in the scope of this project. | |||
The simulation will look like a big 2D space in which objects (that represent the drones) are moving towards a location without colliding. They all have a number which represents their height. There are also static obstacles visible, which represent for example buildings or electricity lines, and moving objects which represent private drones or birds. | |||
==Code structure== | |||
[[File:DronesDiagram.png|1200px]] | |||
==Description of all classes== | |||
- Drone: This class contains the information and all parameters of a single drone. The functions in this class can be used to move the drone, as well as changing and retrieving all information about the drone itself. During each step of the model, the drone moves based on its status and receives all communication from other entities. | |||
- DroneCom: This class contains the framework for the communication of a drone. It contains functions to send messages to the TMS, as well as a function to parse the messages that have been received by the drone. | |||
- DroneSystem: The DroneSystem class represents the main method of our model. This class serves as a controller for the system. It is responsible for the initialization of the system and the updating of the map during each step of the model. | |||
- Fleet: This class represents a fleet of drones and a list of Traffic Management Systems. Upon each timestep in the model, the Fleet class will call the step method for each drone and each TMS. This class is also responsible for moving the drones in the fleet and adjusting the routes when necessary. | |||
- TMS: This class models the drone control system of our model, the Traffic Management System. This class contains the main overview of the system, together with functions to update the status of the system. During each step of the model, the TMS updates the weather information, receives all communication from other entities and changes any routes if a new no-fly zone appears in their radius. | |||
- TMSCom: This class contains the framework for the communication of a TMS. It contains functions to send messages to the drones, as well as a function to parse the messages that have been received by the TMS. | |||
- Communication: The communication class ensures that all packets sent by the DroneCom class and the TMSCom class are received properly by the other party. To simulate a real-life situation, some latency is also added to the communication. | |||
- Environment: The Environment class contains the description of the current environment. This class contains the temperature, the pressure and information about obstacles and no-fly zones. | |||
- Grid: This class contains an overview of the region in which our system is operating. It contains a 3-dimensional array of nodes that show the current status of their respective space in the world. The values of these nodes can indicate normal nodes, obstacles, sources, destinations, drones or no-fly zones. | |||
- Map: The Map class can be used to visualize the model on the user's screen. It draws the nodes, drones and routes on the screen so the user has an overview of the system. | |||
==Traffic Management System functions== | |||
- Provide the drones with the weather and geospatial information | |||
- Ensure drones do not enter no-fly zones and exit unexpected new no-fly zones as quickly as possible | |||
- Check that flight plans do not collide with each other while optimizing all routes whenever possible | |||
- Track the status of all drones currently in flight | |||
- Track unexpected objects such as rogue drones and birds with information passed by the drones | |||
==Functions== | |||
===Model=== | |||
- In the initialization, the model sets the timestep of the simulation, initializes the location and destination of all drones and simulates rogue UAVs | |||
- The model can set the atmospheric pressure and temperature to test the elevation calculation of the drones | |||
- The model has a list with locations containing the coordinates of the location and its elevation relative to the ground | |||
- The model has functions to simulate the latency and detection delay that would be present in a real world situation | |||
- Whenever a drone needs a new or optimized route, the model will assign a new route to a drone | |||
- The model can change the environment and simulate the communication between a drone and the traffic management system | |||
- The results of the simulation, such as average delivery time and the amount of collisions, can be tracked by the model | |||
===System=== | |||
- The TMS keeps track of the location and status of all drones while the simulation is active | |||
- The system also keeps track of the weather conditions, unexpected no-fly zones and locations of rogue UAVs sent by the drones | |||
- The system checks the flight plan of all drones to ensure no collisions happen | |||
- The system communicates route adjustments and environmental changes to the drones when necessary | |||
===Drone=== | |||
- The drone stores a lot of information about itself, including its position, destination, speed, priority, flight plan, status, manoeuvrability category, maximum range, direction and the baryonic pressure + air temperature to compute the current altitude of the drone | |||
- The drone also has a system to detect and evade any unexpected objects that are in close proximity | |||
- It communicates with the TMS about the current status of the drone and any unexpected events that may occur | |||
==Communication between system and drone== | |||
For such a system to work properly, there needs to be some kind of communication between the system and every drone. Each drone will always try to communicate with a traffic management system nearby. If there are no traffic management systems nearby, the drone will follow its last known route. If there is no last known route, the drone will fly straight to its destination. Conversely, if there are multiple traffic management systems in the range of the drone, the drone will always communicate with the closest system. This is a similar method as used by airplanes. The airplane will communicate with multiple air control towers while in flight, just like a drone in our system would do for a long flight. For example, when flying across America, a plane will communicate with 28 controllers in 11 different facilities all across the United States<ref>[https://www.faa.gov/air_traffic/flight_across_america/]Federal Aviation Administration (2019)</ref>. A drone would also communicate with multiple systems while in flight. However, the drone system does not have different systems for takeoff, mid flight and landing. These flight stages can all be handled by the same TMS. | |||
The communication is done using the MAVLink protocol as denoted in the [[PRE2020 1 Group3#Design considerations|Design considerations]]. The following packets are sent from the drone to the system: | |||
- When the drone first connects to the system, the drone will send a message to the system containing the drone's destination, the manoeuvrability category of the drone and its priority. This is needed to help the system to send the drone to the correct destination. | |||
- The drone sends regular status updates to the system. These updates contain the drone's speed, the current status (whether the drone is flying/landing) and the drone's updated position. | |||
- When the drone gets a new mission, it will send its new destination to the system, together with its updated priority and an update to the drone's manoeuvrability category. | |||
- If the drone needs to dodge an unexcepted object and has to leave its route, it will resend its position to the system. | |||
- When the drone leaves the radius of the system or if the communication needs to be stopped for a different reason, the drone will send a goodbye message to the system. | |||
==Demonstration== | |||
[https://youtu.be/uB0FAUW2V9Y Here is a screenrecord of a single run of the model], where first two random no-fly zones are instated, and then the weather information is changed very dramatically, to clearly show the effect. When the no-fly zones are instated, one drone that was inside it is given the shortest route out, and two other drones whose destinations are inside the no-fly zones are notified of this and told to request a new destination. This last process seems to not always work correctly, in other runs drones which had a destination inside a no-fly zone seem to get stuck, maybe because their destination does not get updated properly although it is unclear why. When the weather changes the drones outside of the system's range crash, while the drones inside the range get corrected quickly and can keep on going. | |||
=Simulation tests= | |||
In the simulation of our model, we want to test a few things to make it clear how the system would perform in the real world. As mentioned before in the [[PRE2020 1 Group3#Design considerations|design considerations]], communication is influenced by the latency, which in turn is also influenced by the processing capacity of the system. It is important to note that this is not something we are going to model and manipulate in this simulation because it’s part of the hardware, so the values we find might not be applicable in the real world; it will really be dependent on the processing capacity of the system in use. As we focus our project (and we believe the main use of delivery drones in general is) on urban areas, it is important that there are no collisions taking place at any point in time. The stakes of there being injuries or even casualties because of colliding drones (including packages) are too high to permit any mistakes happening <ref> [https://arc.aiaa.org/doi/abs/10.2514/6.2011-1424 Lum, C., & Waggoner, B. (2011). A risk based paradigm and model for unmanned aerial systems in the national airspace. In Infotech@ Aerospace 2011 (p. 1424).] </ref>. Therefore, we want to use this simulation to see the maximum number for latency that can occur in our communication system before a collision happens. Initially, we set the latency to 200ms (see [[PRE2020 1 Group3#Latency|Latency]]) and we will manipulate this number to be higher to see what happens. We also want to see what the effect of adding more drones in our model is on this number, as this is an interplay; the latency will increase as more drones are used. While deploying more than two drones in our model, we also want to test for the maximum latency when using a little margin of error. A success rate of 98.22% in collision avoidance for 100 UAV's performing planned missions has been reached before, so we want to test for that here as well. <ref> [https://www.mdpi.com/1424-8220/19/10/2404 Fabra, F., Zamora, W., Sangüesa, J., Calafate, C. T., Cano, J. C., & Manzoni, P. (2019). A distributed approach for collision avoidance between multirotor UAVs following planned missions. Sensors, 19(10), 2404.] </ref> | |||
Another thing we want to test in our model is how quickly the drones in the system will react if a sudden no-fly zone appears. This can happen when, for instance, the police wants to use drones for an investigation and requests a no-fly zone for other drones in U-space. Investigating this includes how quickly the system gets drones out of the no-fly zone, and/or in what time span the system can make sure a drone does not even enter a no-fly zone. | |||
==Testing method== | |||
To test our model, we use the following method: | |||
1. Start the first simulation with a latency number of 200 milliseconds | |||
2a. If no crashes happen with this latency and the drones get out of new no-fly zones fast, increase the latency and run the simulation again | |||
2b. If a crash happens or if drones take too much time getting out of new no-fly zones, we take the last latency that worked and take that as maximum latency for our model | |||
==Conclusions to be drawn from testing== | |||
When we get a maximum latency for our model from the tests, we know that we need to keep the expected latency of any real life situation below this number. The maximum number of drones for each real life system can be computed by looking at the maximum number of drones a system can handle before queueing delay occurs and the amount of queueing delay that gets added for each drone after this maximum has been reached. When the latency gets above our computed maximum latency, we know that the real life system is unable to handle that number of drones. | |||
We are not able to determine the maximum number of drones for a general case, since the queueing delay depends on the power of the system running our model. If the system is very powerful, we can have a large number of drones in the area at the same time without the latency being too high. Conversely, if the system is very weak, our model will become unusable much quicker and the maximum capacity will be low. | |||
=Anti-collision system= | |||
Although the anti-collision system will not be modelled and simulated in this project, it is still useful to do research on what kind of system would be the best for delivery drones. | |||
Therefore an investigation has been done on different kinds of tools for a drone to perceive its surroundings. Since the ground control system will calculate a trajectory for all the delivery drones in a way that they will not collide with each other and static objects, the anti-collision system will only come into action when there are moving obstacles like birds or private drones which are not connected to the system. For the drone to be able to detect these obstacles in time, there are multiple techniques which can be used. | |||
'''RADAR''' | |||
Radar is a relatively old technique, which is used in many applications to detect ships, planes, spaceships and other types of vehicles. But it is also used to predict weather. The basic idea is to send out radio waves and then perceive the reflection of this signal. It operates on a very broad frequency range, and has a range of up to several hundred meters in which it can provide a reasonable accuracy <ref> [https://ieeexplore.ieee.org/abstract/document/4422877/ UAV based collision avoidance radar sensor. Kwag, Y. K. Chung, C. H. (2007)] </ref> A disadvantage is its relatively high weight, but constant improvements are made on this . <ref> [https://arxiv.org/abs/1508.07723/ A Survey on Unmanned Aerial Vehicle Collision Avoidance Systems. Pham, H. Smolka, S. H. (2015)]</ref>. It also operates well in all weather conditions. | |||
'''LIDAR''' | |||
Lidar is method for determining the distance to an object by emitting a pulsed laser beam and measuring the time it takes for an object to reflect it and send it back. It is used in multiple areas such as autonomous cars, agriculture, archaeology and geology <ref> [https://www.sciencedirect.com/science/article/pii/S0034425716303212/ Beyond 3-D: The new spectrum of lidar applications for earth and ecological sciences. Eitel, J.U.H. Höfle, B. (2016)]</ref>. When multiple laser and sensors are used in all directions it can create a complete image of its surroundings. It has a higher accuracy than Radar and a lower weight <ref> [https://www.researchgate.net/publication/303693075_LIDAR_obstacle_warning_and_avoidance_system_for_unmanned_aerial_vehicle_sense-and-avoid/ LIDAR obstacle warning and avoidance system for unmanned aerial vehicle sense-and-avoid. Ramasamy, S. Sabatini, R. (2016)]</ref>. A disadvantage is that it is affected by rain and fog, but progress is being made on this. | |||
'''SONAR''' | |||
With sonar there are sound waves emitted, instead of electromagnetic radiation. It also relies on the principle of the reflection of another object. It is mainly used underwater by submarines, but recently research has also been done for applications for obstacle avoidance systems of drones. <ref> [https://www.koreascience.or.kr/article/JAKO201528672627336.page/ Collaborative Obstacle Avoidance Method of Surface and Aerial Drones based on Acoustic Information and Optical Image Dong-Woo, M. (2015)] </ref> <ref> [https://ieeexplore.ieee.org/abstract/document/7833065/ Efficient Optical Flow and Stereo Vision for Velocity Estimation and Obstacle Avoidance on an Autonomous Pocket Drone. McGuire, K. de Croon, G. (2017)] </ref>. However in these cases it was used for drones flying inside a building. This is because the accuracy decreases for objects that are further away <ref> [https://www.koreascience.or.kr/article/JAKO201528672627336.page/ Collaborative Obstacle Avoidance Method of Surface and Aerial Drones based on Acoustic Information and Optical Image Dong-Woo, M. (2015)] </ref>. The update speed of sonar is relatively low Design and analysis of a novel sonar-based obstacle-avoidance system for the visually impaired and unmanned systems. | |||
==Comparison== | |||
Based on all different aspects of the techniques mentioned above and taking the most important design characteristics into consideration, the best choice is an obstacle avoidance systems based on Lidar. It provides the most accurate estimation of the distance to an obstacle, and can therefore calculate the relative speed of that obstacle with respect to the drone the most accurate <ref> [https://www.mdpi.com/2072-4292/12/6/975/ Collision Avoidance of Hexacopter UAV Based on LiDAR Data in Dynamic Environment. Park, J. Cho, N. (2020)] </ref> This system is also the least heavy, which is a very important aspect for drones. | |||
A disadvantage compared to Radar is that its performance drops with rain or fog. But luckily, as already mentioned above lots of progress has been made concerning the robustness in almost all types of weather conditions <ref> [https://www.researchgate.net/publication/303693075_LIDAR_obstacle_warning_and_avoidance_system_for_unmanned_aerial_vehicle_sense-and-avoid/ LIDAR obstacle warning and avoidance system for unmanned aerial vehicle sense-and-avoid. Ramasamy, S. Sabatini, R. (2016)]</ref>. | |||
Another advantage of LiDAR is its superior frame rate, which is about 10 Hz <ref> [https://ieeexplore.ieee.org/abstract/document/6224654/ Visual Teach and Repeat using appearance-based lidar. McManus, C. Furgale, P. (2011)]</ref> <ref> [https://www.ipb.uni-bonn.de/wp-content/papercite-data/pdf/milioto2019iros.pdf/ RangeNet++: Fast and Accurate LiDAR Semantic Segmentation/ Milioto, A. Vizzo, I. (2019).] </ref> Because of this high frame rate obstacles will be noted by the drone in time and an avoiding action can be taken if necessary. | |||
=Reflection= | |||
Looking back, a central ground control system alone might not be the most efficient solution to this problem. We stated in our [[PRE2020 1 Group3#Problem statement and objectives|problem statement]] that we didn’t just want to use laid out routes in the sky, which we stick by, but a combination of both might create a more optimal solution because research has shown that structuring the airspace has a significant role in air traffic management. [ref] It was not feasible for us to implement that as well in our model to test for both things, so no definite conclusion can be given for that matter. But looking back, that is one thing that we may have wanted to do differently. | |||
What we can say, however, is that for the calculation of the routes, there are more efficient algorithms that we could have used. We stated for one of the preferences that we would like to give each drone such a trajectory that the total energy consumption of all delivery drones is lowest. There has been done research on and algorithms created for this matter <ref> [https://dl.acm.org/doi/pdf/10.1145/3218603.3218614 Baek, D., Chen, Y., Bocca, A., Macii, A., Macii, E., & Poncino, M. (2018, July). Battery-aware energy model of drone delivery tasks. In Proceedings of the International Symposium on Low Power Electronics and Design (pp. 1-6).]. </ref> <ref> [https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7565126 Ahmed, S., Mohamed, A., Harras, K., Kholief, M., & Mesbah, S. (2016, April). Energy efficient path planning techniques for UAV-based systems with space discretization. In 2016 IEEE Wireless Communications and Networking Conference (pp. 1-6). IEEE.] </ref> Looking at the costs and risks, algorithms that take this into account for their path planning <ref> [https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9165709 Hu, X., Pang, B., Dai, F., & Low, K. H. (2020). Risk Assessment Model for UAV Cost-Effective Path Planning in Urban Environments. IEEE Access, 8, 150162-150173.] </ref> might also have been interesting to implement. But again, for the scope of this project, this was not feasible for us to implement. | |||
= Code Sources = | |||
The code written for this project can be found on GitHub [https://github.com/Em-R2019/DroneSystem here]. Included on this repository is the Roaf package, the total package was downloaded from [https://www.roaf.de/download here] but as only a small part of it was used only the required files are included on the GitHub. Furthermore inside our package is a file called MavlinkPacket.java, this file is a part of the package found [https://github.com/dronefleet/mavlink here] this was moved into our package because the gradle of the original kept causing errors. Finally the Grid.java file is based on [https://github.com/zhaohuabing/shortest-path-in-grid-with-obstacles-java this file], it was edited to work in 3 dimensions and with a Value class with timeslots instead of integers and some other methods were added as well. | |||
= State of the Art = | = State of the Art = | ||
Line 265: | Line 598: | ||
|- | |- | ||
| Emmy | | Emmy | ||
| | | 2.5 | ||
| | | Tutor meeting [0.5h], group meeting [1h], researching sources and ArduSim [1h] | ||
|- | |- | ||
| Mayra | | Mayra | ||
Line 277: | Line 610: | ||
|- | |- | ||
| Roel | | Roel | ||
| | | 3 | ||
| Tutor meeting [0.5h], Group meeting [1h] | | Tutor meeting [0.5h], Group meeting [1h], contacting companies [1.5h], | ||
|} | |} | ||
Line 288: | Line 621: | ||
|- | |- | ||
| Emmy | | Emmy | ||
| | | 12.5 | ||
| | | tutor meeting [0.5h], group meetings [2h], working on ArduSim [6h], writing Design Constraints and early design [4h] | ||
|- | |- | ||
| Mayra | | Mayra | ||
| | | 12.5 | ||
| | | tutor meeting [0.5h], group meetings [2h], look for arguments for problem statement [3h], adjusting problem statement [2h], adjust planning [0.5h], elaborate on legislation [3h], investigate and write about U-space [1.5h] | ||
|- | |- | ||
| Rick | | Rick | ||
| | | 15 | ||
| | | tutor meeting [0.5h], group meetings [2h],Doing research on different types of systems [10h], typing out use cases and RPC's [2.5h] | ||
|- | |- | ||
| Roel | | Roel | ||
| | | 10.5 | ||
| | | tutor meeting [0.5h], group meetings [2h], working on ArduSim [5h], working on own drone code [3h] | ||
|} | |} | ||
Line 311: | Line 644: | ||
|- | |- | ||
| Emmy | | Emmy | ||
| | | 41 | ||
| / | | tutor meeting [0.5], group meetings [5.5h], designing and programming Communication, DroneCom, Fleet, Environment, DroneSystem, Utilities classes, all non get/set methods of Drone class and (re)writing Map class [35h] | ||
|- | |- | ||
| Mayra | | Mayra | ||
| | | 21 | ||
| | | tutor meeting [0.5], group meetings [5.5h], doing research and working on simulation [15h] | ||
|- | |- | ||
| Rick | | Rick | ||
| | | 30 | ||
| | | tutor meeting [0.5h], group meetings [5.5h], Doing research and work out design considerations [20h], General work on wiki page [4h] | ||
|- | |- | ||
| Roel | | Roel | ||
| | | 17.5 | ||
| | | group meetings [5.5h], working on code [12h] | ||
|} | |} | ||
Line 334: | Line 667: | ||
|- | |- | ||
| Emmy | | Emmy | ||
| | | 44 | ||
| | | tutor meeting [0.5h], group meetings [2.5h], researching route-finding algorithms [1h], designing and programming TMS and TMSCom classes, extending Map, Environment, Utilities, Drone, Fleet, Grid classes [25h], testing and adjusting model [15h] | ||
|- | |- | ||
| Mayra | | Mayra | ||
| | | 11 | ||
| | | tutor meeting [0.5h], group meetings [2.5h], working on presentation [8h] | ||
|- | |- | ||
| Rick | | Rick | ||
| | | 20 | ||
| | | tutor meeting [0.5h], group meetings [2.5h], working on presentation [10h], working on wiki page [7h] | ||
|- | |- | ||
| Roel | | Roel | ||
| | | 15 | ||
| | | tutor meeting [0.5h], group meetings [2.5h], working on code structure [10h], working on presentation [2h] | ||
|} | |} | ||
Line 357: | Line 690: | ||
|- | |- | ||
| Emmy | | Emmy | ||
| | | 10.5 | ||
| | | presentation meeting [1.5h], group meetings [1.5h], fixing Drone position calculation and refining object detection [3.5h], cleaning up code and adding comments [2h], writing code sources [0.5h], making screenrecord [1h], writing model demonstration [0.5h] | ||
|- | |- | ||
| Mayra | | Mayra | ||
| | | 11 | ||
| | | presentation meeting [1.5h], group meetings [1.5h], working on USE section [5h], general work in wiki page [3h] | ||
|- | |- | ||
| Rick | | Rick | ||
| | | 11 | ||
| | | presentation meeting [1.5h], group meetings [1.5h], working on wiki page [8h] | ||
|- | |- | ||
| Roel | | Roel | ||
| | | 10 | ||
| | | presentation meeting [1.5h], group meetings [1.5h], working on wiki [4h], working on code structure [3h] | ||
|} | |} | ||
=References= | =References= | ||
<references/> | <references/> |
Latest revision as of 14:07, 26 October 2020
Group members
Name | Student ID | Department | Email address |
---|---|---|---|
Roel den Hoet | 1248170 | Computer Science and Engineering | r.d.hoet@student.tue.nl |
Rick Peeters | 1021754 | Mechanical Engineering | r.peeters@student.tue.nl |
Mayra van der Pol | 1010569 | Psychology & Technology | m.h.e.m.v.d.pol@student.tue.nl |
Emmy van der Ree | 1244223 | Biomedical Engineering | e.m.v.d.ree@student.tue.nl |
Problem statement and objectives
From being used by consumers solely for entertainment, as a more environmentally friendly alternative to fireworks, by videographers to capture spectacular footage otherwise impossible to achieve, to autonomous drones being used for military purposes, drones are becoming increasingly common in all parts of society. It stands to reason that in the future they will be deployed to aid with the currently already extremely high demand for package- and food delivery services, a market which is only growing. [1] This type of application of drones in transport is the most developed, compared to freight and passenger transport. [2] By avoiding traffic, delivery drones offer opportunities for faster and more customized delivery. Estimated is that by 2035, 70 000 drones around Europe will deliver 200 million lightweight parcels. By 2050, this number will be around 90 000. [3]
Due to the high number of different companies which offer delivery services it is likely that in areas like cities there will be a very high number of drones and that these will have differing operating systems. In order to prevent collisions, drones will have to communicate with each other in some way, while also keeping track of no-fly zones. When many different operating systems have to communicate the chance of errors due to incompatibility increases. Furthermore, in high traffic areas the high number of drones will result in a lot of communication traffic happening between drones and this could lead to insufficient bandwidth to sustain a safe communication speed. All of these drones will also create a large amount of position- and routing data that every drone will need to keep track of and store, on top of the data of all the restricted zones the drone could fly through. In order to alleviate these issues it is necessary to create a single overarching communication and control system which can track and command all autonomous drones in a designated airspace. While research has shown that structuring the airspace has a significant role in air traffic management [4] [5], we believe this structure solely is not enough, and a central system has a couple of advantages. First and foremost, such a central system enables adjustments of routes while travelling from one place to the other. While we believe that anti-collision systems also always need to be in place for unexpected events or encounters, these systems and a precomputed route over laid out infrastructure is not going to be enough. If a drone encounters something that he had not anticipated on and has to dodge it and thereby deviates from the ‘road’, no adjustments can be made to get him back on track. With such a central system, you can. It is also shown that cooperative sensors, such as the dissemination of flight information to nearby drones, allow for a fast enough reaction to a moving object (such as another drone), while non-cooperative sensors do not.[6] On top of that, when wanting to really optimize such system by including weather predictions into the flight calculations or communicating with other stakeholders, a central system is more suitable for that. [7] Therefore, we aim to design a system that will receive position and route information from all drones in a certain area, can compare these with each other and any no-fly zones to find any conflicts, calculate any necessary course corrections and communicate about these with (only) the affected drones.
Our objectives for the end of this project are to deliver:
- Central communication and routing system (the terms 'ground control system' and 'air traffic management system' are used interchangeably for this throughout this Wiki-page)
- Corresponding drone to system communication code
- Literature study on the USE impact of delivery drones
- Literature study on the legal aspects of commercial autonomous drones
User, Society and Enterprise
Users
Clearly, the main users of this air traffic control system would be the delivery companies, irrespective of what they are delivering; parcels, food or other goods. On the other hand, the people who order and receive these good can also be considered as users. They will need to have enough trust in this system otherwise it will never be a success. It is obvious that these two groups of users have different interest, concerns and demands.
Delivery companies
As mentioned there is no real distinction between delivery companies on behalf of what they deliver. The delivery process will be entirely the same regardless of what is delivered. For convenience, we neglect the fact that food can get cold along the way. So for a package delivery to be successful the autonomous drone will have to be equipped with the package, take off from either a truck or a distribution center, fly to the destination without colliding with something and then safely deliver the package. In this project we focus on the part where a drone needs to fly to the destination without colliding. There are multiple things that are important for delivery companies, such as safety, accuracy and delivery time.
Consumers
The group of consumers basically consists of everyone who will make use of this service, whether they specifically ask for this type of delivery or they do not specify this. Since most people in the Netherlands have packages being delivered at home sometimes, this group will consist of the majority of the population. Their biggest interest is, of course, to receive the package undamaged, and as soon as possible. Because we will not take a look at the transfer of the package, the safety of the receiver will not be discussed here as it does not come into dispute.
Several studies have been conducted about consumers acceptance of delivery drones, as acceptance is needed to implement this piece of technology in our society. There are a couple of factors that influence people's attitude towards drone delivery, which in turn influences their intention to use it. These factors consist of the perceived risks, functional benefits and attributes of the technology. [8] [9] Another study shows that individual characteristics play a role as well, and have found a distinction between factors that influence people living in urban and rural areas.[10] The relative advantage of environmental friendliness only affected the attitude of the rural residents (positively). Performance risk negatively affected the attitude of only the urban group, while privacy risk negatively affected attitude only in the rural group. Urban residents seemed to be more worried about property damage, missing their goods, or danger due to the malfunction of drone delivery. And since a drone may deliver parcels to the inner space or yard of customers’ house in rural areas, privacy risk might be a more important issue to rural residents.
Questionnaire
For us to gain a better understanding of the current attitude of the public towards delivery drones, and to identify what is needed still, we created a survey. It became clear that most people like the idea of delivery drones, but there are still concerns.
We followed up by asking what the most important aspects of the delivery drones would be for them as costumers. Their results are depicted in the table below. Participants could select multiple answers.
percentage | |
---|---|
privacy | 20% |
safety: collisions leading to physical damage to either the drone or the to be delivered good | 53.33% |
safety: hacking | 40% |
accuracy in delivering (your neighbour receiving your delivery instead of you) | 26.67% |
no-drone zones, i.e. nature areas | 20% |
crowdedness in the air | 20% |
fast delivery | 20% |
As becomes clear from these percentages, the most important thing is safety. This also came out in the elaboration of their answers. The most important thing for people is that their packages reach their doorstep safely. This implies safety in the air, no collisions taking place, and that the drone should not get hacked or sabotaged in any other way. Some people related the option 'crowdedness in the air' to safety as well: if there are many drones occupying the sky, chances are high that dangerous situations will emerge. The other people who filled out this answer are mainly concerned about the noise and nuisance drones give when present in big numbers.
Therefore, the most important things that people would like to see/guaranteed are that drones can not get hacked, no privacy violations by potential cameras, and no nuisance.
Lastly, when asked about the biggest potential/positive of delivery drones, people were unanimous: drone delivery poses options for (much) faster delivery, and also a few people mentioned they thought it would be better for the environment.
Society
For society, there are different stakeholders to be recognized. Firstly the government, who is in charge of the legislation of the delivery drones. Inhabitants of high-density delivery areas are another group of interest here. Animal rights and environmental organizations will also play a role, as they seek to protect sensitive areas from this type of technology damaging it. Lastly, connected to the last group of stakeholders, are the other users of the airspace - mainly birds and other flying wildlife, but also hobby drones.
Most concerns that people have on the user level also apply for society as a whole. As became apparent from previous research and our own survey data, the most important concern is safety, and this does not go for users alone; it is also very important to other stakeholders. Especially the risk that a drone will drop from the sky and hit someone or something is an important situation to consider, and the risk of a drone being hacked and letting it crash deliberately can also not be underestimated. In order to avoid this, the drone itself will have to be very reliable, especially when they are being deployed in big cities. Besides security, the system should work flawlessly to make sure that they do not only avoid other delivery drones but also static objects like electricity lines or high buildings. Also moving objects like birds or recreational drones that are not connected to the system should be avoided. Besides safety, there is also the problem of nuisance, for example, noise disturbance or invasion of privacy. [11]
When drone delivery becomes more and more common, fewer humans are needed for the same amount of packages delivered. It could be that some people will lose their job because of this. On the other hand, nowadays the delivery companies have great trouble in handling all deliveries and making sure they arrive on time. This system, therefore, has the potential to relieve the pressure of the deliverers without a loss of job opportunity. How this will evolve mainly depends on what kind of deliveries will be autonomous and at what frequency they will be executed.
When the sky will be used more often, there unavoidably arises a threat to wildlife [12] Where two drones connected to the same system are relatively easy to guide passed each other, it becomes a lot harder to avoid a bird which could fly at a speed of 70 km/h [13] A good start to tackling this problem would be to prohibit drones from flying over forests, but this does not eliminate the risk. A very sophisticated anti-collision system with radar would be required to exclude this risk.
However, even when all the above problems are dealt with in an appropriate way, it seems impossible that nothing will go wrong. Because these are autonomous systems, it is a difficult task to point out who is responsible. This could give rise to ethical discussions which nowadays are already being held about self-driving cars [14] When, for example, a drone suddenly falls out of the sky and hits a pedestrian without having the certainty that it is a technical failure or a minor collision with a bird that caused it, who is responsible? If this happens more regularly, it is likely that people will change their minds about this technology and do not make use of it at all. In fact, this probably needs to be sorted out before the deployment of delivery drones, so that when accidents do occur, there is no uncertainty and ambiguity.
Enterprise
This group is formed by the companies developing the air traffic control system and its stakeholders.
Before this system will be available, it will still need to overcome technical challenges as well as some legal requirements. To find out more about these challenges we contacted Avular, a startup company in Eindhoven which, among other things, is doing research about this topic. They mentioned that the three biggest challenges of today were perception, weight and certification. As mentioned before for this project we will mainly focus on the problem of perception, i.e. the ability of these drones to maneuver past static obstacles and avoid moving obstacles. However in order for a company to develop this system all challenges need to be dealt with in an appropriate way. For the problem of weight this means that the capacity of a battery per kilogram will need to increase. Because more and more devices are being equipped with batteries, constant progress is made on this side so in the future this will become less of a problem. In terms of legal requirements there is also some progress (see Legal requirements) made for commercial drones to be deployed.
Another reason why weight and battery capacity might not be a big problem, is because the so called ‘last mile delivery’ is the concept that companies seem most interested in [15]. This means that a truck will drive through a neighbourhood and lots of delivery drones will depart from the truck and only have to fly a relatively small distance to reach their destination. This could make the system potentially more efficient than delivery seen nowadays [16].
Like mentioned earlier is seems very unlikely that there will never occur an accident. For companies who are going to sell this delivery drone system it is important to have clear laws about when they are responsible, and when they are not. Avular mentioned for example that if it is a certain technical error they are willing to take the blame. However if a delivery company decides to use the drones when weather conditions are not good enough, they will certainly not. This seems fair, but it becomes a lot harder when there is no clear cause and there is a bit of a grey area. To prevent issues like this clear government regulations are needed.
Use Cases
The system that will be designed basically consist of two different ways to avoid collision. Besides the ground control system there is an active anti-collision system on each drone. Because of this there could be some situations where it is not entirely clear what the drone should do, therefore we described a few use cases below. As a general rule it can be stated that the active anti-collision system on each drone will always overrule the instructions of the ground control system.
Use Case 1
A delivery drone needs to take an avoiding action to prevent a collision with a private drone or a bird, i. e. a moving object which does not communicate with the ground control system. Therefore it is no longer in the desired position and it comes in the path of another delivery drone which is approaching.
In this case it depends if the ground control system is able to calculate a new trajectory for this delivery drone before it comes into a distance of 10 meters from the other one. If the system is on time with this, the problem is solved and the drone that was out of direction will receive a new trajectory. If this will not happen on time, so not before the drones come within 10 meters of each other, an avoiding action will need to be taken by either only the drone that is out of position, or by both drones. Which of the two it is going to be depends on the speed and orientation of the two drones. The best solution is the one where both drones will lose as little time and energy as possible to avoid collision, and it depends on the situation if the trajectories of both drones will have to be adjusted for that.
Use Case 2
The ground control system fails and cannot send commands to the drones anymore. Some drones will no longer be on their predefined path because of avoiding actions they had to take.
In the rare event that the system does not work due to some error, all drones initially connected to the system are to hover in the air. If after 10 minutes no reconnection to the system has been established, they should descend and land using the anti-collision system, which is still fully operational as it operates independently from the ground control system. Drones that are in rural areas should land somewhere in a safe place, for example a grassland, and wait until the system will be able to give them commands again. In urban areas this would be more difficult and specific landing areas on top of roofs would have to be created. Once a drone has landed on such place, the minimum distance of 10 meters towards a drone in the air will be cancelled in order to make sure they can land close to each other. When hovering in the air for 10 minutes is not feasible, for instance due to an almost empty battery, the drone should land immediately.
Use Case 3
A private drone which is connected to the system, but operated by a civilian is making weird and unpredicted movements, which makes it very hard to calculate a safe trajectory to pass it.
Flying a private drone manually in urban areas will be prohibited, and outside urban areas they will need to be connected to the system. When someone is flying such a private drone in rural areas and a delivery drone comes nearby, the user of the private drone will receive a warning that the delivery drone is coming, and will be asked to hold the drone stationary until it has passed. If the person will not obey this command, the drone can temporarily be taken over by the system and held stationary, until the delivery drone has passed. When someone will actually break the law and fly a drone that is not connected to the system, the anti-collison system of the delivery drone will prevent an encounter when the drones coming too close.
Legal Requirements
The Netherlands
Drones used for recreational goals are already becoming more and more common. Because some of these drones are equipped with cameras, the privacy of people is in danger. Also, the noise can be disturbing when they fly too low over residential areas, and the biggest danger: collisions. When (delivery) drones will be deployed more often in the future, these problems will become even bigger. For this reason, the Dutch government already made laws for the use of drones, divided into recreational and commercial. Firstly, recreational drones are not allowed to fly higher than 120 meters above land or water. They can't weigh more than 25 kilograms (including cargo) and always need to be visible. This has two implications: you are only allowed to fly a drone during the day and it needs to be in your line of sight. And, maybe even most importantly, there are a lot of areas specified where recreational drones cannot come closer than 50 meters, measured from the ground. Places like this are[17]:
• big crowds
• contiguous buildings
• harbours
• industrial area’s
• railways
• highways
• ships
• airports
To make this more clear, a map of the Netherlands with all so-called 'no-fly zones' is available:
Red: no-fly zone
Blue: only when granted permission
Purple: low-fly area
For now, the commercial use of drones is not allowed in the Netherlands, except when you have the right permit and papers. There are two types of permits in the Netherlands: ROC and ROC-Light. The implications for ROC-light are as follows: the maximum height you can fly with your drone is 50 meters and the maximum distance you can fly (horizontally) is 100 meters and is not allowed in controlled airspace. It always needs to be visible (being both daytime and in line of sight), it needs to weigh less than 4 kilograms and needs to keep a distance of 50 meters from buildings, crowds and obstacles. To be in charge of such a drone you need to be at least 18 years old and in possession of a drone theory certificate. For a ROC permit, the rules are almost the same, with a few exceptions: the maximum height is 120 meters, the horizontal distance is maximum 500 meters and the weight needs to be less than 150 kilograms. For the drone operator, there are also some additional requirements: a medical test is mandatory, as is liability insurance and technical examination of the drone. [18]
Apart from the non-permitted use of commercial drones, delivery by drones is almost impossible, as almost all of the big cities in the Netherlands are covered by no-fly zones and delivery options are scarce when drones are only allowed in the line of sight of an operator. This shows that the law is not completely ready for this technology. Luckily, the rules will change as per December 31rd, 2020, when the European Union will get the same regulations for unmanned aircraft systems. This date was originally July 1st, 2020, but that deemed impossible due to the corona crisis.
European Union
According to the regulations laid out by the European Union Aviation Safety Agency (EASA), drones will be divided into three categories: Open, Specific and Certified. This distinction will be based on safety and privacy risks. The first category, the Open category, makes no distinction anymore between recreational or professional usage: it only matters if the flights of the drone impose low risks. There are three subcategories in this Open category, with the criterium being weight. The main difference between these subcategories will be the distance needed to be held from people on the ground. We will not elaborate on this further, as delivery drones won't be classified in the Open category. Another important new requirement is that every drone-operator (being a person or a company) needs to register at an online system (read more at U-space), the only exception being drones weighing less than 250 grams without cameras - these are regarded as toys. For the operator: the minimum age is 16 years old and an online training and knowledge test need to be passed. Also, liability insurance is required. The distance requirements about traffic areas, buildings and other objects expire and are replaced by the requirement that these drones are not allowed to fly above crowds, people not involved with the drone operation or near airports and controlled airspace (within 3 kilometres). The height constraint of 120 meters remains, as does the visual line of sight. Lastly, CE marks become mandatory for drones.
The second category is the Specified category. Drone operations fall into this category when there is more risk involved, for instance when wanting to fly higher than 120 meters, flying with a drone of more than 25 kilograms or operations near people. Permission for a flight in this category will be granted after risk analysis is approved. Considering risk management, there are three options: Specific Operations Risk Assessment (SORA), Pre-Defined Risk Assessment (PDRA) and Standard Scenario (STS). A company can get a Light UAS Operator Certificate (LUC), which enables it to assess its own risk analysis. Again, we will not elaborate on these matters, as this is most probably not the category delivery drones will belong to.[19].
Then, lastly, the category most probable to contain delivery drones: the Certified category, for operations with high risk. High risk can be heavy drones flying above crowds, delivery drones in urban areas or even passenger transport. Now, the operational requirements are not yet worked out by EASA, but are expected in the course of 2021. This is also because regulations will most likely look like that for manned aviation, and are therefore also partly dependent on the development of U-space. [20]
U-space
Unlike the name suggests, U-space is not another airspace classification, such as Classes A-E for controlled airspace. Rather, it is a collective of services and procedures to secure safe access to the airspace for a large number of drones. A collaboration between the public and the private sectors, it addresses solutions to two fronts: regulatory requirements and practices, and technological solutions. According to their blueprint [22], these are the key principles of U-space:
- safety of all airspace users
- provide a scalable, flexible and adaptable system
- enable high-density operations with multiple automated drones
- guarantee equitable and fair access to airspace
- enable competitive and cost-effective service provision
- minimise deployment and operating costs by leveraging existing aeronautical services and infrastructure
- accelerate deployment by adopting technologies and standards from other sectors
- follow a risk-based and performance-driven approach when setting up appropriate requirements while minimizing environmental impact and respecting the privacy of citizens
The services of U-space will be rolled out over time in different 'phases', meaning that both automation and connectivity of the drone will increase.
U1: fundamental services
The foundation services are electronic registration, electronic identification and geofencing. In line with the aforementioned legislation, drones above 250 grams need to register digitally. These registers will also be interoperable and accessible in real time. Of course, electronic registration lays the foundation for electronic identification. Regarding geofencing, for the first phase, it will just be pre-tactical; availability of information prior to take-off.
U2: initial services
The second phase has its focus on the management of drone operations, as it will include flight planning, flight approval, tracking, dynamic airspace information and interfaces with air traffic control. Therefore, in contrast to the fundamental services of U1, it will aim at tactical geofencing; providing updated information during the flight.
U3: advanced services
As apparent, by the time phase U3 comes around, the airspace will be a lot more controlled. U3 takes it a few steps further: it will support more complex operations in dense areas and therefore implements detect and avoid functionalities. It will also provide more reliable means of communication.
U4: full services
The last phase will provide complete integration with manned air traffic and all services provided in the airspace. It will thus support the full operational capability of U-space and will rely on a very high level of automation, connectivity and digitalisation. However vague this sounds, it is for a good reason, as it is not clear - not even in the slightest way actually - how the full integration of drones into the aviation network will look like [23].
Cost Analysis
Nowadays parcels are delivered by a person who drives around with a heavy truck and goes by all the destinations. Therefore all packages are being taken to every location. Not only is this method inefficient in terms of emissions, it also takes a lot longer than is needed. Not to forget, the roads are already very occupied in the Netherlands and with the expected increase in parcel delivery the coming years this will only get worse if methods of delivering will not change. Besides all this, drone delivery has the potential to be also more cost-effective, which is of course the most important reason for delivery companies to use this new technique. Amazon has done quite some research already on the economics of drone delivery services and the outcome of this study shows huge potential. A standard delivery done by a deliverer from UPS with a truck was compared to an autonomous drone delivery [24]. All major and important factor were taken into consideration:
- Operating hours
- Traffic/Weather delays
- Labor hours
- Maintenance
- Research & Development
- Manufacturing/purchase
Not all costs mentioned above are applicable to both ways of delivering, but the most important contributions of both ways are treated. A big difference however with Amazon and for example PostNL would also be the fact that PostNL will likely have to buy drones from other companies, while Amazon has the recourses the develop them themselves. Another thing is that Amazon delivers way more packages than PostNL or any other company in the Netherlands. Nonetheless this research gives a good indication about the expected costs. Besides all the advantages mentioned above, there are also some disadvantages. Weather conditions for example are important for a successful drone delivery and when there is too much wind or rainfall there is still a backup option needed. This will likely be the current system of truck and delivery person. The problem is that it also costs money to have this option available, even when it is unused. This is something that is not taken into consideration in the research. The cost calculations were made with respect to delivery in urban areas, where on one side the distances are shorter, and on the other side traffic is an issue. In rural areas however traffic is not so much of an issue, plus the distance to delivery destinations are much larger. Therefore delivery by truck could still be more profitable in rural areas.
To compare drone delivery with delivery by trucks, only delivery in urban areas is considered here. There are different scenarios mentioned, one of them is that drones will deliver 24 hours a day, seven days a week. The cost per delivery is then estimated at 0.2 dollars. If drones only deliver 12 hours a day, but still seven days a week this would be 0.41 dollars. If you compare this with the costs of delivering a package with a deliverer and a truck, which is 1.20 dollars, the huge business potential immediately becomes clear, despite the differences mentioned earlier.
So as a conclusion it can be stated that from a business perspective, drone delivery has huge potential relative to today’s delivery methods. It should be mentioned however that this potential is mainly hidden in urban areas, at least for now, and there should be a certain amount of deliveries per day. How many this would be in a city like Eindhoven for example, should yet be determined.
Approach & Milestones
A provisionally planning for the project can be found below.
Deliverables
A video with the final presentation
Our final model, together with a simulation created by running our model
As mentioned earlier, the main focus of this project is to create a model of a system that will communicate with all delivery drones to prevent them from colliding and calculate the fastest possible trajectory. Besides that every drone will also have to be equipped with active anti-collision, to prevent any encounters with birds or private drones. To give an overview of what the model should do exactly, a list of RPC's is created:
Requirements
- All delivery drones will need to communicate at all times with the main system that controls the drones
- The system should be able to calculate trajectories of multiple drones without letting them collide
- The drone itself should make an avoiding action when it perceives another obstacle like a bird or a private drone that is within 10 meters
- When an avoiding action like described above happens, the main system should recalculate the trajectory for the drone after a distance of 10 meters to other moving objects is regained.
Preferences
- The system will need to give each drone such a trajectory that the total energy consumption of all delivery drones is lowest
- When an area is made into a no-fly zone, drones that were planned to fly over this area should be given a new trajectory as soon as possible
Constraints
- The drones should always follow the regulations imposed by the government, which are currently still under construction
- Delivery drones should always keep a distance of at least 10 meters towards each other
- Drones should keep a distance of at least 5 meters from buildings or electricity lines
Design considerations
Although only a small part of the whole delivery drone system will be modelled and simulated, research has been done in other areas that can be helpful with modelling and future studies. In this section, we will discuss some important influences on our communication model.
Communication
Firstly, the range is determined by the radio frequency, the amount of obstacles between the drone and the antenna, the transmitter amplifier power and the height of the antenna or receiver, the range can also be extended by using a low noise amplifier. The drone’s transmitter power is of course limited by the battery capacity. The most common frequencies used by small drones today are 900 MHz, 1.2 GHz, 2.4 GHz, and 5.8 GHz. Lower frequencies offer more range and better penetrating power through obstacles such as trees and buildings, however these also require larger antennas. Current high-end portable consumer remote controllers claim a range of 25-50 km using frequencies of 863-950Mhz or 433Mhz. The ground control system(GCS) will use antenna’s placed on tall buildings or on towers to increase the range and reduce the amount of obstacles in the way.
In drone communication, the MAVLink protocol is widely used. It stands for Micro Air Vehicle Communication Protocol and is a very lightweight protocol used for bidirectional communication between a drone and a ground station. There are two types, MAVlink 1 and MAVLink 2. MAVLink 1 has just 8 bytes of overhead per packet and MAVLink 2 has 14 bytes of overhead but is more secure and extensible. It provides methods for detecting packet drops, corruption, and for packet authentication [25]. The message structure of MAVLink is as follows: [26]
Latency
Another important factor to consider in the communication is latency. The total latency of a communication system has multiple contributions, like travel time, processing speed and queuing time. Radio waves travel with the speed of light in air, which over the communication distances these drones use comes down to tenths of a millisecond on a round-trip. Processing speed looks to be a bigger contribution, so the algorithms used by the ground-control system need to be as efficient as possible. The last important factor is queueing delay, because when more drones are trying to communicate with the GCS than it is capable of processing, the latency will go up as the data traffic will be placed in a queue, waiting to be processed. If the latency becomes too high, problems can occur when drones need a new trajectory. Also when weather conditions suddenly change and communication takes too long, height measurements of the drones based on pressure can become unreliable
In 2019 German researchers set up a test to determine the so called Round-Trip Latency, which is equal to sum of the travelling time from the ground control system to the drone, the processing time at the drone, and the time back to the ground [27]. With this test, a multi-radio communication protocol called Hyracom was used. Hyracom uses three different data links, 868 MHz, 2.4 GHz and 4G LTE, which operate in parallel and carry the same data, which are MAVLink packages. Only the signal that reaches the drone first will be processed, the other two packages with the same timestamp will be ignored. This will make the system more redundant to the environment, because the test shows a clear difference in results when testing either at a rural or an urban environment. In rural environments, LTE connection (3G or 4G) can be poor, and when this happens the other two will take over [28]. Because in this project we mainly focus on urban areas, only the results of this test setting will be shown here. The Round Trip Latency of the three separate signals are visualised, and what immediately stands out is that distance plays a negligible role.
What becomes clear of these results is that the 868 MHz signal does not have a big contribution in urban areas. Nonetheless, it is important not only for the situation where LTE connection is not strong enough, but also for security reasons (see Security below). The model of the ground control system that will be created for this project will not incorporate all the necessary hardware to simulate this data communication, only the sending and receiving of MAVLink packages will be simulated. Because of this, latency does not occur in the simulation by itself, but to get a better understanding of how the ground control system would perform in the real world, it will be manually manipulated in order to analyze the effects of it.
Security
With all the new smart devices that are made, cybersecurity is becoming more and more important in our society and of course that also holds for these delivery drones. If even one of these drones will be hacked, the consequences could be immense, let alone if they are all hacked at the same time. If they fall into the hands of terrorists, innocent civilians could be attacked. Multiple examples have been shown of drones being hijacked, some of which even led to fatal casualties [29]. There are different ways at which terrorists or criminals can manipulate the drone. Sometimes they only steal the data that is sent between the drone and the ground-control system. In this specific case this information can be used to for example steal a package from someone’s home, once it is delivered. In the table below there is an overview given of the possible threats, that are specifically related to data traffic between a drone and a ground-control system using MAVLink packages.
Confidential threats are when unauthorized people acquire the data that is sent, like in the example mentioned above. When the integrity is violated, the messages are being changed, or parts are added or removed. This could have severe consequences with lots of potential danger. Availability refers to the possibility of sending and receiving data. Deliberately jamming a signal for example falls under this category. For further explanation of the attack methods mentioned in the table one is referred to the paper [30].
The Hyracom communication protocol that was already discussed in the Latency section, comes with an encryption named AES, which stands for Advanced Encryption Standard. This encryption makes it impossible for hackers to retrieve or modify the data that is sent [31].
Unfortunately the availability of the communication is bit harder to guarantee. Lots of research has been conducted on this topic [32], but even presently it is very difficult to prevent someone from jamming a certain frequency. Luckily, Hyracom uses three signal all with different bandwidths, which makes it more robust to this problem. However, this does not solve it; if people are trying to disable the communication, they will probably jam all three signals. To fully tackle this problem more sophisticated procedures are necessary, and research on this is ongoing [33].
Spacing
In order to make sure that drones will keep enough distance towards each other, each drone will have to be able to calculate its own GPS location and height. Only then it can stay within the trajectory that was provided by the ground-control system. These measurements have certain accuracy which must be taken into account. Besides that the weather will also have an influence on this distance.
Today’s most common GPS receivers have an accuracy of 3-5 meters, however, there are newer GPS chips that use dual-frequency receivers, which are supposed to be accurate to 30 centimetres [34]. There are even mentions of accuracies of 3 centimetres [35], but for this project, we will stick with an accuracy of 30 centimetres. These sensors also do not require a lot of power, so they can be used in drones.
For the height measurement, drones measure the altitude at which they are flying only relative to the altitude at which they took off. They do this by measuring the air pressure and temperature at take-off and comparing this to samples taken in-flight [36]. Barometric sensors nowadays have an accuracy of about 50 centimeters [37]. As the drones will have different take-off altitudes this means that every drone calculates their height differently. A weakness of this method is that when the atmospheric pressure suddenly changes, for example when a cold front arrives, the calculated altitude can be very inaccurate. A solution to this is to constantly measure the air pressure at a central location and have every drone calculate its altitude relative to the changes measured at that point.
So the measurement errors are relatively small, but a sufficient amount of space between drones is also needed because they will have to take actions to avoid birds or private drones sometimes. In order to accomplish this without the need for the ground-control system to calculate a new trajectory, the drone needs to stay within an imaginary sphere. The centre of this sphere is a point moving through space, representing the predefined trajectory. As long as the drone stays within a certain distance to this point, so inside this imaginary sphere, it will not collide with other delivery drones because the ground-control system will calculate trajectories in which the edges of these bubbles are always at least 2 meters apart. The idea is visualized in a simple sketch:
Not enough research has been done yet to determine the perfect diameter for this sphere. When this system will be tested in real-time, a more detailed estimation can be given. For now, it is assumed that both the delivery drone and the obstacle have a size of 1.5 meters in all directions. Adding an additional safety factor the diameter is set to 20 meters so that the drone has about 10 meters in each direction to make a manoeuvre. As mentioned, this parameter can be further perfected by conducting more research.
Model
As mentioned above, a model will be delivered with a simulation to show that this model functions correctly at the end of the project. We will model the Traffic Management System in Java. This system will receive coordinates of the current location and the destination from multiple drones. It will then calculate 3-dimensional trajectories for all drones simultaneously using breadth-first search, without letting the drones collide. It will receive constant updates of the location by GPS and the height measurement system (see Design considerations). It also keeps track of certain properties of the drone (see Communication between system and drone). The drones will only receive information from the system if there is a temporary no-fly zone somewhere, or if the drone had to leave its trajectory to avoid a bird or a private drone which is (illegally) flying and not connected to the system. If the latter occurs, the system will calculate a new trajectory and send this to the drone. The anti-collision and data-traffic themselves are not modelled, as this would require to model all the hardware. This will not fit in the scope of this project.
The simulation will look like a big 2D space in which objects (that represent the drones) are moving towards a location without colliding. They all have a number which represents their height. There are also static obstacles visible, which represent for example buildings or electricity lines, and moving objects which represent private drones or birds.
Code structure
Description of all classes
- Drone: This class contains the information and all parameters of a single drone. The functions in this class can be used to move the drone, as well as changing and retrieving all information about the drone itself. During each step of the model, the drone moves based on its status and receives all communication from other entities.
- DroneCom: This class contains the framework for the communication of a drone. It contains functions to send messages to the TMS, as well as a function to parse the messages that have been received by the drone.
- DroneSystem: The DroneSystem class represents the main method of our model. This class serves as a controller for the system. It is responsible for the initialization of the system and the updating of the map during each step of the model.
- Fleet: This class represents a fleet of drones and a list of Traffic Management Systems. Upon each timestep in the model, the Fleet class will call the step method for each drone and each TMS. This class is also responsible for moving the drones in the fleet and adjusting the routes when necessary.
- TMS: This class models the drone control system of our model, the Traffic Management System. This class contains the main overview of the system, together with functions to update the status of the system. During each step of the model, the TMS updates the weather information, receives all communication from other entities and changes any routes if a new no-fly zone appears in their radius.
- TMSCom: This class contains the framework for the communication of a TMS. It contains functions to send messages to the drones, as well as a function to parse the messages that have been received by the TMS.
- Communication: The communication class ensures that all packets sent by the DroneCom class and the TMSCom class are received properly by the other party. To simulate a real-life situation, some latency is also added to the communication.
- Environment: The Environment class contains the description of the current environment. This class contains the temperature, the pressure and information about obstacles and no-fly zones.
- Grid: This class contains an overview of the region in which our system is operating. It contains a 3-dimensional array of nodes that show the current status of their respective space in the world. The values of these nodes can indicate normal nodes, obstacles, sources, destinations, drones or no-fly zones.
- Map: The Map class can be used to visualize the model on the user's screen. It draws the nodes, drones and routes on the screen so the user has an overview of the system.
Traffic Management System functions
- Provide the drones with the weather and geospatial information
- Ensure drones do not enter no-fly zones and exit unexpected new no-fly zones as quickly as possible
- Check that flight plans do not collide with each other while optimizing all routes whenever possible
- Track the status of all drones currently in flight
- Track unexpected objects such as rogue drones and birds with information passed by the drones
Functions
Model
- In the initialization, the model sets the timestep of the simulation, initializes the location and destination of all drones and simulates rogue UAVs
- The model can set the atmospheric pressure and temperature to test the elevation calculation of the drones
- The model has a list with locations containing the coordinates of the location and its elevation relative to the ground
- The model has functions to simulate the latency and detection delay that would be present in a real world situation
- Whenever a drone needs a new or optimized route, the model will assign a new route to a drone
- The model can change the environment and simulate the communication between a drone and the traffic management system
- The results of the simulation, such as average delivery time and the amount of collisions, can be tracked by the model
System
- The TMS keeps track of the location and status of all drones while the simulation is active
- The system also keeps track of the weather conditions, unexpected no-fly zones and locations of rogue UAVs sent by the drones
- The system checks the flight plan of all drones to ensure no collisions happen
- The system communicates route adjustments and environmental changes to the drones when necessary
Drone
- The drone stores a lot of information about itself, including its position, destination, speed, priority, flight plan, status, manoeuvrability category, maximum range, direction and the baryonic pressure + air temperature to compute the current altitude of the drone
- The drone also has a system to detect and evade any unexpected objects that are in close proximity
- It communicates with the TMS about the current status of the drone and any unexpected events that may occur
Communication between system and drone
For such a system to work properly, there needs to be some kind of communication between the system and every drone. Each drone will always try to communicate with a traffic management system nearby. If there are no traffic management systems nearby, the drone will follow its last known route. If there is no last known route, the drone will fly straight to its destination. Conversely, if there are multiple traffic management systems in the range of the drone, the drone will always communicate with the closest system. This is a similar method as used by airplanes. The airplane will communicate with multiple air control towers while in flight, just like a drone in our system would do for a long flight. For example, when flying across America, a plane will communicate with 28 controllers in 11 different facilities all across the United States[38]. A drone would also communicate with multiple systems while in flight. However, the drone system does not have different systems for takeoff, mid flight and landing. These flight stages can all be handled by the same TMS.
The communication is done using the MAVLink protocol as denoted in the Design considerations. The following packets are sent from the drone to the system:
- When the drone first connects to the system, the drone will send a message to the system containing the drone's destination, the manoeuvrability category of the drone and its priority. This is needed to help the system to send the drone to the correct destination.
- The drone sends regular status updates to the system. These updates contain the drone's speed, the current status (whether the drone is flying/landing) and the drone's updated position.
- When the drone gets a new mission, it will send its new destination to the system, together with its updated priority and an update to the drone's manoeuvrability category.
- If the drone needs to dodge an unexcepted object and has to leave its route, it will resend its position to the system.
- When the drone leaves the radius of the system or if the communication needs to be stopped for a different reason, the drone will send a goodbye message to the system.
Demonstration
Here is a screenrecord of a single run of the model, where first two random no-fly zones are instated, and then the weather information is changed very dramatically, to clearly show the effect. When the no-fly zones are instated, one drone that was inside it is given the shortest route out, and two other drones whose destinations are inside the no-fly zones are notified of this and told to request a new destination. This last process seems to not always work correctly, in other runs drones which had a destination inside a no-fly zone seem to get stuck, maybe because their destination does not get updated properly although it is unclear why. When the weather changes the drones outside of the system's range crash, while the drones inside the range get corrected quickly and can keep on going.
Simulation tests
In the simulation of our model, we want to test a few things to make it clear how the system would perform in the real world. As mentioned before in the design considerations, communication is influenced by the latency, which in turn is also influenced by the processing capacity of the system. It is important to note that this is not something we are going to model and manipulate in this simulation because it’s part of the hardware, so the values we find might not be applicable in the real world; it will really be dependent on the processing capacity of the system in use. As we focus our project (and we believe the main use of delivery drones in general is) on urban areas, it is important that there are no collisions taking place at any point in time. The stakes of there being injuries or even casualties because of colliding drones (including packages) are too high to permit any mistakes happening [39]. Therefore, we want to use this simulation to see the maximum number for latency that can occur in our communication system before a collision happens. Initially, we set the latency to 200ms (see Latency) and we will manipulate this number to be higher to see what happens. We also want to see what the effect of adding more drones in our model is on this number, as this is an interplay; the latency will increase as more drones are used. While deploying more than two drones in our model, we also want to test for the maximum latency when using a little margin of error. A success rate of 98.22% in collision avoidance for 100 UAV's performing planned missions has been reached before, so we want to test for that here as well. [40]
Another thing we want to test in our model is how quickly the drones in the system will react if a sudden no-fly zone appears. This can happen when, for instance, the police wants to use drones for an investigation and requests a no-fly zone for other drones in U-space. Investigating this includes how quickly the system gets drones out of the no-fly zone, and/or in what time span the system can make sure a drone does not even enter a no-fly zone.
Testing method
To test our model, we use the following method:
1. Start the first simulation with a latency number of 200 milliseconds
2a. If no crashes happen with this latency and the drones get out of new no-fly zones fast, increase the latency and run the simulation again
2b. If a crash happens or if drones take too much time getting out of new no-fly zones, we take the last latency that worked and take that as maximum latency for our model
Conclusions to be drawn from testing
When we get a maximum latency for our model from the tests, we know that we need to keep the expected latency of any real life situation below this number. The maximum number of drones for each real life system can be computed by looking at the maximum number of drones a system can handle before queueing delay occurs and the amount of queueing delay that gets added for each drone after this maximum has been reached. When the latency gets above our computed maximum latency, we know that the real life system is unable to handle that number of drones.
We are not able to determine the maximum number of drones for a general case, since the queueing delay depends on the power of the system running our model. If the system is very powerful, we can have a large number of drones in the area at the same time without the latency being too high. Conversely, if the system is very weak, our model will become unusable much quicker and the maximum capacity will be low.
Anti-collision system
Although the anti-collision system will not be modelled and simulated in this project, it is still useful to do research on what kind of system would be the best for delivery drones. Therefore an investigation has been done on different kinds of tools for a drone to perceive its surroundings. Since the ground control system will calculate a trajectory for all the delivery drones in a way that they will not collide with each other and static objects, the anti-collision system will only come into action when there are moving obstacles like birds or private drones which are not connected to the system. For the drone to be able to detect these obstacles in time, there are multiple techniques which can be used.
RADAR
Radar is a relatively old technique, which is used in many applications to detect ships, planes, spaceships and other types of vehicles. But it is also used to predict weather. The basic idea is to send out radio waves and then perceive the reflection of this signal. It operates on a very broad frequency range, and has a range of up to several hundred meters in which it can provide a reasonable accuracy [41] A disadvantage is its relatively high weight, but constant improvements are made on this . [42]. It also operates well in all weather conditions.
LIDAR
Lidar is method for determining the distance to an object by emitting a pulsed laser beam and measuring the time it takes for an object to reflect it and send it back. It is used in multiple areas such as autonomous cars, agriculture, archaeology and geology [43]. When multiple laser and sensors are used in all directions it can create a complete image of its surroundings. It has a higher accuracy than Radar and a lower weight [44]. A disadvantage is that it is affected by rain and fog, but progress is being made on this.
SONAR
With sonar there are sound waves emitted, instead of electromagnetic radiation. It also relies on the principle of the reflection of another object. It is mainly used underwater by submarines, but recently research has also been done for applications for obstacle avoidance systems of drones. [45] [46]. However in these cases it was used for drones flying inside a building. This is because the accuracy decreases for objects that are further away [47]. The update speed of sonar is relatively low Design and analysis of a novel sonar-based obstacle-avoidance system for the visually impaired and unmanned systems.
Comparison
Based on all different aspects of the techniques mentioned above and taking the most important design characteristics into consideration, the best choice is an obstacle avoidance systems based on Lidar. It provides the most accurate estimation of the distance to an obstacle, and can therefore calculate the relative speed of that obstacle with respect to the drone the most accurate [48] This system is also the least heavy, which is a very important aspect for drones. A disadvantage compared to Radar is that its performance drops with rain or fog. But luckily, as already mentioned above lots of progress has been made concerning the robustness in almost all types of weather conditions [49]. Another advantage of LiDAR is its superior frame rate, which is about 10 Hz [50] [51] Because of this high frame rate obstacles will be noted by the drone in time and an avoiding action can be taken if necessary.
Reflection
Looking back, a central ground control system alone might not be the most efficient solution to this problem. We stated in our problem statement that we didn’t just want to use laid out routes in the sky, which we stick by, but a combination of both might create a more optimal solution because research has shown that structuring the airspace has a significant role in air traffic management. [ref] It was not feasible for us to implement that as well in our model to test for both things, so no definite conclusion can be given for that matter. But looking back, that is one thing that we may have wanted to do differently.
What we can say, however, is that for the calculation of the routes, there are more efficient algorithms that we could have used. We stated for one of the preferences that we would like to give each drone such a trajectory that the total energy consumption of all delivery drones is lowest. There has been done research on and algorithms created for this matter [52] [53] Looking at the costs and risks, algorithms that take this into account for their path planning [54] might also have been interesting to implement. But again, for the scope of this project, this was not feasible for us to implement.
Code Sources
The code written for this project can be found on GitHub here. Included on this repository is the Roaf package, the total package was downloaded from here but as only a small part of it was used only the required files are included on the GitHub. Furthermore inside our package is a file called MavlinkPacket.java, this file is a part of the package found here this was moved into our package because the gradle of the original kept causing errors. Finally the Grid.java file is based on this file, it was edited to work in 3 dimensions and with a Value class with timeslots instead of integers and some other methods were added as well.
State of the Art
How reliable does a delivery drone have to be? [55] When a delivery drone fails, it can severely impact the people near it. However, setting a concrete reliability goal for delivery drones is not easy. Multiple sensors on the drone can fail at any moment, leading to dangerous situations. Companies need to take costs, public safety and technological options into consideration when setting a reliability goal.
Logistic deliveries with Drones. State of the art of practice and research. [56] In this paper, the current status of delivery drones is discussed. The authors look at previous tests with drones within the medical and logistic sections. The current state of the research regarding drones is also evaluated. The authors conclude that drones are only able to replace traditional transport methods in very special situations, as there are still too many negatives for drone delivery to work perfectly.
Analysis of Amazon Prime Air UAV Delivery Service. [57] This paper analyses the status of the Amazon Prime Air drones. Different aspects of the drone are discussed, such as its specifications, the delivery costs using the drones and the current regulations concerning drones.
Drones as a Threat to Wildlife: YouTube Complements Science in Providing Evidence about Their Effect [58] This paper discusses the effect of drone usage on the behavior of wildlife in the area by analyzing YouTube videos made by drones.
International Commercial Drone Regulation and Drone Delivery Services [59] This paper discusses the laws concerning drones in different countries with regards to required licenses and line-of-sight regulations.
Amazon’s Drone Patents [60] This paper discusses the drone patents granted to Amazon regarding concepts for delivery drones. This includes patents for aircraft design, safety systems and methods for transferring goods from the air to the ground.
Energy use and life cycle greenhouse gas emissions of drones for commercial package delivery [61] In this paper the energy consumption and the greenhouse emissions of a delivery drone system are discussed.
Strategic Design for Delivery with Trucks and Drones [62] This paper elaborates an investigation where multiple drones are deployed from trucks to deliver packages, and compare this to the case where only trucks are used to deliver packages.
Drone Delivery Models for Healthcare [63] This paper investigates the use of delivery drones specifically for healthcare applications. Especially for developing countries this could be interesting since only a third of all Africans live within 2 kilometres of a road that is functional all year. Deploying drones for delivery could thus potentially save lives.
Framework for Autonomous Movement of Drones [64] In this paper a test is elaborated how good the delivery by drone is. Practical considerations such as electromagnetic interference, weather conditions, range, capacity and construction are all elaborated.
Vehicle Routing Problem with Drones for Last Mile Delivery [65] This paper does research on the efficiency of the 'last mile delivery', which means that a truck drives within a mile of the delivery address and then a drone departs from that truck and delivers the package.
An adapted TPB approach to consumers’ acceptance of service-delivery drones [66] This paper discusses consumers' acceptance of drones for service-delivery technology by applying the theory of planned behaviour (TPB). It names consumers' perceived risks of drones' usage as well as potential functional benefits, and the relational attribute to the drone.
The multiple flying sidekicks traveling salesman problem: Parcel delivery with multiple drones [67] The multiple flying sidekicks traveling salesman problem(mFSTSP) is a scenario in which a delivery truck and a heterogeneous fleet of unmanned aerial vehicles (drones) coordinate to deliver small parcels to geographically distributed customers, wherein the objective of the problem is to leverage the delivery truck and the fleet of UAVs to complete the delivery process and return to the depot in the minimum amount of time. This paper proposes a three-phased heuristic solution approach for this problem with an analysis to highlight the benefits and limitations, as well as the impacts of the region size, potential automation improvements, and implications of different endurance models.
Air traffic control for delivery drones [68] This short article introduces us to the company PrecisionHawk, which is working on the challenge to coordinate drones beyond the light of sight. They mimic the strategy that is increasingly being used to manage full-size aircraft, whereby those aircraft determine their positions using GPS or some other form of satellite navigation and broadcast that information by radio to everyone else. This form of air traffic management is called ADS-B (for Automatic Dependent SurveillanceBroadcast). While it seems sensible to integrate drones in this system, with the growing number of UAVs this system can get easily overwhelmed, and thus an independent system for drone-traffic management seems inevitable.
Flying drones beyond the line of sight using 4G LTE: issues and concerns[69] This paper discusses the extent in which 4G LTE (4th Generation, Long Term Evolution) can be used for air traffic management of small Unmanned Air Vehicles (sUAVs) and the limitations and enhancements that may be necessary.
Drones in Smart Cities: Overcoming Barriers through Air Traffic Control Research [70] This paper focuses on small, low-altitude UAV flights in densely populated cities, which would be the most valuable type of robotic aircraft flight. For this, it presents a cloud-based system for city-wide unmanned air traffic management, prototype sensor systems required by city police to keep the city safe, and an analysis of control systems for collision avoidance.
Pakketbezorging in 2019: meer volume, maar tarieven blijven dalen [71] This article describes the growth of the package delivery market in the Netherlands in 2019 and makes predictions on the growth in 2020.
Geen misstanden geconstateerd bij pakketbezorgers, maar zorgen blijven [72] This article illustrates the increased pressure on the package delivery market and describes problems with package deliverers’ working conditions and law violations.
Klachten pakketbezorging [73] This article analyses the complaints received by the dutch consumer’s bond about package delivery services. The main relevant problems are packages which are delivered late or never, the deliverer falsely marks the recipient as ‘not home’ and inaccurate tracking.
Security, Privacy, and Safety Aspects of Civilian Drones: A Survey [74] This survey is about the security, privacy, and safety aspects associated with the deployment of civilian drones into the national airspace. It identifies both cyber and physical threats to drones.
Security, Privacy and Safety Evaluation of Dynamic and Static Fleets of Drones [75] This paper investigates the challenges faced by fleets of unmanned aerial vehicles (UAVs) and the ways that these can be managed. It proposes a method of fleet control based on swarm intelligence.
Blockchain-base structures for a secure and operate network of semi-autonomous Unmanned Aerial Vehicles [76] This paper analyses the probable security threats to an interoperable UAV communication network and proposes to use and describes a blockchain based structure to secure such a network.
Understanding the drone epidemic [77] This paper describes the attributes of drones that challenge existing regulatory arrangements. It documents the nature and characteristics of drones, the dimensions across which they vary, the purposes to which they are put, and the impacts that they appear likely to have.
Who is doing what?
Week 1
Name | Total hours | Tasks |
---|---|---|
Emmy | 5.5 | Watched videos and lectures [1h], brainstorm session [1.5h], worked on problem statement and objectives [1h], read articles and wrote summeries [2h] |
Mayra | 5 | Watched introductory videos and introductory lecture [1h], brainstorm session [1.5h], studied papers 13-18 and wrote summaries [1.5h], worked on users and user needs [1h] |
Rick | 5 | Watched lectures [1 h], Brainstrom session [1.5h], Reading papers [2 h] and making the planning [0.5 h] |
Roel | 5.5 | Watched introductory videos [0.5h], Introductory lecture [0.5h], Brainstorm session [1.5h], Researched papers, wrote summaries and wrote deliverables [3h] |
Week 2
Name | Total hours | Tasks |
---|---|---|
Emmy | 3 | tutor meeting [0.5h], group meetings [1h], researching architecture control systems [1.5h] |
Mayra | 3.5 | tutor meeting [0.5h], group meetings [1h], researching stakeholders and user groups [1h], making a draft for the user (customers) questionnaire [1h] |
Rick | 5 | Tutor meeting [0.5h], Group meetings [1h], Doing research on laws about drones [3.5h] |
Roel | 5 | Tutor meeting [0.5h], Group meetings [1h], Writing email and finding company contact information [4h] |
Week 3
Name | Total hours | Tasks |
---|---|---|
Emmy | 3 | tutor meeting [0.5h], group meetings [1.5h], writing out the questionnaire [1h] |
Mayra | 3 | tutor meeting [0.5h], group meetings [1.5h], making the questionnaire in Google forms [1h] |
Rick | 2.5 | Tutor meeting [0.5h], Group meeting [1.5h], Create questions and send email to companies [0.5h] |
Roel | 2 | Tutor meeting [0.5h], Group meeting [1.5h] |
Week 4
Name | Total hours | Tasks |
---|---|---|
Emmy | 2.5 | Tutor meeting [0.5h], group meeting [1h], researching sources and ArduSim [1h] |
Mayra | 5.5 | Tutor meeting [0.5h], group meeting [1h], doing research for RPCs [4h] |
Rick | 5 | Group meeting [1h], Doing research and writing about user, society and enterprise needs [4h] |
Roel | 3 | Tutor meeting [0.5h], Group meeting [1h], contacting companies [1.5h], |
Week 5
Name | Total hours | Tasks |
---|---|---|
Emmy | 12.5 | tutor meeting [0.5h], group meetings [2h], working on ArduSim [6h], writing Design Constraints and early design [4h] |
Mayra | 12.5 | tutor meeting [0.5h], group meetings [2h], look for arguments for problem statement [3h], adjusting problem statement [2h], adjust planning [0.5h], elaborate on legislation [3h], investigate and write about U-space [1.5h] |
Rick | 15 | tutor meeting [0.5h], group meetings [2h],Doing research on different types of systems [10h], typing out use cases and RPC's [2.5h] |
Roel | 10.5 | tutor meeting [0.5h], group meetings [2h], working on ArduSim [5h], working on own drone code [3h] |
Week 6
Name | Total hours | Tasks |
---|---|---|
Emmy | 41 | tutor meeting [0.5], group meetings [5.5h], designing and programming Communication, DroneCom, Fleet, Environment, DroneSystem, Utilities classes, all non get/set methods of Drone class and (re)writing Map class [35h] |
Mayra | 21 | tutor meeting [0.5], group meetings [5.5h], doing research and working on simulation [15h] |
Rick | 30 | tutor meeting [0.5h], group meetings [5.5h], Doing research and work out design considerations [20h], General work on wiki page [4h] |
Roel | 17.5 | group meetings [5.5h], working on code [12h] |
Week 7
Name | Total hours | Tasks |
---|---|---|
Emmy | 44 | tutor meeting [0.5h], group meetings [2.5h], researching route-finding algorithms [1h], designing and programming TMS and TMSCom classes, extending Map, Environment, Utilities, Drone, Fleet, Grid classes [25h], testing and adjusting model [15h] |
Mayra | 11 | tutor meeting [0.5h], group meetings [2.5h], working on presentation [8h] |
Rick | 20 | tutor meeting [0.5h], group meetings [2.5h], working on presentation [10h], working on wiki page [7h] |
Roel | 15 | tutor meeting [0.5h], group meetings [2.5h], working on code structure [10h], working on presentation [2h] |
Week 8
Name | Total hours | Tasks |
---|---|---|
Emmy | 10.5 | presentation meeting [1.5h], group meetings [1.5h], fixing Drone position calculation and refining object detection [3.5h], cleaning up code and adding comments [2h], writing code sources [0.5h], making screenrecord [1h], writing model demonstration [0.5h] |
Mayra | 11 | presentation meeting [1.5h], group meetings [1.5h], working on USE section [5h], general work in wiki page [3h] |
Rick | 11 | presentation meeting [1.5h], group meetings [1.5h], working on wiki page [8h] |
Roel | 10 | presentation meeting [1.5h], group meetings [1.5h], working on wiki [4h], working on code structure [3h] |
References
- ↑ van Gurp, T. (2020, July 8). Pakketbezorging in 2019: meer volume, maar tarieven blijven dalen. Nieuwsblad Transport.
- ↑ M. Lange de, H. Gordijn, H. Derriks, and G. Gelauff. Drones in het personen- en goederenvervoer. Technical Report KiM-17-A08, Kennisinstituut voor Mobiliteitsbeleid (KiM), Den Haag, Sept. 2017.
- ↑ SESAR (2016). European Drones Outlook Study – Unlocking the value for Europe. Brussel: SESAR Joint Undertaking
- ↑ Sunil E., Hoekstra J., Ellerbroek J., Bussink F., Nieuwenhuisen D., Vidosavljevic A., Kern S. Metropolis: Relating airspace structure and capacity for extreme traffic densities; Proceedings of the ATM Seminar 2015, 11th USA/EUROPE Air Traffic Management R&D Seminar; Lisbon, Portugal. 23–26 June 2015.
- ↑ Sunil E., Hoekstra J., Ellerbroek J., Bussink F., Vidosavljevic A., Delahaye D., Aalmoes R. The influence of traffic structure on airspace capacity; Proceedings of the ICRAT2016—7th International Conference on Research in Air Transportation; Philadelphia, PA, USA. 20–24 June 2016.
- ↑ Fabra, F., Zamora, W., Sangüesa, J., Calafate, C. T., Cano, J. C., & Manzoni, P. (2019). A distributed approach for collision avoidance between multirotor UAVs following planned missions. Sensors, 19(10), 2404.
- ↑ Samir Labib, N., Danoy, G., Musial, J., Brust, M. R., & Bouvry, P. (2019). Internet of Unmanned Aerial Vehicles—A Multilayer Low-Altitude Airspace Model for Distributed UAV Traffic Management. Sensors, 19(21), 4779.
- ↑ Khan, R., Tausif, S., & Javed Malik, A. (2019). Consumer acceptance of delivery drones in urban areas. International Journal of Consumer Studies, 43(1), 87-101.
- ↑ Zahy B. Ramadan, Maya F. Farah & Mona Mrad (2017) An adapted TPB approach to consumers’ acceptance of service-delivery drones, Technology Analysis & Strategic Management, 29:7, 817-828
- ↑ Yoo, W., Yu, E., & Jung, J. (2018). Drone delivery: Factors affecting the public’s attitude and intention to adopt. Telematics and Informatics, 35(6), 1687-1700.
- ↑ Delivery drones: coming to the sky near you? Heerkens, J. (2015)
- ↑ Drones as a Threat to Wildlife: YouTube Complements Science in Providing Evidence about Their Effect. Rebolo, N. Grilli, M. Lambertucci, S. (2019)
- ↑ The Speed of Birds. The Auk, 23(4), 479-479. Lucas, F. (1906).
- ↑ Responsibility and the Moral Phenomenology of Using Self-Driving Cars. Coeckelbergh, M (2016).
- ↑ Coordinated logistics with a truck and a drone. Carlsson, J. and Song, S. (2017)
- ↑ Xu, Jia, Design Perspectives on Delivery Drones. Santa Monica, CA: RAND Corporation, 2017.
- ↑ 'Laws concerning drones
- ↑ [1]
- ↑ [https://www.dronewatch.nl/2019/04/12/dit-is-wat-de-invoering-van-de-europese-drone-regelgeving-medio-2020-voor-nederland-gaat-betekenen/ / 'EU laws drones]
- ↑ [2]
- ↑ [3]
- ↑ Undertaking, S. J. (2017). U-space Blueprint. SESAR Joint Undertaking. Accessed September, 18.
- ↑ Huttunen, M. (2019). The u-space concept. Reprinted from Air & Space Law, 44(1), 69-89.
- ↑ A Cost Analysis of Amazon Prime Air (Drone Delivery). Hutchinson, E. B. Sudbury, A. W. (2016)
- ↑ / MAVLink Developer Guide
- ↑ Empirical Analysis of MAVLink Protocol Vulnerability for Attacking Unmanned Aerial Vehicles. Kwon, Y. Yu, J. (2018)
- ↑ Flight Tests of Ranges and Latencies of a Threefold Redundant C2 Multi-Link Solution for Small Drones in VLL Airspace Volkert, A. Hackbarth, H. (2019)
- ↑ Flight Tests of Ranges and Latencies of a Threefold Redundant C2 Multi-Link Solution for Small Drones in VLL Airspace Volkert, A. Hackbarth, H. (2019)
- ↑ A Review on Cybersecurity Vulnerabilities for Unmanned Aerial Vehicles. Krishna, L.C.G. Murphy, R. R. (2017)
- ↑ Empirical Analysis of MAVLink Protocol Vulnerability for Attacking Unmanned Aerial Vehicles. Kwon, Y. Yu, J. (2018)
- ↑ MAVSec: Securing the MAVLink Protocol for Ardupilot/PX4 Unmanned Aerial Systems. Allouch, A. Cheikhrouhou, O. (2019)
- ↑ Vulnerability Analysis of the MAVLink Protocol for Command and Control of Unmanned Aircraft. Marty, J. A. (2014)
- ↑ Game-theoretic analysis of an aerial jamming attack on a UAV communication network. Bhattacharya, S. (2010)
- ↑ [4]
- ↑ Accurate absolute GPS positioning through satellite clock error estimation. Han, S.C. Kwon, J.H. (2001)
- ↑ [5]
- ↑ [6]
- ↑ [7]Federal Aviation Administration (2019)
- ↑ Lum, C., & Waggoner, B. (2011). A risk based paradigm and model for unmanned aerial systems in the national airspace. In Infotech@ Aerospace 2011 (p. 1424).
- ↑ Fabra, F., Zamora, W., Sangüesa, J., Calafate, C. T., Cano, J. C., & Manzoni, P. (2019). A distributed approach for collision avoidance between multirotor UAVs following planned missions. Sensors, 19(10), 2404.
- ↑ UAV based collision avoidance radar sensor. Kwag, Y. K. Chung, C. H. (2007)
- ↑ A Survey on Unmanned Aerial Vehicle Collision Avoidance Systems. Pham, H. Smolka, S. H. (2015)
- ↑ Beyond 3-D: The new spectrum of lidar applications for earth and ecological sciences. Eitel, J.U.H. Höfle, B. (2016)
- ↑ LIDAR obstacle warning and avoidance system for unmanned aerial vehicle sense-and-avoid. Ramasamy, S. Sabatini, R. (2016)
- ↑ Collaborative Obstacle Avoidance Method of Surface and Aerial Drones based on Acoustic Information and Optical Image Dong-Woo, M. (2015)
- ↑ Efficient Optical Flow and Stereo Vision for Velocity Estimation and Obstacle Avoidance on an Autonomous Pocket Drone. McGuire, K. de Croon, G. (2017)
- ↑ Collaborative Obstacle Avoidance Method of Surface and Aerial Drones based on Acoustic Information and Optical Image Dong-Woo, M. (2015)
- ↑ Collision Avoidance of Hexacopter UAV Based on LiDAR Data in Dynamic Environment. Park, J. Cho, N. (2020)
- ↑ LIDAR obstacle warning and avoidance system for unmanned aerial vehicle sense-and-avoid. Ramasamy, S. Sabatini, R. (2016)
- ↑ Visual Teach and Repeat using appearance-based lidar. McManus, C. Furgale, P. (2011)
- ↑ RangeNet++: Fast and Accurate LiDAR Semantic Segmentation/ Milioto, A. Vizzo, I. (2019).
- ↑ Baek, D., Chen, Y., Bocca, A., Macii, A., Macii, E., & Poncino, M. (2018, July). Battery-aware energy model of drone delivery tasks. In Proceedings of the International Symposium on Low Power Electronics and Design (pp. 1-6)..
- ↑ Ahmed, S., Mohamed, A., Harras, K., Kholief, M., & Mesbah, S. (2016, April). Energy efficient path planning techniques for UAV-based systems with space discretization. In 2016 IEEE Wireless Communications and Networking Conference (pp. 1-6). IEEE.
- ↑ Hu, X., Pang, B., Dai, F., & Low, K. H. (2020). Risk Assessment Model for UAV Cost-Effective Path Planning in Urban Environments. IEEE Access, 8, 150162-150173.
- ↑ How reliable does a delivery drone have to be? Schenkelberg, F. (2016)
- ↑ Logistic deliveries with Drones. State of the art of practice and research. Roca-Riu, M., Menendez, M. (2019)
- ↑ Analysis of Amazon Prime Air UAV Delivery Service. Sunghun, J., Hyunsu, K. (2017)
- ↑ Drones as a Threat to Wildlife: YouTube Complements Science in Providing Evidence about Their Effect. Rebolo, N., Grilli, M.G., Lambertucci, S.A. (2019)
- ↑ International Commercial Drone Regulation and Drone Delivery Services. Jones, T. (2017)
- ↑ Amazon’s Drone Patents. Michel, A.H. (2017)
- ↑ Stolaroff, J.K., Samaras, C., O’Neill, E.R. Energy use and life cycle greenhouse gas emissions of drones for commercial package delivery. (2018)
- ↑ Strategic Design for Delivery with Trucks and Drones. Campbell, J.F., Sweeney, D. C., Zhang, J. (2017)
- ↑ Drone Delivery Models for Healthcare. Scott, J. Scott, C. H. (2017)
- ↑ Framework for Autonomous Movement of Drones. Milhouse, M. O. (2015)
- ↑ / Vehicle Routing Problem with Drones for Last Mile Delivery. Kitjacharoenchai, P., Seokcheon, L. (2019)
- ↑ Zahy B. Ramadan, Maya F. Farah & Mona Mrad (2017) An adapted TPB approach to consumers’ acceptance of service-delivery drones, Technology Analysis & Strategic Management, 29:7, 817-828
- ↑ Murray, C.C., Raj, R., 2020. The multiple flying sidekicks traveling salesman problem: Parcel delivery with multiple drones. Transport. Res. Part C: Emerg. Technol.110 (February 2019), 368–398
- ↑ D. Schneider, "Air traffic control for delivery drones" in IEEE Spectrum, vol. 54, no. 1, pp. 32-33, January 2017
- ↑ Ivancic, W. D., Kerczewski, R. J., Murawski, R. W., Matheou, K., Downey, A. N., & 2019 Integrated Communications, Navigation and Surveillance Conference (ICNS) Herndon, VA, USA 2019 April 9 - 2019 April 11. (2019). 2019 integrated communications, navigation and surveillance conference (icns). In Flying drones beyond visual line of sight using 4g lte: issues and concerns (pp. 1–13). essay, IEEE
- ↑ A. G. Foina, R. Sengupta, P. Lerchi, Z. Liu and C. Krainer, "Drones in smart cities: Overcoming barriers through air traffic control research," 2015 Workshop on Research, Education and Development of Unmanned Aerial Systems (RED-UAS), Cancun, 2015, pp. 351-359
- ↑ van Gurp, T. (2020, July 8). Pakketbezorging in 2019: meer volume, maar tarieven blijven dalen. Nieuwsblad Transport.
- ↑ [8]
- ↑ [9]
- ↑ [10]
- ↑ [11]
- ↑ [12]
- ↑ [13]