Patent Publication Number: US-2020279194-A1

Title: Systems and methods for uncertainty-aware matching of transportation requestors and providers

Description:
BACKGROUND 
     A dynamic transportation matching service may match individuals and groups who request transportation from a starting point to a destination with transportation providers, such as cars, that are associated with a dynamic transportation network managed by the dynamic transportation matching system. In some cases, the dynamic transportation matching system may provide transportation requestors with an estimated time of arrival (ETA) of a transportation provider. Transportation requestors may rely on these ETAs to make plans and may cancel transportation requests when the ETA turns out to be inaccurate. For example, an ETA of fifteen minutes may inspire a transportation requestor to get a few quick things done around the house while waiting for the provider. If the provider shows up in two minutes, the requestor may not yet be ready to leave and may instead cancel the ride. Conversely, if a requestor receives an ETA of two and ten minutes pass without a provider appearing, the requestor may become frustrated and cancel. In either case, the requestor has had a poor experience with the dynamic transportation matching system due to the inaccurate ETA. 
     Unfortunately, it may be difficult to pinpoint a provider ETA given all of the many factors that can introduce uncertainty as to when exactly the provider will arrive. Accordingly, the instant disclosure identifies and addresses a need for additional and improved systems and methods for uncertainty-aware matching of transportation requestors and providers. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings illustrate a number of exemplary embodiments and are a part of the specification. Together with the following description, these drawings demonstrate and explain various principles of the instant disclosure. 
         FIG. 1  is an illustration of an example scenario involving a transportation requestor and multiple possible transportation providers. 
         FIG. 2  is an illustration of an example architecture for matching requestors and providers based at least in part on uncertainty information. 
         FIG. 3  is an illustration of an example scenario involving a transportation requestor and a transportation provider. 
         FIG. 4  is an illustration of an example scenario involving a transportation requestor and a transportation provider. 
         FIG. 5  is an illustration of a set of probability graphs for two transportation providers. 
         FIG. 6  is a flow diagram of an example probability tree. 
         FIG. 7  is an illustration of a set of probability graphs for one transportation provider. 
         FIG. 8  is an illustration of an example scenario where several transportation requestors share a transportation provider. 
         FIG. 9  is an illustration of an example requestor device displaying ETA uncertainty information. 
         FIG. 10  is an illustration of an example requestor device displaying ETA uncertainty information. 
         FIG. 11  is an illustration of an example requestor device displaying ETA uncertainty information and estimated time to destination information. 
         FIG. 12  is a block diagram of an example system for uncertainty-aware matching of transportation requestors and providers. 
         FIG. 13  is a flow diagram of an example method for uncertainty-aware matching of transportation requestors and providers. 
         FIG. 14  is an illustration of an example requestor/provider management environment. 
         FIG. 15  is an illustration of an example data collection and application management system. 
     
    
    
     Throughout the drawings, identical reference characters and descriptions indicate similar, but not necessarily identical, elements. While the exemplary embodiments described herein are susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. However, the exemplary embodiments described herein are not intended to be limited to the particular forms disclosed. Rather, the instant disclosure covers all modifications, equivalents, and alternatives falling within the scope of the appended claims. 
     DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
     The present disclosure is generally directed to systems and methods for providing and making use of uncertain ETA information when matching transportation providers and requestors. Inaccurate ETA information can result in ride cancellations, poor experience on the part of transportation requestors and providers, and reduced transportation network efficiency. Errors in ETA estimates may be introduced in various ways, including inaccurate starting location data for providers, variable delays in provider navigation readiness, providers failing to react in time to take expected routes to newly assigned destinations, and driving conditions en route. By estimating both the likelihood various scenarios that impact ETA and the impact of these scenarios on arrival time, the method may provide information about the uncertainty of ETA information. For example, the method may provide an ETA probability distribution. ETA uncertainty information (such as an ETA probability distribution) may then be used to make decisions within the transportation network (e.g., matching decisions). For example, the method may match a transportation requestor to a transportation provider with a higher ETA over a transportation provider with greater ETA uncertainty. In some cases, the method may delay a matching decision until ETA uncertainty decreases. In this example, the method may provide information regarding how quickly the uncertainty of ETA information is expected to resolve (e.g., how long until it is known whether a transportation provider was able to react in time to make a needed turn at an intersection). By reducing the uncertainty of ETAs provided to requestors and/or providing requestors with information about ETA uncertainty (e.g., an ETA range), the systems described herein may improve user experience, reduce cancellations, and/or improve the efficiency of a dynamic transportation network. Accordingly, as may be appreciated, the systems and methods described herein may improve the functioning of a computer that matches transportation requestors and providers by reducing the cancellations that detract from the efficiency of the matching algorithm. Furthermore, for the reasons mentioned above and to be discussed in greater detail below, the systems and methods described herein may provide advantages to the field of dynamic transportation by improving user experience and/or transportation network efficiency. 
     As will be explained in greater detail below, a dynamic transportation matching system may arrange transportation on an on-demand and/or ad-hoc basis by, e.g., matching one or more transportation requestors and/or transportation requestor devices with one or more transportation providers and/or transportation provider devices. For example, a dynamic transportation matching system may match a transportation requestor to a transportation provider that operates within a dynamic transportation network (e.g., that is managed by, coordinated by, and/or drawn from by the dynamic transportation matching system to provide transportation to transportation requestors). 
     In some examples, available sources of transportation within a dynamic transportation network may include vehicles that are owned by an owner and/or operator of the dynamic transportation matching system. Additionally or alternatively, sources of transportation within a dynamic transportation network may include vehicles that are owned outside of the dynamic transportation network but that participate within the dynamic transportation network by agreement. In some examples, the dynamic transportation network may include road-going vehicles (e.g., cars, light trucks, etc.). Furthermore, the dynamic transportation network may include personal mobility vehicles. In some embodiments, a dynamic transportation network may include autonomous vehicles (e.g., self-driving cars) that may be capable of operating with little or no input from a human operator. 
       FIG. 1  illustrates an example scenario involving a transportation requestor and multiple possible transportation providers. In some examples, a transportation requestor  102  may request transportation via a requestor device  104 . In one example, a provider  106  may be closer to transportation requestor  102  than a provider  116 . In some examples, a naïve matching algorithm may match provider  106  with transportation requestor  102  due to provider  106  being the closest available provider (e.g., in terms of travel distance, absolute distance, and/or naïvely estimated ETA). However, provider  106  may continue straight or turn right, necessitating a U-turn to meet transportation requestor  102  and rendering any initial ETA provided to transportation requestor  102  inaccurate due to the added delay. Because of the uncertainty associated with the proximity of provider  106  to intersection  108 , it may be more efficient to match provider  116  with transportation requestor  102 . In some examples, there may be less uncertainty associated with an ETA for provider  116  because provider  116  may be far enough from intersection  108  (or any other intersection) that the likelihood of provider  116  failing to make the correct turn (i.e., to meet transportation requestor  102 ) is low. 
       FIG. 2  illustrates an example architecture for matching requestors and providers based at least in part on uncertainty information. In one embodiment, an identification module  220  may identify a set of sources of uncertainty  214  in the ETA of a provider device  218  meeting a transportation requestor associated with a requestor device  216 . In some examples, sources of uncertainty  214  may include provider location  202 , provider route prediction  204 , provider reaction time  206 , traffic  208 , map information  210 , and/or algorithmic error  212 . In some examples, provider location  202  may represent uncertainty about the location of a provider due to potentially inaccurate location system data, stale location data (e.g., older than a certain threshold, such as thirty seconds, one minute, or five minutes, and therefore indicating a decreased likeliness that the location data represents the actual current location), and/or inaccurate mapping data for the provider&#39;s current location (e.g., provider is on a street not listed in the mapping data). In some examples, provider route prediction  204  may represent uncertainty about the near-future location of the provider due to potentially inaccurate bearing information (e.g., information about the current direction of travel of the provider), potentially inaccurate speed information, uncertain prediction of near-future choices (e.g., turns at intersections), and/or uncertain prediction about requestor behavior (e.g., how long will it take the provider to pick up an already-matched requestor for a shared ride). Provider reaction time  206  may represent uncertainty about how long it will take the provider to receive information about the new match (e.g., on a provider device), accept the new match, receive directions to the new match, and/or respond to directions to meet the new requestor. In some examples, provider reaction time  206  may also represent uncertainty about the exact location of the provider. For example, if the provider is in a left-turn-only lane of an intersection rather than the right-hand lane, the provider may not be able to react to directions to turn right at the intersection even if the provider receives the directions before entering the intersection. In some examples, traffic  208  may represent uncertainty caused by unpredictably changing traffic conditions (e.g., an accident) and/or inaccurate information about current traffic. In one example, traffic  208  may also represent uncertainty introduced by traffic lights with long cycles. In some examples, map information  210  may represent uncertainty introduced by potentially inaccurate map data between the provider and the requestor (e.g., missing streets and/or inaccurate information on the legality of turns). In some examples, algorithmic error  212  may represent uncertainty introduced by imperfections in the algorithm used to calculate estimated arrival time. In some embodiments, identification module  220  may identify other relevant sources of uncertainty beyond those described above. 
     In one embodiment, a calculation module  222  may calculate a statistical metric  226  that reflects the overall uncertainty from the various sources of uncertainty. In some embodiments, calculation module  222  may calculate a probability distribution. Additionally or alternatively, calculation module  222  may calculate an ETA range. In some embodiments, calculation module  222  may weight each source of uncertainty and calculate an overall uncertainty metric based on weighted input from the various sources of uncertainty. In some embodiments, a matching module  224  may make a matching decision involving requestor device  216  and/or provider device  218  based at least in part on statistical metric  226 . For example, matching module  224  may match requestor device  216  and provider device  218  in response to determining that statistical metric  226  indicates that the overall uncertainty is below a threshold for acceptable uncertainty. In another example, matching module  224  may not match requestor device  216  and provider device  218  in response to determining that statistical metric  226  indicates that overall uncertainty is above a threshold for acceptable uncertainty. 
       FIG. 3  illustrates an example scenario involving a transportation requestor and a transportation provider. In one example, a transportation requestor  302  may send a request for transportation from a requestor device  304 . In some examples, a provider  306  may be within a reasonable distance of transportation requestor  302  but may be approaching an intersection. In one example, provider  306  may have the option of turning in direction  308 ,  310 , or  312 . In some embodiments, the systems described herein may determine the probability of provider  306  turning in each direction based on the previous behavior of provider  306  and/or other providers. For example, if similar providers historically turn right at this location 30% of the time during the same time of day and/or week, the systems described herein may determine that the probability of provider  306  turning right is 30%. In some embodiments, the systems described herein may use machine learning techniques and/or statistical analysis to determine the probability that provider  306  will take a given action. Additionally or alternatively, the systems described herein may determine the probability of provider  306  turning in each direction based on route information for other trips being completed by provider  306  (e.g., if provider  306  is a shared provider currently transporting one or more requestors to a known destination). In one example, the systems described herein may predict that provider  306  has a 30% chance of turning in direction  310 , a 40% chance of continuing straight in direction  308 , and/or a 30% chance of turning in direction  312 . In one example, this might represent an ETA of eight minutes if provider  306  turns in direction  310 , an ETA of 12 minutes of provider  306  turns in direction  308 , and/or an ETA of 22 minutes if provider  306  turns in direction  312 . In some embodiments, because the turning direction of provider  306  is so uncertain (because the probabilities are relatively even), the systems described herein may determine that provider  306  has an ETA with high uncertainty. In another example, if the probability of provider  306  continuing in direction  308  were 90% (e.g., because provider  306  was transporting a requestor to a destination in that direction), the systems described herein may determine that provider  306  has an ETA with lower uncertainty and/or that provider  306  has an unfavorable ETA due to provider  306  moving away from transportation requestor  302 . In another example, if provider  306  had an 80% probability of turning in direction  310 , the systems described herein may determine that provider  306  has a low uncertainty and a favorable ETA. In some examples, provider  306  may be far enough from the intersection that it is possible but not guaranteed for provider  306  to respond to directions to meet transportation requestor  302  (e.g., by turning left). In these examples, the systems described herein may factor uncertainty about the response time of provider  306  into the overall uncertainty metric. 
     In some embodiments, the systems described herein may delay matching provider  306  due to the high uncertainty surrounding the direction in which provider  306  will turn and/or the low duration of the uncertainty (i.e., because provider  306  will enter the intersection soon). For example, if provider  306  has a relatively even probability of turning in any direction but is expected to pass the intersection within two seconds, the systems described herein may delay matching provider  306  by two seconds in order to have a more accurate ETA for provider  306  and/or in order to determine whether provider  306  is the optimal provider to match to requestor device  304 . In some embodiments, the systems described herein may also delay matching requestor device  304  with any transportation provider device while determining whether provider  306  is suitable for matching. In other embodiments, the systems described herein may match requestor device  304  with a different provider device (e.g., on associated with a provider with lower uncertainty) and may delay matching provider  306  with any requestor device. Although discussed in terms of an intersection, in some examples, provider  306  may be approaching a decision point other than an intersection. For example, the systems described herein may behave similarly if provider  306  is approaching a freeway onramp, offramp, and/or junction. In some embodiments, the systems described herein may delay matching provider  306  if provider  306  is affected by any source of uncertainty with a characteristic and/or type that indicates the source of uncertainty will be resolved within a predetermined time frame. For example, the systems described herein may delay matching provider  306  if the most recent location data from provider  306  is fifty seven seconds old and new location data is expected to be received within the next three seconds. 
       FIG. 4  illustrates an example scenario involving a transportation requestor and a transportation provider. In one example, a transportation requestor  402  may send a request for transportation from a requestor device  404 . In some examples, a provider  406  may be within a reasonable distance of transportation requestor  402  but the dynamic transportation matching system may have low confidence in the accuracy of location information for provider  406 . In some examples, the dynamic transportation matching system may estimate the accuracy of location information based on an accuracy metric provided by a vendor of a location system (e.g., a global positioning system). In some examples, the dynamic transportation matching system may have low confidence in the accuracy of location information for provider  406  due to information staleness. For example, the dynamic transportation matching system may have received location information that provider  406  was at reported location  408  ten seconds ago, but may not have received location information since. In some examples, the dynamic transportation matching system may attempt to predict the current location of provider  406  and/or may assign a probability to the likelihood that provider  406  slowed down, sped up, stopped, turned, and/or maintained the same speed since last reporting location data. In one example, provider  406  may have an ETA of eight minutes if provider  406  maintained speed and/or an ETA of 12 minutes of provider  406  stopped at reported location  408 . In one example, the dynamic transportation matching system may calculate uncertainty about the location of provider  406  based on the length of time since location data was received about provider  406  and/or the amount of possible changes that could have occurred in the state of provider  406  (e.g., made a turn, entered a freeway, stopped to pick up a requestor) since location information was received. In one embodiment, the systems described herein may not have information on whether or not provider  406  has continued straight or made turn  416 . In some examples, provider  406  may have an ETA of eight minutes if provider  406  continued forward but an ETA of 22 minutes if provider  406  made turn  416 . In some examples, the dynamic transportation matching system may delay matching provider  406  until receiving updated location information for provider  406 . 
     Additionally or alternatively, the dynamic transportation matching system may be uncertain about the location of provider  406  due to inaccurate geolocation service (e.g., global positioning system) and/or map data. For example, if provider  406  is traversing a street  410  that is parallel to a street  412 , the dynamic transportation matching system may be uncertain about whether provider  406  is on street  410  or street  412 . In one example, street  412  may have an inflection point  414  at which street  412  ceases to be parallel to street  410 . In some examples, the dynamic transportation matching system may delay matching provider  406  until provider  406  passes inflection point  414 , after which the uncertainty about the location of provider  406  may be reduced. In other examples, the dynamic transportation matching system may not delay matching provider  406  but may factor uncertainty about the exact location of provider  406  into the overall uncertainty metric for provider  406 . 
       FIG. 5  illustrates a set of probability graphs for two transportation providers that show different probability distributions for each provider at different times. For example, provider  106  and/or provider  116  in  FIG. 1  may be roughly equally likely to be moving in one of two directions, towards either a first location (e.g., the location a transportation requestor such as transportation requestor  102  in  FIG. 1 ) or a second location. In one example, moving in the direction of the first location may yield an ETA  512  for meeting the transportation requestor and/or moving in the direction of the second location may yield an ETA  514  for meeting the transportation requestor. In some examples, ETA  512  may be significantly shorter than ETA  514 . For example, ETA  512  may be five minutes while ETA  514  may be twenty minutes. In some examples, at time  508 , it may not be clear whether it is more efficient for a dynamic transportation matching system to match provider  106  or provider  116  with a requestor at the first location. The probability distributions from provider  106  and/or  116  may arise from a variety of sources of uncertainty, including uncertainty about the exact location of one or both providers, uncertainty about route prediction for one or both providers, and/or uncertainty about the accuracy of map data in the area occupied by one or both providers. In some examples, the dynamic transportation matching system may delay matching for the requestor until a clear match is available. In one example, at time  510 , the dynamic transportation matching system may receive information (e.g., updated location information that gives a clearer picture of provider location, direction of travel, and/or speed) that makes it clear that provider  106  is heading towards the first location, resulting in ETA  512  and/or provider  116  is heading towards the second location, resulting in ETA  514 . In some examples, at time  510 , the dynamic transportation matching system may match one or both providers with requestors based at least in part on the low uncertainty about the ETA of the providers to meet the requestors. For example, the dynamic transportation matching system may match a provider with a requestor based on the uncertainty of the ETA falling below a threshold for certainty. In some examples, a low uncertainty may be any uncertainty below a threshold of 30%, 25%, 10%, and/or 5%. Additionally or alternatively, an ETA with a low uncertainty may include any ETA where the maximum and minimum high-probability (e.g., greater than 90% probability) ETAs are within a specified range, such as within two minutes, within five minutes, and/or within ten minutes. 
       FIG. 6  is a flow diagram of an example probability tree. In some embodiments, the systems described herein may estimate branching probabilities for various outcomes. In one example, a provider may be located in an area with tunnels, one-way streets, and/or other navigational impediments that make wrong turns very costly in terms of time. For example, at decision point  602 , the systems described herein may estimate the probability that the provider location data available to the dynamic transportation matching system is accurate. In one example, if the location data is inaccurate (e.g., the provider is one street over), the systems described herein may estimate that the provider has an unsuitably high ETA of at least fifteen minutes. If the location data is accurate, at decision point  604 , the systems described herein may estimate, based on the distance between the provider and an intersection and/or historical provider reaction time, if the provider will receive and act on directions to meet a transportation requestor before reaching the intersection. If the provider does so, the systems described herein may predict an ETA of five minutes. If the provider does not, at decision point  606 , the systems described herein may predict, based on past behavior for the provider and/or other providers at this and/or similar intersections, which way the provider will turn. If the provider turns left, the provider may have coincidentally selected the right direction and may have a five minute ETA. If the provider turns right, the provider may enter a tunnel or bridge and have an unsuitably high ETA. If the provider turns straight, at decision point  608 , the systems described herein may attempt to predict how long it will take the provider to complete a U-turn at the next traffic light based on historical timing data for that traffic light and/or similar traffic lights. In some embodiments, the systems described herein may calculate probabilities for the entire tree before matching the provider. In one example, as illustrated in  FIG. 7 , at time  710  the systems described herein may calculate that there is a total of a 17% probability that the provider arrives in five minutes, a 10% probability that the provider arrives in nine minutes, a 24% probability that the provider arrives in ten minutes, a 15% probability that the provider arrives in eleven minutes, and a 34% probability that the provider will take longer than fifteen minutes to arrive at the meeting point with the transportation requestor. In one example, at time  720 , the systems described herein may receive information indicating that the provider continued straight at the intersection. The systems described herein may then calculate a 20% probability of a nine minute ETA, a 50% probability of a 10 minute ETA, and/or a 30% probability of an 11 minute ETA. 
     In some embodiments, the systems described herein may decline to match the provider based on calculating that there is an unacceptably high (e.g., greater than 30%) probability that the provider will have an unsuitably high ETA. In one embodiment, the decision to match may be dependent on what other providers are available and/or what the probability distributions for those providers are, how long until the uncertainties for those ETA estimates will be clarified for the one or more providers, and/or the probability that a different provider will become available that will have a more certain and/or better ETA for the request. In some examples, the systems described herein may match the provider with the requestor based at least in part on the 67% probability that the provider will arrive in eleven minutes or less. In one embodiment, the systems described herein may average some or all of the probabilities to produce an ETA estimate and/or range to provide to the transportation requestor. For example, the systems described herein may provide an ETA range of 8+/−3 minutes. In one example, the provider may fail to react in time to the directions, continue straight through the intersection, and make a U-turn at a medium-length traffic light, resulting in an actual time of arrival of ten minutes, within the ETA range provided to the transportation requestor. 
       FIG. 8  illustrates an example scenario where several transportation requestors share a transportation provider. In one example, a provider device  808  may traverse a trip leg  812  to meet a requestor device  802 , a trip leg  814  to meet a requestor device  804 , and/or a trip leg  816  to meet a requestor device  806 . In some examples, trip legs  812 ,  814 , and/or  814  may all be subject to uncertainty, compounding the uncertainty of the ETAs provided to requestor devices later in line and/or the uncertainty of estimated times to destination (ETDs) provided to earlier requestor devices. In addition to the sources of uncertainty discussed above, shared trips may introduce an additional source of uncertainty based on the behavior of requestors. For example, if the requestor associated with requestor device  804  is late meeting provider device  808 , the ETA provided to requestor device  806  may no longer be accurate due to the delay. In some examples, the provider associated with provider device  808  may have difficulty finding a safe spot to pull over and meet a requestor. In some embodiments, the dynamic transportation matching system may predict the delay associated with requestor pickups during a shared trip based on previous requestor behavior (e.g., is the requestor typically late or typically on time). Additionally or alternatively, the dynamic transportation network may predict and/or model the delay associated with a pickup location at a given time based on previous delay associated with that pickup location and/or similar pickup locations (e.g., downtown areas versus rural areas and/or intersections versus one-way streets) at similar times (e.g., pickups during rush hour may experience more delay than pickups at night when there is less traffic). By predicting the delay associated with meeting requestors, the dynamic transportation matching system may produce more accurate ETAs and/or ETAs and/or may more accurately determine the uncertainty associated with ETAs and/or ETDs. In one example, the dynamic transportation matching system may factor in uncertainty associated with trip legs  812 ,  814 , and  816  and pickups for requestors associated with requestor devices  802  and  804  when determining the overall uncertainty for the ETA to provide to requestor device  806 . In some examples, the systems described herein may perform different matching based on the ETA uncertainty information than would happen without the ETA uncertainty information. For example, without ETA uncertainty information, the systems described herein may calculate that provider device  808  will arrive at requestor device  806  sufficiently quickly to justify matching provider device  808  with requestor device  806 . However, with ETA uncertainty information, the systems described herein may determine that provider device  808  does not have a sufficiently high probability of arriving at requestor device  806  within an acceptable time frame (e.g., ten minutes) to justify matching requestor device  806  with provider device  808 . In some examples, the systems described herein may delay matching a requestor device to an existing multi-leg trip due to a high level of uncertainty. In some embodiments, the dynamic transportation matching system may match requestor devices and provider devices for shared trips based on worst-case-scenario ETDs. Additionally or alternatively, the dynamic transportation matching system may provide worst-case-scenario ETDs to requestor devices and/or may provide ETDs that are above a probability threshold of being achieved or beaten (e.g., there is a 100% chance the requestor will arrive at the destination at or before the provided ETD). In some embodiments, the dynamic transportation matching system may factor in uncertainty associated with multiple types of trip leg (e.g., a requestor walking to a personal mobility vehicle and then using the personal mobility vehicle to meet a provider) when calculating ETAs and/or ETDs. 
       FIG. 9  illustrates an example requestor device displaying ETA uncertainty information. In some examples, the systems described herein may provide a requestor device  902  with a range of possible ETAs for one or more transportation options. For example, the systems described herein may provide requestor device  902  with an ETA range  904  for a shared ride and/or an ETA range  906  for a private trip. In some embodiments, the systems described herein may include the range of all predicted ETAs in an ETA range. Additionally or alternatively, the systems described herein may include a range of all ETAs above a certain probability (e.g., 30%). 
       FIG. 10  illustrates an example requestor device displaying ETA uncertainty information. In some examples, the systems described herein may provide a requestor device  1002  with ETA confidence information for one or more transportation options. For example, the systems described herein may provide requestor device  1002  with an ETA probability  1004  for a shared ride and/or an ETA probability  1006  for a private trip. In some embodiments, the systems described herein may calculate the ETA with the highest probability and then provide the requestor device with that ETA and the calculated probability of that ETA being correct. 
       FIG. 11  illustrates an example requestor device displaying ETA uncertainty information and ETD information. In some examples, the systems described herein may provide a requestor device  1102  with ETA range information and/or ETD information for one or more transportation options. For example, the systems described herein may provide requestor device  1102  with an ETA range  1104  and/or an ETD estimate  1106 . In some embodiments, the systems described herein may use similar sources of uncertainty and/or uncertainty calculation algorithms to calculate an ETD as to calculate an ETA. In some examples, the systems described herein may display a conservative ETD estimate (i.e., an ETD estimate with a high probability of being achieved). In some examples, the systems described herein may provide an ETD probability and/or ETD range. 
       FIG. 12  illustrates an example system  1200  for matching transportation requests with a dynamic transportation network that includes personal mobility vehicles. As shown in  FIG. 12 , a dynamic transportation matching system  1210  may be configured with one or more dynamic transportation matching modules  1212  that may perform one or more of the steps described herein. Dynamic transportation matching system  1210  may represent any computing system and/or set of computing systems capable of matching transportation requests. Dynamic transportation matching system  1210  may be in communication with computing devices in each of a group of vehicles  1220 . Vehicles  1220  may represent any vehicles that may fulfill transportation requests. In some examples, vehicles  1220  may include disparate vehicle types and/or models. For example, vehicles  1220  may include road-going vehicles and personal mobility vehicles. In some examples, some of vehicles  1220  may be standard commercially available vehicles. According to some examples, some of vehicles  1220  may be owned by separate individuals (e.g., transportation providers). Furthermore, while, in some examples, many or all of vehicles  1220  may be human-operated, in some examples many of vehicles  1220  may also be autonomous (or partly autonomous). Accordingly, throughout the instant disclosure, references to a “transportation provider” (or “provider”) may, where appropriate, refer to an operator of a human driven vehicle, an autonomous vehicle control system, an autonomous vehicle, an owner of an autonomous vehicle, an operator of an autonomous vehicle, an attendant of an autonomous vehicle, a vehicle piloted by a requestor, and/or an autonomous system for piloting a vehicle. While  FIG. 12  does not specify the number of vehicles  1220 , it may be readily appreciated that the systems described herein are applicable to hundreds of vehicles, thousands of vehicles, or more. In one example, dynamic transportation matching system  1210  may coordinate transportation matchings within a single region for 50,000 vehicles or more on a given day. In some examples, vehicles  1220  may collectively form a dynamic transportation network that may provide transportation supply on an on-demand basis to transportation requestors. 
     As mentioned above, dynamic transportation matching system  1210  may communicate with computing devices in each of vehicles  1220 . The computing devices may be any suitable type of computing device. In some examples, one or more of the computing devices may be integrated into the respective vehicles  1220 . In some examples, one or more of the computing devices may be mobile devices. For example, one or more of the computing devices may be smartphones. Additionally or alternatively, one or more of the computing devices may be tablet computers, personal digital assistants, or any other type or form of mobile computing device. According to some examples, one or more of the computing devices may include wearable computing devices (e.g., a driver-wearable computing device), such as smart glasses, smart watches, etc. In some examples, one or more of the computing devices may be devices suitable for temporarily mounting in a vehicle (e.g., for use by a requestor and/or provider for a transportation matching application, a navigation application, and/or any other application suited for the use of requestors and/or providers). Additionally or alternatively, one or more of the computing devices may be devices suitable for installing in a vehicle and/or may be a vehicle&#39;s computer that has a transportation management system application installed on the computer in order to provide transportation services to transportation requestors and/or communicate with dynamic transportation matching system  1210 . 
     As shown in  FIG. 12 , vehicles  1220  may include provider devices  1230 ( 1 )-( n ) (e.g., whether integrated into the vehicle, permanently affixed to the vehicle, temporarily affixed to the vehicle, worn by a driver of the vehicle, etc.). In some examples, provider devices  1230  may include a provider apps  1240 ( 1 )-( k ). Provider apps  1240 ( 1 )-( k ) may represent any application, program, and/or module that may provide one or more services related to operating a vehicle and/or providing transportation matching services. For example, provider apps  1240 ( 1 )-( k ) may include a transportation matching application for providers and/or one or more applications for matching personal mobility vehicles (PMVs) with requestor devices. In some embodiments, different types of provider vehicles may be provisioned with different types of provider devices and/or different provider applications. For example, PMVs may be provisioned with provider devices that are configured with a provider application that enables transportation requestors to reserve and/or operate the PMV while road-constrained vehicles (e.g., cars) may be provisioned with provider devices that are configured with a provider application that enables provider vehicle operators (e.g., transportation providers) to respond to requests from transportation requestors. In some examples, provider applications  1240 ( 1 )-( k ) may match the user of provider apps  1240 ( 1 )-( k ) (e.g., a transportation provider) with transportation requestors through communication with dynamic transportation matching system  1210 . In addition, and as is described in greater detail below, provider apps  1240 ( 1 )-( k ) may provide dynamic transportation management system  1210  with information about a provider (including, e.g., the current location of the provider and/or vehicle) to enable dynamic transportation management system  1210  to provide dynamic transportation matching and/or management services for the provider and one or more requestors. In some examples, provider apps  1240 ( 1 )-( k ) may coordinate communications and/or a payment between a requestor and a provider. According to some embodiments, provider apps  1240 ( 1 )-( k ) may provide a map service, a navigation service, a traffic notification service, and/or a geolocation service. 
     Additionally, as shown in  FIG. 12 , dynamic transportation matching system  1210  may communicate with requestor devices  1250 ( 1 )-( m ). In some examples, requestor devices  1250  may include a requestor app  1260 . Requestor app  1260  may represent any application, program, and/or module that may provide one or more services related to requesting transportation matching services. For example, requestor app  1260  may include a transportation matching application for requestors. In some examples, requestor app  1260  may match the user of requestor app  1260  (e.g., a transportation requestor) with transportation providers through communication with dynamic transportation matching system  1210 . In addition, and as is described in greater detail below, requestor app  1260  may provide dynamic transportation management system  1210  with information about a requestor (including, e.g., the current location of the requestor) to enable dynamic transportation management system  1210  to provide dynamic transportation matching services for the requestor and one or more providers. In some examples, requestor app  1260  may coordinate communications and/or a payment between a requestor and a provider. According to some embodiments, requestor app  1260  may provide a map service, a navigation service, a traffic notification service, and/or a geolocation service. 
     Embodiments of the instant disclosure may include or be implemented in conjunction with a dynamic transportation matching system. A transportation matching system may arrange transportation on an on-demand and/or ad-hoc basis by, e.g., matching one or more transportation requestors with one or more transportation providers. For example, a transportation matching system may provide one or more transportation matching services for a ridesharing service, a ridesourcing service, a taxicab service, a car-booking service, an autonomous vehicle service, a personal mobility vehicle service, or some combination and/or derivative thereof. The transportation matching system may include and/or interface with any of a variety of subsystems that may implement, support, and/or improve a transportation matching service. For example, the transportation matching system may include a matching system (e.g., that matches requestors to ride opportunities and/or that arranges for requestors and/or providers to meet), a mapping system, a navigation system (e.g., to help a provider reach a requestor, to help a requestor reach a provider, and/or to help a provider reach a destination), a reputation system (e.g., to rate and/or gauge the trustworthiness of a requestor and/or a provider), a payment system, and/or an autonomous or semi-autonomous driving system. The transportation matching system may be implemented on various platforms, including a requestor-owned mobile device, a computing system installed in a vehicle, a requestor-owned mobile device, a server computer system, or any other hardware platform capable of providing transportation matching services to one or more requestors and/or providers. 
       FIG. 13  illustrates an example method  1300  for uncertainty-aware matching of transportation requestors and providers. As illustrated in  FIG. 13 , at step  1310 , one or more of the systems described herein may identify at least one source of uncertainty in an ETA of a transportation provider device meeting a transportation requestor associated with a transportation requestor device. 
     In one embodiment, the at least one source of uncertainty may include potentially inaccurate geolocation information for the transportation provider device used to produce the ETA. In some embodiments, the at least one source of uncertainty may include out-of-date geolocation information for the transportation provider device used to produce the ETA. 
     Additionally or alternatively, the at least one source of uncertainty may include potentially inaccurate route information for the transportation requestor device used to produce the ETA. In one embodiment, the potentially inaccurate route information may be potentially inaccurate due at least in part to a probability that an operator of the transportation provider device will make a navigation decision that alters the ETA before responding to routing directions to meet the transportation requestor device that are sent to the transportation provider device. 
     In one example, the at least one source of uncertainty may include potential inaccuracy introduced by an ETA prediction algorithm used to produce the ETA. In some examples, the at least one source of uncertainty may include potentially inaccurate map information used to produce the ETA. 
     At step  1320 , one or more of the systems described herein may calculate, based on the at least one source of uncertainty, a statistical metric that reflects the overall uncertainty for the ETA. 
     In one embodiment, the systems described herein may calculate, based on the at least one source of uncertainty, the statistical metric that reflects the overall uncertainty for the ETA by assigning a weight to each source of uncertainty in the at least source of uncertainty and calculating the statistical metric that reflects the overall uncertainty based at least in part on the weight of each source of uncertainty. In one embodiment, the statistical metric that reflects the overall uncertainty may include a probability distribution for the ETA. 
     At step  1330 , one or more of the systems described herein may match the transportation provider device with the transportation requestor device based at least in part on the statistical metric that reflects the overall uncertainty for the ETA. 
     In some examples, the systems described herein may match the transportation provider device with the transportation requestor device based at least in part on the statistical metric that reflects the overall uncertainty for the ETA by predicting, based on a characteristic of the at least one source of uncertainty, a decrease of the overall uncertainty within a predetermined time frame and delaying matching the transportation provider device with the transportation requestor device until the overall uncertainty decreases based at least in part on predicting that the overall uncertainty will decrease within the predetermined time frame. In some examples, the systems described herein may match the transportation provider device with the transportation requestor device based at least in part on the statistical metric that reflects the overall uncertainty for the ETA by determining that the overall uncertainty is within a predetermined threshold for acceptable uncertainty. 
     Additionally or alternatively, the systems described herein may match the transportation provider device with the transportation requestor device based at least in part on the statistical metric that reflects the overall uncertainty for the ETA by (i) identifying a first transportation provider device with a first ETA and a first overall uncertainty, (ii) identifying a second transportation provider device with a second ETA that is later than the first ETA and a second overall uncertainty that is less than the first overall uncertainty, and (iii) matching the second transportation provider device with the transportation requestor device based on the second overall uncertainty being less than the first overall uncertainty despite the second ETA being later than the first ETA. In one embodiment, systems described herein display, on the transportation requestor device, a representation of the overall uncertainty. 
       FIG. 14  shows a transportation management environment  1400 , in accordance with various embodiments. As shown in  FIG. 14 , a transportation management system  1402  may run one or more services and/or software applications, including identity management services  1404 , location services  1406 , ride services  1408 , and/or other services. Although  FIG. 14  shows a certain number of services provided by transportation management system  1402 , more or fewer services may be provided in various implementations. In addition, although  FIG. 14  shows these services as being provided by transportation management system  1402 , all or a portion of any of the services may be processed in a distributed fashion. For example, computations associated with a service task may be performed by a combination of transportation management system  1402  (including any number of servers, databases, etc.), one or more devices associated with a provider (e.g., devices integrated with managed vehicles  1414 ( a ),  1414 ( b ), and/or  1414 ( c ); provider computing devices  1416  and tablets  1420 ; and transportation management vehicle devices  1418 ), and/or more or more devices associated with a ride requestor (e.g., the requestor&#39;s computing devices  1424  and tablets  1422 ). In some embodiments, transportation management system  1402  may include one or more general purpose computers, server computers, clustered computing systems, cloud-based computing systems, and/or any other computing systems or arrangements of computing systems. Transportation management system  1402  may be configured to run any or all of the services and/or software components described herein. In some embodiments, the transportation management system  1402  may include an appropriate operating system and/or various server applications, such as web servers capable of handling hypertext transport protocol (HTTP) requests, file transfer protocol (FTP) servers, database servers, etc. 
     In some embodiments, identity management services  1404  may be configured to perform authorization services for requestors and providers and/or manage their interactions and/or data with transportation management system  1402 . This may include, e.g., authenticating the identity of providers and determining that they are authorized to provide services through transportation management system  1402 . Similarly, requestors&#39; identities may be authenticated to determine whether they are authorized to receive the requested services through transportation management system  1402 . Identity management services  1404  may also manage and/or control access to provider and/or requestor data maintained by transportation management system  1402 , such as driving and/or ride histories, vehicle data, personal data, preferences, usage patterns as a ride provider and/or as a ride requestor, profile pictures, linked third-party accounts (e.g., credentials for music and/or entertainment services, social-networking systems, calendar systems, task-management systems, etc.) and any other associated information. Transportation management system  1402  may also manage and/or control access to provider and/or requestor data stored with and/or obtained from third-party systems. For example, a requester or provider may grant transportation management system  1402  access to a third-party email, calendar, or task management system (e.g., via the user&#39;s credentials). As another example, a requestor or provider may grant, through a mobile device (e.g.,  1416 ,  1420 ,  1422 , or  1424 ), a transportation application associated with transportation management system  1402  access to data provided by other applications installed on the mobile device. In some examples, such data may be processed on the client and/or uploaded to transportation management system  1402  for processing. 
     In some embodiments, transportation management system  1402  may provide ride services  1408 , which may include ride matching and/or management services to connect a requestor to a provider. For example, after identity management services module  1404  has authenticated the identity a ride requestor, ride services module  1408  may attempt to match the requestor with one or more ride providers. In some embodiments, ride services module  1408  may identify an appropriate provider using location data obtained from location services module  1406 . Ride services module  1408  may use the location data to identify providers who are geographically close to the requestor (e.g., within a certain threshold distance or travel time) and/or who are otherwise a good match with the requestor. Ride services module  1408  may implement matching algorithms that score providers based on, e.g., preferences of providers and requestors; vehicle features, amenities, condition, and/or status; providers&#39; preferred general travel direction and/or route, range of travel, and/or availability; requestors&#39; origination and destination locations, time constraints, and/or vehicle feature needs; and any other pertinent information for matching requestors with providers. In some embodiments, ride services module  1408  may use rule-based algorithms and/or machine-learning models for matching requestors and providers. 
     Transportation management system  1402  may communicatively connect to various devices through networks  1410  and/or  1412 . Networks  1410  and  1412  may include any combination of interconnected networks configured to send and/or receive data communications using various communication protocols and transmission technologies. In some embodiments, networks  1410  and/or  1412  may include local area networks (LANs), wide-area networks (WANs), and/or the Internet, and may support communication protocols such as transmission control protocol/Internet protocol (TCP/IP), Internet packet exchange (IPX), systems network architecture (SNA), and/or any other suitable network protocols. In some embodiments, data may be transmitted through networks  1410  and/or  1412  using a mobile network (such as a mobile telephone network, cellular network, satellite network, or other mobile network), a public switched telephone network (PSTN), wired communication protocols (e.g., Universal Serial Bus (USB), Controller Area Network (CAN)), and/or wireless communication protocols (e.g., wireless LAN (WLAN) technologies implementing the IEEE 1102.12 family of standards, Bluetooth, Bluetooth Low Energy, Near Field Communication (NFC), Z-Wave, and ZigBee). In various embodiments, networks  1410  and/or  1412  may include any combination of networks described herein or any other type of network capable of facilitating communication across networks  1410  and/or  1412 . 
     In some embodiments, transportation management vehicle device  1418  may include a provider communication device configured to communicate with users, such as drivers, passengers, pedestrians, and/or other users. In some embodiments, transportation management vehicle device  1418  may communicate directly with transportation management system  1402  or through another provider computing device, such as provider computing device  1416 . In some embodiments, a requestor computing device (e.g., device  1424 ) may communicate via a connection  1426  directly with transportation management vehicle device  1418  via a communication channel and/or connection, such as a peer-to-peer connection, Bluetooth connection, NFC connection, ad hoc wireless network, and/or any other communication channel or connection. Although  FIG. 14  shows particular devices communicating with transportation management system  1402  over networks  1410  and  1412 , in various embodiments, transportation management system  1402  may expose an interface, such as an application programming interface (API) or service provider interface (SPI) to enable various third parties which may serve as an intermediary between end users and transportation management system  1402 . 
     In some embodiments, devices within a vehicle may be interconnected. For example, any combination of the following may be communicatively connected: vehicle  1414 , provider computing device  1416 , provider tablet  1420 , transportation management vehicle device  1418 , requestor computing device  1424 , requestor tablet  1422 , and any other device (e.g., smart watch, smart tags, etc.). For example, transportation management vehicle device  1418  may be communicatively connected to provider computing device  1416  and/or requestor computing device  1424 . Transportation management vehicle device  1418  may establish communicative connections, such as connections  1426  and  1428 , to those devices via any suitable communication technology, including, e.g., WLAN technologies implementing the IEEE 1102.12 family of standards, Bluetooth, Bluetooth Low Energy, NFC, Z-Wave, ZigBee, and any other suitable short-range wireless communication technology. 
     In some embodiments, users may utilize and interface with one or more services provided by the transportation management system  1402  using applications executing on their respective computing devices (e.g.,  1416 ,  1418 ,  1420 , and/or a computing device integrated within vehicle  1414 ), which may include mobile devices (e.g., an iPhone®, an iPad®, mobile telephone, tablet computer, a personal digital assistant (PDA)), laptops, wearable devices (e.g., smart watch, smart glasses, head mounted displays, etc.), thin client devices, gaming consoles, and any other computing devices. In some embodiments, vehicle  1414  may include a vehicle-integrated computing device, such as a vehicle navigation system, or other computing device integrated with the vehicle itself, such as the management system of an autonomous vehicle. The computing device may run on any suitable operating systems, such as Android®, iOS®, macOS®, Windows®, Linux®, UNIX®, or UNIX®-based or Linux®-based operating systems, or other operating systems. The computing device may further be configured to send and receive data over the Internet, short message service (SMS), email, and various other messaging applications and/or communication protocols. In some embodiments, one or more software applications may be installed on the computing device of a provider or requestor, including an application associated with transportation management system  1402 . The transportation application may, for example, be distributed by an entity associated with the transportation management system via any distribution channel, such as an online source from which applications may be downloaded. Additional third-party applications unassociated with the transportation management system may also be installed on the computing device. In some embodiments, the transportation application may communicate or share data and resources with one or more of the installed third-party applications. 
       FIG. 15  shows a data collection and application management environment  1500 , in accordance with various embodiments. As shown in  FIG. 15 , management system  1502  may be configured to collect data from various data collection devices  1504  through a data collection interface  1506 . As discussed above, management system  1502  may include one or more computers and/or servers or any combination thereof. Data collection devices  1504  may include, but are not limited to, user devices (including provider and requestor computing devices, such as those discussed above), provider communication devices, laptop or desktop computers, vehicle data (e.g., from sensors integrated into or otherwise connected to vehicles), ground-based or satellite-based sources (e.g., location data, traffic data, weather data, etc.), or other sensor data (e.g., roadway embedded sensors, traffic sensors, etc.). Data collection interface  1506  can include, e.g., an extensible device framework configured to support interfaces for each data collection device. In various embodiments, data collection interface  1506  may be extended to support new data collection devices as they are released and/or to update existing interfaces to support changes to existing data collection devices. In various embodiments, data collection devices may communicate with data collection interface  1506  over one or more networks. The networks may include any network or communication protocol as would be recognized by one of ordinary skill in the art, including those networks discussed above. 
     As shown in  FIG. 15 , data received from data collection devices  1504  can be stored in data store  1508 . Data store  1508  may include one or more data stores, such as databases, object storage systems and services, cloud-based storage services, and other data stores. For example, various data stores may be implemented on a non-transitory storage medium accessible to management system  1502 , such as historical data store  1510 , ride data store  1512 , and user data store  1514 . Data stores  1508  can be local to management system  1502 , or remote and accessible over a network, such as those networks discussed above or a storage-area network or other networked storage system. In various embodiments, historical data  1510  may include historical traffic data, weather data, request data, road condition data, or any other data for a given region or regions received from various data collection devices. Ride data  1512  may include route data, request data, timing data, and other ride related data, in aggregate and/or by requestor or provider. User data  1514  may include user account data, preferences, location history, and other user-specific data. Although certain data stores are shown by way of example, any data collected and/or stored according to the various embodiments described herein may be stored in data stores  1508 . 
     As shown in  FIG. 15 , an application interface  1516  can be provided by management system  1502  to enable various apps  1518  to access data and/or services available through management system  1502 . Apps  1518  may run on various user devices (including provider and requestor computing devices, such as those discussed above) and/or may include cloud-based or other distributed apps configured to run across various devices (e.g., computers, servers, or combinations thereof). Apps  1518  may include, e.g., aggregation and/or reporting apps which may utilize data  1508  to provide various services (e.g., third-party ride request and management apps). In various embodiments, application interface  1516  can include an API and/or SPI enabling third party development of apps  1518 . In some embodiments, application interface  1516  may include a web interface, enabling web-based access to data  1508  and/or services provided by management system  1502 . In various embodiments, apps  1518  may run on devices configured to communicate with application interface  1516  over one or more networks. The networks may include any network or communication protocol as would be recognized by one of ordinary skill in the art, including those networks discussed above, in accordance with an embodiment of the present disclosure. 
     While various embodiments of the present disclosure are described in terms of a ridesharing service in which the ride providers are human drivers operating their own vehicles, in other embodiments, the techniques described herein may also be used in environments in which ride requests are fulfilled using autonomous vehicles. For example, a transportation management system of a ridesharing service may facilitate the fulfillment of ride requests using both human drivers and autonomous vehicles. 
     As detailed above, the computing devices and systems described and/or illustrated herein broadly represent any type or form of computing device or system capable of executing computer-readable instructions, such as those contained within the modules described herein. In their most basic configuration, these computing device(s) may each include at least one memory device and at least one physical processor. 
     In some examples, the term “memory device” generally refers to any type or form of volatile or non-volatile storage device or medium capable of storing data and/or computer-readable instructions. In one example, a memory device may store, load, and/or maintain one or more of the modules described herein. Examples of memory devices include, without limitation, Random Access Memory (RAM), Read Only Memory (ROM), flash memory, Hard Disk Drives (HDDs), Solid-State Drives (SSDs), optical disk drives, caches, variations or combinations of one or more of the same, or any other suitable storage memory. 
     In some examples, the term “physical processor” generally refers to any type or form of hardware-implemented processing unit capable of interpreting and/or executing computer-readable instructions. In one example, a physical processor may access and/or modify one or more modules stored in the above-described memory device. Examples of physical processors include, without limitation, microprocessors, microcontrollers, Central Processing Units (CPUs), Field-Programmable Gate Arrays (FPGAs) that implement softcore processors, Application-Specific Integrated Circuits (ASICs), portions of one or more of the same, variations or combinations of one or more of the same, or any other suitable physical processor. 
     Although illustrated as separate elements, the modules described and/or illustrated herein may represent portions of a single module or application. In addition, in certain embodiments one or more of these modules may represent one or more software applications or programs that, when executed by a computing device, may cause the computing device to perform one or more tasks. For example, one or more of the modules described and/or illustrated herein may represent modules stored and configured to run on one or more of the computing devices or systems described and/or illustrated herein. One or more of these modules may also represent all or portions of one or more special-purpose computers configured to perform one or more tasks. 
     In addition, one or more of the modules described herein may transform data, physical devices, and/or representations of physical devices from one form to another. Additionally or alternatively, one or more of the modules recited herein may transform a processor, volatile memory, non-volatile memory, and/or any other portion of a physical computing device from one form to another by executing on the computing device, storing data on the computing device, and/or otherwise interacting with the computing device. 
     In some embodiments, the term “computer-readable medium” generally refers to any form of device, carrier, or medium capable of storing or carrying computer-readable instructions. Examples of computer-readable media include, without limitation, transmission-type media, such as carrier waves, and non-transitory-type media, such as magnetic-storage media (e.g., hard disk drives, tape drives, and floppy disks), optical-storage media (e.g., Compact Disks (CDs), Digital Video Disks (DVDs), and BLU-RAY disks), electronic-storage media (e.g., solid-state drives and flash media), and other distribution systems. 
     The process parameters and sequence of the steps described and/or illustrated herein are given by way of example only and can be varied as desired. For example, while the steps illustrated and/or described herein may be shown or discussed in a particular order, these steps do not necessarily need to be performed in the order illustrated or discussed. The various exemplary methods described and/or illustrated herein may also omit one or more of the steps described or illustrated herein or include additional steps in addition to those disclosed. 
     The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary embodiments disclosed herein. This exemplary description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the instant disclosure. The embodiments disclosed herein should be considered in all respects illustrative and not restrictive. Reference should be made to the appended claims and their equivalents in determining the scope of the instant disclosure. 
     Unless otherwise noted, the terms “connected to” and “coupled to” (and their derivatives), as used in the specification and claims, are to be construed as permitting both direct and indirect (i.e., via other elements or components) connection. In addition, the terms “a” or “an,” as used in the specification and claims, are to be construed as meaning “at least one of.” Finally, for ease of use, the terms “including” and “having” (and their derivatives), as used in the specification and claims, are interchangeable with and have the same meaning as the word “comprising.”