3.1.1. Overview

The first version of the conflict managemen<sup>t</sup> software was developed as a selfcontained computer application, where the conflict managemen<sup>t</sup> framework is started at program execution, and the system users' missions were also started from the application. Essentially, this would enable the system to provide conflict managemen<sup>t</sup> for pre-defined scenarios for testing purposes. Note that this is not equivalent to a scripted scenario, as the users are only given commands to begin their missions, after which the system only manages the conflicts, not the individual paths.

Figure 2 shows a top-level overview of the first framework version's workflow. First, in the system initialization step, the system goes through five tasks, after which it initiates an infinite loop where conflict managemen<sup>t</sup> is facilitated. The system components are presented and discussed following the order presented in the flow diagram.

**Figure 2.** Top level flow diagram of first framework version.

#### 3.1.2. System Users and Connections

The users of the system are the individual vehicles, people, etc., for which the system provides the conflict managemen<sup>t</sup> service. Following the defined requirements and key principles, the users are represented as an abstract class, from which the individual user types are inherited, thus ensuring modularity. The first version implements the following user types:



The algorithmically generated data essentially calculates a time series of position data, and provides it for the conflict managemen<sup>t</sup> system, without considering the actual vehicle type or its dynamics. Additionally, the vehicle receives no control commands from the system. This class of users represents a vehicle, which is not a cooperative member of the conflict managemen<sup>t</sup> framework; however, its position is known. For example, positions could be received through protocols and channels not implemented in the system yet, or its position could be inferred with using computer vision or similar methods and the position provided by other users of the system. In this project, the class was initially implemented to enable the research group's self-driving smart car (Figure 3) to integrate into the system.

**Figure 3.** BME Automated Drive self-driving Smart [48].

The Smart currently operates as a self-contained unit; it is able to follow pre-specified paths in an autonomous way. However, with its current implementation, it cannot receive commands from an off-board source, nor does it provide telemetry data in any standardised format. As such, to integrate it into the system, the Smart provides its current position along the pre-defined path as simple coordinates data, which conceptually works the same way as the algorithmically generated data from the system's point of view. The algorithmically generated class is also very useful to test specific scenarios, as actual vehicle control and dynamics do not constrain the possible timings and paths.

The MAVLink connection class implements two-way communication between MAVLink-capable vehicles and the system. There are three options available in the system:


PX4 [49] is an open-source control software that is ported to a wide variety of hardware. It is capable of controlling fixed-wing and multi-rotor UAVs and UGVs among many other configurations. The PX4 SITL simulator can be run on any compatible computer (Windows, Linux, Mac), with relatively low resource requirements. The SITL itself runs the same flight controller algorithms that are used when flying actual UAV hardware. For it to simulate flight or driving, a simulation environment needs to be attached to it to provide information such as simulated world and sensor data and to resolve the dynamics of the vehicle. The simulation environment used in this project is Gazebo [50], which integrates seamlessly with the PX4 SITL simulator. This configuration is able to simulate up to 10 (and possibly more) UAVs, UGVs or any other type of vehicle for which models exist. The simulations communicate with the system through the UDP (user datagram protocol) protocol, and for

the purposes of the conflict managemen<sup>t</sup> framework they behave exactly like real hardware would. Simulated and real vehicles can be freely combined.

The X500 is a UAV development kit, from which a complete UAV can be built that uses the Pixhawk 4 flight controller, running the PX4 autopilot software. This is a very common configuration and probably provides the best solution in terms of achievable functions and ease of expandability. The other hardware, "PX4 in a box" also uses a Pixhawk hardware as the flight controller; however, it only includes the most essential sensors, so that the unit is able to connect to the system and provide telemetry data. There is no frame or propulsion unit, so it is not flight capable; rather, it is built into a box, which can be mounted on vehicles or even carried by hand, enabling integration into the system for arbitrary users. After boot, the box's controller needs to be "tricked" into believing it is flying or driving, which is achieved using the GCS software. Figure 4 shows this hardware as used during system tests.

**Figure 4.** PX4-based real hardware: X500 (**left**) "PX4 in a box" (**right**).

The PX4-based users connect to the system via telemetry radios (the particular type of hardware is called SiK radio), sending telemetry data and commands as MAVLink messages via serial communication. This solution is one of the most widespread and available for open-source drones today. They operate on nominal 433 MHz using a frequency-hopping method to enable a number of these units to work simultaneously without interference. One end of the unit is connected to the vehicle and the other to the PC running the conflict managemen<sup>t</sup> framework. These radios are primarily designed to work in pairs, and while multiple units could be connected for multi-point comms, in the authors' experience, it does not work suitably for this purpose. Considering this, during the operation of a production version of the conflict managemen<sup>t</sup> system, these radios will be plugged in to the computers of the users who are operating the drones and not to the central conflict managemen<sup>t</sup> computer. These telemetry radios are used by the operators to monitor the status of the UAV and manage missions. Routing and forwarding the communication to the system via UDP or TCP (transmission control protocol) can relatively easily solve this

problem. For other type of radio systems, different interfaces need to be implemented, and this is part of the longer-term development plans.

#### 3.1.3. Conflict Detection Methods

For the initial prototype of the system two conflict detection methods are implemented, both of the deterministic class, and they detect conflicts between pairs of users, initially only in two dimensions:


In the first method, it is assumed that both users provide their mission definition, and as such the trajectories they are going to take are determined in advance. An "s" ratio is introduced, which represents the ratio of the mission trajectory already completed by the user. This "s" ratio in theory simplifies the detection as the ratios where conflicts could potentially arise during the mission of the users can be predicted in advance, as soon as a user registers (connects) to the system. It is then only important to know what the current "s" ratios of the vehicles are (presuming the mission definition also includes velocity targets) and determine if a possible conflict is active or not based on the ratios. Figure 5 shows an example visualisation of the detection of the conflict areas using this algorithm. A uniform safety buffer of 5 m was used on both sides of the defined mission trajectory (middle black and grey lines).

**Figure 5.** Pairwise waypoint-based static area detection method example; trajectories with safety offset (black and grey), determined conflict areas (yellow), "s" ratios along trajectory when conflict can be active (green for black trajectory and orange and red for grey trajectory).

While the algorithm in theory simplifies the detection and frees up resources from checking for conflicts where they simply cannot arise, the practical implementation showed that there are issues with the robust and accurate determination of the vehicles' "s" ratio. Most of the autopilot software solutions give some form of feedback regarding what the vehicle is doing; however, in the experience of the author, the current mission waypoint information is not always robust enough. Predicting which waypoint is the target without receiving it via telemetry also fails when the trajectories become more complex, such as self-intersecting trajectories, repeating waypoints, etc. Furthermore, any deviation from the flight path, including auto-land or return-to-home emergency functions, means that during these deviatory manoeuvres the system does not provide conflict managemen<sup>t</sup> capabilities. Based on these results we decided not to pursue this form of conflict detection at the moment but to revisit it at a later stage of the research project to find potential solutions to the issues.

The pairwise dynamic projected area detection method works by calculating the predicted position of the user based on the current position and velocity, received as telemetry data. The predictions are updated at every cycle of the conflict managemen<sup>t</sup> algorithm. The prediction time and a safety buffer are set for each user in each conflict pair. This allows the system to customise each conflict; for example, for users that operate with higher uncertainty a larger or differently shaped buffer area could be used, and slower responding users could have longer prediction times. Figure 6 shows an example of this methodology during testing in the first version of the GUI. Note the axes in Figure 6 are based on the UTM33N (EPSG:32633) coordinate system, and as such they include the full coordinate values to the points. Coordinate systems need to be converted often when using the framework system, as for example, Smart records coordinates in UTM33, but DJI and PX4 systems report telemetry in WGS84. In the first iteration it decided to display vehicles in UTM33N.

**Figure 6.** First version GUI display of pairwise dynamic projected area detection method; lines show user's mission (if available), points show the current position and arrows show predicted position. The grey (inactive) and red (active) areas show the conflict area with safety buffer applied).

Using the current and the predicted position and the safety buffer, a polygon is generated using the Shapely package of python. Shapely then can also be used to efficiently calculate intersections between the polygons of the two users. If the intersection area exists, then the conflict is set to be active, and it needs to be resolved. The method is very robust

and quick, and as such it was set as the default algorithm for future development activities. An important aspect is the tuning of the prediction time and safety buffer parameters, which was performed using SITL simulations to yield an acceptable performance for the prototype system.

The system is intended to be used to develop and evaluate further methodologies, which will be modularly added in future steps of the development process.

#### 3.1.4. Conflict Resolution Methods

Once the conflict detection method has established that a given conflict is active, then the allocated resolver method must provide a resolution for it. Detectors and resolvers are designed so they can be mixed within the framework and different combinations tested.

The baseline resolver that has been implemented is the stop-and-go resolution method. In this method one from the pair of vehicles in a conflict is stopped by the system, while the other is left to carry on with its mission. As one user can be involved in many conflicts, if a user receives a stop command from any of its conflicts, it must stop. Only those users who receive "carry on" commands (or rather, do not receive stop commands from any of its conflicts) can carry on with their mission.

To prevent impossible situations and deadlocks in the system, a priority assignment algorithm is created. The priority assignment considers first how a user is participating in the system. If the user is cooperative and it can receive and act on control commands from the system, it is assigned lower priority than a non-cooperative user. For each conflict pair, the user with the highest priority is given the carry-on command, and the lower priority user is sent the stop command. In the case of two non-cooperative users coming into conflict, no commands are sent, as the system has no means of affecting these users. In this case, it is up to the non-cooperative users to resolve the conflict to the best of their abilities. Non-cooperative users need to be dealt with at a different level, for example, by introducing policies that define mandatory standard protocols for vehicles, so that in theory they all become cooperative users. In the case where two cooperative users come into conflict, they will be allocated priority based on a set of rules. In the first implementation, the user's ID (unique for each user assigned when it registers to the system) is used to allocate priority, but this method can be used to give priority to less manoeuvrable or sensitive users, etc. It just needs to ensure that priority values are always absolute, and no deadlocks arise in multiple conflict pairs, in which all vehicles are given the stop command, and they all wait for each other forever.

The stop-and-go algorithm, despite its simplicity, works relatively well; however, it does not work for some cases, including coming into conflict head on, as one user would stop right on the trajectory of the second, possibly preventing its safe passage. For the second iteration of the system an improved algorithm is used, in which, in the case of head-on conflict, an evasive command is given to the lower priority vehicle before it is sent the stop command, so it moves out of the way. The robustness of this algorithm still needs to be improved, especially to make sure the lower priority vehicle is commanded to a position that is safe; this can be difficult to guarantee when multiple conflicts are active or the environment is confined.

When multiple vehicles are in conflict, how the multiple conflict is treated depends on the assigned conflict detection and resolution algorithms. Essentially, two types of algorithms can be defined, one which works between a pair of vehicles and one which resolves the detected conflict for an arbitrary number of vehicles. Obviously, when the pairwise algorithm is used, multiple algorithms are running parallel at the same time. When treating a very large number of vehicles, the managemen<sup>t</sup> of the computational requirements needs to be considered. The number of conflict algorithms to be run in parallel scales as the factorial of the number of vehicles inolved, when pairwise treatment is chosen. The utilised stop-and-go algorithm for both versions of the managemen<sup>t</sup> framework relies on pairwise detection and resolution, and due to the relatively low number of vehicles, computing capacity is of no concern.

Figure 7 shows the resolution process for a multi-vehicle conflict using the pairwise stop-and-go managemen<sup>t</sup> algorithm. While all algorithms being developed have the capability to deal with multi-vehicle conflicts, as seen in the figure, the key focus at this stage of the research is the development of robust methodologies and testing with one pair of vehicles in conflict, as it is a lot clearer, easier and safer to track and control how a single pair of vehicles are behaving, especially during real hardware tests. In the following, discussion will be limited to a single pair of vehicles in conflict for this reason.

**Figure 7.** Multi-vehicle conflict resolution **1**,**2**: Conflict is detected between blue and purple, 3rd vehicle (green) unaffected; **3**: Lower priority (blue) vehicle is given command to stop and moves out of impact path; **4**,**5**: Conflict is resolved, vehicles not stopped carry on, commanded (blue) continues mission after safety delay. Non-English text are road section designations.

> It is also worth mentioning that as the system does not deal with low-level flight control, as it only sends commands to the users. During testing it was observed that for some flight controllers, sending a pause or stop mission command would result in the UAV first stopping, then reversing to the position where it received the stop command. While it is debatable whether this is a feature or issue, it can be overcome, but the more important conclusion is that extensive testing is required for each type of user that is integrated into the system to understand how to best control them.

#### 3.1.5. Lessons Learnt from Testing the First Version

The first version of the system was tested using primarily SITL simulators, but a successful real hardware test was also performed to validate the concept. During these tests some shortcomings were identified, which are presented and briefly discussed here.

Probably the greatest issue identified was the fragility of the software implementation. While the conflicts were managed safely when the system operated as intended, there were too many occasions when the operation of the system stopped. The primary culprit was

the communication system. It was too easy for the telemetry radios to drop the connection between a user and the system, even if just momentarily. Since the connection to the users was established during initialization, this meant that the whole system had to be restarted to reconnect. The implementation of the MAVLink connection used (MAVSDK-python) also seemed to be a fragile type of link, as when the connection failed it often took manual intervention and effort to reset everything and initiate the connection again. This is clearly not acceptable for an automated system. Because the tools used in this case are open source, it would be possible to develop the communication link; however, that would go against the principles of the system. It was decided that a solution is required where instead of fixing the link's fragility, the system would manage the connection to make sure it can always recover after a failure.

Improving the robustness of the system's other aspects was also a priority. One of the biggest issues was the lack of persistent storage of data. Whenever the system stopped for any reason, the only way to fix it was essentially to reset it and start again. This is particularly problematic for the missions, as the missions are also started during the initialization step. This means that if the users were already executing their missions when it was restarted, they would first return to the first waypoint to start the mission from the beginning. This has undesirable consequences, as most controllers send the vehicle on the shortest possible direct route when the return command is received, irrespective of the conflicts that could be caused. This also makes testing difficult. When investigating specific conflict situations, the return activity throws off the timing required for the situation to arise, because it is not known from which point of its trajectory the vehicle will start its return when the system is restarted. While there was an attempt to mitigate these issues by not always restarting the missions when the system restarted, it was decided that a robust solution would be required rather than a workaround.

Another issue identified was the restriction of user interaction possibilities. When the system connects to MAVLink capable users it blocks the ports necessary to run GCS software. As such, the user loses its ability to monitor and control the vehicle's mission. This is a most undesirable outcome, as the system's role is only to manage conflicts; it must not take away the mission managemen<sup>t</sup> possibility (and responsibility) from the users. While this could potentially be fixed by implementing GCS functionalities in the system and forcing users to use the system for their mission management, this also goes against the principle of relying on COTS components.

Among the issues there are also minor elements, such as the low quality of GUI implementation. As can be seen in Figure 6, the first iteration uses a Matplotlib plot to display the system status and conflicts. While it would be possible to develop this further, it would inherently be restrictive, as it can only be displayed on the computer running the system. Additionally, developing new GUIs when there are other possibilities that could be implemented and would probably work well is a waste of resources and goes against the LEAN principles. A final issue that also arises partly from the GUI implementation is that users cannot be added or removed from the system during runtime—the system needs to be stopped, and new users added in the code. While a production system would need to have automatic user managemen<sup>t</sup> capabilities, for the prototype it would be useful if the system operator (supervisor) could add or remove users as required.

To summarise, the following shortcomings had to be addressed in the second version:


#### *3.2. Second Version of Software Implementation*

To address the shortcomings identified, a significant redesign of the system was required. This section discusses the second implementation of the conflict managemen<sup>t</sup> system, focusing particularly on the features that solve the problems identified.

#### 3.2.1. System Architecture

The principal change in version 2 was a change in the system architecture from a locally running code to a networked web-based application. The framework used was the python-based Django web framework (version 3.2). Django is a very popular framework for web application development with powerful capabilities and a large database of expansion modules. The default implementation of Django is a synchronous service, which means that when long-running tasks are initiated, the service temporarily becomes unresponsive until the task is resolved. This is not desirable for the conflict management, as the various activities need to be run parallel (asynchronously). In order to achieve this the Celery (version 5.1.2)-distributed task queue was integrated into the system. The application also relies on a PostgreSQL relational database server for persistent data storage and the RabbitMQ message passing interface for managing tasks. A high-level overview of the system architecture is shown in Figure 8, and the significant changes compared to the first version are discussed in the following section.

**Figure 8.** Conflict managemen<sup>t</sup> system architecture—second version.

#### 3.2.2. Communication Solutions

The introduction of the new architecture enables the implementation of robust communication solutions. In the current setup, each user is connected to the system by generating an individual connection manager task that is responsible for monitoring the health of the specific connection. The manager task is run periodically, and when the connection drops, it reinitiates the connection task. To facilitate this all tasks are designed to deliberately fail if they encounter non-desirable situations, implementing a fail-safe layer in the system. This is important, as tasks that are seemingly running but are stuck in a non-operative status can provide misleading information, which can result in dangerous situation during conflict management.

#### 3.2.3. Data Persistence

The second version of the system uses a relational database to store data in a persistent and accessible manner. This is beneficial in two ways. First, it provides the system with an enhanced restart capability, as the relevant data are immediately available from the database even after a failure. Additionally, this approach enables the robust and parallel (asynchronous) handling of user data collection and the conflict detection and resolution tasks. Unlike the first version, where for each iteration of the conflict managemen<sup>t</sup> loop, the system has to wait for each user to provide updated data, the data collection and usage run as separate tasks. A typical database system such as the one used is capable of handling in the order of 100,000 transactions per second with minimal tuning. Considering that the typical frequency of telemetry data acquisition from users is in the order of 20 Hz or less, the system should be capable of handling a large number of users without performance issues. In the case of a production system with a large number of users, the appropriate IT architecture planning (distributed databases, optimised transactions, etc.) solutions must be implemented. From the point of view of this research, these steps are not relevant, as it is known that solutions exist for this purpose, and it was not investigated further.

The database also has useful built-in utility functions, for example, timestamping the last modification of a table in the db. This is used, for example, to check the "freshness" of the collected telemetry data. From the system's standpoint, whether a user's connection is alive or not can be determined from the time the last telemetry data were written to the database. In the current system 3 s is set as the threshold. If the data are not "fresh", then the system treats the user as not connected, i.e., non-cooperative, until the connection manager reconnects the user. Figure 9 shows the second iteration of the GUI, displaying a user with timed-out telemetry messages and showing the indication of an active conflict zone.

**Figure 9.** Version 2 GUI: indication of timed out telemetry (**left**), conflict area marked as active (**right**). Non-English text are road and area designations.

The colour coding of the current GUI is the following:


#### 3.2.4. COTS Solutions Integration

Since the system is to be added as an additional security layer, not one replacing operator control, changes have been made to the way the users are connected. The PX4- based units are still connected through the SiK telemetry radios; however, the system no longer uses the connection COM port directly. The MAVLink-router package is used to run a forwarding service for each user, which in effect creates a mirrored copy of the connection port using the UDP protocol. This enables the computer running the system to connect to a user and a GCS at the same time. Or it can just receive UDP communication from a completely different computer, which connects to the user and its own GCS via the telemetry radio, as would be the case for an operating user. This way, the interface for connecting a simulated vehicle or a real hardware becomes identical as well. The same strategy was developed for DJI drones (using Windows or Mobile SDK—Software Development Kit), and it is currently in the process of being implemented. Integrating DJI SDK and MAVLink-based vehicles accounts for a very large segmen<sup>t</sup> of the current UAV solutions. MAVLink is a viable option for UGVs as well, either connecting to the vehicle itself or deploying the "PX4 in a box" solution. The use of pure position data from an arbitrary vehicle architecture is also a valid approach; however, this would provide only one-way communication, and thus would result in a non-cooperative user.

#### 3.2.5. Graphical User Interface and Human Interaction

The GUI for the second version was significantly upgraded. Instead of using a single computer-based application and graphics, the system GUI is now served by the Django framework. It is an HTML response which can be viewed by any compatible device running an internet explorer (Edge, Firefox, Chrome, Safari, etc.). The base of the GUI is a Leaflet map. Leaflet is an open source javascript-based mapping library. It is simple to integrate into an HTML (HyperText Markup Language) view, and it is interactive and handles Geojson inputs. Geojson is a standard format for encoding various geographical features, such as points, paths, areas, etc. Plotting the users' positions, the conflict areas with the safety buffers, geofencing areas and other GIS features naturally lends itself to Geojson representation. From the conflict managemen<sup>t</sup> related data stored in the database, the Django framework generates the Geojson features to be displayed on the Leaflet map, which is served to an arbitrary number of users via the web service.

The Leaflet map is completely customisable, the tilesets (background) of the map can be selected from different providers and the items displayed can be placed in layers that can be made hidden by the user and other similar features. Interacting with a map item (click or touch) can reveal additional information on the specific item in the form of a popup window or a separate HTML view. While this high level of customisation is beneficial, we was decided to deliberately limit the functionalities of the GUI to the conflict managemen<sup>t</sup> specifics. A typical GCS has many options for setting up the vehicle, the mission, emergency functions and similar. It is our intention to keep these features separate, so the individual operators have to rely on their GCS and only use the conflict managemen<sup>t</sup> system for its core purpose. This is important for maintaining the concept of relying on

COTS solutions. However, integrating the conflict managemen<sup>t</sup> system into existing GCS is an option that will be considered in the future.

#### 3.2.6. Improved Stop-and-Go Resolution Algorithm

For the second iteration of the system, the stop-and-go algorithm was also improved based on the lessons learnt from the first iteration. This chapter describes the algorithm used, highlighting the improvement and the reasons behind it for the second iteration.

In the first iteration of the methodology, as soon as the conflict was detected between two users, the system issued a "stop mission" command. This command is fairly universally present in the implementation of various flight controllers and their SDK mechanisms; however, it presents some significant drawbacks. First of all, the functionality might not exist for all COTS systems. Second, the implementation might not be done in the same way for different systems. The implementation in the PX4 flight controller stack used extensively in the research project suffers from a drawback; when the command is issued, the vehicle decelerates, stops, then reverses to the point where the vehicle has acknowledged the stop command. This is an undesirable behaviour, as the stopping point cannot be set deterministically due to the unknown latency in the communications systems. Furthermore, because the vehicle passes through the commanded stopping point, there is no guarantee that an impact is avoided in a conflict.

Upon investigating the specifics of the controller algorithm, the reason for this behaviour was found. Figure 10 shows the controller algorithm used by the flight control software. It can be seen that the system relies on a single proportional constant to ensure the position hold capacity of the vehicle. It can also be seen that the output of the system is a velocity control signal, which is saturated (limited) to prevent excessive accelerations. While it would be possible to include a derivative (and if necessary, an integral) constant to prevent overrun and reversing in the system, one of the key principles of the conflict managemen<sup>t</sup> system is to not modify the individual control algorithms of the vehicles.

**Figure 10.** PX4 controller algorithm for position control (source: [51]).

The solution, which is adopted in the second iteration of the stop-and-go algorithm, is to use a "set position" command, instead of the "stop mission" command. When using this command, the vehicle dynamics are considered to issue a command where the accelerations can be kept below the saturation level of the controller. While this does not completely eliminate overswings while acquiring positions, in practice these overswings are reduced to the order of 10–20 cm, and as such they are no longer of concern.

Using set position commands also mitigates another big drawback of the stop-and-go algorithm, specifically, that it cannot handle head-on or shallow angle conflicts, such as if one vehicle is stopped in the path of the other one. Although it avoided immediate impact, this did not actually resolve the conflict. Using set positions allows the command to define the stopping point, so that the vehicle would stop outside the predicted conflict area of the other vehicle given the go signal. Due to the vehicle dynamics this stopping area needs to be chosen within a fairly narrow angle cone, below 30 degrees half angle measured

from the velocity vector of the commanded vehicle. The quoted angle can be even more restrictive based on velocity, conflict prediction time and safety buffer size. In the second iteration, based on the test scenarios performed, to achieve acceptable behaviour, the safety buffer was set to a 4.5 m radius, and the conflict detection time was set to 4.0 s. The position target for stopping is derived based on 3.0 s of resolution time and the current vehicle velocity, which results in a distance that can be mapped within the cone defined by the dynamics. These specific settings do not necessarily provide an optimum behaviour, but rather they are settings that were chosen based on a trial-and-error process and seem to provide an acceptable qualitative performance for the algorithm in the test scenarios. For quantitative evaluation, please refer to the discussion section of this paper.

A final modification of the stop-and-go methodology involved the conflict detection algorithm. When the vehicle is commanded to stop, its conflict area will gradually reduce as its speed drops (refer to Figure 6, Figure 7 or Figure 9 for conflict area visualizations). In many cases during the tests in the first iteration of the system, this drop resulted in a situation where a stopped vehicle's conflict zone no longer intersected the conflict zone of the other. In this case, the algorithm assumes that the conflict is resolved, and the stopped vehicle is given the go signal, effectively sending it in front of the other vehicle, creating a significant impact risk. In the second iteration this issue is resolved by increasing the safety buffer of stopped or slow-moving (below 0.25 m/s velocity) vehicles to 1.5 times the defined conflict buffer distances. This allows the stopped or almost stopped vehicles to remain in conflict and stopped.
