U.S. patent application number 15/941449 was filed with the patent office on 2018-08-09 for on-demand high-capacity ride-sharing via dynamic trip-vehicle assignment with future requests.
The applicant listed for this patent is Massachusetts Institute of Technology. Invention is credited to Javier ALONSO-MORA, Daniela L. RUS, Alexander J. WALLAR.
Application Number | 20180224866 15/941449 |
Document ID | / |
Family ID | 63037180 |
Filed Date | 2018-08-09 |
United States Patent
Application |
20180224866 |
Kind Code |
A1 |
ALONSO-MORA; Javier ; et
al. |
August 9, 2018 |
On-Demand High-Capacity Ride-Sharing Via Dynamic Trip-Vehicle
Assignment with Future Requests
Abstract
Described is a method and system for vehicle routing and request
assignment which incorporates a prediction of future demand. The
method seamlessly integrates sampled future requests into request
assignments and vehicle routing.
Inventors: |
ALONSO-MORA; Javier;
(Leiden, ES) ; RUS; Daniela L.; (Weston, MA)
; WALLAR; Alexander J.; (Cambridge, MA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Massachusetts Institute of Technology |
Cambridge |
MA |
US |
|
|
Family ID: |
63037180 |
Appl. No.: |
15/941449 |
Filed: |
March 30, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15877935 |
Jan 23, 2018 |
|
|
|
15941449 |
|
|
|
|
62478889 |
Mar 30, 2017 |
|
|
|
62449315 |
Jan 23, 2017 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06N 5/04 20130101; G05D
1/0291 20130101; G05D 1/0088 20130101; G06Q 10/06311 20130101; G08G
1/202 20130101 |
International
Class: |
G05D 1/02 20060101
G05D001/02; G05D 1/00 20060101 G05D001/00; G06N 5/04 20060101
G06N005/04; G06Q 10/06 20060101 G06Q010/06 |
Goverment Interests
GOVERNMENT RIGHTS
[0002] This invention was made with Government support under Grant
N00014-12-1-1000 awarded by the Office of Naval Research. The
Government has certain rights in the invention.
Claims
1. A system for controlling and continuously rerouting a fleet of
vehicles based up on real-time requests, the system comprising: (a)
means for receiving current requests for rides from one or more
vehicles within a fleet of vehicles within a window and for
receiving a prediction of future demand; (b) means for generating a
pairwise request-vehicle shareability graph (RV-graph) which takes
into account the prediction of future demand; (c) means for
generating a request-trip-vehicle graph (RTV-graph) of trips and
the vehicles that can serve them which takes into account the
prediction of future demand; (d) means for solving an integer
linear program (ILP) to determine an assignment of vehicles to
trips while taking into account the prediction of future demand;
and (e) means for assigning specific vehicles from the fleet of
vehicle to specific trips while taking into account the prediction
of future demand.
2. The system of claim 1 further comprising means for determining
the feasibility of trips in the RTV-graph.
3. The system of claim 1 further comprising means for rebalancing
idle vehicles to areas with high demand.
4. The system of claim 1 wherein the fleet of vehicles is a fleet
of autonomous vehicles.
5. A method for controlling and continuously rerouting a fleet of
vehicles based up on real-time ride requests, the method
comprising: (a) receiving current requests for rides from one or
more vehicles within a fleet of vehicles within a window; (b)
receiving a prediction of future demand; (c) generating a pairwise
request-vehicle shareability graph RV-graph which takes into
account the prediction of future demand; (d) generating an
RTV-graph of trips and the vehicles that can serve them while
taking into account the prediction of future demand; (e) solving an
integer linear program (ILP) to determine an assignment of vehicles
to trips while taking into account the prediction of future demand;
and (f) assigning specific vehicles from the fleet of vehicle to
specific trips while taking into account the prediction of future
demand.
6. The method of claim 5 further comprising determining the
feasibility of trips in the RTV-graph.
7. The method of claim 5 further comprising rebalancing idle
vehicles to areas with high demand.
8. The method of claim 5 wherein the fleet of vehicles is a fleet
of autonomous vehicles.
9. The method of claim 6 wherein providing an assignment for the
current requests and time comprises providing an optimal assignment
for the current requests and time. providing an assignment for the
current requests and time.
10. The method of claim 6 wherein providing an assignment for the
current requests and time comprises providing a best solution found
within an allotted amount of time.
11. A method for assigning one or more vehicles in response to one
or more vehicle requests, the method comprising: (a) generating a
pairwise request-vehicle shareability graph while taking into
account a prediction of future demand; (b) generating a graph of
feasible trips including the vehicles that can serve them while
taking into account the prediction of future demand; (c) forming an
integer linear program (ILP) to determine an assignment of vehicles
to trips while taking into account the prediction of future demand;
(d) solving an integer linear program (ILP) to determine an
assignment of vehicles to trips while taking into account the
prediction of future demand; and (e) assigning specific vehicles
from the fleet of vehicle to specific trips while taking into
account the prediction of future demand.
12. The method of claim 10 further comprising rebalancing the
remaining idle vehicles while taking into account the prediction of
future demand.
13. A system for assigning one or more vehicles in response to one
or more vehicle requests, the method comprising: (a) means for
generating a pairwise request-vehicle shareability graph while
taking into account the prediction of future demand; (b) means for
generating a graph of feasible trips including the vehicles that
can serve them while taking into account the prediction of future
demand; (c) means for forming an integer linear program (ILP) based
upon a graph of feasible trips to determine an assignment of
vehicles to trips while taking into account the prediction of
future demand; (d) a processor for solving an integer linear
program (ILP) to determine an assignment of vehicles to trips while
taking into account the prediction of future demand; and (e) means
for assigning specific vehicles from the fleet of vehicle to
specific trips while taking into account the prediction of future
demand.
Description
CROSS REFERENCE TO RELATED PATENT APPLICATION
[0001] This application claims the benefit of U.S. Provisional
Application No. 62/478,889 filed Mar. 30, 2017. This application is
also a continuation-in-part of co-pending application Ser. No.
15/877,935 filed Jan. 23, 2018 which application claims the benefit
of U.S. Provisional Application No. 62/449,315 filed Jan. 23, 2017.
Each of the above applications are hereby incorporated herein by
reference in their entireties.
BACKGROUND
[0003] As is known in the art, in the domain of intelligent
transportation, ridesharing systems with autonomous vehicles are a
relatively new frontier for enhancing the efficiency of urban
mobility.
[0004] As is also known, ride sharing services, such as UberPool
and Lyft Line, are transforming urban mobility. Also known as
vehicle pooling options, these systems allow several passengers,
typically limited to two, to share a vehicle when traveling along
similar routes. Similar services include Via, which provides
vehicle pooling with vans, and Bridj, which provides an alternative
to buses. Currently these companies relay on drivers to operate the
vehicles, but there is a push in the industry towards autonomous
self-driving vehicles. Examples include Google, Uber, Nutonomy and
other major car manufacturers. These fleets of autonomous vehicles
are expected to provide safe, reliable and affordable
transportation.
[0005] Yet, efficient methods capable of assigning travel requests
to a fleet of vehicles, and routing the vehicles efficiently, are
required.
[0006] Informed driving is becoming a key feature to increase the
sustainability of taxi companies and with a combination of readily
available large datasets and powerful data mining tools, estimation
of future patterns from data is an active field of research.
Several works have looked at estimating future demand given past
taxi data, for example.
[0007] A recent study in New York City showed that up to 80% of the
taxi trips in Manhattan could be shared by two riders with an
increase in the travel time of a couple minutes and also showed the
gains attainable by a "global oracle" with full knowledge of the
future. Much of the fleet management literature for
mobility-on-demand systems consider the case of ridesharing without
pooling requests, focusing on fluid approximations, queuing based
formulations, case studies in specific regions. and operational
considerations for fleet managers. With the growing interest and
rapid developments in autonomous vehicles, there has also been an
increasing focus on autonomous mobility-on-demand systems. However,
none of these works consider the ride-pooling problem of servicing
multiple rides with a single trip nor the prediction of future
requests.
[0008] It would, therefore, be desirable to provide a system and
technique which considers the ride-pooling problem of servicing
multiple rides with a single trip as well as the prediction of
future requests.
SUMMARY
[0009] It has been recognized herein that the ridesharing problem
is related to the vehicle-routing problem and the dynamic pickup
and delivery problem in which spatiotemporally distributed demand
must be picked up and delivered within prespecified time
windows.
[0010] It has also been recognized that one challenge when
addressing this problem is the need to explore a very large
decision space, while computing solutions fast enough to provide
users with the experience of real-time booking and ride
service.
[0011] It would therefore, be desirable to provide a system and
technique which improves, and ideally fully address the potential
of ride-sharing services.
[0012] In one aspect of the concepts described herein, described
are a system and technique for real-time high-capacity ride-sharing
that (i) scales to large numbers of passengers and trips and (ii)
dynamically generates optimal routes with respect to online demand
and vehicle locations is described.
[0013] In one embodiment, the system and techniques may be used to
implement ridesharing with rider capacity of up to 10 simultaneous
passengers per vehicle.
[0014] In another aspect of the disclosed concepts, described is a
ridesharing technique which utilizes a reactive anytime optimal
method (i.e. a method that efficiently returns a valid assignment
of travel requests to vehicles and then refines it over time,
converging to an optimal solution).
[0015] With this particular arrangement, a system and technique for
controlling a fleet of vehicles with varying occupant capacities
which address both the problems of assigning vehicles to matched
passengers and rebalancing--or repositioning--the fleet to service
demand is provided. The system and method described herein solve
the unified problem of passenger and vehicle assignment in a
computationally efficient manner at a large scale and demonstrates
the capability of operating a real-time MoD system with multiple
service tiers (shared-taxi, shared-vans, and shared-buses) of
varying capacity. If enough computational resources are available,
the optimal assignment for the current requests and time would be
found; otherwise, the best solution found so far (e.g. within a
selected, determined or measured period of time) is returned.
[0016] In another aspect of the disclosed concepts, described is a
system which utilizes a reactive anytime optimal method (i.e. a
method that efficiently returns a valid assignment of travel
requests to vehicles and then refines it over time, converging to
an optimal solution). If enough computational resources are
available, the optimal assignment for the current requests and time
would be found; otherwise, the best solution found within given
limitations (e.g. a given time limit) is returned.
[0017] In accordance with a further aspect of the concepts
described herein, a technique for assigning ridesharing requests to
vehicles includes (a) receiving current requests for rides from one
or more vehicles within a fleet of vehicles within a window; (b)
generating a pairwise request-vehicle shareability graph
(RV-graph); (c) generating a generating a request-trip-vehicle
graph (RTV-graph) of trips and the vehicles that can serve them;
(d) solving an integer linear program (ILP) to determine an
assignment of vehicles to trips; and (e) assigning specific
vehicles from the fleet of vehicle to specific trips.
[0018] With this particular arrangement, a technique for assigning
ridesharing requests to vehicles which is efficient and scalable is
provided. In embodiments, the method starts from a greedy
assignment and improves it through a constrained optimization,
quickly returning solutions of good quality and converging to the
optimal assignment over time. In embodiments, the method further
includes determining the feasibility of trips in the RTV-graph. In
embodiments, the method further includes rebalancing idle vehicles
to areas with high demand. In embodiments, the method further is
applied to a fleet of autonomous vehicles. In embodiments,
tradeoffs may be made between fleet size, capacity, waiting time,
travel delay, and operational costs for low- to medium-capacity
vehicles, such as taxis and van shuttles and desired
performance.
[0019] In one embodiment, a highly scalable anytime optimal
technique is described. In embodiments, such a system and technique
the system and technique can be applied such that in a shared
vehicle fleet with passenger capacities of up to ten, 2,000
vehicles (15% of the taxi fleet) of capacity 10 or 3,000 of
capacity 4 can serve 98% of the demand within a mean waiting time
of 2.8 min and mean trip delay of 3.5 min.
[0020] The described system and techniques may be applied to fleets
of autonomous vehicles and also incorporates rebalancing of idling
vehicles to areas of high demand. This technique framework is
general and can thus be used for many real-time multivehicle,
multitask assignment problems.
[0021] In another aspect of the concepts sough to be protected
herein, it has recognized that some traditional approaches that
rely on an integer linear program (ILP) formulation (such as
Cordeau J F (2006) A branch-and-cut technique for the dial-a-ride
problem. Oper Res 54(3):573-586), also provide anytime guarantees
for the multivehicle-routing problem.
[0022] However, in contrast to the approach described herein, the
applicability of prior art approaches is limited to small problem
instances (e.g. 32 requests and 4 vehicles, with a computation cost
of several minutes in the above cited J F Cordeau reference).
[0023] And while the techniques and systems described herein also
rely on an ILP formulation, they do not explicitly model the edges
of the road network in the ILP. Thus, the approach described herein
scales to much larger problem instances. For example, the
techniques and systems described herein can provide real time
solutions to large problem instances such as New York City, with
thousands of vehicles, requests, and road segments.
[0024] The approach described herein decouples the problem by first
computing feasible trips from a pairwise shareability graph and
then assigning trips to vehicles. It is shown that this assignment
can be posed as an ILP of reduced dimensionality. The framework
allows for flexibility in terms of prescribing constraints such as
(but not limited to) maximum user waiting times and maximum
additional delays due to sharing a ride. The method also be
extended to proactively rebalance the vehicle fleet by moving idle
vehicles to areas of high demand.
[0025] Detailed experimental results of an illustrative embodiment
are presented for a subset of 3 million rides extracted from the
New York City taxicab public dataset. It is shown that 3,000
vehicles with a capacity of 2 and 4 could serve 94 and 98% of the
demand with a mean waiting time of 3.2 and 2.7 min, and a mean
delay of 1.5 and 2.3 min, respectively. To achieve 98% service
rate, with comparable waiting time (2.8 min) and delay (3.5 min), a
fleet of just 2,000 vehicles with a capacity of 10 was required.
This fleet size is 15% of the active taxis in New York City. One
also shows that our approach is robust with respect to the density
of requests and could therefore be applied to other cities.
[0026] The system described herein operates in real time and is
particularly well suited for use with autonomous vehicle fleets
that can continuously reroute based on real-time requests. It can
also rebalance idle vehicles to areas with high demand and is
general enough to be applied to other multivehicle, multitask
assignment problems.
[0027] In accordance with a further aspect of the concepts
described herein, a system for controlling and continuously
rerouting an fleet of vehicles based up on real-time ride requests
includes (a) means for receiving current requests for rides from
one or more vehicles within a fleet of vehicles within a window;
(b) means for generating a pairwise request-vehicle shareability
graph (RV-graph); (c) means for generating a generating a
request-trip-vehicle graph (RTV-graph) of trips and the vehicles
that can serve them; (d) means for solving an integer linear
program (ILP) to determine an assignment of vehicles to trips; and
(e) means for assigning specific vehicles from the fleet of vehicle
to specific trips.
[0028] With this particular arrangement, a system for controlling a
fleet of vehicles with varying passenger capacities which address
both the problems of assigning vehicles to matched passengers and
rebalancing--or repositioning--the fleet to service demand is
provided. One show how the unified problem of passenger and vehicle
assignment can be solved in a computationally efficient manner at a
large scale, thereby demonstrating the capability to operate a
real-time MoD system with multiple service tiers (shared-taxi,
shared-vans, and shared-buses) of varying capacity.
[0029] In embodiments, the fleet of vehicles may include one or
more autonomous vehicles.
[0030] In embodiments, the fleet of vehicles may be provided as a
fleet of autonomous vehicles.
[0031] In embodiments, the system may further comprise means for
rebalancing idle vehicles (either autonomous or non-autonomous
vehicles) to areas with high demand.
[0032] In accordance with a further aspect of the concepts
described herein, a method for controlling and continuously
rerouting a fleet of vehicles based up on real-time ride requests,
includes (a) receiving current requests for rides from one or more
vehicles within a fleet of vehicles within a window; (b) generating
a pairwise request-vehicle shareability graph (RV-graph); (c)
generating a generating a request-trip-vehicle graph (RTV-graph) of
trips and the vehicles that can serve them; (d) solving an integer
linear program (ILP) to determine an assignment of vehicles to
trips; and (e) assigning specific vehicles from the fleet of
vehicle to specific trips.
[0033] With this particular arrangement, a method for controlling a
fleet of vehicles with varying passenger capacities and which
address both the problems of assigning vehicles to matched
passengers and rebalancing--or repositioning--the fleet to service
demand is provided. It is shown how the unified problem of
passenger and vehicle assignment can be solved in a computationally
efficient manner at a large scale, thereby demonstrating the
capability to operate a real-time MoD system with multiple service
tiers (shared-taxi, shared-vans, and shared-buses) of varying
capacity.
[0034] In embodiments, the method may control either or both of
autonomous vehicles and non-autonomous vehicles. In embodiments,
the method may control one or more autonomous vehicles. In
embodiments, the method may control a fleet of only autonomous
vehicles. In embodiments, the method may control a fleet of only
non-autonomous vehicles.
[0035] In embodiments, the method may further comprise rebalancing
idle vehicles (either autonomous or non-autonomous vehicles) to
areas having a high demand or ride requests.
[0036] It should be appreciated that the concepts, systems and
techniques described herein find use in a variety of different
applications including, but not limited to: routing of vehicles,
taxi/shuttle/bus/boat ride sharing, package delivery, logistics and
multi-vehicle multi-task assignment.
[0037] Also described herein is an efficient constrained
optimization method for vehicle routing and multi-request
multivehicle assignment that takes into account a prediction of the
future demands (i.e. future ride sharing requests) as well as a
system which uses such a method.
[0038] In an embodiment, the described method and system utilize a
constrained optimization technique that leverages historical data
to address a persistent mobility-on-demand task with a large
network of self-driving vehicles (e.g. taxis). In particular, the
described method and system are capable of assigning thousands of
requests to thousands of vehicles (e.g. autonomous vehicles) in
real time and route them in an informative way which accounts for
future predicted ride requests.
[0039] Consequently, the described method and system allows several
passengers with independent trips to share a vehicle and allows
such passenger-loaded vehicles to pick additional passengers as the
vehicles (with passengers on-board) progress through their routes.
Based upon historical data, a probability distribution over future
demand may be computed. Then, samples from the learned probability
distribution are incorporated into any-time optimal method for
vehicle routing and passenger assignment to take into account the
predicted future demand. The benefits and trade-offs of this
predictive approach are shown in an experimental evaluation with
over three million rides extracted from a dataset of taxi trips in
New York City. The method and system described herein produces
routes and assignments that, in expectation, reduce the travel and
waiting times for passengers, with respect to a purely reactive
approach. Besides the mobility on demand application, the method
described herein is general and could also be applied to other
multi-task multivehicle assignment and routing problems.
[0040] In one aspect, described herein is a constrained
optimization method which accounts for future, predicted, requests
to route vehicles. The method includes computing a probability
distribution over future demand. In embodiments this may be
accomplished based upon historical data.
[0041] In another aspect, described is an any-time optimal method
for vehicle routing and passenger assignment that takes into
account the future demand to produce routes and assignments that in
expectation reduce the travel and waiting times. The method can
assign thousands of requests to thousands of vehicles (including
but not limited to autonomous vehicles) in real time, while
allowing passengers (e.g. several passengers) with independent
trips to share a vehicle and that a vehicle may select additional
passengers as it progresses in its route.
[0042] The system and method described herein accounts for the
state of individual vehicles within a fleet of vehicles and the
requests at a current time instance while also incorporating a
prediction of future demand. This approach results in better
positioning of vehicles within a fleet of vehicles towards
satisfying future requests. Such a system and technique are
directed toward achieving long term optimality of ride-sharing
assignment and routing.
BRIEF DESCRIPTION OF THE DRAWINGS
[0043] The foregoing features may be more fully understood from the
following description of the drawings in which:
[0044] FIG. 1 is a flow diagram of a method for batch assignment of
multiple ride requests to multiple vehicles of capacity v;
[0045] FIG. 1A is a diagram of an illustrative street network with
four requests and two vehicles with a first one of the vehicles
having one passenger and a second one of the vehicles being empty
of passenger-occupants;
[0046] FIG. 1B is a pairwise shareability RV-graph of requests and
vehicles. Cliques of this graph are potential trips;
[0047] FIG. 1C is an RTV-graph of candidate trips and vehicles
which can execute them. A node (yellow triangle) is added for
requests that cannot be satisfied;
[0048] FIG. 1D is a diagram illustrating optimal vehicle
assignments given by the method of FIG. 1 (i.e. a solution of the
Integer Linear Program (ILP)), where vehicle 1 serves requests 2
and 3 and vehicle 2 serves requests 1 and 4;
[0049] FIG. 1E is a diagram illustrating planned routes for the two
vehicles and their assigned requests. In this case, no rebalancing
process is required because all requests and vehicles are
assigned;
[0050] FIG. 2 is a diagram of an illustrative pairwise
RV-graph;
[0051] FIG. 3A is an illustration of a geographic region having
2,000 vehicles, capacity of 4;
[0052] FIG. 3B is an enlarged view of a portion of the geographic
region illustrated in FIG. 3A showing an enlarged view of a
scheduled path for a vehicle with four passengers, which drops one
off, picks up a new one, and drops all four;
[0053] FIG. 4A is a plot of mean number of passengers per vehicle
vs. time for four different vehicle types (capacity one, two, four,
and ten) over a one-week time period for a vehicle fleet size of
1000 vehicles and a maximum waiting time of two (2) minutes;
[0054] FIG. 4B is a plot of mean number of passengers per vehicle
vs. time for four different vehicle types (capacity one, two, four,
and ten) over a one-week time period for a vehicle fleet size of
1000 vehicles and a maximum waiting time of seven (7) minutes;
[0055] FIG. 4C is a plot of mean number of passengers per vehicle
vs. time for four different vehicle types (capacity one, two, four,
and ten) over a one-week time period for a vehicle fleet size of
3000 vehicles and a maximum waiting time of two (2) minutes;
[0056] FIG. 4D is a plot of mean number of passengers per vehicle
vs. time for four different vehicle types (capacity one, two, four,
and ten) over a one-week time period for a vehicle fleet size of
3000 vehicles and a maximum waiting time equal to seven (7)
minutes;
[0057] FIG. 5A is a plot of percentage of vehicles in each state
(waiting, rebalancing, and number of passengers) vs. time for a
representative day (Friday 0000 hours to 2400 hours) with a fleet
of 1,000 vehicles of capacity 10 with many opportunities for
ride-sharing in high-capacity vehicles;
[0058] FIG. 5B is a plot of percentage of vehicles in each state
(waiting, rebalancing, and number of passengers) vs. time for a
representative day with a fleet of 2,000 vehicles of capacity
four;
[0059] FIG. 6A is a plot of percent of serviced requests vs.
maximum waiting time for varying vehicle capacity (1, 2, 4, and 10
passenger) and varying fleet sizes (fleet sizes of 1,000, 2,000,
and 3,000 vehicles);
[0060] FIG. 6B is a plot of average in car delay .delta.-.omega.
vs. maximum waiting time for varying vehicle capacity (1, 2, 4, and
10 passenger) and varying fleet sizes (fleet sizes of 1,000, 2,000,
and 3,000 vehicles);
[0061] FIG. 6C is a plot of average waiting time .omega., vs.
maximum waiting time for varying vehicle capacity (1, 2, 4, and 10
passenger) and varying fleet sizes (fleet sizes of 1,000, 2,000,
and 3,000 vehicles);
[0062] FIG. 6D is a plot of average distance traveled by each
vehicle during a single day vs. maximum waiting time for varying
vehicle capacity (1, 2, 4, and 10 passenger) and varying fleet
sizes (fleet sizes of 1,000, 2,000, and 3,000 vehicles);
[0063] FIG. 6E is a plot of percentage of shared rides (number of
passengers who shared a ride divided by the total number of
picked-up passengers) vs. maximum waiting time for varying vehicle
capacity (1, 2, 4, and 10 passenger) and varying fleet sizes (fleet
sizes of 1,000, 2,000, and 3,000 vehicles);
[0064] FIG. 6F is a plot of average computational time for a thirty
(30) second iteration of the method described herein including
computation of the RV-graph, computation of the RTV-graph, ILP
assignment, rebalancing, and data writing; and
[0065] FIG. 7 is a block diagram of a ride sharing system for
assigning travel requests to vehicles and finding optimal routes
for a vehicle fleet;
[0066] FIG. 8 is a diagram of a system for assigning vehicles to
trips that takes into account a predicted demand in both vehicle
routing and request-vehicle assignments in the context of ride
sharing by utilizing a method for batch assignment of multiple ride
requests to multiple vehicles of capacity v taking into account
future requests;
[0067] FIG. 8A is an example of a street network with two requests,
two predicted requests and two vehicles;
[0068] FIG. 8B is an example of a pairwise shareability RV-graph of
requests and vehicles with cliques of this graph corresponding to
potential trips;
[0069] FIG. 8C is an example of an RTV-graph of candidate trips and
vehicles which can execute them;
[0070] FIG. 8D is an example of an optimal assignment given by the
solution of the ILP, where vehicle 1 serves requests 2 and 3 and
vehicle 2 serves requests 1 and 4;
[0071] FIG. 8E is an example of a planned route for the two
vehicles and their assigned requests shown on FIG. 8A where the
predicted requests alter the route of the vehicles, driving them
towards areas of likely future requests;
[0072] FIG. 9 is a flow diagram of a method for positioning
vehicles within a fleet of vehicles taking into account predicted
future requests;
[0073] FIG. 10 is a flow diagram of a method for incorporating into
a vehicle routing method and passenger assignment selected samples
from a probability distribution of predicted future requests;
[0074] FIG. 11 is a flow diagram of a method for determining a
probability distribution of origin-destination requests for fixed
intervals of time;
[0075] FIG. 12 is a diagrammatic view of a geographic area having
in which region centers determined by a greedy station
technique;
[0076] FIGS. 13A-13D are a series of heatmaps depicting a
destination demand distribution; and
[0077] FIGS. 14A-14F are a series of graphs which present a
comparison of several performance metrics for varying number of
sampled requests.
DETAILED DESCRIPTION
[0078] Before describing concepts, systems, devices and techniques
and details of a ridesharing system and technique for assigning
travel requests to vehicles and finding optimal routes for the
vehicle fleet, some introductory concepts and terminology are
explained.
[0079] As used herein, the term "ridesharing" refers to the sharing
of vehicles by persons. One form of ridesharing, for example, is
carpooling. Carpooling may be described as the sharing of a vehicle
(e.g. a passenger vehicle such as a car) by two or more persons so
that more than one-person travels in a car. Another form of
ridesharing is vanpooling. Vanpools are an element of a transit
system that allow groups of people to share a ride similar to a
carpool, but on a larger scale with concurrent savings in fuel and
vehicle operating costs. A special case of ridesharing is referred
to "ride-pooling" where multiple requests may be served by the same
vehicle simultaneously.
[0080] Vehicles in a ridesharing operation may be provided by
individuals, individuals in cooperation with various public and
private support programs, by companies (e.g. private taxi cab
companies) through a program operated by or on behalf of an element
of government, or a program operated by or on behalf of a public or
private employer.
[0081] An important concept of ridesharing is that people share a
vehicle while travelling from one or more common or disparate
starting locations (or "origins") to different or a common ending
location (or "destination"). Thus, each person may have different
starting locations and different ending locations, each person may
have different starting locations and the same (or substantially
the same) ending location (e.g. a common destination such as a work
center such as an office building, or corporate campus, or an
educational campus, for example), each person may have the same
starting location (e.g. a common meeting place) and different
ending locations or each person may have the same starting location
(e.g. a common meeting place) and a common ending location.
[0082] Ridesharing may be real-time ridesharing--e.g. a form of
taxi-like service in which vehicles may, for example, be operated
by independent contractors who may receive requests for rides (i.e.
ride-requests) online (e.g. over the internet using a third-party
matchmaking application) and provide transport services (e.g.
rides) to people in real-time.
[0083] Furthermore, ridesharing may be conducted as peer-to-peer
ridesharing. Peer-to-peer ridesharing can be divided along a
spectrum ranging from commercial, for-fee transportation network
companies to for-profit ridesharing services to informal nonprofit
peer-to-peer carpooling arrangements. Many modern peer-to-peer
ridesharing schemes rely on web applications and/or mobile app
technology available to potential users (e.g. people seeking some
form of rideshare arrangement).
[0084] In general overview, described herein is a framework for
techniques and systems for solving the real-time ride-pooling
problem with (i) arbitrary numbers of passengers and trips, (ii)
anytime optimal rider allocation and routing dependent on the fleet
location, and (iii) online rerouting and assignment of riders to
existing trips.
[0085] The techniques described herein address the problems of both
optimally assigning one or more travel requests R (e.g. online
travel requests) to one or more vehicles in a fleet of vehicles and
finding routes for at least the assigned vehicles in the vehicle
fleet. Ideally, and as will be described in detail below, (e.g.
with respect to some cost function, an example of which will be
provided herein below) the assignments of travel requests to
vehicles are optimal or near-optimal assignments and the routes for
the vehicle fleet are optimal or near-optimal routes.
[0086] In the description provided hereinbelow, considered is a
fleet V of m vehicles of capacity v, where v represents the maximum
number of passengers each vehicle can have at any given time. An
individual travel request r may be one of a set of travel requests
R (i.e. R={r.sub.1, . . . r.sub.n}).
[0087] Also, as used herein, the term "passenger" is defined as a
traveler (e.g. a person) who has submitted a travel request (e.g. a
past travel request) and has been picked up by a vehicle and that
is now in route to its destination and the term P.sub.v denotes a
set of passengers for vehicle of the fleet (i.e. v V).
[0088] FIG. 1 illustrates an anytime optimal process for batch
assignment of a set of requests R={r.sub.1 . . . r.sub.n} to a set
of vehicles V={v.sub.1 . . . v.sub.m}, which: (1) reduces (and
ideally minimizes) a cost function C (to be described below); (2)
satisfies a set of constraints Z (to be described below); and (3)
allows for multiple passengers per vehicle. It should be
appreciated that the fleet may be the entire set of vehicles but
need not be (i.e. the set of vehicles may be some or all of the
fleet of vehicles). Also included the process of FIG. 1 is an
optional process to rebalance a fleet of vehicles (to which the set
of vehicles V belongs). It should be appreciated that rebalancing
can be done on the entire fleet of vehicles or less than the entire
fleet of vehicles. For example, rebalancing may be done on just the
set of vehicles V by driving idle vehicles to areas of high demand,
where those vehicles are likely to be required in the future.
[0089] Turning now to FIG. 1, a method for batch assignment of
multiple ride requests to multiple vehicles of capacity v begins as
shown in processing blocks 12 and 14 in which one or more travel
requests 12 and one or more indicators of vehicle status 14 are
received. Each travel request includes at least a time of request,
a pickup location and a drop-off location. The number of vehicles
for which a vehicle status is received may be some or all of the
vehicles in the fleet.
[0090] Referring briefly to FIG. 1A, an example scenario includes
an illustrative street network with four requests (orange human,
origin; red triangle, destination) and two vehicles (yellow car,
origin; red triangle, destination of passenger). Vehicle 1 has one
passenger, and vehicle 2 is empty.
[0091] Turning again to FIG. 1, after receipt of at least some
travel requests and vehicle status indicators, a pairwise
request-vehicle graph (RV-graph) is formed as shown in processing
block 14. The RV-graph represents which requests and vehicles might
be pairwise-shared, and significantly, also includes the vehicles
at their current state. FIG. 1B is an RV-graph for the scenario of
FIG. 1A while FIG. 2 is an example of a more complex RV-graph
having 90 requests (star) and 30 vehicles (circle) with edges
between two requests in dotted red and between a request and a
vehicle in solid green. The maximum waiting time and delay are
three and six minutes in this example.
[0092] Processing then proceeds to processing block 16 in which a
round trip vehicle graph (RTV graph) is formed. In particular
cliques of the RV-graph (or regions for which its induced subgraph
is complete) are explored to find feasible trips and are used to
compute the RTV-graph in a manner to be described below. Suffice it
here to say that the RTV-graph is used to determine if a trip is
feasible (i.e. the RTV-graph is used to determine whether all of
the requests can be picked up and dropped off by some vehicle,
while satisfying one or more constraints).
[0093] Processing then proceeds to processing block 18 in which
assignment problem Integer Linear Program (ILP) processing is
performed. In embodiments, an anytime optimal technique may be used
for batch assignment of a set of requests R={r.sub.1, . . .
r.sub.n} to a set of vehicles V={v.sub.1, . . . v.sub.m} which: (1)
optimizes (and ideally minimizes) a cost function C; (2) satisfies
a set of constraints Z; and (3) allows for multiple passengers per
vehicle.
[0094] Solutions from the ILP processing 18 are provided to
processing block 20 in which assignment processing (i.e. the actual
assigning of requests to vehicles) is performed.
[0095] Solutions from the ILP processing 20 may also optionally be
provided to processing block 22 where rebalancing is performed.
Such rebalancing is accomplished, at least in part, by moving idle
vehicles to areas in which those vehicles are likely to be required
in the future (i.e. so-called "areas of high demand"). In
embodiments, "regions of high demand" may generally be defined as
regions where there are more requests than those that can be
serviced with the vehicles in the region. It should be appreciated
that the concepts and techniques described herein need not consider
specifically defined regions, but rather do an assignment of "idle"
vehicles to "ignored" requests, where an ignored request is a
request that was not assigned to any vehicle in the assignment
step. Details of rebalancing are described hereinbelow.
[0096] It should be appreciated that in some instances, it may be
possible that only assignment processing is required while in other
instances it may be possible that only rebalancing processing while
in still other instances assignment processing and rebalancing
processing may both be required.
[0097] It should also be appreciated that the formulation
illustrated in FIG. 1 is flexible with respect to physical and
performance-related constraints that might need to be added (i.e.
it is possible to add, modify or otherwise incorporate different
physical and/or performance-related constraints.
[0098] In an illustrative implementation consistent with the broad
concepts describe herein, the following rules are considered:
[0099] (i) for each request r, the waiting time .omega..sub.r,
given by the difference between a pickup time t.sub.r.sup.p and a
request time t.sub.r.sup.r, must be below a maximum waiting time
.OMEGA., for example, 2 minutes; [0100] (ii) for each passenger or
request r the total travel delay
.delta..sub.r=t.sub.r.sup.d-t.sub.r* must be lower than a maximum
travel delay .DELTA., for example, 4 min, where [0101]
t.sub.r.sup.d corresponds to a drop-off time of a request r; and
[0102] t.sub.r*=t.sub.r.sup.r+r(o.sub.r, d.sub.r) corresponds to
the earliest possible time at which the destination could be
reached if the shortest path between the origin or and the
destination d.sub.r was followed without any waiting time and
wherein the total travel delay .delta..sub.r includes both the
in-vehicle delay and the waiting time. [0103] (iii) for each
vehicle v, a maximum number of passengers,
n.sub.p.sup.pass.ltoreq.v (for example, capacity 10).
[0104] The cost C of an assignment is defined as the sum of the
total travel delays .delta..sub.r (which includes the waiting time)
over all assigned requests and passengers, plus a large constant
c.sub.ko for each unassigned request.
[0105] Given an assignment .SIGMA. of requests to vehicles, the set
of requests that have been assigned to some vehicle is denoted as
R.sub.ok and the set of unassigned requests (e.g. due to the
constraints or the fleet size) is denoted R.sub.ko. This
constrained optimization problem may be formally express as:
C(.SIGMA.)=.SIGMA..nu. V.SIGMA.r P.nu.+.SIGMA.r
R.sub.ok.delta..sub.r+.SIGMA..sub.r R.sub.koc.sub.ko. (1)
[0106] This constrained optimization problem represented by Eq. 1
may be solved via the process as illustrated in FIGS. 1 and 1B-1E
which are: (1) computing a pairwise request-vehicle shareability
graph (RV-graph), as illustrated, for example, in FIG. 1B; (2)
computing a graph of feasible trips and the vehicles that can serve
them (RTV-graph) as illustrated, for example, in FIG. 1C; (3)
solving an ILP to compute the assignment of vehicles to trips (and
ideally to compute optimal assignment of vehicles to trips) as
illustrated, for example, in FIG. 1D; and optionally (4)
rebalancing remaining idle vehicles. It should be appreciated that
in FIG. 1E, no rebalancing processing process is required because
all requests and vehicles are assigned. The details of an
illustrative a rebalancing process are described below.
[0107] Given a network graph with travel times, a so-called "travel
function" for single-vehicle routing may be formed and expressed as
travel (v, R.sub.v). For a vehicle v, with passengers P.sub.v, this
function returns a travel route (and ideally an optimal or
near-optimal travel route) .sigma..sub.v to satisfy requests
R.sub.v. This route reduces (and ideally minimizes) a sum of delays
(e.g. the sum of delays .SIGMA..sub.r P.nu.UR.nu..delta.r) subject
to one or more constraints Z (e.g. one, some (e.g. a subset) or all
of: waiting time, delay, and capacity). Other constraints, may of
course, also be used.
[0108] For vehicles having a relatively low (or small) occupant
capacity, such as a sedan style taxi cab, the optimal path can be
computed via an exhaustive search. For vehicles with larger
capacity (e.g. greater than five (5) total occupants), heuristic
methods such as the Lin-Kernighan technique (as described, for
example, in Helsgaun K (2000) An effective implementation of the
Lin-Kernighan traveling salesman heuristic. Eur J Oper Res
126(1):106-130), the Tabu Search technique (as described, for
example, in Glover F, Laguna M (2013) Tabu Search? (Springer,
Berlin); or a simulated annealing approach (as described, for
example, in Pham D T, Karaboga D (2012) Intelligent Optimisation
Techniques: Genetic Algorithms, Tabu Search, Simulated Annealing
and Neural Networks (Springer Science & Business Media, Berlin)
may be used. Furthermore, other techniques known to those of
ordinary skill in the art, may of course, also be used.
[0109] As noted above in conjunction with the example of FIG. 1B,
the RV-graph represents which requests and vehicles might be
pairwise-shared and builds on the idea of shareability graphs.
Significantly the RV-graph described herein also includes the
vehicles at their current state. One vehicle stat is "V.sub.idle"
which is defined as: vehicle is empty and unassigned to any request
(it might be in movement if it was rebalancing in the previous
step). Other vehicle states include, but are not limited to, empty
en route to pick some passenger; rebalancing; with # passengers,
where # can be 1, 2, 3, . . . v (max vehicle capacity).
[0110] The method begins by computing (a) which requests can be
pairwise combined, and (b) which vehicles can serve which requests
individually, given their current passengers (i.e. compute a
pairwise graph of vehicles and requests--i.e. an RV-graph). This
builds on the idea of share-ability graphs, but is it not limited
to the requests and includes the vehicles at their current state as
well.
[0111] In the described processing, two requests r1 and r2 are
connected if some empty vehicle starting at the origin of one of
them could pick up and drop off both requests while satisfying one
or more designated constraints Z. A cost
.delta..sub.r1+.delta..sub.r2 is associated to each edge e(r1, r2).
Similarly, a request r and a vehicle v are connected if the request
can be served by the vehicle while satisfying the constraints Z, as
given by the travel function travel(v, r). The edge is denoted as
e(r, v).
[0112] Next, the cliques of the RV-graph--or regions for which its
induced subgraph is complete--are explored to find feasible trips
and compute an RTV-graph (e.g. as illustrated in FIG. 1C). A trip
T={r.sub.1, . . . , r.sub.nT} is a set of nT requests (where n is
the number of passengers) to be combined in one vehicle. A trip is
feasible if all of the requests can be picked up and dropped off by
some vehicle, while satisfying some. most or all of the constraints
Z.
[0113] As noted above, a trip is feasible if all of the requests
can be picked up and dropped off by some vehicle, while satisfying
the constraints Z and thus it is necessary to determine which trips
are feasible trips. There may exist several trips of varying size
that can service a particular request. In addition, more than one
vehicle might be able to service a trip. Once feasible trips are
identified, the assignment process will ensure that each request
and vehicle are assigned to a maximum of one trip.
[0114] With reference to FIG. 1C, it should be noted that an
RTV-graph contains two types of edges: a first type of edge is
denoted e(r; T) corresponding to edges between a request r and a
trip T that contains request r (i.e., .A-inverted. e(r,T)r T); and
a second type of edge is denoted e(T, v), corresponding to edges
between a trip T and a vehicle v that can execute the trip (i.e.,
.A-inverted.e(T, v)travel(v,T) is feasible). The cost .SIGMA..sub.r
P.nu.UT.delta.r, sum of delays, is associated to each edge
e(T,v).
[0115] The process to determine the feasible trips and edges
proceeds incrementally in trip size for each vehicle, starting from
the request-vehicle edges in the RV-graph. An illustrative process
(which may be considered as a process for generating an RTV-graph
such as that shown in FIG. 1C above) is shown in Table 1 below.
TABLE-US-00001 TABLE 1 1: T = .0. 2: for each vehicle v V do 3.
T.sub.k = .0. .A-inverted.k {1, . . . , v} 4. [Add trips of size
one] 5. for e(r, v) edge of RV-graph do 6. T.sub.1 .rarw. T = {r};
Add e(r, T) and e(T, v) 7. [Add trips of size two] 8. for all
{r.sub.1}, {r.sub.2} T.sub.1 and e(r.sub.1, r.sub.2) RV-graph do 9.
if travel (v,{ r.sub.1, r.sub.2}) = valid then 10. T.sub.2 .rarw. T
= {r.sub.1, r.sub.2}; Add e(r.sub.i, T) and e(T, v) 11. [Add trips
of size k] 12. for k {3, . . . , v} do 13. for all T.sub.1, T.sub.2
T.sub.k-1 with |T.sub.1 .orgate. T.sub.2| = k do 14. Denote T.sub.1
.orgate. T.sub.2 = {r.sub.1, . . . , r.sub.k} 15. if .A-inverted.i
{1, . . . , k}, {r.sub.1, . . . , r.sub.k} \ r.sub.i T.sub.k-1 then
16. if travel (v, T.sub.1 .orgate. T.sub.2) = valid then 17.
T.sub.k .rarw. T = T.sub.1 .orgate. T.sub.2 18. Add e(r.sub.i, T),
.A-inverted.r.sub.i T, and e(T, v) 19. T .rarw. U.sub.i {1,...,V}
T.sub.i
[0116] For computational efficiency, one can optionally decide to
rely on the fact that a trip T only needs to be checked for
feasibility if there exists a vehicle v for which all of its
sub-trips T'=T\r (obtained by removing one request) are feasible
and have been added as edges e(T', v) to the RTV-graph.
[0117] Once feasibility is determined, the assignment of vehicles
to trips (and ideally the optimal assignment .SIGMA..sub.optimum of
vehicles to trips) is computed. This optimization is formalized as
an ILP, initialized with a greedy assignment (or any other
technique well-known to those of ordinary skill in the art that
quickly provides a feasible solution) obtained directly from an
RTV-graph. To compute the greedy assignment (.SIGMA..sub.greedy,)
trips are assigned to vehicles iteratively in decreasing size of
the trip and increasing cost (e.g. sum of travel delays). The
general concept is to increase (and ideally maximize) the number
(i.e. amount) of requests served while reducing (and ideally,
minimizing) the cost. An illustrative process is shown in Table 2
below.
TABLE-US-00002 TABLE 2 1: R.sub.ok = .0.; V.sub.ok = .0. 2: for k =
v; k > 0; k -- do 3: S.sub.k := sort e(T, v) in increasing cost,
.A-inverted.T T.sub.k, v V 4: while Sk .noteq. .0. do 5: pop e(T,
v) .rarw. S.sub.k 6: if .A-inverted.r T, r R.sub.ok V.sub.ok then
7: R.sub.ok .rarw. {.A-inverted.r T}; V.sub.ok .rarw. v 8:
.SIGMA.greedy .rarw.e(T, v)
[0118] Described below is a method to assign trips to vehicles (and
ideally, a method to optimally assign trips to vehicles).
[0119] 1) Variables: A binary variable .sub.i,j {0,1} is introduced
for each edge e(T.sub.i, V.sub.j) between a trip T.sub.i T and a
vehicle v.sub.j V in the RTV-graph. If .sub.i,j=1 then vehicle
v.sub.j is assigned to trip T.sub.i. Denote by .sub.TV the set of
{i, j} indexes for which an edge e(T.sub.i, v.sub.j) exists in the
RTV-graph.
[0120] An additional binary variable .chi..sub.k {0, 1} is
introduced for each request r.sub.k R. These variables are active,
.chi..sub.k=1, if the associated request r.sub.k cannot be served
by any vehicle and is ignored.
[0121] Denote the set of variables X as:
X={ .sub.i,j,.chi..sub.k;.A-inverted.e(T.sub.i,v.sub.i) node in
RTV-graph .A-inverted.r.sub.k R}. (2)
[0122] 2) Cost: The cost function C, equivalent to C(.SIGMA.) in
Equation (1), is given by
C(X):=Z.sub.i,j .epsilon.TVci,j i,j+.SIGMA..sub.K {0, . . .
,n}c.sub.koX.sub.k, (3)
[0123] where the individual costs are given by the sum of
delays,
c.sub.i,j=.SIGMA..sub.r T.sub.i(t.sub.r.sup.d=t.sub.r*), as
returned by travel (v.sub.j,T.sub.i), (4)
[0124] and c.sub.ko is a large enough constant to penalize ignored
requests.
[0125] 3) Constraints: Two types of constraints are included, as
follows.
[0126] Each vehicle is assigned to a single trip at most,
.SIGMA..sub.e .rho..tau..sub.j.sub..upsilon.
.sub.i,j.ltoreq.1.A-inverted..upsilon..sub.j V, (5)
[0127] Where .tau..sub.j.sup..nu. denotes the indexes i for which
an edge e(T.sub.i,v.sub.j) exists in the TRV-graph. Each request is
assigned to a vehicle or ignored,
.SIGMA..sub.i .tau..sub.k.sub.R.SIGMA..sub.j .tau..sub.i.sub.T
.sub.i,j+Xk=1 .A-inverted.r.sub.k R, (6)
[0128] Where .sub.k.sup.R denotes the indexes for i for which an
edge e(r.sub.k, T.sub.i) exists in the RTV-graph and .sub.i.sup.T
denotes the indexes j for which an edge e(T.sub.i,v.sub.j) exists
in the RTV-graph. This is, the trips of which the request forms
part and the vehicles that can service each of those trips.
[0129] 4) Assignment: The optimal assignment is found by solving an
ILP optimization defined by the aforementioned variables, cost and
constraints, as shown in Table 3 below.
[0130] Starting from the greedy assignment, the ILP can be solved
with state of the art solvers via branch and bound with heuristics
and duality gap checking. These processes can be parallelized and
return a suboptimal solution if stopped before convergence.
[0131] It should be noted that the cost function of Eq. 3 is
equivalent to Eq. 1 only if the cost term ci,j of an individual
assignment, of trip i to vehicle j, is given by the sum of delays
for all current passengers and assigned requests of vehicle i,
minus the sum of delays for all current passengers of vehicle i if
it were not to take any additional requests.
[0132] The optimization problem is formulated in Table 3 below. A
binary variable .sub.i,j {0,1}; is introduced for each edge
e(T.sub.i, v.sub.i) between a trip T.sub.i T and a vehicle v.sub.j
V in the RTV-graph. If .sub.i,j=1 then vehicle v.sub.j is assigned
to trip T.sub.i.
[0133] The set of {i, j} indices for which an edge
e(T.sub.i,v.sub.j) exists in the RTV-graph, i.e., the set of
possible pickup trips is denoted .epsilon..sub.TV. An additional
binary variable X.sub.k {0,1} is introduced for each request
r.sub.k R. These variables are active, i.e., X.sub.k=1, if the
associated request r.sub.k cannot be served by any vehicle and is
ignored. The set of variables is then X={ .sub.i,j;
Xk.sub.i.A-inverted.e(T.sub.i, v.sub.j) edge in RTV-graph and
.A-inverted.r.sub.k R}.
[0134] The cost terms c.sub.i,j are the sum of delays for trip Ti
and vehicle v.sub.j pickup (stored in the e(T.sub.i, v.sub.i) edge
of the RTV-graph) and c.sub.ko is a large constant to penalize
ignored requests.
[0135] Two types of constraints are included. Line 3 in Table 3
below imposes that each vehicle is assigned to one trip at most.
Line 4 in Table 3 imposes that each request is assigned to a single
vehicle or ignored. In these constraints, three sets appear.
[0136] The set of trips that can be serviced by a vehicle j, or
edges e(T.sub.i, v.sub.j), is denoted as I.sub.T=j.sup.V.
[0137] The set of trips that contain request k, or edges
e(r.sub.k;T.sub.i), is denoted as I.sub.R=k.sup.V.
[0138] The set of vehicles that can service trip i, or edges
e(T.sub.i, v.sub.j), is denoted as I.sub.T=i.sup.V.
[0139] This ILP is solved incrementally from the greedy assignment
.SIGMA..sub.greedy, thereby improving the quality of the assignment
over time.
TABLE-US-00003 TABLE 3 1: Initial guess: .SIGMA..sub.greedy 2:
optim := arg .chi. min i , j TV c i , j i , j + k { 1 , ... , n } c
k o .chi.k ##EQU00001## 3: s . t . i .tau. V = j T i , j .ltoreq. 1
.A-inverted. V j V ##EQU00002## 4: i .tau. R = k T J .tau. T = i V
i , j + .chi. k = 1 .A-inverted. r k R ##EQU00003##
[0140] The above method for assigning travel requests to vehicles
is well suited for online execution to assign incoming requests
r(t) to a fleet of vehicles for which a pool of requests R is
maintained where (i) new requests are added as they are received
and (ii) requests are removed when they are either (a) picked up by
a vehicle or (b) could not be successfully matched to any vehicle
within the maximum waiting time (e.g. they are ignored).
[0141] In embodiments, requests are collected during a window which
may, for example be provided as a time window or an event window.
In implementations in which the window is provided as a time
window, the time window may be "open," (i.e. the system may accept
requests) for a preselected period of time (e.g., 30 seconds). In
selecting the size of the time window (i.e. the duration of time
for which requests can be collected) the factors to consider
include, but are not limited to computational time and resources
and a number of requests per minute. Alternatively, in some
embodiments, the window could simply be based on a number of
requests received rather than based on time (e.g. during "rush
hour" or after a "major event" such as a concert or sporting event
game) where many requests may be received substantially
simultaneously. It is possible to dynamically compute and adjust
the size of the window (e.g. either a time-based or non time-based
window). For example, the duration of a time window could change
based upon a variety of factors, including, but not limited to, the
number of requests per minute, computational resources, number of
available vehicles, etc . . . .
[0142] After expiration of the time window, at least some (and
preferably all) of the collected requests are assigned in batch to
the different vehicles. If a request is matched to a vehicle at any
given iteration, its latest pickup time is reduced to the expected
pickup time by that vehicle and the cost X.sub.ko of ignoring it is
increased for subsequent iterations. A request might be re-matched
to a different vehicle in subsequent iterations so long as its
waiting time does not increase and until it is picked up by some
vehicle. Once a request is picked up (i.e., the request becomes a
passenger), it remains in that vehicle and cannot be re-matched.
The vehicle may, however, still pick additional passengers. In each
iteration, the new assignment of requests to vehicles guarantees
that the current passengers (occupants of the vehicle) are dropped
off to a desired destination within the maximum delay
constraint.
[0143] After the assignment, due to fleet imbalances, the set
R.sub.ko of unassigned requests may not be empty, and some empty
vehicles (i.e. vehicles unoccupied except for a driver in the case
where the vehicle is not an autonomous vehicle) designated as
V.sub.idle may still by unassigned to any request. These imbalances
may occur when idle vehicles are in areas far away from an area of
current requests and/or due to the maximum waiting time and/or
delay constraints and/or vehicle capacity. Under the assumptions
that (a) ignored requests may wait longer and request again, (b) it
is likely that more requests occur in the same area where all
requests cannot be satisfied, and (c) there are not enough requests
in the neighborhood of the idle cars, the following approach may be
used to rebalance the fleet of vehicles by moving only the idle
vehicles.
[0144] To rebalance the vehicle fleet, after each batch assignment,
vehicles having a status of V.sub.idle are assigned to requests in
R.sub.ko to reduce, and ideally minimize, the sum of travel times,
with the constraint that either all requests or all of the vehicles
are assigned. The process begins by first computing the travel time
T.sub.v,r of each individual idle vehicle having the status of
V.sub.idle to pick each individual request in R.sub.ko, the set of
ignored--or not serviced--request and then obtaining an assignment
(ideally, an optimum assignment), via a linear program as described
in Table 4 below. With this approach, if all requests can be
satisfied, some vehicles may remain idle, saving fuel and distance
traveled (which may be, for example, the case at nighttime).
TABLE-US-00004 TABLE 4 1: Given: the idle (empty, stopped and
unassigned) vehicles V.sub.idle, and the unassigned requests
R.sub.ko. 2: Given: the shortest travel time T.sub.v,r for vehicle
v V.sub.idle to pick request r R.sub.ko. 3: Variables: Y =
.orgate..sub.v V.sub.idle,r R.sub.ko y.sub.v,r. Where y.sub.v,r
indicates individual assignments. 4: 5: .SIGMA..sub.rebalance :=
arg.sub.y.sup.min .SIGMA..sub.v v.sub.idle .SIGMA..sub.r R.sub.ko
T.sub.v,r y.sub.v,r 6: s.t. .SIGMA..sub.v v.sub.idle
.SIGMA..sub.Rko y.sub.v,r = min(|V.sub.idle|),|R.sub.ko|) 0
.ltoreq. y.sub.v,r .ltoreq. 1 .A-inverted.y.sub.v,r Y. 7: 8: 9:
Where |.| denotes the number of elements of a set. 10: The solution
of this Linear Program is also a solution of the Integer Linear
Program with y.sub.v,r {0, 1}.
[0145] FIGS. 3A and 3B illustrate an optimal route for a vehicle
with four passengers and an additional request.
[0146] FIG. 3A is an illustration of a geographic region having
2,000 vehicles, capacity of 4; (=5 min, Wednesday, 2000 hours).
Vehicle in the fleet are represented at their current positions.
Colors indicate number of passengers (0: light blue; 1: light
green; 2: yellow; 3: dark orange; 4: dark red); 39 rebalancing
vehicles are displayed in dark blue--mostly in the upper Manhattan
returning to the middle.
[0147] FIG. 3B is an enlarged view of a portion of the geographic
region illustrated in FIG. 3A showing a close view of the scheduled
path for a vehicle (dark red circle) with four passengers, which
drops one off, picks up a new one (blue star), and drops all four.
Drop-off locations are displayed with inverted triangles.
[0148] It should be noted that the number of variables in the ILP
is equal to the number of edges e(T, v) in the RTV-graph plus the
number of requests. In the worst case, the number of variables is
of order O(mnv) but only reached with complete RV- and RTV-graphs,
where all vehicles can serve all requests and all requests can be
combined with each other. In practice, the number of variables is
orders of magnitudes lower and related to the size of the cliques
in the RV-graph. The number of constraints is n+m.
[0149] If all of the steps are executed until termination and
exploration of all possible trips and assignments, the described
method guarantees optimality of the assignment of the currently
active requests, while satisfying the constraints Z. In practice,
timeouts can be set both for the amount of time spent generating
candidate trips for each vehicle and for the time spent exploring
the branches of the ILP. A limit on the number of vehicles
considered per request, the number of trips per vehicle, or the
optimality gap of the ILP can also be set. These timeouts trade
optimality for tractability, and the particular values selected
will depend upon the available resources. It should be noted that
the described method is reactive in the sense that it provides
anytime-optimality guarantees given the current state of the system
and the current requests. To inform the assignment and routing
about future demand, an additional cost term could be added to Eq.
1, and future requests could be sampled from historical data. The
method allows for parallelization in all steps.
[0150] In one illustrative system, the performance of a MoD fleet
controller using the technique described herein against real data
from an arbitrarily chosen representative week, from 0000 hours
Sunday, May 5, 2013, to 2359 hours, Saturday May 11, 2013, from a
publicly available dataset of taxi trips in Manhattan, New York
City is next described. This dataset contains, for each day, the
time and location of all of the pickups and drop-offs executed by
each of the 13,586 active taxis. From these data, all of the
requests (origin and destination within Manhattan) are extracted
and the time of request is considered equal to the time of pickup.
In this example, the complete road network of Manhattan (4,092
nodes and 9,453 edges) is considered, with the travel time on each
edge (road segment) of the network given by the daily mean travel
time estimate, computed using a conventional method which may be
the same as or similar to the method described in Santi P, et al.
(2014) Quantifying the benefits of vehicle pooling with
shareability networks. Proc Natl Acad Sci USA 111(37):13290-13294.
Shortest paths and travel times between all nodes are then
precomputed and stored in a lookup table.
[0151] In one simulation of the evolution of a taxi fleet, vehicles
were initialized at midnight at sampled positions from a historical
demand distribution and continuously travel to pick up and drop off
passengers to satisfy the real requests extracted from a dataset.
Requests were collected during a 30 second time window after which
the requested were assigned in batch to the different vehicles.
Past requests are kept in the requests pool until picked up and can
be reassigned if a better match is found before pickup. Each day
contains between 382,779 (Sunday) and 460,700 (Friday) requests,
and the running pool of requests contains up to 2,000 requests at
any given time. It such a simulation it has been found that the
system and methods described herein are robust both with respect to
the chosen time window and the density of demands. This is
particularly true with results having a time window between 10 and
50 seconds, and having half/double the amount of requests
(.about.220,000/.about.880,000 per day) in New York City.
[0152] Further, several metrics were analyzed, with different
vehicle fleet sizes (m 1,000, 2,000, 3,000} vehicles), vehicle
capacities (X {1, 2, 4, 10} passengers), and maximum waiting times
(.omega. {120, 300, 420} seconds). The maximum trip delay .DELTA.
is double the maximum waiting time and includes both the waiting
time .omega. and the inside-the-vehicle travel delay. The analysis
shows that, thanks to high capacity ride-sharing, a reduced fleet
of vehicles (below 25% of the active taxis in New York City) is
able to satisfy 99% of the requests, with a mean waiting time and
delay of about 2.5 min. All results include rebalancing of idle
vehicles to unassigned requests. Experimentally, it is observed
that the rebalancing process contributed an increase in the service
rate of about 20% and that high vehicle occupancy is achieved in
times of high demand, with a large number of the trips being
shared. It is observed that many vehicles are located in
mid-Manhattan and contain three or four passengers.
[0153] Referring now to FIGS. 4A-4D, shown are a series of plots of
mean number of passengers per vehicle vs. time for four different
vehicle types (capacity one, two, four, and ten). FIGS. 4A-4D show
four one-week time series for different fleet sizes and maximum
waiting time: (A) 1000 vehicles and =2 min; (8) 1000 vehicles and
=7 min; (C) 3000 vehicles and =2 min; and (D) 3000 vehicles and =7
min. At night, most vehicles wait, and during rush hour, the mean
occupancy decreases as the fleet gets larger. Larger maximum
waiting time enables more opportunities for ride-sharing.
[0154] FIGS. 4A-4D thus illustrate that occupancy depends upon the
fleet size, capacity, and the maximum waiting/delay time. Lower
fleet size, larger capacity and longer waiting/delay times increase
the possibilities for ride-sharing and lead to higher mean vehicle
occupancy.
[0155] FIGS. 5A, 5B illustrate the percentage of vehicles in each
state (waiting, rebalancing, and number of passengers) for a
representative day (Friday 0000 hours to 2400 hours). (A) A fleet
of 1,000 vehicles of capacity 10 with many opportunities for
ride-sharing in high-capacity vehicles. (8) A fleet of 2,000
vehicles of capacity four, showing the utility of full
vehicle-sharing.
[0156] In FIGS. 5A, 5B, it is observed that during peak hours, a
small fleet of high-capacity vehicles does indeed operate at high
occupancy. For a fleet of 1,000 vehicles of capacity 10, one
observes that, during peak time (1800 hours) of a Friday, 10% of
the vehicles have eight or more passengers, 40% of the vehicles
have six or more, 80% have three or more, and 98% have at least one
passenger. For a fleet of 2,000 vehicles of capacity four, it is
observed that, at the same peak time, over 70% of them have at
least three passengers onboard.
[0157] It is observed that the value of fleets with larger
passenger capacities increases with larger .OMEGA. and .DELTA.
values, as expected, because passengers are willing to incur a
larger personal time penalty. High-capacity vehicles are also more
important when the fleet size is smaller, because seating capacity
might be a bottleneck with smaller fleets.
[0158] It is also observed that increasing the vehicle capacity not
only increases the service rate but also reduces the mean distance
traveled by the vehicles in the fleet (FIG. 6D), potentially
leading to a reduction in costs, congestion, and pollution. It is
also observed that, with the method described herein (which may be
implemented as an online method), about 90% of the rides were
shared. The number of shared rides slightly increases with A and
decreases with the fleet size (FIG. 6E). Finally, it is noted that
the system and techniques described herein are real-time capable
(FIG. 6F). In the examples described herein, for 300 s, the method
is executed in less than 30 s, which is the period for which
requests are collected.
[0159] FIGS. 6A-6F are a series of plots which may be used to
compare several different performance metrics vs. maximum waiting
time for varying vehicle capacity (1, 2, 4, and 10 passenger) and
varying fleet sizes (fleet sizes of 1,000, 2,000, and 3,000
vehicles).
[0160] It should be appreciated that each of FIGS. 6A-6E include
three subplots. The subplots included in each of FIGS. 6A-6E are
for fleet sizes of 1,000, 2,000, and 3,000 vehicles, respectively.
The coordinate axes show increasing maximum waiting time .OMEGA. of
2, 5, and 7 min.
[0161] FIG. 6A is a plot of percent of serviced requests vs.
maximum waiting time for varying vehicle capacity (1, 2, 4, and 10
passenger) and varying fleet sizes (fleet sizes of 1,000, 2,000,
and 3,000 vehicles).
[0162] As illustrated in FIG. 6A, a fleet of 1,000 vehicles with a
capacity of 10 can satisfy almost 80% of the requests with=420 s,
compared with below 30% for a single-rider taxi, for a net gain of
over 50%. However, with a larger fleet of 3,000 vehicles and =120
s, the benefit is only about 15%. Interestingly, if longer waiting
times and delays are allowed, =420 s, a fleet of 3,000 vehicles
with a capacity of 2, 4, and 10 could serve 94, 98, and 99% of the
demand. To achieve 98% service rate, a fleet of just 2,000 vehicles
with a capacity of 10 was required, which represents a reduction of
the fleet size to 15% of the active taxi fleet in New York
City.
[0163] FIG. 6B is a plot of average in car delay .delta.-.omega.
vs. maximum waiting time for varying vehicle capacity (1, 2, 4, and
10 passenger) and varying fleet sizes (fleet sizes of 1,000, 2,000,
and 3,000 vehicles).
[0164] FIG. 6C is a plot of average waiting time .omega., vs.
maximum waiting time for varying vehicle capacity (1, 2, 4, and 10
passenger) and varying fleet sizes (fleet sizes of 1,000, 2,000,
and 3,000 vehicles).
[0165] As expected, the in-car travel delay does increase with the
increase in vehicle capacity (FIG. 6B). Nonetheless, that increase
seems practically negligible--well below 100 s--once ride-sharing
is allowed. Furthermore, the mean waiting time does in fact
decrease as vehicle capacity is increased (FIG. 6C). For a fleet
size of 1,000 vehicles and =420 s, high-capacity vehicles not only
improved the service rate but also achieved a reduction in mean
waiting time of over 100 s, which partially offsets the increased
in-car delay. In particular, one observes that 3,000 vehicles with
a capacity of 2 and 4 could serve 94 and 98% of the demand, with a
mean waiting time of 3.2 and 2.7 min and a mean delay of 1.5 and
2.3 min, respectively. To achieve 98% service rate, with comparable
waiting time (2.8 min) and delay (3.5 min), a fleet of just 2,000
vehicles with a capacity of 10 was required.
[0166] FIG. 6D is a plot of average distance traveled by each
vehicle during a single day vs. maximum waiting time for varying
vehicle capacity (1, 2, 4, and 10 passenger) and varying fleet
sizes (fleet sizes of 1,000, 2,000, and 3,000 vehicles).
[0167] FIG. 6E is a plot of percentage of shared rides (number of
passengers who shared a ride divided by the total number of
picked-up passengers) vs. maximum waiting time for varying vehicle
capacity (1, 2, 4, and 10 passenger) and varying fleet sizes (fleet
sizes of 1,000, 2,000, and 3,000 vehicles).
[0168] FIG. 6F is a plot of average computational time for a thirty
(30) second iteration of the method in a 24 core 2.5 GHz machine,
including computation of the RV-graph, computation of the
RTV-graph, ILP assignment, rebalancing, and data writing (higher
levels of parallelization would drastically reduce this
computational time).
[0169] In summary, FIGS. 6A-6F illustrate an analysis of: service
rate (percentage of requests serviced) (A), average in car delay
.delta.-.omega.(B), average waiting time .omega. (C), average
distance traveled by each vehicle during a single day (D),
percentage of shared rides (number of passengers who shared a ride
divided by the total number of picked-up passengers) (E), and
average computational time for a 30-s iteration of the method (F),
in a 24 core 2.5 GHz machine, including computation of the
RV-graph, computation of the RTV-graph, ILP assignment,
rebalancing, and data writing (higher levels of parallelization
would drastically reduce this computational time).
[0170] Some parameters used in the simulations described herein are
next described.
[0171] In practice, a time-out can be set both for the amount of
time spent generating candidate trips for each vehicle, and for the
amount of time spent exploring the branches of the ILP.
Alternatively, one may set a limit on the number of vehicles
considered per request, the number of candidate trips per vehicle
or the optimality gap of the ILP. These timeouts trade-off
optimality for tractability and their values will depend upon the
available resources.
[0172] To achieve real-time performance it may be necessary to
employ a set of timeouts. If allowed to progress past the selected
timeout, the method would eventually find the optimal
assignment.
[0173] In one embodiment, one may implement the function travel (T;
v), which computes the optimal route for given trip T and vehicle
v, as follows. If the number of passengers and requests is less or
equal than four, one perform an exhaustive search to compute the
optimal route which satisfies the constraints. If the number of
passengers is greater than four, for each additional request one
only check the routes that maintain the order of the current
passengers in the vehicle.
[0174] In the computation of the RV-graph one may set limits on the
number of edges. In particular, one compute the complete graph and,
for each request, one keep a maximum of 30 links with candidate
vehicles, in particular those of lowest trip cost. Speed-ups such
as the ones proposed in T-share [4] could be employed in this stage
to prune the most likely vehicles to pick up a request.
[0175] In the computation of the RTV-graph one may specify a
maximum amount of time, per vehicle, to explore potential trips and
add edges to the graph. In particular, one used a timeout of 0:2
seconds per vehicle. This leads to sub-optimality of the solution,
but faster computation, removing longer trips.
[0176] It should be appreciated that the ILP can be solved with
state of the art solvers. For example, a MOSEK Optimization Solver
from MATLAB may be used. In an embodiment, a MOSEK solver may be
used with an optimality gap of 0.1% and a maximum run time of 15
seconds. The MOSEK solver employs heuristics in the exploration of
the branches of the problem. Other solvers having the same or
similar capabilities, may of course, also be used.
[0177] Referring now to FIG. 7, a ride sharing system for assigning
ravel requests for vehicles and finding optimal routes for one or
more vehicles within a fleet of vehicles in response to one or more
ride requests includes a MoD fleet controller 702 in communication
with one or more vehicles 704a-704k, generally denoted 704, and one
or more persons wishing to ride share 705a-705N ang generally
denoted 705, through a network 706. Network 706 may, for example,
be an internet or any other type of network capable of supporting
communication between MoD fleet controller 702 and vehicles and
ride sharing persons 704, 705.
[0178] The MoD fleet controller includes an interface 708 to the
vehicles and requesters. In response to requests provided thereto
through interface 708, travel requests are stored in a travel
request memory. The travel request may include at least a timer
request, a pickup location and a drop off location. Other
information may also be part of the travel request such as the
number of persons in the party requesting travel. Vehicle 705
provides vehicle status information which is stored in memory 712.
The memories 710, 712 are coupled to an assignment processor
714.
[0179] In response to the travel request information and vehicle
status information provided thereto, the assignment processor
assigns travel requests to vehicles and/or finds optimal routes for
each assigned vehicle in accordance with the techniques described
hereinabove in conjunction with FIGS. 1-6F.
[0180] MoD fleet controller 702 further includes a vehicle plan
memory 718 which receives information via interface 708 and which
has two-way communication paths with the assignment and rebalancing
processors 714, 716. Planned path memory 718 receives and stores
planned path and pickup/drop-off schedules for occupied vehicles.
For example, for vehicles with occupants denoted 707, information
related to a planned path and drop-off/pickup schedule is stored in
a memory 718. Thus, MoD fleet controller is able to track and
process information related to travel requests, vehicle status and
planned path and drop-off/pickup schedules. This information may be
used by assignment and rebalancing processors to track vehicle
paths (for example) and use such information in future
request-vehicle assignments as well as in the rebalancing
process.
[0181] In embodiments, MoD fleet controller 702 may also further
include a rebalancing processor 716. Upon completion of one or more
assignments, it is possible that more vehicles are located in a
region having less requests than are needed for the number of
vehicles in that location. For example, such imbalances may occur
when idle vehicles are in areas far away from an area of current
requests and/or due to the maximum waiting time and/or delayed
constraints and/or vehicle capacity. To rebalance the vehicle
fleet, upon completion of one or more assignments some vehicles are
geographically repositioned to a location which allows all travel
requests to be serviced while reducing and ideally minimizing
travel times.
[0182] Next described is a method and system for vehicle routing
and multi-request multivehicle assignment that takes into account a
prediction of the future demands. Before describing such a method
and system is detail, some introductory notations employed
throughout the below description as well as problem formulation and
an overview of the method and system are described.
[0183] Considered herein is a fleet V of m vehicles of capacity v,
the maximum number of passengers each vehicle can have at any given
time. A set of vehicles V is denoted as V={.upsilon..sub.1, . . . ,
.upsilon..sub.m}. The current state of a vehicle .upsilon. is given
by a tuple {q.sub..upsilon., t.sub..upsilon., P.sub..upsilon.}
indicating its current position q.sub..upsilon., the current time
t.sub..upsilon. and its passengers P.sub..upsilon.={p.sub.1, . . .
, p.sub.n.sub..upsilon..sub.pass}. A passenger p is a request that
has been picked-up by a vehicle.
[0184] Also considered are a set of travel requests (or more simply
"requests") ={r.sub.1, . . . , r.sub.n}. Where each travel request
comprises the time of request, a pick-up location and a drop-off
location. Formally, a request r is defined by a tuple for;
{o.sub.r, d.sub.r, t.sub.r.sup.r, t.sub.r.sup.pl, t.sub.r.sup.p,
t.sub.r.sup.d, t.sub.r*}, indicating its origin o.sub.r, its
destination d.sub.r, the time of the request t.sub.r.sup.r, the
latest acceptable pick-up time t.sub.r.sup.pl (initially given by
t.sub.r.sup.pl=t.sub.r.sup.r+.OMEGA. with .OMEGA. the maximum
waiting time), the pick-up time t.sub.r.sup.pl, the expected drop
off time t.sub.r.sup.d, and the earliest possible time at which the
destination could be reached t.sub.r*=t.sub.r.sup.r+.tau.(o.sub.r,
d.sub.r).
[0185] Given a graph of the streets with estimated travel times, a
function .tau.(q.sub.1, q.sub.2) computes the travel time from
q.sub.1 to q.sub.2, two positions in space encoded by their
latitude and longitude coordinates. When a network representation
of the map is available, standard techniques for efficiently
computing shortest paths can be used.
[0186] Further a trip T may be defined as T={r.sub.1, . . . ,
r.sub.n.sub.t} as a set of requests that can be combined and served
by a single vehicle. A trip may have one or more candidate vehicles
for execution and contain more requests than the capacity of the
vehicle if they are picked and dropped off in a way that the
capacity limit is satisfied at all times.
[0187] With respect to problem formulation a first problem
(referred to herein as problem 1 or the problem of informed batch
assignment) may be formulated as follows by considering a set of
requests R, a set of vehicles V at their current state including
passengers, and a function to compute travel times on the road
network. Compute an optimal assignment .SIGMA. of requests to
vehicles may be computed that satisfies a set of constraints Z,
including a maximum capacity v of passengers per vehicle, and that
minimizes a cost function C=C.sub.now+C.sub.future, where C.sub.now
could be the sum of travel delays for the current passengers and
requests and C.sub.future is a term which includes the cost of
satisfying future predicted travel requests.
[0188] The formulation is flexible with respect to physical and
performance-related constraints Z. In one illustrative
implementation the following performance-related constraints are
considered: for each request r, the waiting time w.sub.r, given by
the difference between the pick-up time t.sub.r.sup.p, and the
request time t.sub.r.sup.r, must be below a maximum waiting time
.OMEGA., for example 5 minutes; for each request r (or passenger p)
the total travel delay
.delta..sub.r=t.sub.r.sup.d-t=t.sub.p*(.delta..sub.p=t.sub.p.sup.d-t.sub.-
p*) must be lower than a maximum travel delay .DELTA., for example
10 minutes, where t.sub.r.sup.d is the drop-off time and
t.sub.r*=t.sub.r.sup.r+.tau.(o.sub.r, d.sub.r) t is the earliest
possible time at which the destination could be reached if the
shortest path between the origin or and the destination d.sub.r was
followed without any waiting time while the total travel delay
.delta..sub.r includes both the in-vehicle delay and the waiting
time; and for each vehicle v, a maximum number of passengers,
n.sub.v.sup.pass.ltoreq.v, for example capacity ten.
[0189] Ideally, all requests shall be assigned to a vehicle, but
given the constraints, this might not always be the case. The set
of requests assigned to a vehicle may be denoted as .sub.ok and the
set of requests that are not served by any vehicle as .sub.ko.
[0190] The cost C.sub.now of an assignment may be defined as a sum
.SIGMA. of travel delay over all passengers P and all assigned
requests plus a large enough cost c.sub.ko for each non-assigned
request. This may be expressed as shown in Equation (1).
C now ( .SIGMA. ) = p .di-elect cons. ( t p d - t p * ) + r
.di-elect cons. ok ( t r d - t r * ) + r .di-elect cons. ko c ko (
1 ) ##EQU00004## [0191] in which: [0192] C.sub.now is the cost of
an assignment [0193] .sub.ok is the set of requests assigned to a
vehicle; [0194] .sub.ko is the set of requests that are not served
by any vehicle; [0195] t.sub.r.sup.d is the expected drop off time;
[0196] t.sub.r* is the earliest possible time at which the
destination could be reached if the shortest path between the
origin or and the destination d.sub.r was followed without any
waiting time; [0197] P represents the set of all passengers; and
[0198] C.sub.ko is the cost of a non-assigned request.
[0199] To account for the future performance of the system, a new
term C.sub.future, is introduced which is the expected cost of
serving future requests (see Equation (7) below). This cost term is
based upon the predicted future demand with the objective of
achieving a better routing and assignment of the fleet towards the
future requests. This will be discussed in further detail
below.
[0200] For real-time fleet management, the method can be applied to
continuous discovery and assignment of incoming requests. The
described approach is to perform batch assignment of the requests
to the fleet of vehicles within a defined period of time (and
preferably a short time span, for example every 30 seconds).
Problem 1 is invoked with the predicted state of the fleet at the
assignment time and the cumulated requests. Requests that have not
been picked-up by a vehicle within the previous assignment round
are kept in the pool for assignment.
[0201] The method includes first estimating a number of requests
from origins of interest to destinations of interest in a given
geographic area in a given period of time. In one illustrative
embodiment, such estimating may be accomplished by estimating, for
at least portions of each time of the day (e.g. for certain
particular times of a day) and for at least some days of the week
the amount (i.e. the number) of requests from at least some origins
(or in some cases even each origin) in the geographic area (e.g. a
city) to at least some destinations (or some cases even each
destination) in the geographic area. In some embodiments, such
estimating may be accomplished by estimating, each time of the day
and for each day of the week, the amount of requests from each
origin in the city to each destination. This is a probability
distribution and, in some embodiments, may be computed from
historical data.
[0202] Once the probability distribution is computed, the method
also comprises solving the informed batch assignment problem
(referred to above as "Problem 1"). To do this, during assignment
rounds (e.g. at each assignment round) future requests are sampled
from the probability distribution. Such future request samples are
then introduced into the assignment and routing problem. It should
be noted that in embodiments, such future request samples are
introduced into the assignment and routing problem with lower cost
than the real or actual requests.
[0203] In general overview and with reference to FIG. 8 which will
be described in detail below, shown is a system for performing an
anytime optimal process for batch assignment of a set of requests
R={r.sub.1 . . . r.sub.n} to a set of vehicles V={v.sub.1 . . .
v.sub.m}, which: (1) reduces (and ideally minimizes) a cost
function C (to be described below); (2) satisfies a set of
constraints Z (to be described below); (3) allows for multiple
passengers per vehicle; and (4) accounts for future requests. It
should be appreciated that the fleet may be the entire set of
vehicles but need not be (i.e. the set of vehicles may be some or
all of the fleet of vehicles). Also included in a process performed
by the system at FIG. 8, is an optional process to rebalance a
fleet of vehicles (to which the set of vehicles V belongs). It
should be appreciated that rebalancing can be done on the entire
fleet of vehicles or less than the entire fleet of vehicles. For
example, rebalancing may be done on just the set of vehicles V by
driving idle vehicles to areas of high demand, where those vehicles
are likely to be required in the future.
[0204] Referring now to FIG. 8 is a schematic overview of an
illustrative system and method for batch assignment of multiple
requests to multiple vehicles of capacity v. The method executed by
the system comprises several steps leading to an integer linear
optimization which provides an anytime optimal assignment.
Significantly, the system and method includes the addition of
predicted future requests and a modified formulation of the ILP
assignment.
[0205] Turning now to FIG. 8, the system and method for batch
assignment of multiple ride requests to multiple vehicles of
capacity v while taking into account a prediction of the future
demands for vehicle routing and multi-request multivehicle
assignment begins as shown in processing blocks 10, 12 and 13 in
which one or more travel requests 12, one or more indicators of
vehicle status 12 and one or more prediction requests 13 are
received in a processing element 14'. Each travel request (and in
at least in some embodiments prediction requests) includes at least
a time of request, a pickup location and a drop-off location. The
number of vehicles for which a vehicle status is received may be
some or all of the vehicles in the fleet.
[0206] After receipt of at least some travel requests and vehicle
status indicators, a pairwise request-vehicle graph (RV-graph)
processor 14' forms a pairwise request-vehicle graph (RV-graph). As
described above in conjunction with FIGS. 1-7, such an RV-graph
represents which requests and vehicles might be pairwise-shared,
and significantly, also includes the vehicles at their current
state and may also account for prediction requests.
[0207] A round trip vehicle graph (RTV graph) processor 16'
receives the RV-graph information from RV-graph processor 14' and
proceeds to generate an RTV graph which takes into account
prediction requests. In particular, cliques of the RV-graph (or
regions for which its induced subgraph is complete) are explored to
find feasible trips and are used to compute the RTV-graph in a
manner which may be the same as or similar to that described
hereinabove excepting that prediction requests are included when
generating the RTV-graph. Suffice it here to say that the RTV-graph
is used to determine if a trip is feasible (i.e. the RTV-graph is
used to determine whether all of the requests can be picked up and
dropped off by some vehicle, while satisfying one or more
constraints).
[0208] RTV graph processor 16' then provides RV-graph information
to an assignment processor 18' in which assignment problem Integer
Linear Program (ILP) processing is performed (while again taking
into account prediction requests). In embodiments, an anytime
optimal technique may be used for batch assignment of a set of
requests R={.sub.1 . . . r.sub.n} to a set of vehicles V={.sub.1 .
. . v.sub.m} which: (1) optimizes (and ideally minimizes) a cost
function C; (2) satisfies a set of constraints Z; (3) allows for
multiple passengers per vehicle; and (4) takes into account future
predicted requests.
[0209] Solutions from the ILP processor 18' are provided to an
assignment processor 20' in which assignment processing (i.e. the
actual assigning of requests to vehicles while also taking into
account prediction requests) is performed.
[0210] Solutions from the ILP processor 18' may also optionally be
provided to a rebalancing processor 22' where rebalancing is
performed. Such rebalancing also takes into account prediction
requests and is accomplished, at least in part, by moving idle
vehicles to areas in which those vehicles are likely to be required
in the future (i.e. so-called "areas of high demand"). In
embodiments, "regions of high demand" may generally be defined as
regions where there are more requests than those that can be
serviced with the vehicles in the region. It should be appreciated
that the concepts and techniques described herein need not consider
specifically defined regions, but rather do an assignment of "idle"
vehicles to "ignored" requests, where an ignored request is a
request that was not assigned to any vehicle in the assignment
step. Details of rebalancing are described hereinbelow.
[0211] It should also be appreciated that in some instances, it may
be possible that only assignment processing is required while in
other instances it may be possible that only rebalancing processing
while in still other instances assignment processing and
rebalancing processing may both be required.
[0212] It should also be appreciated that all or some of at least
processors 14', 16', 18', 20' may be part of a single processor
714' which may be the same as or similar to processor 714 described
in conjunction with FIG. 7 described above. Alternatively,
processors 14', 16', 18', 20' may be provided as two or more
distributed processors. However, regardless of whether a fleet
controller system includes a single processor (e.g. a central
processor) or several processors (e.g. several distributed
processors) the system can still perform the functionality and
operations required to assign, direct and control one or more
vehicles within a fleet of vehicles.
[0213] Referring now to FIG. 8A, shown is an example of a street
network with two requests (humans 802, 804), two predicted requests
(806, 808) and two vehicles 810, 812. In this example, vehicle one
810 has one passenger 814 with a destination 814a and vehicle two
is empty.
[0214] Humans 802, 804 define the origins of a trip while triangles
802a, 804a identify the respective destinations. Similarly, humans
806, 808 define the origin of the two predicted requests while
triangles 806a, 808a identify the respective destinations of the
predicted requests.
[0215] Referring now to FIG. 8B, shown is an example of a pairwise
shareability RV-graph generated by an RV processor such as the RV
processor 14' of FIG. 8. The RV-graph processor 14' generates an
RV-graph of requests and vehicles as illustrated in FIG. 8A.
Cliques of this graph are potential trips.
[0216] Referring now to FIG. 8C, shown is an example of an
RTV-graph generated by an RTV processor such as the RTV processor
16' of FIG. 8. The RTV-graph shows candidate trips and vehicles
which can execute them. A node 820 (triangle) is added for requests
that cannot be satisfied.
[0217] Referring now to FIG. 8D, shown is an example of optimal
vehicle-passenger assignment given by the solution of an ILP
processor such as the ILP processor 18' of FIG. 8, where vehicle 1
serves requests 2 and 3 and vehicle 2 serves requests 1 and 4.
[0218] Referring now to FIG. 8E, shown is an example of a planned
route for the two vehicles and their assigned requests. The
predicted requests 806, 808 alter the routes of vehicles 810, 812
such that the vehicles drive towards areas of likely future
requests;
[0219] Referring now to FIG. 9 within a fleet of vehicles taking
into account future predicted request begins in processing block
902 in which a probability distribution over future demand is
computed. One illustrative embodiment of such a process is
described in detail below in conjunction with FIG. 11.
[0220] Processing then proceeds to processing block 904 in which
samples are selected from the probability distribution. Once the
samples are selected, processing proceeds to processing block 906
in which the selected samples are incorporated into a vehicle
routing method and passenger assignment to take into account
predicted future demand. Processing then proceeds to processing
block 908 in which the position of one or more vehicles within the
fleet of vehicles are adjusted to satisfy future requests (e.g.
vehicles are positioned taking into account future requests).
[0221] Referring now to FIG. 10, in general overview, the
assignment and routing method may be said to include: computing a
pair-wise request-vehicle shareability graph (RV-graph) in which
requests r, predicted requests r.sup.pred and vehicles v are
pairwise connected if r, or r.sup.pred, can be satisfied by v
within the defined constraints and given the current state of v;
computing a graph (RTV-graph) of feasible trips (formed by one or
more requests and/or predicted requests) and the vehicles that can
serve them within the specified constraints; solving an Integer
Linear Program (ILP) to compute the best assignment of vehicles to
trips; and rebalancing the remaining idle vehicles towards areas
with a deficit of vehicles and too many request via a Linear
Program (LP).
[0222] Given that the problem at hand is NP hard, obtaining an
optimal (or near-optimal) assignment can be computationally
expensive. For practical applications, it is required that a
sub-optimal solution is returned within an allocated runtime
budget, which might be improved incrementally up to optimality. The
system and technique described herein provides such an
"anytime-optimal" property while taking into account future
predicted requests.
[0223] To take into account future processing requests, a
preprocessing step 1002 is performed. In the preprocessing step, a
probability distribution of origin-destination requests is computed
for fixed intervals. Such fixed intervals may be selected to suit
the needs of a particular application. For example, such fixed
intervals may correspond to fixed intervals of the week. In
embodiments, the probability distribution is computed by
discretizing a desired geographic area into regions and cumulating
requests from historical data. In one embodiment, requests were
cumulated over a year of historical taxi data. Other techniques for
determining a probability distribution may also be used.
[0224] Referring now to FIG. 11, a method for determining a
probability distribution of origin-destination requests for fixed
intervals of time begins as shown in processing block 1102 in using
a list of all intersections, the geographic area of interest is
discretized into one or more regions given by a selected distance
parameter r. In embodiments, the selected distance parameter r
relates to a distance a person would need to walk (e.g. a distance
deemed to be an acceptable walking distance meaning a distance it
can be reasonably expected a person would walk). The range of an
what is an acceptable walking distance is, of course, subject to
many factors including, but not limited to environmental factors
(e.g. wind, rain, snow) and as well as personal preference (related
to age, fitness, disability, etc. . . . ). Those of ordinary skill
in the art, after reading the disclosure provided herein, will
appreciate how to select a range parameter r to suit the needs of a
particular application. For example, if the system is operating in
an assisted living community, then range parameter r may be
selected having a value which different than if the system were
operating on or near a college campus (where the assumption may be
that persons in an assisted living community would not want to walk
(or may not be able to walk) the same distance as a person on a
college campus.
[0225] With this discretization, processing then proceeds to
processing block 1104 in which the origin and destination of the
requests from the historical data can be assigned to the closest
region centers.
[0226] As shown in processing block 1106 a predetermined time
interval is selected to satisfy needs of a particular application.
In one illustrative embodiment, the time interval is selected as
the factors to consider in selecting a time interval include, but
are not limited to
[0227] As shown in processing block 1108 using a frequentist
approach, for each selected time interval, (e.g. for each 15-minute
interval of the week), the number of requests going from origins to
destinations are counted. In embodiments, the number of requests
going from every origin region to every destination region are
counted.
[0228] This information is used to determine trip frequency (which
may, for example, be collected and possibly stored in a frequency
table).
[0229] As shown in processing block 1110, with this data (e.g. the
trip frequency table data), it is possible to determine (e.g. with
a processor) the probability of a given destination region given
the origin region, time interval, and day of the week.
[0230] In embodiments, the discretization of a geographic area into
regions may be accomplished as follows: given a list C of all the
intersections in a road network of a geographic region (e.g. a
city, a set of regions may be computed such that in the resulting
list no two centers are within a given radius, r, of each other,
i.e. .A-inverted.,j C, .parallel.-j.parallel.>r. The technique
of Table 1 may be employed where BALLTREE is a space partitioning
data structure that allows for fast radius bounded nearest neighbor
lookup. The data structure has query function, QUERY(c,r), that
lets us find all the points within r of a point c.
TABLE-US-00005 TABLE 1 1: .rarw. BALLTREE (C) 2: for c C do 3: C
.rarw. C | QUERY(c,r) 4: end for
[0231] FIG. 12 is a diagrammatic view of a geographic area having
region centers determined by a greedy station method.
[0232] Referring now to FIG. 12, shown are centers of regions from
a discretization of a geographic area. In this illustrative
embodiment, the geographic area is Manhattan and a radius of 150
meters was used. In this illustrative embodiment, the region
centers were determined by a greedy station technique. Other
techniques, may of course, also be used.
[0233] In embodiments, a probability distribution may be determined
as follows: given the set of region centers, a probability
distribution, P(d|p;.xi.,w) which is the probability of destination
region d, may be constructed given the origin region p, time
interval .xi., and day of the week w. In an illustrative
embodiment, each day is partitioned into 15-minute intervals
resulting in 1.ltoreq..xi..ltoreq.96.
[0234] As noted above, in some embodiments, the probability
distribution can be generated via a frequentist approach. In one
illustrative embodiment, one year of historical taxi data
comprising 165,114,362 trips was used. Each trip contained the
origin and destination coordinates along with the time and date of
the pickup. Using this data, it is possible to populate a
96.times.7.times.|C|.times.|C| table, , indexed by the time
interval, day of the week, origin region, and destination region
with the number of times a given trip occurred. This allows the
probability of a destination to be determined given the origin and
a time period. The time period is defined as an initial and final
time interval and the day of the week, I=(.xi..sub.0,.xi..sub.1,w)
resulting in the probability distribution of origin-destination
P ( d , p | I ) = P ( p | I ) P ( d | p , I ) where ( 2 ) P ( p | I
, w ) = .xi. = .xi. 0 .xi. 1 i = 1 C .xi. , w , p , i .xi. = .xi. 0
.xi. 1 i = 1 C j = 1 C .xi. , w , i , j and ( 3 ) P ( d | p , I , w
) = .xi. = .xi. 0 .xi. 1 .xi. , w , p , d .xi. = .xi. 0 .xi. 1 i =
1 C .xi. , w , p , i ( 4 ) ##EQU00005##
[0235] Referring now to FIG. 13, shown is an example of predicted
demand for two fixed origins and two different time periods. From
this probability distribution, future requests can be sampled to
anticipate demand.
[0236] FIGS. 13A-BF are a series of heatmaps depicting the
destination demand distribution. For this example, two locations in
Manhattan (Westside and Eastside) are used as origins with a
30-minute time interval to show the distribution. For each
location, two time intervals are used to show different snapshots
of the demand throughout the day. FIG. 13A illustrates Manhattan
Westside for the time window of 7:30-8:00 while FIG. 13B
illustrates Manhattan Westside for the time window of 21:30-22:00.
Similarly, FIG. 13C illustrates Manhattan Eastside for the time
window of 7:30-8:00 while FIG. 13B illustrates Manhattan Westside
for the time window of 21:30-22:00. Cross-hatched regions indicate
regions with the highest demand. while stippled (or dotted) regions
indicating areas of next highest demand.
[0237] Consider a given period of time (.xi..sub.0,.xi..sub.1) and
day of the week, w. A list S, comprised of the cumulative sum of
frequencies from the start time to the end time and another list ,
of the same size, comprised of the corresponding origin-destination
pairs may be constructed. To sample requests, a random number s,
from 0 to max(S) is generated and the index i of S such that
S.sub.i-1.ltoreq.s.ltoreq.S.sub.i is determined. A value Li which
is the corresponding origin-destination pair of the cumulative sum
of frequencies interval is returned. An illustrative process is
shown in Table 2. This process, allows samples to be drawn from
(I). The function RAND(0;N) returns a uniformly distributed random
number from 0 to N. FINDINTERVAL(S, s) returns the index i such
that S.sub.i-1.ltoreq.s.sub.i.ltoreq.s.ltoreq.S.sub.i if
s>S.sub.o, otherwise it returns 0. This is done using binary
search since S is sorted.
TABLE-US-00006 TABLE 2 1: S.rarw. { }, L.rarw. { } 2: for .xi.
.di-elect cons. [.xi..sub.0, .xi..sub.1] do 3: for (pd) .di-elect
cons. [1,|C|}.sup.2 do 4: S .rarw. S.orgate. {max{S} +
F.sub..xi.,w,p,d}| 5: L .rarw. L.orgate. {(p,d)} 6: end for 7: end
for 8: s .rarw. RAND (0, max(S)) 9: i .rarw. FINDINTERVAL (S, s)
10: return .sub.i
[0238] The goal is to bias the vehicles towards areas where future
requests are more likely to appear. The method takes into account
the current state of the fleet, the current set of requests, as
well as the predicted demand, comprised of both origins and
destinations. The method computes a batch assignment of the current
requests in the requests pool R to the vehicles of the fleet V. For
real scenarios with incoming requests, this routing and assignment
is performed at a constant frequency. In embodiments, this constant
frequency may be once every 30 seconds. Other time intervals, may
of course also be used. The particular time interval to use in any
particular application may be selected in accordance with a variety
of factors related to the needs of a particular application.
[0239] With respect to the system of FIG. 8, it should be
appreciated that in one embodiment, in each iteration of the batch
optimizer, a set of additional requests R.sub.future are sampled
from a historical probability distribution of future demand as
described above. First, a time interval is defined for the
predictions I.sub.pred=[t.sub.now, t.sub.pred, w], where t.sub.now
is the current time and t.sub.pred a time in the future. In one
illustrative embodiment, the time in the future t.sub.pred is set
to t.sub.now+1800s for an interval of 30 minutes in the future, and
w is the day of the week. Also defined are a maximum number of
samples n.sub.pred.sup.max.
[0240] At run time, the number of samples is given by
n.sub.pred=min(n.sub.pred.sup.max,E(D(I.sub.pred))), (5)
[0241] where E(D(I.sub.pred)) denotes the number of expected
request in interval I.sub.pred, given the distribution D estimated
as described above, for example.
[0242] Each future request n.sub.i.sup.pred .sub.future is sampled,
via the technique shown in Table 2, from D and the time
interval,
r.sub.i.sup.pred.about.D(I.sub.pred). (6)
[0243] At each time step, after each batch assignment, the set
R.sub.future is cleared. New future requests will be sampled in the
following time step, every 30 seconds in some embodiments.
[0244] These requests are added to the pool of requests 30
:=+R.sub.future for the current iteration (and removed afterwards).
Vehicles can then be matched with trips containing future requests
in .sub.future and may make progress towards them (although they
cannot be picked since they are virtual). The additional requests
.sub.future are subject to the same constraints Z as the real
requests , and enter the assignment problem via the additional term
in the optimization cost C.sub.future. Following Eq. (1), this term
is defined as (shown in Equation (7):
C future ( .SIGMA. ) = r .di-elect cons. ok pred ( t r d - t r * )
+ r .di-elect cons. ko pred c ko pred , ( 7 ) ##EQU00006##
where .sub.ok.sup.pred is the set of assigned future requests and
.sub.kp.sup.pred the set of unassigned future requests, such that
.sub.ok.sup.pred.orgate..sub.ko.sup.pred=.sub.future.
[0245] The cost of a future request being ignored satisfies
C.sub.ko.sup.pred<<c.sub.ko, much lower than that of real
requests. This process gives preference to real requests, with a
bias in the assignment and routing towards servicing areas of
higher expected future demand.
[0246] The batch assignment technique comprises: sampling a set of
requests .sub.future.about.D; computing a pair-wise request-vehicle
shareability graph (RV-graph) between the requests + and the
vehicles V; in this graph, request r and vehicle v are connected
if, given the current state of v, request r can be satisfied by v
while respecting the defined constraints Z for maximum waiting
time, delay and vehicle capacity; computing a graph (RTV-graph) of
feasible trips (formed by one or more requests) and the vehicles
that can serve them within the specified constraints; each trip may
contain both real and predicted requests; feasible trips are
computed incrementally for each vehicle. Each trip is linked in the
graph to the requests that form it and the vehicles that can serve
it while respecting the constraints Z; computing a greedy
assignment .SIGMA..sub.greedy, where trips are assigned to vehicles
iteratively in decreasing size of the trip and increasing cost (the
idea is to maximize the amount of requests served while minimizing
cost);starting from the greedy assignment, solve an Integer Linear
Program to compute an optimal assignment .SIGMA..sub.optim of
vehicles to trips, and therefore to requests.
[0247] As described above in conjunction with FIGS. 1-7, a binary
variable is added for each link between a feasible trip and a
vehicle that can execute it within the RTV-graph; this assignment
also provides the optimal routes, as computed in the RTV-graph; and
rebalancing the remaining idle vehicles towards areas with a
deficit of vehicles and too many requests via a Linear Program; the
idle vehicles are assigned to the unassigned requests of the
previous step.
[0248] Following the notation described above in conjunction with
FIGS. 1-7, the new Integer Linear Program (fifth step of the
method, see the technique of Table 3) comprises the following
binary variables
.chi.={ .sub.i,j,.chi..sub.h;.A-inverted.(T.sub.i,.upsilon..sub.j)
edge in RTV-graph, .A-inverted.r.sub.k .sup.+}.
[0249] From Eq. (1) and Eq. (7) the cost terms c.sub.i,j are given
by the sum of delays for all the passengers and requests associated
to a trip T.sub.i, as served by a vehicle v.sub.j
c i , j = r .di-elect cons. T = t , V = j R ( t r d - t r * ) + p
.di-elect cons. V = j P ( t p d - t p * ) , ( 8 ) ##EQU00007##
TABLE-US-00007 TABLE 3 1: Initial guess: .SIGMA..sub.greedy 2:
optim := arg .chi. min i , j TV c i , j i , j + ##EQU00008## 3: 1
.ltoreq. k .ltoreq. n c k o X k + n + 1 .ltoreq. k .ltoreq. n + n
pred c k o pred X k ##EQU00009## 4: s . t . i V = j T i , j
.ltoreq. 1 .A-inverted. V j V ##EQU00010## 4: i .tau. R = k T J
.tau. T = i V i , j + .chi.k = 1 .A-inverted. r k R +
##EQU00011##
[0250] where T.sub.V=i.sup.R, v=j denotes the requests in trip
T.sub.i as served by vehicle v.sub.j, and .sub.V=j.sup.P the
passengers of vehicle v.sub.j. The optimal assignment is obtained
by solving the ILP of technique Table 3. Recall that:
.epsilon..sub.TV denotes the edges between a trip T.sub.i and a
vehicle v.sub.j in the RTV-graph (i.e. there exists a route for
which vehicle v.sub.j can serve trip T.sub.i within the given
constraints Z) .sub.V=j.sup.T denotes the trips that can be served
by vehicle .sub.T=i.sup.V denotes the trips (combinations of
requests) in which request r.sub.k can be served; and
.sub.T=i.sup.V denotes the vehicles that can serve trip
T.sub.i.
[0251] After assignment and routing, the vehicles make progress
towards their assigned requests, picking requests (which become
passengers) as they reach them, and the set .sub.future is cleared.
Then, this process is repeated at the desired frequency with the
incoming requests.
[0252] It should be appreciated that the number of variables in the
ILP is equal to the number of edges e(T, v) in the RTV graph plus
the number of requests in *. In the worst case, it is of order
O(m(n+n.sub.pred).sup.v), only reached with complete RV and
RTV-graphs where all vehicles can serve all requests and all
requests can be combined with each other. In practice, the number
of variables is orders of magnitudes lower and related to the size
of the cliques in the RV-graph, but does scale poorly with the
number of predicted requests n.sub.pred, since they can typically
be combined with many of the current requests (since they are at a
future time at which some of the passengers might have been dropped
off). The number of constraints is n+n.sub.pred+m.
[0253] It should also be appreciated that the proposed model
includes the constraints Z and the cost term
C=C.sub.now+C.sub.future which aim at minimizing the total delay in
expectation, with respect to the current passengers, the current
requests and the expected future demand D. With respect to the
model, this method guarantees optimality of the assignment of the
currently active requests, while satisfying the constraints Z, if
all the steps are executed until termination and exploration of all
possible trips and assignments. In practice, timeouts are set both
for the amount of time spent generating candidate trips for each
vehicle, and for the amount of time spent exploring the branches of
the ILP. A limit on the number of vehicles considered per request,
the number of trips per vehicle or the optimality gap of the ILP
can also be set. These timeouts trade-off optimality for
tractability and their values will depend on the available
resources. It should be noted that the described future prediction
technique is not reactive but does account for a prediction of the
future demand. Furthermore, the method seamlessly allows for
parallelization in all steps.
[0254] The performance of an example system operating in accordance
with the concepts described herein may be assessed with a fleet of
1000, 2000, and 3000 vehicles of capacity two and four passengers
using a fixed maximum waiting time of .OMEGA.=5 minutes and a
maximum delay of .DELTA.=10 minutes. The minimum inter-station
distance used for the region discretization was 150 meters. For the
experiments, one week of historical taxi trip data from 00:00 on
Sunday May 5, 2013 to 23:59 on Saturday May 11, 2013 was used to
assess the performance of the system and techniques described
herein. This data comes from a publicly available source of all
taxi trips in Manhattan, N.Y., USA. This dataset contains the
geographical coordinates for the origins and destinations along
with the associated pick up and drop off dates and times for all
trips in executed by the 13,586 active taxis in New York City. From
this data, the request and pick up time are considered to be equal
since the time for the request is not publicly available.
[0255] In order to find routes for the taxis to execute, the entire
road network of Manhattan is we considered. The travel time for
each road segment is estimated using a daily mean travel time. In
one illustrative embodiment, the daily mean travel time may be
computed by the method described in P. Santi; G. Resta, M. Szell,
S. Sobolvesky, S. Strogatz and C. Ratti "Quantifying the Benefits
of Vehicle Pooling with Shareability Networks," PNAS, 2014.
Different travel times were used for weekdays, Saturday, and
Sunday. The shortest paths using these travel times were
precomputed between every two intersections in the road network and
were stored in a look-up table.
[0256] In this embodiment, the vehicles are initialized each day at
midnight at sampled positions from the demand distribution. The
execution of the fleet is simulated by issuing the requests
obtained from the historical taxi dataset for the given day. The
requests are collected within a 30 second time window after which
they are assigned in batch to different vehicles using the
technique described herein. In each time interval, or assignment
step, future requests are sampled up to 30 minutes in the future.
The number of predictions are varied by using 0, 200, and 400
sampled predicted requests (per interval). These predicted requests
enter the assignment problem technique of Table 3, but are removed
immediately afterwards, with new future requests being sampled in
the following step. They do affect the assignment and routing at
that time.
[0257] A pool of requests are kept until they have been picked up
in case they can be reassigned to a better match. In this example,
the number of requests in a single day varied from 382,779 on
Sunday to 460,700 on Friday.
[0258] Several metrics are collected that characterize the system,
including the service rate, in-car travel delay, waiting time,
average distance traveled by the vehicles, percentage of shared
rides, and the computational time. The parameters include the
additional sampled requests and cost term. These metrics are
plotted for vehicle capacities two and four side by side in FIGS.
14A-14F.
[0259] Referring now to FIGS. 14A-14F, these figures show a
comparison of several performance metrics for varying number of
sampled requests (No rebalancing 1402, Reactive 1408 (0 samples),
200 samples 1406, and 400 1404 samples). The reactive method
follows the techniques described herein. Each subplot corresponds
to the vehicle capacity of 2 and 4 with the x-axis showing the
fleet size (1000, 2000, and 3000 vehicles). A number of parameters
are analyzed including (a) service rate (percentage of requests
serviced as shown in FIG. 14A), (b) average in car delay
.delta.-.omega., as shown in FIG. 14B; (c) average waiting time
.omega., as shown in FIG. 14C; (d) average distance traveled by
each vehicle during a single day, as shown in FIG. 14D (e)
percentage of shared rides (number of passengers who shared a ride,
divided by the total number of picked-up passengers) as shown in
FIG. 14E and (f) average computational time for a 30 seconds
iteration of the method, in a 24 core 2.5 GHz machine, including
computation of the RV-graph, computation of the RTV-graph, ILP
assignment including the sampled requests, rebalancing and writing
the data to file as shown in FIG. 14F.
[0260] It is observed that the service rate (number of requests
serviced) remains approximately constant independently of the
number of sampled requests, and it is close to 100% for 3,000
vehicles of capacity 4 (there are 13,000 active taxis per day in
Manhattan). By sampling predicted requests, the system is able to
reduce the mean in-car travel delay by 1.5 minutes and the mean
waiting time by around 1 minute, with respect to the reactive
approach.
[0261] Particularly, for the in-car travel delay and the waiting
time, it can be seen that there is a large benefit in using
rebalancing and then a similar benefit by sampling predicted
requests, see FIGS. 14B and 14C). However, increasing the number of
samples from 200 to 400 only marginally decreased the in-air travel
delay by 3.4 seconds, when using a four-passenger vehicle capacity
and 3000 vehicles. It is likely that this small improvement is due
to the time-outs introduced for real-time performance, which limit
the benefit of additional samples. It is believed that the increase
would be larger if the technique was run to optimality.
[0262] Observed is a trade-off between operational cost and
performance, since the travel distance by the vehicles and the
computational time of the approach do increase with the number of
samples. The increase in travel distance arises from the fact that
vehicles are routed towards predicted requests which may or may not
appear in reality. This reduces mean waiting time and mean delay
but does increase the miles traveled by each vehicle. The increase
in computational time is due to the larger number of requests that
enter the routing and assignment problem. Furthermore, since they
are in the future, they can be combined with many different trips,
which leads to a potentially large number of feasible trips to be
accounted for in the assignment. Nonetheless, the approach can be
parallelized and would benefit from the large parallel servers
available for fleet management companies.
[0263] Thus, an experimental study confirms that the performance of
a mobility-on-demand system with ridesharing via the methods
described herein improves with knowledge of future demand.
[0264] In summary, described is a method and system for vehicle
routing and request assignment which incorporates a prediction of
future demand. The method seamlessly integrates sampled future
requests into a request assignment and vehicle routing technique.
It has been shown experimentally that including predictions
improves the positioning of the fleet of vehicles towards
satisfying future requests, reducing waiting time and travel time.
This is a step closer towards long term optimality.
[0265] Having described preferred embodiments, which serve to
illustrate various concepts, structures and techniques, which are
the subject of this patent, it will now become apparent to those of
ordinary skill in the art that other embodiments incorporating
these concepts, structures and techniques may be used.
Additionally, elements of different embodiments described herein
may be combined to form other embodiments not specifically set
forth above.
[0266] Accordingly, it is submitted that that scope of the patent
should not be limited to the described embodiments but rather
should be limited only by the spirit and scope of the following
claims.
[0267] All publications and references cited herein are expressly
incorporated herein by reference in their entirety.
* * * * *