- Email: [email protected]
Building, Verifying and Validating a Collision Avoidance Model for Unmanned Aerial Vehicles
Available online at www.sciencedirect.com
ScienceDirect Procedia Engineering 178 (2017) 155 – 161
16thConference on Reliability and Statistics in Transportation and Communication, RelStat’2016, 19-22 October, 2016, Riga, Latvia
Building, Verifying and Validating a Collision Avoidance Model for Unmanned Aerial Vehicles Dmitrijs Lancovs* Transport and Telecommunication Institute, Lomonosova 1, Riga, LV-1019, Latvia SPH Engineering, Daugavgrīvas 140, Riga, LV-1007, Latvia
Abstract This paper documents verification and validation of a multi-rotor aircraft emulator in a collision avoidance simulation scenario by comparing its behaviour during a specific flight plan against a “live” hexacopter following the same flight plan. Positional data is collected using telemetry downlink with the precision of onboard global positioning sensors. Scenario described above is part of an ongoing research project to create a cooperative collision avoidance system for small unmanned aerial vehicles with a specified reliability level. © 2017 2017The TheAuthors. Authors. Published by Elsevier Ltd. is an open access article under the CC BY-NC-ND license © Published by Elsevier Ltd. This (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the scientific committee of the 16th International Conference on Reliability and Statistics in Peer-review underand responsibility of the scientific committee of the International Conference on Reliability and Statistics in Transportation Communication. Transportation and Communication Keywords: unmanned aerial vehicles, remotely piloted aircraft, collision avoidance, unregulated airspace, simulation, model
1. Introduction Present day commercial UAV technology does not provide solid, reliable collision avoidance mechanisms (Lancovs, 2015). However, there are alternatives to using on board sensors, such as using broadcast transponders. An example is ADS-B technology used in manned craft, but it does not transfer well to small UAV craft.
* Corresponding author. E-mail address: [email protected]
1877-7058 © 2017 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the scientific committee of the International Conference on Reliability and Statistics in Transportation and Communication
doi:10.1016/j.proeng.2017.01.082
156
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
An alternative system was proposed, similar to ADS-B, but designed specifically for small, low flying commercial UAVs that do not require to enter controlled airspace (Lancovs, 2016). Such system needs to comply with strict safety regulations, especially if such craft would ever be used autonomously in urban areas – in no small part because it could be the only collision avoidance system on board. As potential for human injury or death exists in case of failure, this system would be classified as “Class A” in manned aviation, posing strict reliability requirements (Won KeunYoun et al., 2015). Parameters of this system need to be determined to adequately cover all possible use scenarios, while maintaining a specific reliability level in each case. Since these parameters are interdependent, a stepwise approach to designing such system was proposed (Lancovs, 2016). At each subsequent step new internal or external factors are introduced, while parameters are updated to maintain reliability. This approach relies on modelling collision avoidance at each step. This article develops the proposed approach. A model needs to be created to simulate UAVbehaviour during collision avoidance. Such model would consist of a specific flight plan and rely upon an “emulator”, a program that simulates behaviour of an actual craft with specified parameters. The flight plan should imitate manoeuvres during collision avoidance, while the emulator acts as the aircraft performing these manoeuvres. U|g|CS mission planning and flight control software (SPH Engineering, 2016) supplies multi-rotor and fixedwing aircraft emulators, and is therefore used for aircraft modelling and flight control purposes. However, supplied emulators need to be verified and validated before they can be used. 2. Collision avoidance model Collision avoidance model is required to fulfil the research goal of designing a collision avoidance system, as presented during 3rd Conference on Sustainable Urban Mobility (Lancovs, 2016). Aforementioned system is to function in a real environment, consisting of a narrow band of airspace below regulated airspace, as seen in Fig.1. Such airspace presents its own hazards, including stationary obstacles, such as buildings and trees, but those can be dealt with using initial path planning and quality sensors. The issue of avoiding collisions with similar craft in a highly saturated airspace is more complex, since craft are too small to be detected reliably by on board systems. A cooperative approach was proposed by author, similar to ADS-B, used by manned craft.
Fig. 1. Operating environment (Lancovs, 2016).
The system in question has two important functions to fulfil – provide broadcast of craft location to other participants of aerial traffic within the same airspace, and provide reception of this information coming from other craft. The system is operating in a real-life environment, and is made of real-life components, each having a set of limitations. Safety requirements, however, dictate that all these factors are taken into account when providing its main collision avoidance functions at a specific level of reliability.
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
Fig. 2. Internal and external factors (Lancovs, 2016).
Fig. 2 shows these factors. Both transmitters and receivers are considered internal factors, since our design choices can alter their parameters, even if within what components are available commercially. There are, however, also external factors – almost all frequency bands that are open for civilian use are saturated with transmissions by other equipment, and RF noise is also a potential problem. All the factors mentioned above have a potential to affect reaction times and reception ranges. However, transmitter and receiver themselves should be designed so that these factors are taken into account, which leads to multi-step approach, when at each step new factors are introduced, and, potentially, hardware parameters are adjusted to deal with them. In order to account for all possible scenarios, involving interaction between craft – the process of avoiding a collision, a set of experiments was planned at each step of this approach (Lancovs, 2016). These would test proposed system with a specified set of parameters (established as a result of the previous step), against situations when various craft are approaching each other at different angles, climbing, descending, etc. It is not technically feasible to test all possible craft configurations in all such scenarios using real-life experimentation. Instead, a model is required to perform experimentation at each stage, simulating craft behaviour, without risking physical assets. This model consists of a flight path the craft avoiding a collision is expected to take, imitating a sharp turn away from its original heading. It also contains a vehicle emulator – specific software modelling the craft itself. This software not only simulates physical aspects of the craft, but also the way its autopilot reacts to course changes. In order to rely on the model, it needs to be adequate. Since this particular model consists of two parts, both need to pass verification and validation. In case of the flight path, it should consist of two segments, representing course before collision avoidance mechanism is triggered, and course after it takes over. It should also be a valid set of instructions that can be uploaded into an autopilot and flown by an actual craft. Since autopilot does flight smoothing, the real flight path flown will not be an exact replica of this theoretical path – instead, it will enable us to identify at which point the craft needs to start turning to not overshoot the second segment. In case of the emulator, it should accept the flight plan and fly it, and it should behave during flight exactly like a real craft would. This would require at least some flights to be done in real life experimentation, in order to record telemetry from an actual craft and compare it to that of the emulator. If it does produce similar flight path to an actual craft, it can be seen as adequate and used in further experimentation. 3. Verification and validation of the collision avoidance model and vehicle emulator Proposed model consists of two elements: flight plan (called “route” in U|g|CS) and craft emulator. Both need to be verified. As can be seen in Fig. 3, route consists of a takeoff waypoint, one standard waypoint and a landing waypoint. Route segment between takeoff waypoint and standard waypoint imitates normal flight, while segment from standard waypoint and landing waypoint imitates a sharp 90º change in trajectory to avoid a collision. Landing itself is not a required part of the experiment, but is necessary to safely end the experiment. All waypoints are
157
158
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
located at 20 m. above ground level, avoiding ground obstacles but within unregulated airspace. Such configuration corresponds with requirements and portrays “ideal” behaviour in a collision avoidance scenario. Note that this is a flight plan, and is not an exact representation of where an aircraft is going to be at any given moment. This is why an emulator is needed.
Fig. 3. Flight plan as shown by U|g|CS software.
Emulator was verified by performing an emulated flight using given flight plan. Its telemetry data was recorded. Emulator has accepted the route and performed every element in it. Therefore, emulator is able to fly the route. While verification was relatively trivial, validation of the emulator required real-life flight tests. The same route had to be flown by actual craft, and results then compared to the data from the emulator. A multi-rotor craft was used to perform real-life flights on the same route. It was a hexacopter design with a flight controller and a telemetry link (Fig. 4).
Fig. 4. Hexacopter used in real-life experimentation.
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
Table 1 contains exact specification. Note that the flight controller is configurable and different maximum speed limits can be set as needed, as long as the airframe and propulsion systems are capable of handling such speeds. GPS provides positioning data used for navigation and reporting via telemetry data link hardware. Table 1. Hexacopter specification. Subsystem
Type
Frame
xAircraft 650 Hexa
Flight controller
Ardupilot v. 3.2.1.
GPS module
u-blox LEA-6H
Telemetry
433 MHz 3DR uplink/downlink
Propulsion
6 x SunnySky 2212-13 980 KV motors, 4S configuration
Power
4S Li-Po 5600 mAh
Weight
2 kg
Flights were performed at coordinates 56:58" N / 24:04" E. Weather was calm and dry, wind influence was negligible. Fig. 5 and 6 show latitude and longitude seconds plotted against time, for both the emulator (Emucopter) and the hexacopter during one of the flights (worst case).
>ĂƚŝƚƵĚĞ;ƐͿǀƐdŝŵĞ;ƐͿ Ϯϱ͕ϱϬ Ϯϱ͕ϬϬ Ϯϰ͕ϱϬ Ϯϰ͕ϬϬ
ŵƵĐŽƉƚĞƌ
Ϯϯ͕ϱϬ
,ĞdžĂĐŽƉƚĞƌ
Ϯϯ͕ϬϬ ϮϮ͕ϱϬ ϮϮ͕ϬϬ Ϭ͕ϬϬ
ϮϬ͕ϬϬ
ϰϬ͕ϬϬ
ϲϬ͕ϬϬ
ϴϬ͕ϬϬ ϭϬϬ͕ϬϬ ϭϮϬ͕ϬϬ
Fig. 5. Plot of latitude (seconds) against time (seconds), worst case.
>ŽŶŐŝƚƵĚĞ;ƐͿǀƐdŝŵĞ;ƐͿ ϭϴ͕ϱϬ ϭϴ͕ϬϬ ϭϳ͕ϱϬ ŵƵĐŽƉƚĞƌ ,ĞdžĂĐŽƉƚĞƌ
ϭϳ͕ϬϬ ϭϲ͕ϱϬ ϭϲ͕ϬϬ Ϭ͕ϬϬ
ϮϬ͕ϬϬ
ϰϬ͕ϬϬ
ϲϬ͕ϬϬ
ϴϬ͕ϬϬ ϭϬϬ͕ϬϬ ϭϮϬ͕ϬϬ
Fig. 6. Plot of longitude (seconds) against time (seconds), worst case.
159
160
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
Unfortunately, telemetry reception was not always reliable for the live flights, therefore exact measurements are not available at any given time. However, enough points have been recorded. Difference between emulated and observed real flight coordinates was calculated and converted into meters, one latitude second at this latitude corresponding to 30.93 meters and one longitude second corresponding to 17.33 meters. Results are visible in Fig. 7.
ŝĨĨĞƌĞŶĐĞ;ŵͿǀƐdŝŵĞ;ƐͿ ϴ͕ϬϬ ϳ͕ϬϬ ϲ͕ϬϬ ϱ͕ϬϬ ϰ͕ϬϬ
ŝĨĨĞƌĞŶĐĞ
ϯ͕ϬϬ Ϯ͕ϬϬ ϭ͕ϬϬ Ϭ͕ϬϬ Ϭ͕ϬϬ
ϭϬ͕ϬϬ
ϮϬ͕ϬϬ
ϯϬ͕ϬϬ
ϰϬ͕ϬϬ
ϱϬ͕ϬϬ
Fig. 7. Plot of differences between real and emulated flights against time, worst case.
The highest difference observed was 7.12 meters. It does not fit within the 2.5 m. error margin specified for the GPS unit used on the hexacopter (u-blox America, Inc., 2016). However, this error margin is achieved with a stationary receiver during a period of time measuring hours, which is far in excess of an average commercial UAV flight time. The latest standard on GPS accuracy lists errors not exceeding 12.8 m. for any practical user application, with a confidence of 95% (National Coordination Office for Space-Based Positioning, Navigation, and Timing, United States of America, 2008). Even the highest observed difference is well within this level of accuracy. Better accuracy can be achieved using assisted GPS technologies, but, presently, such technologies are not widely used in commercial UAVs, therefore all further modelling must assume GPS precision no better than what is possible for unassisted GPS modules. Multi-copter emulator within U|g|CS was found to be adequate for the purpose of emulating multi-copter UAVs during a collision avoidance scenario. 4. Conclusions A model for UAV collision avoidance was constructed using U|g|CS software, consisting of a route and an aircraft emulator. U|g|CS supplies two emulators: multi-rotor and fixed-wing emulator. Multi-rotor emulator was validated and found adequate for simulation purposes using real life flights with a hexa-copter. A similar procedure needs to be performed for fixed-wing aircraft emulator. Once this is done, research may continue on designing a cooperative collision avoidance system for small unmanned aerial vehicles with a specified reliability level. Current data seems to indicate that GPS precision may prove to be one of the most limiting factors during modelling stages. Hopefully, this may change as more and more GPS sensors come equipped to receive data from multiple positioning systems, potentially increasing precision. However, to guarantee a specific level of reliability one must consider worst case scenarios.
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
Acknowledgements This work was supported by Latvian state research programme project “The Next Generation of Information and Communication Technologies (Next IT)” (2014-2017).
References Lancovs, D. (2015) On Sharing of Uncontrolled Airspace for Low Flying Unmanned Aerial Vehicle Systems. In: Proceedings of the XXth International Conference “Reliability and Statistics in Transportation and Communication”. Riga, Latvia, Transport and Telecommunication Institute, 21–24 October 2015. Lancovs, D. (2016) Broadcast transponders for low flying unmanned aerial vehicles. In: Proceedings of 3rd Conference on Sustainable Urban Mobility, 3rd CSUM 2016, Volos, Greece, 26–27 May 2016. National Coordination Office for Space-Based Positioning, Navigation, and Timing, United States of America, (2008) Global Positioning System Standard Positioning Service Performance Standard, http://www.gps.gov/technical/ps/2008-SPS-performance-standard.pdf: United States of America. SPH Engineering, (2016) Ground station software. https://www.ugcs.com/: SPH Engineering, 2016. u-blox America, Inc., (2016) LEA-6, u-blox 6 GPS Modules Data Sheet. https://www.u-blox.com/sites/default/files/products/documents/LEA6_DataSheet_(UBX-14044797).pdf: u-blox America, Inc. Won KeunYoun, Seung Bum Hong, Kyung Ryoon Oh, Oh Sung Ahn, (2015) Software Certification of Safety-Critical Avionic Systems: DO178C and Its Impacts, IEEE Aerospace and Electronic Systems Magazine 30(4): pp 4–13.
161
ScienceDirect Procedia Engineering 178 (2017) 155 – 161
16thConference on Reliability and Statistics in Transportation and Communication, RelStat’2016, 19-22 October, 2016, Riga, Latvia
Building, Verifying and Validating a Collision Avoidance Model for Unmanned Aerial Vehicles Dmitrijs Lancovs* Transport and Telecommunication Institute, Lomonosova 1, Riga, LV-1019, Latvia SPH Engineering, Daugavgrīvas 140, Riga, LV-1007, Latvia
Abstract This paper documents verification and validation of a multi-rotor aircraft emulator in a collision avoidance simulation scenario by comparing its behaviour during a specific flight plan against a “live” hexacopter following the same flight plan. Positional data is collected using telemetry downlink with the precision of onboard global positioning sensors. Scenario described above is part of an ongoing research project to create a cooperative collision avoidance system for small unmanned aerial vehicles with a specified reliability level. © 2017 2017The TheAuthors. Authors. Published by Elsevier Ltd. is an open access article under the CC BY-NC-ND license © Published by Elsevier Ltd. This (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the scientific committee of the 16th International Conference on Reliability and Statistics in Peer-review underand responsibility of the scientific committee of the International Conference on Reliability and Statistics in Transportation Communication. Transportation and Communication Keywords: unmanned aerial vehicles, remotely piloted aircraft, collision avoidance, unregulated airspace, simulation, model
1. Introduction Present day commercial UAV technology does not provide solid, reliable collision avoidance mechanisms (Lancovs, 2015). However, there are alternatives to using on board sensors, such as using broadcast transponders. An example is ADS-B technology used in manned craft, but it does not transfer well to small UAV craft.
* Corresponding author. E-mail address: [email protected]
1877-7058 © 2017 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the scientific committee of the International Conference on Reliability and Statistics in Transportation and Communication
doi:10.1016/j.proeng.2017.01.082
156
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
An alternative system was proposed, similar to ADS-B, but designed specifically for small, low flying commercial UAVs that do not require to enter controlled airspace (Lancovs, 2016). Such system needs to comply with strict safety regulations, especially if such craft would ever be used autonomously in urban areas – in no small part because it could be the only collision avoidance system on board. As potential for human injury or death exists in case of failure, this system would be classified as “Class A” in manned aviation, posing strict reliability requirements (Won KeunYoun et al., 2015). Parameters of this system need to be determined to adequately cover all possible use scenarios, while maintaining a specific reliability level in each case. Since these parameters are interdependent, a stepwise approach to designing such system was proposed (Lancovs, 2016). At each subsequent step new internal or external factors are introduced, while parameters are updated to maintain reliability. This approach relies on modelling collision avoidance at each step. This article develops the proposed approach. A model needs to be created to simulate UAVbehaviour during collision avoidance. Such model would consist of a specific flight plan and rely upon an “emulator”, a program that simulates behaviour of an actual craft with specified parameters. The flight plan should imitate manoeuvres during collision avoidance, while the emulator acts as the aircraft performing these manoeuvres. U|g|CS mission planning and flight control software (SPH Engineering, 2016) supplies multi-rotor and fixedwing aircraft emulators, and is therefore used for aircraft modelling and flight control purposes. However, supplied emulators need to be verified and validated before they can be used. 2. Collision avoidance model Collision avoidance model is required to fulfil the research goal of designing a collision avoidance system, as presented during 3rd Conference on Sustainable Urban Mobility (Lancovs, 2016). Aforementioned system is to function in a real environment, consisting of a narrow band of airspace below regulated airspace, as seen in Fig.1. Such airspace presents its own hazards, including stationary obstacles, such as buildings and trees, but those can be dealt with using initial path planning and quality sensors. The issue of avoiding collisions with similar craft in a highly saturated airspace is more complex, since craft are too small to be detected reliably by on board systems. A cooperative approach was proposed by author, similar to ADS-B, used by manned craft.
Fig. 1. Operating environment (Lancovs, 2016).
The system in question has two important functions to fulfil – provide broadcast of craft location to other participants of aerial traffic within the same airspace, and provide reception of this information coming from other craft. The system is operating in a real-life environment, and is made of real-life components, each having a set of limitations. Safety requirements, however, dictate that all these factors are taken into account when providing its main collision avoidance functions at a specific level of reliability.
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
Fig. 2. Internal and external factors (Lancovs, 2016).
Fig. 2 shows these factors. Both transmitters and receivers are considered internal factors, since our design choices can alter their parameters, even if within what components are available commercially. There are, however, also external factors – almost all frequency bands that are open for civilian use are saturated with transmissions by other equipment, and RF noise is also a potential problem. All the factors mentioned above have a potential to affect reaction times and reception ranges. However, transmitter and receiver themselves should be designed so that these factors are taken into account, which leads to multi-step approach, when at each step new factors are introduced, and, potentially, hardware parameters are adjusted to deal with them. In order to account for all possible scenarios, involving interaction between craft – the process of avoiding a collision, a set of experiments was planned at each step of this approach (Lancovs, 2016). These would test proposed system with a specified set of parameters (established as a result of the previous step), against situations when various craft are approaching each other at different angles, climbing, descending, etc. It is not technically feasible to test all possible craft configurations in all such scenarios using real-life experimentation. Instead, a model is required to perform experimentation at each stage, simulating craft behaviour, without risking physical assets. This model consists of a flight path the craft avoiding a collision is expected to take, imitating a sharp turn away from its original heading. It also contains a vehicle emulator – specific software modelling the craft itself. This software not only simulates physical aspects of the craft, but also the way its autopilot reacts to course changes. In order to rely on the model, it needs to be adequate. Since this particular model consists of two parts, both need to pass verification and validation. In case of the flight path, it should consist of two segments, representing course before collision avoidance mechanism is triggered, and course after it takes over. It should also be a valid set of instructions that can be uploaded into an autopilot and flown by an actual craft. Since autopilot does flight smoothing, the real flight path flown will not be an exact replica of this theoretical path – instead, it will enable us to identify at which point the craft needs to start turning to not overshoot the second segment. In case of the emulator, it should accept the flight plan and fly it, and it should behave during flight exactly like a real craft would. This would require at least some flights to be done in real life experimentation, in order to record telemetry from an actual craft and compare it to that of the emulator. If it does produce similar flight path to an actual craft, it can be seen as adequate and used in further experimentation. 3. Verification and validation of the collision avoidance model and vehicle emulator Proposed model consists of two elements: flight plan (called “route” in U|g|CS) and craft emulator. Both need to be verified. As can be seen in Fig. 3, route consists of a takeoff waypoint, one standard waypoint and a landing waypoint. Route segment between takeoff waypoint and standard waypoint imitates normal flight, while segment from standard waypoint and landing waypoint imitates a sharp 90º change in trajectory to avoid a collision. Landing itself is not a required part of the experiment, but is necessary to safely end the experiment. All waypoints are
157
158
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
located at 20 m. above ground level, avoiding ground obstacles but within unregulated airspace. Such configuration corresponds with requirements and portrays “ideal” behaviour in a collision avoidance scenario. Note that this is a flight plan, and is not an exact representation of where an aircraft is going to be at any given moment. This is why an emulator is needed.
Fig. 3. Flight plan as shown by U|g|CS software.
Emulator was verified by performing an emulated flight using given flight plan. Its telemetry data was recorded. Emulator has accepted the route and performed every element in it. Therefore, emulator is able to fly the route. While verification was relatively trivial, validation of the emulator required real-life flight tests. The same route had to be flown by actual craft, and results then compared to the data from the emulator. A multi-rotor craft was used to perform real-life flights on the same route. It was a hexacopter design with a flight controller and a telemetry link (Fig. 4).
Fig. 4. Hexacopter used in real-life experimentation.
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
Table 1 contains exact specification. Note that the flight controller is configurable and different maximum speed limits can be set as needed, as long as the airframe and propulsion systems are capable of handling such speeds. GPS provides positioning data used for navigation and reporting via telemetry data link hardware. Table 1. Hexacopter specification. Subsystem
Type
Frame
xAircraft 650 Hexa
Flight controller
Ardupilot v. 3.2.1.
GPS module
u-blox LEA-6H
Telemetry
433 MHz 3DR uplink/downlink
Propulsion
6 x SunnySky 2212-13 980 KV motors, 4S configuration
Power
4S Li-Po 5600 mAh
Weight
2 kg
Flights were performed at coordinates 56:58" N / 24:04" E. Weather was calm and dry, wind influence was negligible. Fig. 5 and 6 show latitude and longitude seconds plotted against time, for both the emulator (Emucopter) and the hexacopter during one of the flights (worst case).
>ĂƚŝƚƵĚĞ;ƐͿǀƐdŝŵĞ;ƐͿ Ϯϱ͕ϱϬ Ϯϱ͕ϬϬ Ϯϰ͕ϱϬ Ϯϰ͕ϬϬ
ŵƵĐŽƉƚĞƌ
Ϯϯ͕ϱϬ
,ĞdžĂĐŽƉƚĞƌ
Ϯϯ͕ϬϬ ϮϮ͕ϱϬ ϮϮ͕ϬϬ Ϭ͕ϬϬ
ϮϬ͕ϬϬ
ϰϬ͕ϬϬ
ϲϬ͕ϬϬ
ϴϬ͕ϬϬ ϭϬϬ͕ϬϬ ϭϮϬ͕ϬϬ
Fig. 5. Plot of latitude (seconds) against time (seconds), worst case.
>ŽŶŐŝƚƵĚĞ;ƐͿǀƐdŝŵĞ;ƐͿ ϭϴ͕ϱϬ ϭϴ͕ϬϬ ϭϳ͕ϱϬ ŵƵĐŽƉƚĞƌ ,ĞdžĂĐŽƉƚĞƌ
ϭϳ͕ϬϬ ϭϲ͕ϱϬ ϭϲ͕ϬϬ Ϭ͕ϬϬ
ϮϬ͕ϬϬ
ϰϬ͕ϬϬ
ϲϬ͕ϬϬ
ϴϬ͕ϬϬ ϭϬϬ͕ϬϬ ϭϮϬ͕ϬϬ
Fig. 6. Plot of longitude (seconds) against time (seconds), worst case.
159
160
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
Unfortunately, telemetry reception was not always reliable for the live flights, therefore exact measurements are not available at any given time. However, enough points have been recorded. Difference between emulated and observed real flight coordinates was calculated and converted into meters, one latitude second at this latitude corresponding to 30.93 meters and one longitude second corresponding to 17.33 meters. Results are visible in Fig. 7.
ŝĨĨĞƌĞŶĐĞ;ŵͿǀƐdŝŵĞ;ƐͿ ϴ͕ϬϬ ϳ͕ϬϬ ϲ͕ϬϬ ϱ͕ϬϬ ϰ͕ϬϬ
ŝĨĨĞƌĞŶĐĞ
ϯ͕ϬϬ Ϯ͕ϬϬ ϭ͕ϬϬ Ϭ͕ϬϬ Ϭ͕ϬϬ
ϭϬ͕ϬϬ
ϮϬ͕ϬϬ
ϯϬ͕ϬϬ
ϰϬ͕ϬϬ
ϱϬ͕ϬϬ
Fig. 7. Plot of differences between real and emulated flights against time, worst case.
The highest difference observed was 7.12 meters. It does not fit within the 2.5 m. error margin specified for the GPS unit used on the hexacopter (u-blox America, Inc., 2016). However, this error margin is achieved with a stationary receiver during a period of time measuring hours, which is far in excess of an average commercial UAV flight time. The latest standard on GPS accuracy lists errors not exceeding 12.8 m. for any practical user application, with a confidence of 95% (National Coordination Office for Space-Based Positioning, Navigation, and Timing, United States of America, 2008). Even the highest observed difference is well within this level of accuracy. Better accuracy can be achieved using assisted GPS technologies, but, presently, such technologies are not widely used in commercial UAVs, therefore all further modelling must assume GPS precision no better than what is possible for unassisted GPS modules. Multi-copter emulator within U|g|CS was found to be adequate for the purpose of emulating multi-copter UAVs during a collision avoidance scenario. 4. Conclusions A model for UAV collision avoidance was constructed using U|g|CS software, consisting of a route and an aircraft emulator. U|g|CS supplies two emulators: multi-rotor and fixed-wing emulator. Multi-rotor emulator was validated and found adequate for simulation purposes using real life flights with a hexa-copter. A similar procedure needs to be performed for fixed-wing aircraft emulator. Once this is done, research may continue on designing a cooperative collision avoidance system for small unmanned aerial vehicles with a specified reliability level. Current data seems to indicate that GPS precision may prove to be one of the most limiting factors during modelling stages. Hopefully, this may change as more and more GPS sensors come equipped to receive data from multiple positioning systems, potentially increasing precision. However, to guarantee a specific level of reliability one must consider worst case scenarios.
Dmitrijs Lancovs / Procedia Engineering 178 (2017) 155 – 161
Acknowledgements This work was supported by Latvian state research programme project “The Next Generation of Information and Communication Technologies (Next IT)” (2014-2017).
References Lancovs, D. (2015) On Sharing of Uncontrolled Airspace for Low Flying Unmanned Aerial Vehicle Systems. In: Proceedings of the XXth International Conference “Reliability and Statistics in Transportation and Communication”. Riga, Latvia, Transport and Telecommunication Institute, 21–24 October 2015. Lancovs, D. (2016) Broadcast transponders for low flying unmanned aerial vehicles. In: Proceedings of 3rd Conference on Sustainable Urban Mobility, 3rd CSUM 2016, Volos, Greece, 26–27 May 2016. National Coordination Office for Space-Based Positioning, Navigation, and Timing, United States of America, (2008) Global Positioning System Standard Positioning Service Performance Standard, http://www.gps.gov/technical/ps/2008-SPS-performance-standard.pdf: United States of America. SPH Engineering, (2016) Ground station software. https://www.ugcs.com/: SPH Engineering, 2016. u-blox America, Inc., (2016) LEA-6, u-blox 6 GPS Modules Data Sheet. https://www.u-blox.com/sites/default/files/products/documents/LEA6_DataSheet_(UBX-14044797).pdf: u-blox America, Inc. Won KeunYoun, Seung Bum Hong, Kyung Ryoon Oh, Oh Sung Ahn, (2015) Software Certification of Safety-Critical Avionic Systems: DO178C and Its Impacts, IEEE Aerospace and Electronic Systems Magazine 30(4): pp 4–13.
161