Research Article  Open Access
Hybrid OptimizationBased Approach for Multiple Intelligent Vehicles Requests Allocation
Abstract
Selfdriving cars are attracting significant attention during the last few years, which makes the technology advances jump fast and reach a point of having a number of automated vehicles on the roads. Therefore, the necessity of cooperative driving for these automated vehicles is exponentially increasing. One of the main issues in the cooperative driving world is the Multirobot Task Allocation (MRTA) problem. This paper addresses the MRTA problem, specifically for the problem of vehicles and requests allocation. The objective is to introduce a hybrid optimizationbased approach to solve the problem of multiple intelligent vehicles requests allocation as an instance of MRTA problem, to find not only a feasible solution, but also an optimized one as per the objective function. Several test scenarios were implemented in order to evaluate the efficiency of the proposed approach. These scenarios are based on wellknown benchmarks; thus a comparative study is conducted between the obtained results and the suboptimal results. The analysis of the experimental results shows that the proposed approach was successful in handling various scenarios, especially with the increasing number of vehicles and requests, which displays the proposed approach efficiency and performance.
1. Introduction
Selfdriving cars could revolutionize how people get around; with the introduction of automation into roads, it will contribute to solving the issues related to the traffic accidents, congestion, and energy consumption. The driverless vehicle technologies are advancing on a great scale, specifically the multiple sensors fusion techniques, deep learning, and computational intelligence. Together, they enable these vehicles to understand the nearby surroundings and take appropriate actions to navigate on their own from one point to another. The technology does not stop at vehicle being fully automated; however multiple of them cooperate together to achieve smoother driving operation [1–3].
Researchers in the Intelligent Transportation Systems (ITS) field are investing more time on the selfdriving cars research and development [4–6]. However, during the last decade, Multirobot Systems (MRS) fell under the research attention of the ITS community. This increased interest comes from the significant advantages and higher potential provided by MRS over single robot systems. MRS can be simply understood to be a group of robots cooperating together for accomplishing a certain task or mission [7, 8]. With reference to the literature review survey, the coordination and cooperation among multiagent systems can be modeled as Multirobot Task Allocation (MRTA) problem. MRTA is a NPhard problem, which concerns the use of the available resources in an efficient manner. Accordingly, the decision of which robot will do which task strongly affects the performance of the system [9, 10].
Accordingly, this paper introduces a hybrid optimizationbased approach to solve the MRTA problem. This approach can coordinate among several intelligent vehicles and aid in the cooperation for better overall performance. The algorithm is implemented on automated golf carts and tested in offroad environments in reallife scenarios. Moreover, in order to prove the proposed solution efficiency, several experiments are carried out over wellknown benchmarks. The benchmarks optimal solution is obtained after hundreds of hours of computations. The proposed approach was able to obtain a nearoptimal solution in a matter of seconds. This proves the proposed approach high performance.
The remainder of the paper is organized as follows: Section 2 presents the previous work in the field of multiple automated vehicles and the allocation problem, followed by Section 3, which introduces the problem formulation, solution constraints, objective function, and the proposed solving hybrid approach. In Section 4, the used platform is described, along with the experimental setup in the designed architecture, selected scenarios, and the evaluation metrics. Results and discussion are illustrated in Section 5. Finally, the conclusion and future work are summarized in Section 6.
2. Related Work
Autonomous cars are becoming more frequent in nowadays scientific and industrial context, since Google launched their driverless car project in 2011 [4]. From then onwards, many other approaches proposed different architectures and solutions, all of them moving towards the development of the autonomous vehicle. For instance, Mercedes with the Bertha project proved the viability of autonomous vehicles in German roads based on advance sensing capabilities [11]. The VCharge project researches in the direction of allowing automated valet parking for selfdriving cars [12]. Moreover, several vehicle manufacturers have proposed different solutions in the field of autonomous vehicles which are close to markets, such as BMW and Audi [13], MercedesBenz [14], and Volvo [15]. Furthermore, several other proposals offer the possibility of including autonomous vehicles in public transportation systems [5, 6].
The selfdriving technology is advancing rapidly, but in order to safely deploy vehicles on public roads, cooperation with other road users is mandatory. This cooperation would allow the safe interaction with other vehicles, whether with a human driver or driverless. Although some of the proposed solutions already handle the presence of other vehicles in the road [16–18], by handling static and dynamic obstacles and adapting the trajectory accordingly, the cooperative driving is not yet achieved. Cooperative driving demands the information exchange and control strategies deployed in all the vehicles involved following a twoway communication. In this sense, during recent years many works have addressed this topic, trying to provide solutions based on different configuration and solutions. The Grand Cooperative Driving Challenge 2016 was created with the purpose of boosting cooperative automated vehicles in the form of a cooperative based competition [19]. On the one hand, authors in [20] presented an auctionbased cooperative control for autonomous vehicles; on the other hand, authors in [21] proposed an approach to enhance common motion planning algorithms; this proposal allows cooperation with humandriven vehicles. Additionally, a novel concept is presented, based on a centralized strategy, using maneuver templates, which are formalized collaborative maneuvers, to select cooperative driving strategies [22]. All this work proves the importance of collaboration and communication among vehicles to allow a safe and efficient deployment of autonomous vehicles really in driving scenarios.
Since cooperation is essential among multiple vehicles on the road, coordination becomes the first issue to solve. In the MRS, the question of which robot is going to execute which task is answered through task allocation problem, which is commonly known as MRTA problem. By reviewing the literature, it was found that different optimization approaches have been used in order to solve the general task allocation problem and were also used in order to solve the MRTA problem. In [23], a mixed integer linear programming optimization approach was used in order to allocate heterogeneous robots for maximizing the coverage area of the regions of interest. In [24], a simulated annealing approach was used to solve the allocation of MRS through formulating the MRTA problem as multiTraveling Salesmen Problem (mTSP). Then in [25], a marketbased approach was proposed to solve the MRTA problem for heterogeneous robots and task formulated as mTSP. Moreover, the task allocation problem was also solved using hybrid optimization approaches such as the tabu search with random search method in [26] and tabu search with noising method in [27].
3. Methodology
In this section, the MRTA problem modeling and formulation are introduced, followed by the selected objective cost function. Afterward, the proposed algorithm is described, highlighting the main contribution. MRTA problem [7] is formulated to allocate multiple robots, in this case, vehicles, to numerous tasks, in this case, requests. The procedures are summarized as follows:(1)Given a set of vehicles, .(2)Given a set of requests, .(3)Allocation of the requests to the vehicles occurs, .(4)Output set is the best allocation of the requests to the vehicles:(5)Allocation minimizes or maximizes a certain objective function in order to get the best performance of the system.
3.1. Problem Formulation
A variant of mTSP is used to model MRTA problem. In the standard mTSP formulation, nodes are defined with the edges distances and salesmen are known. The salesmen are required to cover all the available nodes and return back to their starting node, such that each salesman makes a round trip. The mTSP can be formally defined on a graph where is the set of nodes and is the set of edges. Let be the distance matrix associated with . Assuming the more general case which is an asymmetric mTSP, thus . The mTSP can be formulated as follows [9]:where (3) represents the objective function which is the summation of the total distance traveled, (4) and (5) ensure that exactly salesmen departed their starting node and returned back. Equations (6), (7), and (8) are the usual assignment constraints. Finally, (9) is the subtour elimination constraint.
The proposed formulation is extended and adapted to the problem, where vehicles represent the salesmen and requests represent the cities. Therefore, vehicles capabilities and requests requirements are considered and included in the mTSP implementation. The added features of the vehicles are capacity, velocity, energy, efficiency, and sensors, and the ones for the requests are timestamp, priority, and passengers.
Where the vehicle capacity is the maximum number of passengers that it can hold, the velocity is a representation of the maximum speed it can reach, the energy is a representation of the battery level, the efficiency is a representation of the aging factor, and finally the sensors are a set of onboard devices to consider the vehicles as heterogeneous robots. On the other hand, the request timestamp is the date and time of the request creation, the priority is a representation or the request urgency based on the request type, and passengers are a representation of the number of users for the request.
3.2. Solution Construction
The solution is constructed as a set that includes a list of all vehicles in the system, followed by their assigned requests. The order of the list defines the quality of the solution according to the objective function. For example, for a problem with three vehicles and five requests, one of the possible candidate solutions is represented as follows:
Any combination of this list presents another candidate solution, and since the mTSP is a permutation problem, therefore the order of this list affects the quality of the solution as per the objective function. The order implies that each vehicle is going to execute all requests succeeding it. In candidate solution (10), requests 1 and 2 are executed by vehicle 1, requests 3 and 4 are executed by vehicle 2, and finally request 5 is executed by vehicle 3.
3.3. Objective Function
Although the MRTA problem is formulated as an instance of the mTSP, the same objective function of the mTSP previously explained in (3) cannot be straightforwardly used as the objective function for the MRTA problem. Therefore, some variations had to be introduced to the objective function of the mTSP in order to be effectively used for the MRTA problem [28].
There are three main variations of the MRTA problem objective function compared with the mTSP objective function. First, it is a multiobjective function instead of a single objective function, second, the variable to be minimized is the time rather than the distance, and, third, the time of the maximum subtour is minimized rather than the total time, thus dealing with it as a MinMax problem. Then, for subtours and requests in each subtour, the total traveling time is calculated as follows:
3.4. Solution Constraints
Although any arrangements of the vehicles and requests solution set are considered as a candidate solution for the mTSP problem, this does not guarantee that this solution is feasible for the MRTA problem. Therefore, few constraints are applied to the obtained solution, to ensure its validity and feasibility, which means checking whether the vehicle capabilities and request requirements are matching.
The first constraint is related to the capacity; for example, a vehicle with a maximum capacity of 4 passengers cannot handle a request of 6 passengers in one go; thus the request is decomposed into several requests and reallocated accordingly. The next constraint is the energy; the vehicle battery level is always taken into consideration before the final allocation of the request, since if the vehicle does not have sufficient energy for a specific request, it is reallocated to another vehicle. Another constraint is the priority level of the request, which implies that some requests, maintenance request, for instance, must be executed first. Last but not least, there is a constraint related to the mounted onboard sensors, which check if the request requires the presence of a specific sensor in the vehicle.
These applied constraints strongly affect the search space of the problem through decreasing the number of candidate solutions that can be accepted as feasible solutions. One may think that this decrease of the number of feasible solutions among the candidate solutions may make it easier for the applied algorithm to find the best solution than the case without the constraints. However, these applied constraints, in fact, make it more difficult and more time consuming to find the best solution. This is mainly because the algorithm will be visiting a large number of solutions that are candidate solutions of the mTSP but are not feasible to solve the MRTA problem.
3.5. Proposed Algorithm
The proposed solution is designed as metaheuristic optimization algorithm. It is a hybrid approach, which is based on both trajectorybased and populationbased techniques. The trajectorybased one is the family of optimization techniques that use a single solution throughout the algorithm, in order to find the nearoptimal solution. While the populationbased one is the family of optimization techniques that iteratively transforms a set of solutions, in order to generate a new population of solutions with the aim of finding the nearoptimal solution [29].
On the one hand, SA was selected as a trajectorybased approach, where the neighboring operator is randomly chosen at each iteration for diversity. The mutation operators are swapping, deletion and insertion, inversion, and scrambling. On the other hand, genetic algorithm (GA) was selected as the populationbased approach, where the selected mutation operators are the same; however, additional crossover operators are selected, which are partially mapped crossover and order crossover.
The swapping operator chooses two random elements of the solution list and swaps them with each other. Deletion and insertion operator chooses a random element and deletes it from its current position and randomly inserts it in a new position. The inversion operator chooses two random positions and inverts the order of elements between these two positions. The scrambling operator picks two random positions and scrambles the elements between these two positions. Figure 1 illustrates an example of all proposed operators, where positions 1 and 6 are selected as the two random elements. At each iteration, one of the four mutators is randomly chosen in order to generate a neighboring solution of the current solution. The four methods vary in their diversification and intensification effect on the generated neighboring solution.
The crossover operator is the mimicking of the biological recombination between chromosomes, when some portion of the genetic material is swapped between chromosomes producing a new offspring chromosome. On the one hand, in the partially mapped crossover, two points are selected at random in both parents solutions and the offspring is created by exchanging the inbetween chromosomes. On the other hand, in the order crossover a portion of one parent is mapped to a portion of the other parent; then from the replaced portion onwards, the rest is filled up by the remaining genes, where already present genes are omitted and the order one is preserved. Figure 2 illustrates an example of proposed crossover operators, where positions 2 and 5 are selected as the two random elements. At each iteration, one of the two crossover mutators is randomly chosen in order to generate a neighboring solution of the current solution. Additionally, the random choice of the used operator gives the algorithm both the explorative and exploitative features that are useful in escaping local minimum and finding a better solution through searching in the neighbors of elite solutions, respectively.
The algorithm is used to solve the formulated model of the MRTA problem. Inputs are the list of the requests with their requirements, the list of vehicles with their capabilities, and the matrix of the distances between the points of interests of the requests locations. At each iteration of the algorithm, a solution is constructed to be evaluated; initially, it is random. The initial solution set is always filled with random elements of the requests list and the vehicles list until both lists are empty; the only constraint is that the start of the solution must be an element of the vehicles list. After the construction of the initial candidate solution or any other neighboring solution through the algorithm iterations, the feasibility of this solution must be checked, according to the solutions constraints that are previously explained in Section 3.4. As the algorithm progresses, neighboring solutions of the current solution must be generated in order to explore the search space of the problem. Algorithm 1 presents the proposed algorithm used to solve the MRTA problem in this paper.

Here the parameters can be defined as follows:(i) is the list with parents solutions.(ii) is the list with children solutions.(iii) is the list with next generation solutions.(iv) is the number of iterations.(v) is the elitism percent.(vi) is the population size.(vii) is the initial temperature.(viii) is the final temperature.(ix) is the current temperature.(x) is the number of iterations per temperature decrement.(xi) is the geometric coefficient.(xii) is the transition probability.(xiii) is the current allocation solution.(xiv) is the current solution cost.(xv) is the neighbor allocation solution.(xvi) is the neighbor solution cost.(xvii) is the best allocation solution.(xviii) is the best solution cost.
4. Experimental Work
In this section, the realworld platform is described, followed by the proposed ROSbased architecture for the multiple vehicle cooperation. Moreover, it presents the selected scenarios along with the chosen evaluation metrics.
4.1. Platform Description
In this work, two automated vehicles were selected as the platforms for the realworld experiments. Figure 3 shows the vehicles; they are part of the Intelligent Campus Automobile (iCab) project. They are electric golf carts, which are modified mechanically and electronically for the purpose of fully automated vehicles.
Each vehicle is equipped with multiple onboard sensors, such as GPS and compass module, stereocamera, laserrangefinder, 3D LiDAR, optical encoders, and ultrasonic sensors. All sensors are connected to the onboard embedded computers, which are connected to a 4G router with a constant Internet connection [30].
The onboard embedded computers use Robot Operating System (ROS) architecture to carry out numerous technologies. The architecture is divided into three layers. Lowlevel commands are executed in the reactive layer, such as communicating with sensors and actuators. Communication between the layers and decomposing the complex task to simple ones are executed in the sequencer layer. Finally, highlevel commands are executed in the deliberative layer, which is mainly responsible for environment perception, navigation, planning, localization, and mapping among others [31].
4.2. Communication and Cooperation Architecture
Communication and cooperation among a team of unmanned vehicles is a crucial task. Since in case of long duration missions, or vehicle failure, it is unlikely that a single vehicle is enough to complete the operation [10], therefore, for the communication among vehicles, the multimaster_fkie package is used [32]. It combines the required nodes to establish and manage a multimaster network over the implemented ROSbased architectures. In order to use the aforementioned package, vehicles must operate under a common network. Thus, for secure and stable paradigm, a Virtual Private Network (VPN) is used to overlay the commonly available one, which is implemented following the ITS Cooperative ITS (CITS) ETSI TR 101 607 V1.1.1 (201305) protocol. Detailed description for using the adopted communication schemes is explained in [33].
For the cooperation, mrta node is implemented as the one responsible for handling the task allocation problem. The inputs for the node are vehicle status topic, vehicle pose topic, and list of requests topic. The allocation output is published to the task_executor node of each vehicle. The idea of this node is to decompose the requests allocation into executable tasks, according to the vehicles capabilities. The objective is to execute the user transport requests by multiple automated vehicles, using coordination and cooperation mechanisms. Passengers use their own smartphones to create a request by selecting the number of the passengers and the pickup and dropoff locations. The transport requests are then stored on a webserver, which is accessible by every vehicle in the system [34].
To avoid the centralized paradigm, leader token approach is proposed. Thus, at each iteration, the vehicles run a token selection algorithm, which determines the leader token holder for this loop. The algorithm decision is based on the vehicle status and current computational load. Only the leader vehicle communicates with the webserver for the updates of the requests lists and then publishes it to all other vehicles in the system. Accordingly, this mechanism ensures the consistency and synchronization of the requests through a distributed paradigm.
4.3. Selected Scenarios
In order to test the proposed approach, several scenarios are selected in both simulation and realworld. The simulation scenarios are selected from wellknown benchmarks of mTSP; this is in order to have the optimal cost available for comparison. Each scenario consists of a different number of cities, which are distributed over the environment in various locations.
Figure 4 shows the four selected scenarios, where the top left one is Christofides/Eilon with 51 cities, top right one is Berlin (Groetschel) with 52 locations, bottom left one is Christofides/Eilon with 76 cities, and bottom right one is Rattled Grid (Pulleyblank) with 99 cities [35, 36]. Each scenario has only one depot, represented by the red marker in the graphs.
On the other hand, the realworld scenario was designed in a way to evaluate the functionality of the proposed solution and the architecture in the platforms. The scenario involved three users using the application to create transportation requests. The three users had different starting points and different destinations; moreover the request time was close to others to evaluate how the vehicles are going to respond. Figure 5 shows the environment map with the vehicles and passengers locations, the two vehicles are represented with the golfcart clipart, and the passengers representation is marked in three different colors, with a circular shape of the same color for the desired destination. The experiment was video recorded and its results discussion is in the next section.
4.4. Evaluation Metrics
The proposed hybrid optimizationbased solution is used to solve each scenario of the MRTA problem and the results are recorded for evaluation. In order to evaluate the quality, two evaluation metrics are introduced, which are the allocation cost and computational time.
The first evaluation metric is the allocation cost of the best allocation found. The allocation cost is calculated based on the objective function. Thus two allocations costs are computed, one is the MinMax cost, which represents the length of the longest subtour in the allocation, and the other is the total overall cost of all subtours.
The second metric is the computational time required by the algorithm to reach the best solution. The timer starts after the databases of the vehicles and requests are read and stops when the algorithm stops; then the elapsed time is reported. Since the computational time calculation is based on the machine, the computer used for all experiments has the specifications in Table 1.

5. Results
In this section, a comparative study is conducted between the proposed approach results and the reference optimal results presented in [35, 36]. The optimal results are obtained for the four wellknown benchmarks, which are described in the scenarios subsection. The authors in [35] adjusted the benchmark settings, to have all vehicles located at the depot, where the vehicles are required to visit all locations in the scenario. With the condition that each location is visited exactly once, vehicles must return to the depot afterward.
Table 2 summarizes all the results from both the optimal solutions costs, compared to the obtained solutions costs, in addition to the computational time for the obtained solutions costs. The optimal costs are obtained using IBM CPLEX; it took 96 hrs for the eil51 dataset, 120 hrs for the berlin52 dataset, 168 hrs for the eil76 dataset, and 216 hrs for the rat99 dataset. On the other hand, the reported values of the obtained costs are the mean of the 25 experiments of each scenario.
