BACKGROUNDDifferent vehicle operators may prefer and/or be comfortable with different styles, patterns, etc., of operating a vehicle such as an automobile, truck, watercraft, etc. Various styles, patterns, etc. may provide varying degrees of comfort, enjoyment, etc., to operators and/or occupants of autonomous vehicles. Autonomous vehicles according to current designs generally operate according to instructions that do not take into account factors such as an operator's identity, and/or an operator identity in combination with factors such as weather, time of day, etc. Autonomous vehicles further are lacking with respect to operator-selectable settings to provide various patterns of driving that might be desired or warranted based on a current situation.
DRAWINGSFIG. 1 is a block diagram of an exemplary vehicle system for providing and/or managing various modes of operation of an autonomous vehicle.
FIG. 2 is a diagram of an exemplary process for providing and/or managing various modes of operation of an autonomous vehicle.
DESCRIPTIONIntroductionFIG. 1 is a block diagram of anexemplary vehicle system100 for providing and/or managing various modes of operation of anautonomous vehicle101. Acomputing device105 in thevehicle101 generally receives collecteddata115 from one or more data collectors e.g., sensors,110. Thevehicle101 further includes an autonomous driving module106, e.g., as a set of instructions stored in a memory of, and executable by a processor of, thecomputing device105. Thevehicle computer105 is generally configured to evaluate and synchronize operator input, collecteddata115, and/or one or more storedparameters116 to select a mode of operating thevehicle101 and/or to determine whether to make a change or adjustment to a mode of operating thevehicle101.
For example, different modes of operating theautonomous vehicle101 may include a sport mode, a standard mode, and a comfort mode. Thus, avehicle101 operator may experience autonomous operation of thevehicle101 in a manner similar to the operator's preferred driving style, e.g., if the operator prefers to change lanes whenever a lane change is likely to allow an increase of vehicle speed, a mode of theautonomous vehicle101 may be configured for such behavior. Likewise, if avehicle101 operator prefers to remain in a non-passing lane of interstate highway whenever possible, a mode of theautonomous vehicle101 may be configured to enter a passing lane of a highway only when confronted with an obstacle, when necessary to maintainvehicle101 speed below a non-threshold, etc.
Further, asame vehicle101 operator may prefer different driving styles or patterns depending on the current situation, e.g., a Rush mode: “I'm already 5 minutes late to my meeting in a half-hour and need to pick up the pace;” a Running-on-empty mode: “Conserve gasoline or you may run out before reaching the gas station;” Sightseeing mode: “Show visiting in-laws the sights driving slowly;” Cautious mode: “Drive on the interstate during an ice storm,” etc. Other examples ofautonomous vehicle101 modes, and mechanisms for selecting avehicle101 mode, including various attributes thereof, are provided below.
Exemplary System ElementsAvehicle101 includes avehicle computer105 that generally includes a processor and a memory, the memory including one or more forms of computer-readable media, and storing instructions executable by the processor for performing various operations, including as disclosed herein. For example, thecomputer105 generally includes, and is capable of executing, instructions to select an autonomous operation mode, to adjust an autonomous operation mode, to change an autonomous operation mode, etc., of thevehicle101.
Further, thecomputer105 may include more than one computing device, e.g., controllers or the like included in thevehicle101 for monitoring and/or controlling various vehicle components, e.g., an engine control unit (ECU), transmission control unit (TCU), etc. Thecomputer105 is generally configured for communications on a controller area network (CAN) bus or the like. Thecomputer105 may also have a connection to an onboard diagnostics connector (OBD-II). Via the CAN bus, OBD-II, and/or other wired or wireless mechanisms, thecomputer105 may transmit messages to various devices in a vehicle and/or receive messages from the various devices, e.g., controllers, actuators, sensors, etc., includingdata collectors110. Alternatively or additionally, in cases where thecomputer105 actually comprises multiple devices, the CAN bus or the like may be used for communications between devices represented as thecomputer105 in this disclosure.
In addition, thecomputer105 may be configured for communicating with thenetwork120, which, as described below, may include various wired and/or wireless networking technologies, e.g., cellular, Bluetooth, wired and/or wireless packet networks, etc. Further, thecomputer105, e.g., in the module106, generally includes instructions for receiving data, e.g., from one ormore data collectors110 and/or a human machine interface (HMI), such as an interactive voice response (IVR) system, a graphical user interface (GUI) including a touchscreen or the like, etc.
Generally included in instructions stored in and executed by thecomputer105 is an autonomous driving module106. Using data received in thecomputer105, e.g., fromdata collectors110, data included asstored parameters116, theserver125, etc., the module106 may controlvarious vehicle101 components and/or operations without a driver to operate thevehicle101. For example, the module106 may be used to regulatevehicle101 speed, acceleration, deceleration, steering, distance between vehicles and/or amount of time between vehicles, lane-change minimum gap between vehicles, left-turn-across-path minimum, time-to-arrival, intersection (without signal) minimum time-to-arrival to cross the intersection, etc. Further, the module106 may learn the desired speed, acceleration, deceleration steering, car following time headway, lane change minimum gap, turn-across path minimum time-to-arrival, etc., based on specific previously visited locations and/or traversed routes and headings as driven by aparticular vehicle101 driver, thereby providing a naturalistic feel relative to what the driver expects to experience, e.g., by providing operations at specific locations that mimic maneuvers that the driver may have performed.
Data collectors110 may include a variety of devices. For example, various controllers in a vehicle may operate asdata collectors110 to provide collecteddata115 via the CAN bus, e.g., collecteddata115 relating to vehicle speed, acceleration, etc. Further, sensors or the like, global positioning system (GPS) equipment, etc., could be included in a vehicle and configured asdata collectors110 to provide data directly to thecomputer105, e.g., via a wired or wireless connection.Data collectors110 could also include sensors or the like for detecting conditions outside thevehicle101, e.g., medium-range and long-range sensors. For example,sensor data collectors110 could include mechanisms such as RADAR, LADAR, sonar, cameras or other image capture devices, that could be deployed to measure a distance between thevehicle101 and other vehicles or objects, to detect other vehicles or objects, and/or to detect road conditions, such as curves, potholes, dips, bumps, changes in grade, etc.
Adata collector110 may further includebiometric sensors110 and/or other devices that may be used for identifying an operator of avehicle101. For example, adata collector110 may be a fingerprint sensor, a retina scanner, orother sensor110 providingbiometric data105 that may be used to identify avehicle101 operator. Alternatively or additionally, adata collector110 may include a portable hardware device, e.g., including a processor and a memory storing firmware executable by the processor, for identifying avehicle101 operator. For example, such portable hardware device could include an ability to wirelessly communicate, e.g., using Bluetooth or the like, with thecomputer105 to identify avehicle101 operator.
A memory of thecomputer105 generally stores collecteddata115. Collecteddata115 may include a variety of data collected in avehicle101 fromdata collectors110. Examples of collecteddata115 are provided above, and moreover,data115 may additionally include data calculated therefrom in thecomputer105. In general, collecteddata115 may include any data that may be gathered by acollection device110 and/or computed from such data. Accordingly, collecteddata115 could include a variety ofdata115 related tovehicle101 operations and/or performance, as well as data related to in particular relating to motion of thevehicle101. For example, collecteddata115 could include data concerning avehicle101 speed, acceleration, braking, lane changes and or lane usage (e.g., on particular roads and/or types of roads such as interstate highways), average distances from other vehicles at respective speeds or ranges of speeds, and/orother data115 relating to avehicle101 operator's historical and/or preferred driving style.
A memory of thecomputer105 may further store one ormore parameters116 for determining one or more modes of autonomously operating thevehicle101. Aparameter116 generally may be based on collecteddata115, and may be used to determine anautonomous vehicle101 mode or modes according to one or more values in collecteddata115. Various categories of autonomous modes are possible at a global level, e.g., affecting a plurality of sub-modes in thevehicle101, and/or at a more granular, e.g., sub-mode level. For example,parameters116 could be used for globally specifying different modes of operating theautonomous vehicle101 including a sport mode, a standard mode, and a comfort mode. In a sport mode according to this example, thevehicle101 may operate at or within a limit in excess of posted speed limits, perhaps based on surrounding traffic patterns; change lanes whenever desirable to maintain or increasevehicle101 speed. Further,parameters116 could be used for specifying sub-modes, i.e., particular attributes ofvehicle101 operation.
Advantageously,parameters116 may be used to promote not onlyvehicle101 operator comfort and safety, but also to benefit other vehicles, e.g., by promoting better traffic flow. For example, where avehicle101 operator is comfortable with a more aggressive driving style, e.g., frequent lane changes, closer following distances, etc., thenparameters116 can be set accordingly, e.g., to a “sport” mode. Allowing for such a more aggressive driving style may allow thevehicle101 to move more efficiently in traffic, and prevent thevehicle101 from hindering, and in fact allow thevehicle101 to enhance, traffic flow.
A few examples ofparameters116 are provided in Table 1 below.
| TABLE 1 |
|
| Parameter | Possible Parameter Attribute Settings |
|
| Global | Sport (e.g.,parameters 116 for sub-modes such as those |
| identified below could be set to “sport”) |
| Global | Moderate (e.g.,parameters 116 for sub-modes such as |
| those identified below could be set to “moderate”) |
| Global | Comfort (or conservative) (e.g.,parameters 116 for sub- |
| modes such as those identified below could be set to |
| “conservative”) |
| Lane Changes | Sport - change lanes whenever will increase vehicle |
| speed at or within 10 mph of posted speed limit |
| Lane Changes | Moderate - change lanes to increase vehicle speed |
| but never in excess of posted speed limit |
| Lane Changes | Conservative - change lanes only to avoid obstacles, |
| speed in below predetermined threshold, and speed |
| in next lane is faster by a predetermined amount |
| Acceleration | Sport - accelerate as rapidly as possible remaining |
| within accepted limits of occupant safety andvehicle |
| 101 powertrain operation |
| Acceleration | Moderate - accelerate at a moderate rate |
| Acceleration | Conservative - accelerate at a slow rate |
| Speed | Sport - operate thevehicle 101 at or within 5 mph |
| above posted speed limits |
| Speed | Moderate - operate thevehicle 101 at or below |
| posted speed limits |
| Speed | Conservative - operate thevehicle 101 at least 5 mph |
| below posted speed limits |
| Following | Minimum - operate thevehicle 101 at a minimum safe |
| distance | following distance from other vehicles depending on |
| thevehicle 101 speed |
| Following | Medium - operate thevehicle 101 at a minimum safe |
| distance | following distance plus a specified extra margin from |
| other vehicles depending on thevehicle 101 speed |
| Following | Maximum - operate thevehicle 101 at a minimum |
| distance | safe following distance plus a specified extra margin |
| (greater than the medium margin from other vehicles |
| depending on thevehicle 101 speed |
| Turn clearance | Minimum - provide a minimum distance from othe |
| rvehicles when turning in an intersection (could be |
| different parameters 116 for left and right turns) |
| Turn clearance | Medium - provide a medium distance from other |
| vehicles when turning in an intersection (could be |
| different parameters 116 for left and right turns) |
| Turn clearance | Maximum - provide a maximum distance from other |
| vehicles when turning in an intersection (could be |
| different parameters 116 for left and right turns) |
|
Many other examples ofparameters116, beyond the few examples listed in Table 1, are possible. For example, aparameter116 could include a time of day, a day of year, etc. Further, atime parameter116 could be used to determine at least in partother parameters116. For example, an aggressive driving style may be desired during daytime hours, where as a moderate or conservative driving style may be desired during evening hours. Accordingly, collecteddata115, e.g., from aclock data collector110, could be used to invoke anappropriate time parameter116. Likewise, collecteddata115 and/or data provided from theserver125 could be used to indicate weather conditions, road conditions, traffic conditions, driving environment (e.g., city vs. highway), etc., which then could be used in determining appropriate driving styles. For example, a driver may ordinarily prefer an aggressive driving style, but during wet, snowy, etc., conditions, a conservative driving style may be warranted, andparameters116 could be adjusted accordingly. Further for example,certain parameters116 could be adjusted according to traffic conditions, e.g., a followingdistance parameter116 may be set to allow a shorter following distance when traffic is moving slowly, alane change parameter116 may be set to allow for fewer lane changes when traffic is moving slowly, etc. Yet further for example,parameters116 could be adjust for road conditions, e.g., a very bumpy road could warrant increasing following distances, allowing for greater braking distances, etc. Likewise, a driving environment could affectparameters116; for example, following distances may be more compressed in city driving and greater in highway driving, and therefore differences in different levels ofparameters116 for following distance may be less for city driving that for highway driving.
In general, aparameter116 may be stored in association with an identifier for a particular user or operator of thevehicle101, i.e.,parameters116 are generally specified forparticular vehicle101 operators. As mentioned above, thecomputer101 may use mechanisms, such as a signal from a hardware device identifying avehicle101 operator, biometric collecteddata115, etc., to identify aparticular vehicle101 operator whoseparameters116 should be used.
Appropriate parameters116 to be associated with aparticular vehicle101 operator, e.g., according to an identifier for the operator, may be determined in a variety of ways. For example, thevehicle101 operator could use an HMI or the like to specifyparameters116 either singly or in combinations. Likewise, thevehicle101 operator could use an interface, e.g., a webpage or the like, to specifyparameters116 to theserver125 for storage in thedata store130. Similarly, thedata store130 may associate certain selected operator preferences with a level of driving skills/experience. In addition thedata store130 may contain restrictions, or lift restrictions, related tocertain parameters116 based on traffic conditions.Such parameters116 could then be downloaded via thenetwork120 to one ormore vehicles101.
Additionally or alternatively,parameters116 could be based at least in part on operator characteristics, e.g., identified by use of biometric data collectors, an operator profile stored in thecomputer105 and/or retrieved from theserver125, etc. For example, factors such as an operator's age, level of driving experience, estimated time to respond tovehicle101 events (e.g., when the module106 requires operator input concerning turning, braking, object avoidance, etc.), general health, comfort levels withvarious vehicle101 speeds, following distances, lane changes, etc., could be taken into account. In one example, aglobal parameter116 could be set to a “conservative” level forvehicle101 operators older than a threshold age and/or forvehicle101 operators below a threshold amount of driving experience. For allother vehicle101 operators in this example, theglobal parameter116 could default to “moderate.”
Yet further additionally or alternatively, thecomputer105 and/or theserver125 could determineparameters116 based on usage of one ormore vehicles101 by an operator. For example, acomputer105 could store historical collecteddata110 reflecting manual operation of thevehicle101 by the operator. Such collecteddata115, e.g., reflecting acceleration and/or braking patterns, speeds on various roads, lane change patterns, etc. could be used to generateparameters116. Further, collecteddata110 could be used to generateparameters116 not readily ascertainable according to user input. An example of such aparameter116 would be an operator's preferred jerk rate, i.e., a preferred rate of change of acceleration and/or deceleration. Although an operator may not know what a jerk rate is, or be able to specify a preferred jerk rate, collecteddata115 could be aggregated to determine historical average jerk rates for an operator, which could then be specified in aparameter116 for thevehicle101 operator.
Moreover, various mathematical, statistical and/or predictive modeling techniques could be used to generate and/or adjustparameters116. In a simple example,certain parameters116 including a desired following distance and/or time interval for avehicle101 to followother vehicles101 at a speed of 50 miles per hour, e.g., a following-time headway of 2.0 seconds, could be specified by default. Thecomputer105 could be configured to adjustsuch parameters116 based on an operator's manual operation of avehicle101. For example, if an operator generally followedother vehicles101 at a distance of 5 meters, the operator's historical following distance (5 meters) could be averaged with the default following distance (10 meters). Further, the operator's historical following distance could be weighted according to an amount of time that the operator was measured at the following distance, such that eventually theparameter116 governing following distance would converge from the default following distance to the operator's preferred, or historical, following distance of 5 meters.
More complex mathematical techniques are also possible, such as predictive modeling techniques that, based on driver behavior in certain situations, could be used to predictpreferred parameters116 forautonomous vehicle101 operations. For example, the statistical distribution of manual driving speeds (or driver-selected speeds) for a given road segment might be used to tailor factory settings in avehicle101 for automated driving and customize the autonomous driving modes to an individual operator. For instance, the 90thpercentile of speeds that a driver drives on a given road type might define “sport” mode speed, the 75thpercentile might define “standard” mode speed, and the 50thpercentile might define “comfort” mode speed. These percentile thresholds could be globally adjusted ifsensor data collectors110 detect slippery roads, unfamiliar roads (based on GPS coordinates and prior trip data), or other to-be-determined factors. Anautonomous vehicle101 operator, through an HMI of, and according to instructions in, acomputer105, could also be able to revert to “default” factory settings or save a set of autonomous driving settings that he or she wishes to be applied for a given mode selection.
Returning toFIG. 1, thenetwork120 represents one or more mechanisms by which avehicle computer105 may communicate with aremote server125 and/or a user device150. Accordingly, thenetwork120 may be one or more of various wired or wireless communication mechanisms, including any desired combination of wired (e.g., cable and fiber) and/or wireless (e.g., cellular, wireless, satellite, microwave, and radio frequency) communication mechanisms and any desired network topology (or topologies when multiple communication mechanisms are utilized). Exemplary communication networks include wireless communication networks (e.g., using Bluetooth, IEEE 802.11, etc.), local area networks (LAN) and/or wide area networks (WAN), including the Internet, providing data communication services.
Theserver125 may be one or more computer servers, each generally including at least one processor and at least one memory, the memory storing instructions executable by the processor, including instructions for carrying out various steps and processes described herein. Theserver125 may include or be communicatively coupled to adata store130 for storing collecteddata115 and/orparameters116. For example, one ormore parameters116 for a particular user could be stored in theserver125 and retrieved by thecomputer105 when the user was in aparticular vehicle101. Likewise, theserver125 could, as mentioned above, provide data to thecomputer105 for use in determiningparameters116, e.g., data concerning whether conditions, road conditions, construction zones, etc.
A user device150 may be any one of a variety of computing devices including a processor and a memory, as well as communication capabilities. For example, the user device150 may be a portable computer, tablet computer, a smart phone, etc. that includes capabilities for wireless communications using IEEE 802.11, Bluetooth, and/or cellular communications protocols. Further, the user device150 may use such communication capabilities to communicate via thenetwork120 including with avehicle computer105. A user device150 could communicate with avehicle101computer105 the other mechanisms, such as a network in thevehicle101, a known protocols such as Bluetooth, etc. Accordingly, a user device150 may be used to carry out certain operations herein ascribed to adata collector110, e.g., voice recognition functions, cameras, global positioning system (GPS) functions, etc., in a user device150 could be used to providedata115 to thecomputer105. Further, a user device150 could be used to provide a human machine interface (HMI) to thecomputer105.
Exemplary Process FlowsFIG. 2 is a diagram of anexemplary process200 for providing and/or managing various modes of operation of anautonomous vehicle101.
Theprocess200 begins in ablock205, in which thecomputer105 identifies avehicle101 operator. For example, when an operator starts thevehicle101, approaches thevehicle101, etc., a hardware device may provide a signal to thecomputer105 identifying operator,biometric data collectors110 could provide collecteddata115 by which thecomputer105 could identify the operator, etc. Further, implementations are possible in which theblock205 is omitted, i.e., an autonomous mode or modes may be selected for thevehicle101 without identifying an operator.
Following theblock205, in ablock210, thecomputer105 receives an operator selection of one or more autonomous modes. For example, an HMI such as described above could be used to receive operator input selecting an autonomous mode, e.g., aggressive, moderate, conservative, etc. Further, the HMI could be used to receive operator input concerning particular attributes, i.e., sub-modes, ofautonomous vehicle101 operation, such as preferred speeds, acceleration and/or braking patterns, lane change preferences, etc. in addition to, or as an alternative to, omitting theblock205, theblock210 could be omitted. For example, as discussed below,vehicle101 operator selection of an autonomous mode and/or sub-modes may not be necessary or desirable because an autonomous mode and/or sub-modes may be determined from historical patterns ofvehicle101 operation.
Next, in ablock215, thecomputer105 retrieves one ormore parameters116 for autonomous operation of thevehicle101. Examples ofparameters116 are provided above in Table 1. Further,parameters116 are generally retrieved according to the operator identifier determined as described above with respect to theblock205. That is,different vehicle101 operators may have different preferredparameters116, as mentioned above. Moreover, as also mentioned above,parameters116 may be modified or adjusted for avehicle101 operator based on historical collecteddata115 and/or various mathematical techniques. In some cases, a set ofdefault parameters116 may be retrieved, e.g., because an operator has not previously specifiedparameters116, nohistorical data115 exists and/or has been used for modifyingdefault parameters116, etc.
Next, in a block220, thevehicle101 commences autonomous driving operations using theparameters116 retrieved as described above with respect to theblock215. Thus, thevehicle101 is operated partially or completely autonomously, i.e., a manner partially or completely controlled by the autonomous driving module106, and at least partially according to one ormore parameters116. For example, allvehicle101 operations, e.g., steering, braking, speed, etc., could be controlled by the module106 in thecomputer105. It is also possible that, in the block220, thevehicle101 may be operated in a partially autonomous (i.e., partially manual, fashion, where some operations, e.g., braking, could be manually controlled by a driver, while other operations, e.g., including steering, could be controlled by thecomputer105. Likewise, the module106 could control when avehicle101 changes lanes. Further, it is possible that theprocess200 could be commenced at some point aftervehicle101 driving operations begin, e.g., when manually initiated by a vehicle occupant through a user interface of thecomputer105.
Following the block220, in ablock225, thecomputer105 determines whether to change or adjust an autonomous driving mode, i.e., whether to change or adjust one ormore parameters116. For example, as noted above,parameters116 may vary according to a time of day, weather conditions, a type of road (e.g., gravel, paved, interstate, city street, etc.), etc. Accordingly,parameters116 may be changed or adjusted based on collecteddata115 and/or data provided from theserver125.
If it is determined in theblock225 thatparameters116 should be adjusted or changed, i.e., because of new data such as new collecteddata115, then theprocess200 returns to theblock215. Otherwise, ablock230 is executed next.
In theblock230, thecomputer105 determines whether operator input has been received to change or adjust one or more autonomous modes. For example, an operator could provide input to change a mode from aggressive to conservative, etc. Further for example, an operator could provide input to change a sub-mode or attribute, e.g., the operator could provide input to an HMI of thecomputer105 by turning a knob, setting a control on a touchscreen, providing a voice command, etc., concerning an autonomous driving sub-mode such as following distance. For example, the operator could specify for thevehicle101 to increase its following distance at 50 miles per hour by two meters. In any event, if input is received to change or adjust an autonomous driving mode or modes, then theprocess200 returns to theblock210. Otherwise, theprocess200 proceeds to theblock235.
In theblock235, thecomputer105 determines whether theprocess200 should continue. For example, theprocess200 may end if autonomous driving operations end and a driver resumes manual control, if thevehicle101 is powered off, etc. In any case, if theprocess200 should not continue, theprocess200 ends following theblock235. Otherwise, theprocess200 returns to theblock210. Theprocess200 may also end if there is a change invehicle101 operators. In this case acurrent process200 could end andnew process200 could be initiated for thenew vehicle101 operator, e.g., starting in theblock205.
ConclusionComputing devices such as those discussed herein generally each include instructions executable by one or more computing devices such as those identified above, and for carrying out blocks or steps of processes described above. For example, process blocks discussed above may be embodied as computer-executable instructions.
Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java™, C, C++, Visual Basic, Java Script, Perl, HTML, etc. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer-readable media. A file in a computing device is generally a collection of data stored on a computer readable medium, such as a storage medium, a random access memory, etc.
A computer-readable medium includes any medium that participates in providing data (e.g., instructions), which may be read by a computer. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, etc. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes a main memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
In the drawings, the same reference numbers indicate the same elements. Further, some or all of these elements could be changed. With regard to the media, processes, systems, methods, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments, and should in no way be construed so as to limit the claimed invention.
Accordingly, it is to be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided would be apparent to those of skill in the art upon reading the above description. The scope of the invention should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the arts discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the invention is capable of modification and variation and is limited only by the following claims.
All terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by those skilled in the art unless an explicit indication to the contrary in made herein. In particular, use of the singular articles such as “a,” “the,” “said,” etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.