Definition of a driving envelope for driver assistance systems

Abstract

1. A computer-implemented method comprising: receiving sensor data from a sensor of a first vehicle associated with a first person, the sensor data generated by the sensor; applying a machine learning algorithm to the sensor data to define a driving envelope for a driver assistance system, the driver assistance system being installed in a second vehicle; and providing the driving envelope to the driver assistance system installed in the second vehicle.

Description

Technical Field

[0001] Cross-Reference to Related Applications This application claims priority to U.S. Patent Application No. 16 / 949,158, filed October 15, 2020, entitled "DEFINING DRIVING ENVELOPE FOR ASSISTED-DRIVING SYSTEM", the disclosure of which is hereby incorporated by reference in its entirety.

[0002] This document relates to the definition of a driving envelope for an assisted driving system.

Background Art

[0003] Vehicle transportation has become established in modern society. The majority of the population in many countries has a driver's license for one or more types of vehicles or, otherwise, the ability to operate those vehicles. While there are many different types of vehicles that such individuals can drive, the driving styles of many drivers also vary from one another. Any person who travels can observe significant variations among drivers with respect to driving skills, driving preferences, and driving practices. There are no two drivers exactly alike.

Summary of the Invention

[0004] Receiving sensor data from sensors of a first vehicle associated with a first person, the sensor data being generated by the sensors; applying a machine learning algorithm to the sensor data to define a driving envelope for an assisted driving system, the assisted driving system being introduced into a second vehicle; and providing the driving envelope to the assisted driving system introduced into the second vehicle. A computer-implemented method comprising the steps of.

[0005] The implementation may include any or all of the following features: The driver assistance system operates using at least one configuration parameter, the driver assistance system uses the driving envelope to determine a value for the configuration parameter; the configuration parameter controls at least one situation of the driver assistance system, the situation includes one or more of the distance between the second vehicle and an object, the speed of the second vehicle, the trajectory of the second vehicle, or the acceleration of the second vehicle; the step of applying the machine learning algorithm includes the step of identifying at least one event in the sensor data; and the step of tagging the identified event. The driver assistance system is also installed in the first vehicle, and the step of identifying at least one event further includes the step of considering the level of autonomous driving of the operation of the driver assistance system installed in the first vehicle when the sensor data was generated by the sensor. The driver assistance system is also installed in the first vehicle, and the step of identifying at least one event is performed by the driver assistance system. The step of identifying the at least one event further includes considering cases in which the first person takes control of the first vehicle from the driver assistance system installed in the first vehicle. The computer implementation method further includes performing batch updates of the driving envelope based on additional sensor data generated by the sensor over a period of time. The sensor data is received while the first person is driving the first vehicle. The sensor data is received while the driver assistance system is at least partially controlling the first vehicle, and the sensor data includes feedback from the first person to the driver assistance system. The feedback includes the first person taking control at least partially from the driver assistance system. The feedback includes input from the first person to the driver assistance system. The driver assistance system uses the driving envelope when performing actions on the second vehicle.The computer implementation method further comprises the steps of receiving user feedback from the first person regarding the execution of the action by the driver assistance system, and updating values ​​for configuration parameters of the driver assistance system based on the user feedback. The user feedback includes the first person taking control of the driver assistance system at least partially. The computer implementation method further comprises the step of prompting the first person to provide the user feedback, which is received in response to the prompting step. When the driving envelope is provided to the driver assistance system installed in the second vehicle, the second vehicle is being driven by the second person. The computer implementation method further comprises the step of receiving contextual data relating to the first vehicle, which relates to the first vehicle when the sensor data was generated by the sensor, and which includes quantitative or qualitative exogenous metrics. The second vehicle is the first vehicle. The driver assistance system installed in the second vehicle provides a query to a configuration manager, and the driving envelope is provided to the driver assistance system by the configuration manager in response to the query. The driver assistance system installed in the second vehicle provides the query to the configuration manager before taking action on the second vehicle, and the driving envelope specifies the status of the action. The driver assistance system installed in the second vehicle decides whether or not to provide the query to the configuration manager before taking action. When deciding whether or not to provide the query to the configuration manager before taking action, the driver assistance system installed in the second vehicle considers real-time data about the second vehicle. The driving envelope is defined to increase the likelihood of a successful handover from the driver assistance system by the first person.

[0006] In a second embodiment, a computer program product is tangibly embodied in a non-temporary storage medium, and the computer program product includes instructions that, when executed, cause a processor to perform an action, the action including: receiving sensor data from sensors of a first vehicle associated with a first person, the sensor data being generated by the sensors; applying a machine learning algorithm to the sensor data to define a driving envelope for a driver assistance system, the driver assistance system being installed in a second vehicle, and the driving envelope being defined to increase the likelihood of a successful takeover from the driver assistance system by the first person; and providing the driving envelope to the driver assistance system being installed in the second vehicle. [Brief explanation of the drawing]

[0007] [Figure 1] This shows an example of a system for defining the operating envelope.

[0008] [Figure 2] This flowchart shows an example of data collection for defining the operating envelope.

[0009] [Figure 3] A flowchart illustrating an example of the definition of a driving envelope is shown.

[0010] [Figure 4] This flowchart shows an example of a driving envelope used by a vehicle's driver assistance system.

[0011] [Figure 5A] This demonstrates the creation of a driving envelope for a vehicle and its use in performing actions on the vehicle. [Figure 5B] This demonstrates the creation of a driving envelope for a vehicle and its use in performing actions on the vehicle.

[0012] [Figure 6] This shows another example of using a driving envelope in performing actions on a vehicle.

[0013] [Figure 7] This shows another example of using a driving envelope in performing actions on a vehicle.

[0014] [Figure 8A] This shows another example of using the driving envelope in performing actions on a vehicle. [Figure 8B] This shows another example of using the driving envelope in performing actions on a vehicle.

[0015] [Figure 9] This shows another example of using a driving envelope in performing actions on a vehicle.

[0016] [Figure 10] This document illustrates an exemplary architecture of a computing device that can be used to carry out aspects of this disclosure.

[0017] Similar reference numerals in various drawings indicate the same elements. [Modes for carrying out the invention]

[0018] This document describes examples of systems and techniques for defining a driving envelope for a driving assistance system. The driving envelope can be defined, for example, for the purpose of improving safety in situations where a driver is required to take over as a fallback for dynamic driving tasks or non-dynamic driving tasks such as those being performed by a driving assistance system. For example, in the J3016 classification system published by SAE International, so-called SAE levels 2 and 3 modes are defined, which rely on the driver to take over from the automated system in the case of unresolved defects in the automated system. Such and other scenarios are based on the implicit premise that it is actually possible for the driver to take over and maintain control of the vehicle at this time, but this may not always be a valid premise. The systems and techniques described herein can infer the situation and context for a driving scenario and calculate a driving envelope that is similar or identical to what a driver would operate in the absence of automation. Using such a driving envelope, a driving assistance system can plan its behavior and actions to improve (e.g., increase or optimize) the likelihood that a driver will successfully take over control of the vehicle. Also, multiple such driving envelopes can be maintained in a database (e.g., on-vehicle or in the cloud) and made available by this database for customizing the driving assistance system for any number of drivers. This subject matter can be applied to vehicles operating at any of levels 1-5 described above.

[0019] In some implementations, driver behavior information and related context information can be collected under different environmental conditions and at the occurrence of different driving events. This can be based on, to name just a few, traffic density; weather conditions; and whether the driving context is highway, or urban or rural environment. Accumulation and processing of such data can enable extraction of one or more situations (e.g., speed of travel, distance to another object, and / or other factors) that describe what the driver does. The driving envelope can be defined based on at least one situation extracted from such processed data.

[0020] In some implementations, the definition of the driving envelope described herein and its use by a driving assistance system can smooth at least the following two aspects. First, by applying the driving envelope to the driving assistance system, the driving assistance system can attempt to ensure that it does not exceed the limits regarding situations where handover is comfortable or possible for this driver. Second, this can provide for the driving assistance system to operate such that the person is more comfortable during the automation phase. For example, it can make the ride more enjoyable for the person, and / or can cause the person to confirm that the driving assistance system is operating safely by virtue of that experience.

[0021] Some implementations can offer one or more advantages. For example, the entire activity of automating some or all vehicle functions can be made safer by increasing the likelihood of the driver successfully taking over from the driver assistance system. User experience and / or user trust in the driver assistance system can be improved. For example, drivers may no longer need to customize the driver assistance system according to their personal driving skills, driving preferences, or driving practices. Vehicle design can be simplified. For example, vehicle designers may no longer need to identify and define system configuration settings (which may be performed with tens or hundreds of individually adjustable parameters) or generate separate input controls for them.

[0022] In the examples herein, we refer to vehicles. A vehicle is a machine that transports occupants, cargo, or both. A vehicle may have one or more motors that use at least one type of fuel or other energy source (e.g., electricity). Examples of vehicles include, but are not limited to, automobiles, trucks, and buses. The number of wheels may vary depending on the type of vehicle, and one or more (e.g., all) of the wheels may be used for propulsion. A vehicle may have an occupant compartment that accommodates one or more persons. At least one vehicle occupant may be considered the driver; in this case, various tools, instruments, or other devices may be provided to the driver. In the examples herein, the vehicle that is the subject of the example (e.g., one vehicle with a driver assistance system) may be referred to as the “own vehicle.” One or more other vehicles may be referred to as the “leading vehicle.”

[0023] The examples herein refer to driver assistance (e.g., performed by driver assistance systems). Driver assistance includes at least partially automating one or more dynamic driving tasks. Advanced driver assistance systems (ADAS) are an example of driver assistance systems that can perform driver assistance. Driver assistance is typically performed in part on the output of one or more sensors located on, under, or inside the vehicle. Autonomous vehicles are an example of systems that perform driver assistance, but not all driver assistance systems are designed to provide fully autonomous vehicles. SAE International has defined several levels of driving automation, typically referred to as levels 0, 1, 2, 3, 4, and 5, respectively. For example, a level 0 system or driving mode does not have to include continuous vehicle control by the system. For example, a level 1 system or driving mode may include adaptive cruise control, emergency brake assist, automatic emergency brake assist, lane keeping, and / or lane centering. For example, a level 2 system or driving mode may include highway assist, autonomous obstacle avoidance, and / or autonomous parking. For example, a Level 3 or 4 system or driving mode may include incremental control of the vehicle by a driver assistance system. For example, in a Level 5 system or driving mode, human intervention with the driver assistance system may not be required.

[0024] The examples herein refer to sensors. Sensors are configured to detect changes in one or more conditions of an event and / or its environment and to output a signal that reflects that detection. As merely illustrative examples, sensors may indicate one or more of the following: the distance between a vehicle and an object, the speed of a vehicle, the trajectory of a vehicle, the acceleration of a vehicle, or an action taken by a driver on a vehicle. Examples of sensors that can be used with one or more embodiments include, but are not limited to, optical sensors (e.g., cameras); scanning systems (e.g., lidars); wireless sensors (e.g., radars); acoustic sensors (e.g., ultrasonic devices and / or microphones); inertial measurement units (e.g., gyroscopes and / or accelerometers); speed sensors (e.g., for a vehicle or its components); driver-operated vehicle controls (e.g., switches, buttons, sliders); user-operated vehicle input controls; location sensors (e.g., for a vehicle or its components); orientation sensors (e.g., for a vehicle or its components); torque sensors; temperature sensors (e.g., primary or secondary thermometers); pressure sensors (e.g., for ambient air or vehicle components); humidity sensors (e.g., rain detectors); or seat occupancy sensors.

[0025] The examples herein refer to driving envelopes. Driving envelopes include functions, tables, or curves. Driving envelopes link together multiple vehicle states, thereby they can be used to determine or generate one or more values ​​(e.g., a range of values) for at least one configuration parameter of a driver assistance system. These values ​​may include, to name just two, configuration parameters and / or configuration constraints. Configuration parameters can be defined to control at least one situation of a driver assistance system. Driving envelopes can be specific to individual drivers or to the type or category of drivers. A driving envelope individually tailored for a particular driver is a representation of specific situations in that person's driving style to define the driving situations that are comfortable (or uncomfortable) for that driver. Such preferences may differ depending on whether the vehicle is currently being driven by that person or by a driver assistance system. Accordingly, an individual driver's preferences regarding their own driving are not necessarily directly replaceable by the same driving envelope for a driver assistance system. Rather, differences in preference may exist between these two. The driving envelope can be defined based on one or more independent variables. For example, the driving envelope can be a function of the detected event context, vehicle yaw rate, and vehicle speed.

[0026] The examples in this specification refer to the possibility of a successful takeover. A takeover is a situation in which a human driver takes over control from a driver assistance system. This can occur when the driver assistance system enters a state that requires the driver to take control (e.g., when detecting an obstacle), or when the person voluntarily chooses to take charge of the vehicle. A takeover can be considered successful if the human driver feels comfortable with the driving tasks that occur during the takeover and for a limited time thereafter. In some implementations, a voluntary takeover can be considered successful if the driver does not re-engage the driver assistance system within a predetermined time. In the examples above, the length of the specific time may depend on the situation and / or the driver. For example, after a successful takeover, the driver may be able to control the vehicle in a normal manner for at least a few seconds (e.g., a few seconds or tens of seconds).

[0027] The examples herein refer to a human being as the driver of a vehicle. As used herein, the term driver includes a person being transported by a vehicle, regardless of the state of any automation installed in the vehicle and regardless of whether the vehicle's driver assistance systems are currently active. Thus, for brevity, a person may be referred to here as the driver of a vehicle both when the person is driving the vehicle and when the driver assistance systems are operating.

[0028] The examples herein refer to events. An event is a concrete or abstract occurrence that can be detected by one or more systems. An event may include one or more operations that are identified as elements of a discrete set. An event may include sub-events that occur simultaneously with each other or within a common time span defined by that event. Examples of events include, but are not limited to, changing lanes, following a lead vehicle, remaining in a lane without a lead vehicle, or creating a gap to allow another vehicle to enter a lane. Events may include dynamic driving tasks and / or non-dynamic driving tasks (including, but are not limited to, tasks that maintain the current speed and current lateral lane position for a vehicle).

[0029] The examples herein refer to context relating to the driver and / or vehicle. Context is one or more quantitative or qualitative exogenous metrics temporarily related to an event. Exogenous metrics for the vehicle or driver are metrics external to the vehicle and its systems and / or the driver, respectively. Causal relationships between context and events are sometimes evident or can be inferred, but causality is not required. Examples of context include, but are not limited to, weather (e.g., precipitation, temperature, or light conditions); traffic conditions (e.g., average speed, density, or order); vehicle conditions (e.g., speed, acceleration, trajectory, occupancy, occupant cabin climate, or infotainment system operating status); and road conditions (e.g., curve radius, bank angle, number of lanes, surface material, surface condition, surface traction).

[0030] The examples herein refer to machine learning algorithms. As used herein, a machine learning algorithm can include an implementation of artificial intelligence in which a machine, such as a driver assistance system, has the ability to perceive its environment and take action to achieve one or more goals. A machine learning algorithm can apply one or more principles of data mining to derive a driving envelope from data collected about a vehicle and its associated circumstances. A machine learning algorithm can be trained in one or more aspects. For example, supervised, semi-supervised, and / or unsupervised training can be performed. In some implementations, a machine learning algorithm can use one or more classifiers. For example, a classifier can assign one or more labels to recognized instances in the processed data. In some implementations, a machine learning algorithm can use one or more forms of regression analysis. For example, a machine learning algorithm can apply regression to determine one or more numerical values. In some implementations, a machine learning algorithm can be configured to collect and store data, use this data to detect events, use this data to identify context, and generate a driving envelope based at least in part on the detected events and context.

[0031] Figure 1 shows an example of a system 100 that defines a driving envelope. System 100 can be used in conjunction with one or more other examples described elsewhere in this specification. System 100 and / or one or more of its components can be operated by at least one processor that executes instructions stored in a computer-readable medium, as described below, for example with reference to Figure 10. In some implementations, system 100 can be configured to define a driving envelope in such a way that it increases the likelihood of a successful handover from a human-operated driving assistance system.

[0032] System 100 can partially define a driving envelope by collecting and processing data about how a person operates a vehicle. System 100 receives one or more inputs 102, conceptually shown here as boxes. Inputs 102 may include sensor readings from any or all of the vehicle's sensors. For example, input 102 may reflect or indicate the situation regarding the vehicle and / or actions taken by the driver. Input 102 may reflect or indicate the occurrence of one or more events and / or driver triggers in the presence of one or more contextual parameters. For example, input 102 may reflect or indicate a lane change event. As another example, input 102 may reflect or indicate that the driver took (or did not take) one or more actions that triggered a response from the vehicle. As yet another example, input 102 may reflect or indicate the presence or absence of one or more ambient conditions (e.g., the presence or absence of a particular weather phenomenon). In some implementations, input 102 may include sensor data that reflects how a person drives the vehicle. For example, this could allow for the analysis of the person's driving preferences and characteristics, which could then be taken into consideration when generating the driving envelope. In some implementations, input 102 may include sensor data that reflects the user's response to how the driver assistance system controls the vehicle. For example, the user can provide feedback by taking over control of the vehicle from the driver assistance system. As another example, the user can provide feedback by entering their opinion into a user interface (e.g., a feedback form) regarding how the driver assistance system controls the vehicle.

[0033] System 100 includes a system 104 for data acquisition and storage. System 104 can receive one or more of the inputs 102, process the inputs 102, and generate at least one output. In some implementations, system 104 is installed in a vehicle. For example, system 104 can be characterized as an onboard system.

[0034] System 104 may include an event detection component 106. In some implementations, the event detection component 106 can detect behaviors and / or operations performed by the driver. In some implementations, the event detection component 106 can monitor the driver's behavior and identify the above operations as elements of one or more discrete sets. Examples include, but are not limited to, lane changes, following a lead vehicle in a lane, remaining in a lane without a lead vehicle, sudden braking, or a decrease or increase in time intervals. The event detection component 106 can identify quantitative or qualitative exogenous metrics associated with or characterizing an event. Examples include, but are not limited to, determining the duration and / or speed of a lane change, determining the time interval relative to a lead vehicle when following, determining the speed at which the driver remains in a lane when no lead vehicle is present, and / or determining the degree of deceleration when creating a gap in front of the vehicle to allow another vehicle to enter the lane. The event detection component 106 may include one or more situations of machine learning algorithms. In some implementations, the event detection component 106 may depend on or be provided by a driver assistance system for the vehicle. For example, the driver assistance system may be installed in the same vehicle, and event detection may be performed by that driver assistance system. In some implementations, the event detection component 106 may identify at least one event in the data from the input 102 and tag the identified event.

[0035] The event detection component 106 can be installed in vehicles that do not have a driver assistance system, or in vehicles that do have a driver assistance system. In the latter scenario, the driver assistance system can be active or inactive while data is being collected by system 104. For example, if the driver assistance system is operational, events detected by system 104 can be attributed partly to the driver and partly to the driver assistance system. Accordingly, the event detection component 106 can depend on the operational status of the driver assistance system when detecting events. For example, event identification may include considering the level of autonomous driving of the driver assistance system installed in the vehicle when sensor data is generated by the input sensor 102.

[0036] Detecting an event may include determining that the driver has taken control of the vehicle. For example, the event detection component 106 may determine that the driver took control of the vehicle at a specific time, even though the driver assistance system is not in a fault condition or has not otherwise requested a driver takeover. Such a determination may be associated with event detection.

[0037] System 100 can be installed in a vehicle for the purpose of collecting data on how a person operates the vehicle. Such data can be processed to define one or more driving envelopes that will be applied when a person is driving a vehicle equipped with a driver assistance system. The vehicle to which the driving envelope is applied may be the same vehicle, or a vehicle of the same model and / or construction, as the vehicle from which the data was collected. Alternatively, the vehicle to which the driving envelope is applied may be a different vehicle from the vehicle from which the data was collected.

[0038] Here, system 104 includes a context identification component 108. The context identification component 108 can detect external operating conditions that cause a driver to perform (or not perform) an operation detected as an event. In some implementations, the context identification component 108 can collect quantitative or qualitative exogenous metrics related to the event. In some implementations, the context identification component 108 can tag weather, traffic conditions, road curvature, and / or road conditions. The context identification component 108 may include one or more machine learning algorithms.

[0039] Here, system 104 includes an onboard data recorder 110. The onboard data recorder 110 can record information output by the event detection component 106 and the context identification component 108. In some implementations, the onboard data recorder 110 can facilitate the data residing in one or more locations by storage 112. For example, storage 112 may include an on-site / cloud data store 114. As another example, storage 112 may include an onboard data store 116. The data located in storage 112 may have one or more formats suitable for processing to be performed later. For example, the output from the event detection component 106 and / or the context identification component 108 may be formatted before storage.

[0040] Here, system 100 may include a component 118 that is responsible for the task of creating a driving envelope and generating a configuration for the driver assistance system 120. In some implementations, component 118 identifies at least one configuration parameter for the driver assistance system 120, determines a value for the configuration parameter, and provides that value to the driver assistance system 120. Such a configuration parameter can control at least one situation of the driver assistance system 120. For example, the driving envelope can adjust the relationship between the yaw rate r currently applied to the front wheels of the vehicle and the side slip β currently experienced by the vehicle. In some implementations, component 118 can implement a learning-based software algorithm to infer the driving envelope from information about the driving performed by that person. For example, from that data, it can be inferred that, on a highway at 65 mph (104.61 km / h), with rainfall exceeding 0.5 inches (12.7 millimeters) per hour, and with no traffic, a person would typically slow down to about 55 miles per hour (mph) (88.51 km / h) for a curve with a radius of about 200 meters. Other types of inferences can be made, including the same or different criteria. In some implementations, component 118 can distinguish between drivers who find a particular operation comfortable when they are in control and drivers who find the same operation more comfortable or uncomfortable under the same road and weather conditions when the vehicle is controlled by the driver assistance system 120.

[0041] The driving envelope can be stored in a format that allows convenient access (e.g., by query operations) to information related to one or more decisions made by the driver assistance system 120. In some implementations, one or more configuration values ​​can be stored in a table 122. For example, table 122 can be tailored to the context and event-driven configuration of the driver assistance system 120.

[0042] The driver assistance system 120 can retrieve information from table 122 to determine whether to perform one or more actions. For example, the driver assistance system 120 can query component 118 for such information. Alternatively, the driver assistance system 120 can directly access table 122. The retrieved information can enable the driver assistance system 120 to select limits on the actions to apply to one or more decisions. In some implementations, a cost function can be designed for a region defined by one or more action limits. For example, such action limits can describe the region in which the cost function is effective. In some implementations, the cost defined by the above function may increase as the vehicle's trajectory on the road deviates from the normal driving envelope, given the applicable context.

[0043] The above example shows that the method may include a step of receiving sensor data from sensors of a first vehicle (e.g., by input 102). Such sensor data may be generated by the sensors while a first person is driving the first vehicle. The method may include a step of applying a machine learning algorithm to the sensor data (e.g., from system 100) to define a driving envelope for a driver assistance system (e.g., for driver assistance system 120) (e.g., by component 118). The driver assistance system may be introduced in a second vehicle. The method may include a step of providing the driving envelope to the driver assistance system introduced in the second vehicle (e.g., as table 122).

[0044] Figure 2 shows a flowchart of Example 200 of data collection for defining a driving envelope. Example 200 can be used in conjunction with one or more other examples described elsewhere in this specification. Example 200 and / or one or more of its components can be operated by at least one processor that executes instructions stored in a computer-readable medium, as described below with reference to, for example, Figure 10. In some implementations, Example 200 can be used when defining a driving envelope to increase the likelihood of a successful handover from a human-assisted driving system.

[0045] Data 202 is entered into Example 200. In some implementations, Data 202 can be characterized as raw, real-time vehicle data. The data can come from one or more sensors in the vehicle (e.g., a dedicated sensor suite for a driver assistance system).

[0046] Data 202 can be provided to one or more situations in Example 200. Data 202 can be provided to Component 204. In some implementations, Component 204 can be responsible for detecting events in Data 202 and tagging the data according to those detections. For example, Component 204 can apply one or more situations of machine learning algorithms during its operation. Data 202 can be provided to Cloud 206.

[0047] Data 208 is entered into Example 200. In some implementations, Data 208 can be characterized as raw, real-time exogenous data, which can be contextual data related to the monitored vehicle. The data can come from one or more sensors on the vehicle (e.g., from a sensor suite dedicated to a driver assistance system) and / or from external sources (e.g., a weather reporting service, mapping service, or road condition reporter).

[0048] Data 208 can be provided to one or more situations in Example 200. Data 208 can be provided to Component 210. In some implementations, Component 210 can be responsible for detecting the context within Data 208 and tagging the data accordingly. For example, Component 210 can apply one or more situations of a machine learning algorithm during its operation. Data 208 can be provided to Cloud 206.

[0049] Component 204 can generate output 212. In some implementations, output 212 reflects the behavior or operation of the vehicle driver. Output 212 can be provided in a preferred format and stored in database 214.

[0050] Component 210 can generate output 216. In some implementations, output 216 reflects the qualitative or quantitative context of output 212 (for example, related to the behavior or operation of a vehicle driver). Output 216 can be provided in a preferred format and stored in database 214.

[0051] Database 214 can be updated with new information at regular intervals or at random times. In some implementations, database 214 is updated when components 204 and / or 210 generate new outputs. For example, as a result, updates to database 214 may occur with a gap of one or several minutes between them. As data accumulates in database 214, a software algorithm can update one or more operating envelopes to improve the accuracy or precision of their boundaries.

[0052] Figure 3 shows a flowchart of Example 300 of the definition of a driving envelope. Example 300 can be used in conjunction with one or more other examples described elsewhere in this specification. Example 300 and / or one or more of its components can be operated by at least one processor that executes instructions stored in a computer-readable medium, as described below with reference to, for example, Figure 10. In some implementations, Example 300 can be configured to define the driving envelope in a way that increases the likelihood of a successful handover from a driver assistance system to a human driver.

[0053] In Example 300, the database 214 provides information to a component 302 configured to perform one or more inferences based on that information. In some implementations, component 302 can infer driver skills, driver preferences, and / or driver practices about drivers from whom data has been collected and processed (e.g., tagged). Component 302 can output one or more driving envelopes 304. In some implementations, the driving envelopes 304 can define one or more controllable situations of the driver assistance system. For example, the driving envelopes 304 can be further or alternatively characterized as controllability envelopes. In Example 300, the driving envelopes 304 can be provided to a configuration manager 306. In some implementations, the configuration manager 306 controls configurations that will be applied to the driver assistance system to favor safe driver handover and a comfortable ride for the driver. For example, the configuration manager 306 may include one or more databases.

[0054] The configuration manager 306 database can be updated with new information at regular intervals or at random times. In some implementations, the database is updated when component 302 generates new output. For example, as a result, database updates may occur a day or several days apart from each other. In some implementations, batch updates of the operating envelope 304 are performed based on additional sensor data generated by the sensors over a period of time.

[0055] Figure 4 shows a flowchart of an example of a driving envelope 400 used by a vehicle's driver assistance system. Example 400 can be used in conjunction with one or more other examples described elsewhere in this specification. Example 400 and / or one or more of its components can be operated by at least one processor that executes instructions stored in a computer-readable medium, as described below with reference to, for example, Figure 10. In some implementations, Example 400 can be configured to provide a driving envelope that increases the likelihood of a successful handover from the driver assistance system by a person.

[0056] Here, the driver assistance system 402 decides whether or not to take action in the context currently represented by situation 404. For example, the driver assistance system 402 might decide whether or not to perform a lane change operation. The driver assistance system 402 can create a query 406 to the configuration manager 306. In some implementations, the query 406 indicates the intended operation. The driver assistance system 402 can query the configuration manager 306 in an effort to ensure that the intended behavior and operation are comfortable for the driver or within an envelope in which they are capable. This can attempt to ensure that the driver can take control of the vehicle when necessary. For example, this could include ensuring that the vehicle does not move too fast, does not position itself too close to other vehicles, and / or turns sharper than the driver could control the vehicle themselves. This query can attempt to ensure that the driver feels safe and comfortable during the operation. For example, this can increase the driver's trust in the driver assistance system 402 and their overall satisfaction with the vehicle and the experience.

[0057] The response to query 406 may include the configuration manager 306 accessing one or more databases. The configuration manager 306 may generate a driving envelope 408 in response to query 406, or the driving envelope 408 may be a predetermined driving envelope (e.g., a large dataset) provided in response to query 406. In some implementations, the driving envelope 408 includes one or more restrictions on the application or execution of an action intended by the driver assistance system 402. For example, the driving envelope 408 may include a speed limit. As another example, the driving envelope 408 may include restrictions on longitudinal and / or lateral acceleration. In some implementations, a combination of restrictions may be used. The result of applying the driving envelope 408 may be that the driver assistance system 402 initiates a lane change only if the distance between adjacent lanes (i.e., the distance between vehicles) is at least x feet (x centimeters) and the driver assistance system 402 has y seconds or more of free time to complete the action.

[0058] Assuming that the driver assistance system 402 decides to initiate the above action, the driver assistance system 402 may generate one or more outputs. In some implementations, the driver assistance system 402 outputs information corresponding to the track 410. The driving envelope 408 may have one or more specified or adjusted conditions for the track 410. The track 410 may correspond to causing the vehicle to take on a specific location, speed, acceleration, and rate of change of acceleration (sometimes called "jerk"). For example, the track 410 can be achieved by setting the steering angle of the wheels and the torque output of the propulsion motors. Here, execution 412 conceptually represents the use of the driving envelope 408 when performing the above action based on the track 410. The driver 414 is a human being, schematically represented here by a circle. The driver 414 receives execution 412 of the action planned and performed by the driver assistance system 402.

[0059] In some implementations, the driver assistance system 402 may not need to query the configuration manager 306 for every action performed. For one or more specific actions, the driving envelope 408 can essentially consist of at least one number that can be maintained in local storage accessible by the driver assistance system 402 without querying it. For example, if it is known that the driver 414 is sensitive to lateral acceleration, the driver assistance system 402 can ensure that no operations are planned that would increase the lateral acceleration beyond a certain value, without having to query the configuration manager 306 every time. That is, such a tuning parameter may always be enabled for the driver 414.

[0060] The configuration manager 306 and / or the driver assistance system 402 may benefit from the input of the real-time data provider 416. The real-time data provider 416 can provide one or more pieces of information that are considered when generating the driving envelope 408. In some implementations, comfort preferences for an event (e.g., lane change) may depend on the immediate situation, which can be reflected by input from the real-time data provider 416. For example, traffic density or the vehicle's speed. At lower speeds, the driver's comfort level may not be an important factor, but at higher speeds, comfort may be an important factor. Continuing the above example of performing an action without a query, the driver assistance system 402 can be provided with information that essentially describes the parameter values ​​that apply under visible conditions. If the weather changes, this can trigger the driver assistance system 402 to issue a query 406. That is, the driver assistance system 402 installed in the vehicle may consider real-time data about the vehicle when deciding whether or not to provide a query to the configuration manager before taking action.

[0061] The driver 414 may provide feedback 418 for the benefit of at least the configuration manager 306. The feedback 418 may be provided by the human-machine interface (HMI) 420. The driver 414 may indicate the feedback 418 by taking action on the vehicle (e.g., by taking control at least partially from the AD system 402), or by inputting the feedback 418 into a graphical user interface, or by speaking the feedback 418 into an audio interface. In some implementations, the driver 414 taking control of the vehicle while the AD system 402 is performing a driving task according to the driving envelope 408 can be detected as user feedback 418. For example, user feedback 418 may trigger the configuration manager 306 to adjust, eliminate, and / or add at least one condition of the driving envelope 408. In some implementations, Example 400 can prompt the driver 414 for feedback 418, and in response to this prompt, the feedback 418 can be received by the HMI 420. In some implementations, the driver 414 can provide feedback 418 regardless of whether Example 400 is configured to prompt for feedback, and regardless of whether any prompt has occurred.

[0062] To prompt feedback, the HMI 420 can identify the action in question (e.g., "the lane change just performed") to the driver 414, or, to avoid ambiguity, can present a prompt in close proximity to the action. For example, "like" and / or "dislike" buttons can be made available for selection by the driver 414. The HMI 420 can provide feedback 418 to the configuration manager 306. In some implementations, feedback 418 can be used for further adjustment (or elimination) of the driving envelope 408. For example, performed actions are tagged in virtually real-time as preferred or disliked by the driver 414, and / or the values ​​of configuration parameters are updated based on the feedback 418.

[0063] In some implementations, the driver 414 who receives the actions performed by the driver assistance system 402 may be the same person from whom the data used by the configuration manager 306 when defining the driving envelope 408 was obtained. For example, this can provide the advantage that the driving experience is tailored to the specific individual who is driver 414.

[0064] In some implementations, the driving envelope 408 can be generated based on driving data from two or more of the drivers 414. As another example, the driving envelope 408 can be applied to multiple separate driving situations involving different individuals as drivers 414. In scenarios involving so-called ride-sharing activities, two or more different individuals may act as drivers 414 of the same vehicle at different times. In such operations, feedback 418 can be collected from two or more ride-sharing drivers and used to tailor the driving envelope 408 to reasonably fit the group of individuals expected to become drivers 414.

[0065] Figures 5A and 5B illustrate examples 500 and 502 of creating a driving envelope for vehicle 504 and using it in performing actions on the vehicle. Example 500 or 502 may be used in conjunction with one or more other examples described elsewhere in this specification. Vehicle 504 is currently driving on a one-way roadway 506, traveling in one of two adjacent lanes. Here, vehicle 508 is also shown on roadway 506. In particular, vehicle 504 is currently located in the right lane, and vehicles 508A and 508B are currently located in the left lane. Here, the terms right and left are used from the perspective of the driver of vehicle 504.

[0066] The driver of vehicle 504 is referred to as driver A. Assume that driver A wants to change lanes and move from the right lane to the left lane. In this example, there is currently a distance of 510 between vehicles 508A and 508B along roadway 506. Driver A considers the distance 510 to be sufficient to make a lane change and therefore completes this operation. A data collection system monitoring vehicle 504 tracks and tags the relevant data. For example, the processed data may indicate that, under the current conditions of roadway 506 (e.g., traffic density, road quality, weather) and the current conditions of vehicle 504 (e.g., speed, occupancy), it is comfortable for driver A to complete a lane change of the current length of distance 510 (this action may cause vehicle 504 to experience some longitudinal and lateral acceleration). The above may be considered (e.g., together with other observed operations) in generating the driving envelope for driver A.

[0067] When a driving envelope is generated for driver A, it can be applied to the driver assistance system installed in vehicle 504. Here, we assume that a situation similar to that shown in Figure 5A occurs while the driver assistance system is active. That is, the driver assistance system intends to change lanes and move from the right lane to the left lane. The driver assistance system can query the configuration manager to find the relevant parameters. For example, the configuration manager may notify the driver assistance system that it is possible to perform the lane change as long as the distance between vehicles 508A and 508B is at least equal to distance 510 and the other conditions correspond to those when the driver data was tagged. In this example, the driver assistance system then performs the above action. This will be a comfortable experience for driver A. Furthermore, if a situation arises where driver A needs to take over control of vehicle 504 during the above action, it can be expected that the takeover will be successful.

[0068] Referring here to Figure 5B, the driver of vehicle 504' is referred to as driver B. In this example, there is currently a distance of 510' between vehicles 508A and 508B along roadway 506, and distance 510' is greater than distance 510 in Figure 5A. Assume that driver B wants to change lanes and move from the right lane into the left lane. Driver B considers distance 510' to be sufficient to make the lane change and therefore completes this operation. A data collection system monitoring vehicle 504' tracks and tags the relevant data. For example, the processed data may indicate that, under the current conditions of roadway 506 (e.g., traffic density, road quality, weather) and the current conditions of vehicle 504' (e.g., speed, occupancy), it is comfortable for driver B to complete the lane change at the current value of distance 510' (this action may cause vehicle 504' to experience some longitudinal and lateral acceleration). In generating the driving envelope for driver B, the above factors can be considered (for example, together with other observed operations).

[0069] When a driving envelope is generated for driver B, it can be applied to the driver assistance system installed in vehicle 504'. Here, we assume that a situation similar to that shown in Figure 5B occurs while the driver assistance system is active. That is, the driver assistance system intends to change lanes and move from the right lane to the left lane. The driver assistance system can query the configuration manager to find the relevant parameters. For example, the configuration manager may inform the driver assistance system that it is possible to perform the lane change as long as the distance between vehicles 508A and 508B is at least equal to the distance 510' and the other conditions correspond to those when the driver data was tagged. In this example, the driver assistance system then performs the above action. This will be a comfortable experience for driver B. Furthermore, if a situation arises where driver B needs to take over control of vehicle 504' during the above action, it can be expected that the takeover will be successful.

[0070] In contrast, applying the driving envelope for driver A to vehicle 504' transporting driver B may not yield successful results, just as in the two examples above. If vehicle 504' undergoes a lane change operation when the distance between vehicles 508A and 508B is only approximately equal to the distance 510, this could cause driver B to lose confidence in the driver assistance system. For example, driver B might subjectively perceive the action as dangerous or unpleasant. Furthermore, if a situation arises in that scenario requiring driver B to take control of vehicle 504', the likelihood of a successful takeover may be relatively low.

[0071] Similarly, applying the driving envelope for driver B to vehicle 504 transporting driver A may not yield the same successful results as when driver A's driving envelope was applied to driver A. If vehicle 504 attempts a lane change maneuver when the distance between vehicles 508A and 508B is only approximately equal to distance 510, the driver assistance system may abandon this action because distance 510 is shorter than distance 510'. Driver A may become uncomfortable and have a negative experience due to the driver assistance system.

[0072] Figure 6 shows another example 600 of the use of a driving envelope in performing an action on vehicle 602. Example 600 can be used in conjunction with one or more other examples described elsewhere in this specification. This example relates to adaptive cruise control. When vehicle 602 is traveling behind vehicle 604 in the same lane, the driver assistance system maintains an approximate distance of at least 606 between vehicles 602 and 604. If vehicle 604 accelerates, the driver assistance system may respond by accelerating vehicle 602 (optionally to a predetermined maximum speed). If vehicle 604 decelerates, the driver assistance system may respond by braking vehicle 602 to maintain an approximate distance of at least 606 between them. The distance 606 may be subject to a driving envelope.

[0073] In some implementations, driver C may prefer that distance 606 be relatively shorter than that preferred by driver D. For example, if driver C is in vehicle 602, a relatively short distance 606 may cause the driver assistance system to brake vehicle 602 more frequently. However, driver C may prefer that a relatively short distance 606 results in relatively fewer vehicles cutting into the lane between vehicles 602 and 604.

[0074] In contrast, when driver D is in vehicle 602, the distance 606 associated with driver D's driving envelope is relatively long, which may result in more vehicles cutting into the lane between vehicles 602 and 604. However, driver D may appreciate that the relatively long distance 606 allows the driver assistance system to brake vehicle 602 less frequently.

[0075] Figure 7 shows another example 700 of the use of a driving envelope in performing an action on a vehicle 702. Example 700 can be used in conjunction with one or more other examples described elsewhere in this specification. The vehicle 702 is currently moving through a curve 704 at a speed 706, which is schematically represented by a velocity vector. The turning of the vehicle 702 due to the curve 704 corresponds to the vehicle 702 (and the driver) experiencing a lateral acceleration 708, which is schematically represented by a force vector. The lateral acceleration 708 depends on how acute the curve 704 is (e.g., its radius of curvature at all points) and the speed 706. The driver E may prefer only the minimum deceleration (or no deceleration) of the speed 706 with respect to the curve and may not mind a relatively high instance of the lateral acceleration 708 when moving through the curve 704. The above can be taken into consideration (e.g., together with other observed operations) in generating a driving envelope for the driver E.

[0076] On the other hand, driver F may prefer a clearly discernible deceleration of speed 706 with respect to curves and may not feel comfortable with relatively high instances of lateral acceleration 708 when proceeding through curve 704. These factors can be taken into consideration (in conjunction with other observed operations, for example) when generating the driving envelope for driver F.

[0077] Figures 8A and 8B show other examples 800 and 802 of the use of a driving envelope in performing an action on vehicle 804. Examples 800 and 802 can be used in conjunction with one or more other examples described elsewhere in this specification. In example 800, vehicle 804 is currently stopped on the roadway 810 at a distance of 806 from vehicle 808, and vehicle 808 is also stationary. That is, no vehicles visible on the roadway 810 are currently moving due to congestion or traffic lights, etc. Driver G controls vehicle 804 to stop at a distance of 806 from vehicle 808, as is driver G's preference or customary practice. The above can be considered (in conjunction with, for example, other observed operations) in generating a driving envelope for driver G.

[0078] In Example 802, vehicle 804 is controlled by driver H and is currently stopped on the roadway 810, a distance 812 behind vehicle 808 which has begun to move forward. That is, the vehicle visible on the roadway 810 may have recently stopped due to congestion or traffic lights, etc., and the distance 812 is now increasing as vehicle 808 moves while vehicle 804 remains stationary. When the distance 812 from vehicle 808 increases to a certain length compared to the distance when vehicles 804 and 808 were stationary, driver H will begin moving vehicle 804 forward. Driver H does this as a preference or customary practice. The above can be considered (in conjunction with other observed operations, for example) in the generation of the driving envelope for driver H.

[0079] Figure 9 shows another example 900 of the use of the driving envelope in performing an action on a vehicle. Example 900 can be used in conjunction with one or more other examples described elsewhere in this specification. Vehicle 902 is currently driving on a one-way roadway 904, traveling in one of two adjacent lanes. Here, a large vehicle 906 (e.g., a tractor with one or more semi-trailers, or a bus) is also present on the roadway 904. The large vehicle 906 and vehicle 902 are currently side by side on the roadway 904. For example, the large vehicle 906 and vehicle 902 may be traveling at the same speed, or either the large vehicle 906 or vehicle 902 may currently be overtaking the other. Vehicle 902 is currently in the right lane, and the large vehicle 906 is currently in the left lane. Here, the terms right and left are used from the perspective of the driver of vehicle 902. Driver I controls vehicle 902 to create a distance 908 from larger vehicle 906 as a preference or customary practice of driver I. For example, distance 908 may be referred to as lane bias.

[0080] In some implementations, driver I may create distance 908 as part of taking over control, at least partially, from the driver assistance system of vehicle 902. For example, driver I may feel that the driver assistance system is using too little (or too much) lane bias for a large vehicle 906, and therefore prefer to take over control to increase (or decrease) the lane bias. Accordingly, the driver assistance system may interpret the takeover by driver I as user feedback about the lane bias so that it applies a different lane bias thereafter (e.g., corresponding to distance 908).

[0081] In generating the driving envelope for driver I, the above matters can be considered (for example, together with other observed operations).

[0082] Figure 10 shows an exemplary architecture of a computing device 1000 that can be used to carry out aspects of this disclosure, including any of the systems, apparatus, and / or techniques described herein, or any other systems, apparatus, and / or techniques that may be used in various possible embodiments.

[0083] The computing device shown in Figure 10 can be used to run the operating systems, application programs and / or software modules (including software engines) described herein.

[0084] In some embodiments, the computing device 1000 comprises at least one processing device 1002 (e.g., a processor), such as a central processing unit (CPU). Various processing devices are available from various manufacturers, e.g., Intel or Advanced Micro Devices. In this example, the computing device 1000 also comprises system memory 1004 and a system bus 1006 that connects various system components, including the system memory 1004, to the processing device 1002. The system bus 1006 is one of any number of available bus structures, including, but not limited to, a memory bus, or a local bus using any of the following: a memory bus, a memory controller, a peripheral bus, and various bus architectures.

[0085] Examples of computing devices that can be used with computing device 1000 include desktop computers, laptop computers, tablet computers, mobile computing devices (such as smartphones, touchpad mobile digital devices, or other mobile devices), or other devices configured to process digital instructions.

[0086] The system memory 1004 includes a read-only memory 1008 and a random-access memory 1010. A basic input / output system 1012, which includes basic routines that act to transfer information into the computing device 1000 at startup, etc., can be stored in the read-only memory 1008.

[0087] In some embodiments, the computing device 1000 also includes a secondary storage device 1014, such as a hard disk drive, for storing digital data. The secondary storage device 1014 is connected to the system bus 1006 by a secondary storage interface 1016. The secondary storage device 1014 and its associated computer-readable medium provide non-volatile and non-temporary storage of computer-readable instructions (including application programs and program modules), data structures, and other data for the computing device 1000.

[0088] The environments in the examples described herein use hard disk drives as secondary storage devices, but other embodiments may use other types of computer-readable storage media. Examples of these other types of computer-readable storage media include magnetic cassettes, flash memory cards, digital video discs, Bernoulli cartridges, compact disk read-only memory, digital versatile disk read-only memory, random access memory, or read-only memory. Some embodiments include non-temporary media. For example, computer program products can be tangibly embodied in non-temporary storage media. Furthermore, such computer-readable storage media may include local storage or cloud-based storage.

[0089] Multiple program modules, including an operating system 1018, one or more application programs 1020, other program modules 1022 (such as the software engine described herein), and program data 1024, can be stored in the secondary storage device 1014 and / or system memory 1004. The computing device 1000 may use any suitable operating system, such as Microsoft® Windows®, Google Chrome® OS, Apple® OS, Unix®, or Linux® and its variations, and any other operating system suitable for computing devices. Other examples may include Microsoft, Google, or Apple operating systems, or any other suitable operating system used in tablet computing devices.

[0090] In some embodiments, the user provides input to the computing device 1000 through one or more input devices 1026. Examples of input devices 1026 include a keyboard 1028, a mouse 1030, a microphone 1032 (for voice and / or other audio input), a touch sensor 1034 (such as a touchpad or touch-sensitive display), and a gesture sensor 1035 (for gesture input). In some implementations, the input devices 1026 provide detection based on presence, proximity, and / or motion. In some implementations, the user may walk into their home, which may trigger input to the processing device. For example, in this case, the input devices 1026 may facilitate an automated experience for the user. Other embodiments include other input devices 1026. The input devices can be connected to the processing device 1002 through an input / output interface 1036 coupled to the system bus 1006. These input devices 1026 can be connected by any number of input / output interfaces such as parallel ports, serial ports, game ports, or universal serial buses. Wireless communication between the input device 1026 and the input / output interface 1036 is also possible, and in some possible embodiments, to name just a few examples, includes infrared, Bluetooth® wireless technology, 802.11a / b / g / n, cellular, ultra-wideband (UWB), ZigBee®, or other radio frequency communication systems.

[0091] In this embodiment, a display device 1038, such as a monitor, liquid crystal display device, light-emitting diode display device, projector, or touch-sensitive display device, is also connected to the system bus 1006 via an interface such as a video adapter 1040. In addition to the display device 1038, the computing device 1000 may include various other peripheral devices (not shown), such as speakers or printers.

[0092] The computing device 1000 can connect to one or more networks through the network interface 1042. The network interface 1042 can provide wired and / or wireless communication. In some implementations, the network interface 1042 may include one or more antennas for transmitting and / or receiving wireless signals. When used in a local area networking environment or a wide area networking environment (such as the Internet), the network interface 1042 may include an Ethernet® interface. Other possible embodiments use other communication devices. For example, some embodiments of the computing device 1000 include a modem for communication over the network.

[0093] The computing device 1000 may include at least some form of computer-readable medium. The computer-readable medium includes any available medium that can be accessed by the computing device 1000. For example, the computer-readable medium includes computer-readable storage medium and computer-readable communication medium.

[0094] Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any device configured to store information such as computer-readable instructions, data structures, program modules, or other data. Computer-readable storage media include, but are not limited to, random-access memory, read-only memory, electronically erasable programmable read-only memory, flash memory or other memory technologies, compact disk read-only memory, digital versatile disk or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other media that can be used to store desired information and can be accessed by computing device 1000.

[0095] Computer-readable communication media typically embody computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and include any information distribution medium. The term “modulated data signal” refers to a signal whose one or more characteristics are set or modified in order to encode information into a signal. Examples of computer-readable communication media include wired media such as wired networks or direct wired connections, and wireless media such as acoustic, radio frequency, infrared, and other wireless media. Any combination of the above also falls within the scope of computer-readable media.

[0096] The computing device shown in Figure 10 is also an example of programmable electronics which may include one or more such computing devices, and if multiple computing devices are included, such computing devices may be coupled together with a suitable data communication network to collectively perform various functions, methods, or operations disclosed herein.

[0097] The terms “substantially” and “approximately” as used throughout this specification are used to describe and account for small variations due to processing variability, etc. For example, they may refer to less than or equal to ±5%, for example less than or equal to ±2%, for example less than or equal to ±1%, for example less than or equal to ±0.5%, for example less than or equal to ±0.2%, for example less than or equal to ±0.1%, for example less than or equal to ±0.05%. Also, as used herein, indefinite articles such as “a” or “an” mean “at least one.”

[0098] It should be understood that all combinations of the above concepts, and any additional concepts described in more detail below (provided that such concepts do not contradict each other), are assumed to be part of the subject matter of the invention disclosed herein. In particular, all combinations of the claimed subject matter appearing at the end of this disclosure are assumed to be part of the subject matter of the invention disclosed herein.

[0099] Multiple implementations are described. However, please understand that various modifications may be made without deviating from the intent and scope of this specification.

[0100] Furthermore, the logical flow shown in the diagram does not require any specific order or sequence to achieve the desired result. Additionally, multiple other processes may be provided, or multiple processes may be excluded from the described flow, and multiple other components may be added to or removed from the described system. Therefore, other implementations fall within the scope of the following claims.

[0101] While specific features of the implementations described herein are illustrated as described herein, many modifications, substitutions, changes, and equivalents will be conjured here upon those skilled in the art. It is understood that the appended claims are intended to encompass all such modifications and changes that fall within the scope of the above implementations. They are presented merely as examples and not as limitations, and it should be understood that various modifications may be made to their form and details. Any part of the apparatus and / or method described herein may be combined in any combination, except for mutually exclusive combinations. The implementations described herein may include various combinations and / or partial combinations of the functions, components, and / or features of the different implementations described herein.

Claims

1. In the step of receiving sensor data from a sensor of a first vehicle associated with a first person, the sensor data is generated by the sensor; The steps include: applying a machine learning algorithm to the sensor data to define a driving envelope for a driver assistance system, wherein the driver assistance system is installed in a second vehicle, and the driving envelope is defined to increase the likelihood of a successful handover from the driver assistance system by the first person; and The step of providing the driving envelope to the driving assistance system introduced in the second vehicle. A computer implementation method comprising the following:

2. The computer implementation method according to claim 1, wherein the driving assistance system operates using at least one configuration parameter, and the driving assistance system uses the driving envelope to determine a value for the configuration parameter.

3. The computer implementation method according to claim 2, wherein the configuration parameter controls at least one condition of the driving assistance system, the condition includes one or more of the distance between the second vehicle and an object, the speed of the second vehicle, the trajectory of the second vehicle, or the acceleration of the second vehicle.

4. The step of applying the aforementioned machine learning algorithm is: A step of identifying at least one event in the sensor data; and The step of tagging the identified event. A computer implementation method according to any one of claims 1 to 3, including the method described in any one of claims 1 to 3.

5. The driver assistance system is also installed in the first vehicle, and the step of identifying the at least one event further includes a step of considering the level of autonomous driving of the operation of the driver assistance system installed in the first vehicle when the sensor data was generated by the sensor, or The aforementioned driver assistance system is also installed in the first vehicle, and the step of identifying the at least one event is performed by the driver assistance system, and / or The computer implementation method according to claim 4, wherein the step of identifying the at least one event further includes considering a case in which the first person takes over control of the first vehicle from the driver assistance system installed in the first vehicle.

6. The step of receiving sensor data from a sensor of a first vehicle associated with a first person, wherein the sensor data is generated by the sensor; The steps include: applying a machine learning algorithm to the sensor data to define a driving envelope for a driver assistance system, wherein the driver assistance system is installed in a second vehicle; and The step of providing the driving envelope to the driving assistance system introduced in the second vehicle. Equipped with, The step of applying the aforementioned machine learning algorithm is: A step of identifying at least one event in the sensor data; and The step of tagging the identified event. Includes, The step of identifying at least one event is: A step considering the case in which the first person takes over control of the first vehicle from the driver assistance system installed in the first vehicle. Computer implementation methods including

7. The computer implementation method according to any one of claims 1 to 6, further comprising the step of performing a batch update of the operating envelope based on additional sensor data generated by the sensor over a period of time.

8. The computer implementation method according to any one of claims 1 to 7, wherein the sensor data is received while the first person is driving the first vehicle.

9. The computer implementation method according to any one of claims 1 to 8, wherein the sensor data is received while the driver assistance system is at least partially controlling the first vehicle, and the sensor data includes feedback from the first person to the driver assistance system.

10. The feedback includes the first person taking over control from the driver assistance system, or, The computer implementation method according to claim 9, wherein the feedback includes input from the first person to the driving assistance system.

11. Receiving sensor data from a sensor of a first vehicle associated with a first person, wherein the sensor data is generated by the sensor and includes feedback from the first person to a driver assistance system, the feedback includes the first person taking over control from the driver assistance system at least partially; The steps include: applying a machine learning algorithm to the sensor data to define a driving envelope for the driver assistance system, wherein the driver assistance system is installed in a second vehicle; and The step of providing the driving envelope to the driving assistance system introduced in the second vehicle. A computer implementation method comprising the following:

12. The computer implementation method according to any one of claims 1 to 11, wherein the driving assistance system uses the driving envelope in performing an action on the second vehicle.

13. The computer implementation method according to claim 12, further comprising the steps of receiving user feedback from the first person regarding the execution of the action by the driving assistance system, and updating values ​​for the configuration parameters of the driving assistance system based on the user feedback.

14. The user feedback includes the first person taking over control from the driver assistance system, or, The computer implementation method according to claim 13, further comprising a step of prompting the first person to provide the user feedback, wherein the user feedback is received in response to the prompting step.

15. The step of receiving sensor data from a sensor of a first vehicle associated with a first person, wherein the sensor data is generated by the sensor; In the step of applying a machine learning algorithm to the sensor data to define a driving envelope for a driver assistance system, the driver assistance system is installed in a second vehicle, and the driver assistance system uses the driving envelope in performing actions on the second vehicle; A step of receiving user feedback from the first person regarding the execution of the action by the driver assistance system; The step of updating values ​​for the configuration parameters of the driver assistance system based on the user feedback, the user feedback including the first person taking over control from the driver assistance system at least partially; and The step of providing the driving envelope to the driving assistance system introduced in the second vehicle. A computer implementation method comprising the following:

16. The computer implementation method according to any one of claims 12 to 15, wherein when the driving envelope is provided to the driving assistance system introduced into the second vehicle, the second vehicle is being driven by a second person.

17. The computer implementation method according to any one of claims 1 to 16, further comprising the step of receiving context data relating to the first vehicle, wherein the context data relates to the first vehicle at the time the sensor data was generated by the sensor, and the context data includes quantitative or qualitative exogenous metrics.

18. The computer implementation method according to any one of claims 1 to 17, wherein the second vehicle is the first vehicle.

19. The computer implementation method according to any one of claims 1 to 18, wherein the driver assistance system introduced in the second vehicle provides a query to a configuration manager, and the driving envelope is provided to the driver assistance system by the configuration manager in response to the query.

20. The computer implementation method according to claim 19, wherein the driver assistance system installed in the second vehicle provides the query to the configuration manager before taking action on the second vehicle, and the driving envelope specifies the status of the action.

21. The computer implementation method according to claim 20, wherein the driver assistance system introduced in the second vehicle determines whether or not to provide the query to the configuration manager before taking the action.

22. The computer implementation method according to claim 21, wherein the driver assistance system installed in the second vehicle considers real-time data about the second vehicle when deciding whether or not to provide the query to the configuration manager before taking the action.

23. A computer program for causing a processor to execute the computer implementation method described in any one of claims 1 to 22.

Images