Data-driven customization of driver assistance systems

Abstract

The computer-implemented method includes receiving first telemetry data generated by sensors of each first vehicle in a fleet; clustering the first telemetry data into groups, each of the groups representing a profile of one or more first drivers of the first vehicles in the fleet; receiving second telemetry data generated by sensors of a second vehicle controlled by a second driver; associating the second driver with a first one of the groups by classifying the received second telemetry data; providing a subset of the first telemetry data corresponding to the first cluster as a baseline data set for training a machine learning algorithm; generating baseline tuning parameter values ​​using the trained machine learning algorithm; and providing the baseline tuning parameter values ​​to a driver assistance system of a third vehicle controlled by the second driver.

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application is a continuation of, and claims priority to, U.S. Non-Provisional Patent Application No. 18 / 193,219, filed March 30, 2023, entitled "DATA DRIVEN CUSTOMIZATION OF DRIVER ASSISTANCE SYSTEM," which claims the benefit under 35 U.S.C. § 119 of U.S. Provisional Patent Application No. 63 / 373,659, filed August 26, 2022, entitled "DATA DRIVEN CUSTOMIZATION OF DRIVER ASSISTANCE SYSTEM," the disclosures of both of which are incorporated herein by reference in their entireties.

[0002] This application also claims priority to U.S. Provisional Patent Application No. 63 / 373,659, filed August 26, 2022, the disclosure of which is incorporated herein by reference in its entirety.

[0003] This paper concerns data-driven customization of driver assistance systems. [Background technology]

[0004] Vehicular transportation is entrenched in modern society. A large portion of the population in many countries has a driver's license for one or more types of vehicle or is otherwise capable of operating such vehicles. While there are many different types of vehicles that can be driven by such individuals, many drivers also differ from one another in their driving styles. Anyone traveling in traffic can observe significant differences between drivers with respect to driving skills, driving preferences, and driving habits. No two drivers are exactly alike. Summary of the Invention

[0005] In a first aspect, a computer-implemented method includes receiving first telemetry data generated by sensors of each first vehicle in a fleet; clustering the first telemetry data into groups, each of the groups representing a profile of one or more first drivers of the first vehicles in the fleet; receiving second telemetry data generated by sensors of a second vehicle controlled by a second driver; associating the second driver with a first one of the groups by classifying the received second telemetry data; providing a subset of the first telemetry data corresponding to the first cluster as a baseline data set for training a machine learning algorithm; generating baseline tuning parameter values ​​using the trained machine learning algorithm; and providing the baseline tuning parameter values ​​to a driver assistance system of a third vehicle controlled by the second driver.

[0006] Implementations may include any or all of the following features. The computer-implemented method further comprises filtering the first telemetry data into filtered telemetry data, where clustering the first telemetry data into groups comprises clustering the filtered telemetry data into the groups. The computer-implemented method further comprises augmenting the first telemetry data into augmented telemetry data, where clustering the first telemetry data into groups comprises clustering the augmented telemetry data into the groups. The computer-implemented method further comprises performing dimensionality reduction on the received first telemetry data to generate dimensionality-reduced telemetry data, where clustering the first telemetry data into groups comprises clustering the dimensionality-reduced telemetry data into the groups. The performing dimensionality reduction on the received first telemetry data comprises projecting the received first telemetry data into an abstract space. Projecting the received first telemetry data into the abstract space includes combining first and second values, the first and second values ​​having different physical units, and classifying the received second telemetry data includes projecting the received second telemetry data into the abstract space. The baseline tuning parameter values ​​control at least one aspect of the driver assistance system, the aspect including one or more of a distance between the third vehicle and an object, a speed of the third vehicle, a trajectory of the third vehicle, or an acceleration of the third vehicle. The third vehicle is the second vehicle. Receiving the second telemetry data includes performing event detection to record a specific scenario. Clustering the first telemetry data into groups includes specifying a desired number of groups. The computer-implemented method further includes obfuscating an association between the baseline dataset and the second driver before providing the baseline dataset for the training of the machine learning algorithm. Obfuscating the association between the baseline dataset and the second driver includes applying a hash function to (i) a vehicle identification number of the second vehicle and (ii) a user identifier for the second driver. The computer-implemented method further includes training a feature generation algorithm using the second telemetry data. The feature generation algorithm is trained to generate candidate parameter values ​​for at least one of: (i) time gap; (ii) lane change duration parameter; (iii) distance from exit to lane change; (iv) lane bias; (v) speed, acceleration, or jerk in a lateral direction; or (vi) parking distance. The machine learning algorithm includes at least one of a regression algorithm or a classification algorithm.

[0007] In a second aspect, a computer program product tangibly embodied in a non-transitory storage medium comprises instructions that, when executed, cause a processor to perform operations including receiving first telemetry data generated by sensors in each first vehicle in a fleet; clustering the first telemetry data into groups, each of the groups representing a profile of one or more first drivers of the first vehicles in the fleet; receiving second telemetry data generated by sensors in a second vehicle controlled by a second driver; associating the second driver with a first one of the groups by classifying the received second telemetry data; providing a subset of the first telemetry data corresponding to the first cluster as a baseline data set for training a machine learning algorithm; generating baseline tuning parameter values ​​using the trained machine learning algorithm; and providing the baseline tuning parameter values ​​to a driver assistance system of a third vehicle controlled by the second driver.

[0008] Implementations may include any or all of the following features: the operations further include filtering the first telemetry data into filtered telemetry data, where clustering the first telemetry data into groups includes clustering the filtered telemetry data into groups; the operations further include augmenting the first telemetry data into augmented telemetry data, where clustering the first telemetry data into groups includes clustering the augmented telemetry data into groups; the operations further include performing dimensionality reduction on the received first telemetry data to generate dimensionality-reduced telemetry data, where clustering the first telemetry data into groups includes clustering the dimensionality-reduced telemetry data into groups; and the operations further include obfuscating an association between the baseline dataset and the second driver prior to providing the baseline dataset for the training of the machine learning algorithm. The operations further include training a feature generation algorithm using the second telemetry data. [Brief explanation of the drawings]

[0009] [Figure 1] 1 illustrates an example of a system that can perform data-driven customization of a driver assistance system.

[0010] [Figure 2] 1 shows a flowchart of an example of data collection for data-driven customization of a driver assistance system.

[0011] [Figure 3] 1 illustrates a flowchart of an example of providing baseline tuning parameter values ​​to a driver assistance system of a vehicle.

[0012] [Figure 4] 10 illustrates an example of applying baseline tuning parameter values ​​when performing an action on a vehicle. [Figure 5] 10 illustrates an example of applying baseline tuning parameter values ​​when performing an action on a vehicle. [Figure 6] 10 illustrates an example of applying baseline tuning parameter values ​​when performing an action on a vehicle. [Figure 7] 10 illustrates an example of applying baseline tuning parameter values ​​when performing an action on a vehicle.

[0013] [Figure 8] 1 illustrates an exemplary architecture of a computing device that may be used to implement aspects of the present disclosure.

[0014] Like reference symbols in the various drawings indicate like elements. DETAILED DESCRIPTION OF THE INVENTION

[0015] This document describes example systems and techniques for data-driven customization of driver assistance systems. Techniques according to the present disclosure can collect information about driving history for a fleet of test vehicles; perform a classification of the current vehicle driver based on the previously recorded behavior of the test fleet; and use the classification to provide at least one parameter to the driver assistance system. Any type of learnable parameter can be determined and provided. In some implementations, an abstract driving profile can be used to directly influence the driver's assistance system over time in a user-friendly manner. Examples include, but are not limited to, user-specific time gap settings applied to active cruise control or lane change maneuver duration for lane change assistance.

[0016] The present subject matter may provide a system that generates feature parameters for one or more specific driver assistance systems, such as active cruise control, lane change suggestion, lane change assist, etc., by profiling a user's driving profile based on a set of learned abstract driving profiles. This encapsulation may provide a baseline for tuning specific parameters affecting any given driver assistance system, thereby ensuring that the system can be further tailored to the user's driving preferences. Aside from learning the user's tangible and understandable preferences, the system may also strive to learn the driver's hidden preferences to better match the driver's unique driving profile and thus further motivate people to use the driver assistance system. Such a system may be beneficial to the user because it follows the driver's tendencies. For example, for a feature such as active cruise control, users have individual preferences for the distance their vehicle should take for different time gap settings. Typical time gap setting ranges may be overly aggressive or overly conservative, depending on the user's preferences. The present disclosure generates baseline time gap settings that more closely match a user's driving tendencies in different driving conditions (e.g., conservative in bad weather conditions and aggressive in heavy traffic), thereby resulting in a feature implementation that is more in line with the user's preferences and, in turn, more likely to be viewed favorably by the user.

[0017] The examples described herein refer to vehicles. A vehicle is a machine that transports passengers, 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, cars, trucks, and buses. The number of wheels may vary between vehicle types, and one or more (e.g., all) of the wheels may be used to propel the vehicle. A vehicle may include a passenger compartment that accommodates one or more people. At least one vehicle occupant may be considered the driver; in this case, various tools, implements, 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 with a driver assistance system) is sometimes referred to as the "ego-vehicle." The vehicles shown in the figures are shown as similar to each other for illustrative purposes only.

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

[0019] The examples described herein refer to driver assistance systems. Driver assistance systems at least partially automate one or more dynamic driving tasks to provide driving assistance. Driver assistance systems typically operate based in part on the output of one or more sensors located on, under, or within the vehicle. While an autonomous vehicle is an example of a driver assistance system, not all driver assistance systems are designed to provide fully autonomous vehicles. SAE International has defined multiple levels of driving automation, typically referred to as Levels 0, 1, 2, 3, 4, and 5. For example, a Level 0 system or driving mode may not involve persistent 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 the driver assistance system. For example, a Level 5 system or driving mode may not require human intervention in the driver assistance system.

[0020] Examples described herein refer to machine learning algorithms. As used herein, a machine learning algorithm may include an implementation of artificial intelligence that enables a machine, such as a driver assistance system, to perceive its environment and take action to achieve one or more goals. A machine learning algorithm may apply one or more principles of data mining to define a driver profile from data collected about a fleet of vehicles and their associated circumstances. A machine learning algorithm may be trained in one or more perspectives. For example, supervised, semi-supervised, and / or unsupervised training may be performed. In some implementations, a machine learning algorithm may utilize one or more classification algorithms, or classifiers for short. For example, a classifier may assign one or more labels to recognized instances in processed data. In some implementations, a machine learning algorithm may utilize one or more forms of regression analysis. For example, a machine learning algorithm may apply regression to determine one or more numerical values. In some implementations, the machine learning algorithm may be configured to collect and store data, use the data to detect events, use the data to identify context, and generate a driving envelope based at least in part on the detected events and context.

[0021] Examples described herein refer to sensors. A sensor is configured to detect one or more aspects of its environment and output a signal reflective of the detection. The detected aspect may be static or dynamic at the time of detection. By way of illustrative example only, a sensor may indicate one or more of the following: a distance between the sensor and an object, a speed of a vehicle carrying the sensor, a trajectory of the vehicle, or an acceleration of the vehicle. A sensor may generate an output without probing its surroundings with anything (e.g., passive detection such as an image sensor capturing electromagnetic radiation), or the sensor may probe its surroundings (e.g., active detection by sending out electromagnetic radiation and / or sound waves) and detect a response to the probing. Examples of sensors that may be used in one or more embodiments include, but are not limited to, optical sensors (e.g., cameras); light-based sensing systems (e.g., light ranging and detection (LiDAR) devices); radio-based sensors (e.g., radar); acoustic sensors (e.g., ultrasonic devices and / or microphones); inertial measurement units (e.g., gyroscopes and / or accelerometers); speed sensors (e.g., for the vehicle or its components); position sensors (e.g., for the vehicle or its components); orientation sensors (e.g., for the vehicle or its components); torque sensors; thermal sensors; temperature sensors (e.g., primary or secondary thermometers); pressure sensors (e.g., for the ambient air or vehicle components); humidity sensors (e.g., rain detectors); or occupancy sensors.

[0022] FIG. 1 illustrates an example of a system 100 that can perform data-driven customization of a driver assistance system. System 100 can be used with one or more other examples described elsewhere herein. System 100 includes a system 102 for vehicle telemetry collection, an algorithm 104 for dimensionality reduction, an algorithm 106 for data clustering, a system 108 for user driving profile classification, and a system 110 for parameter learning. One or more of system 102, algorithms 104 or 106, or systems 108 or 110, to name just a few, can be implemented as standalone, separate systems or can be integrated with at least one other component of system 100. In summary, multiple sets of data (e.g., fleet data and user data) can be received using system 102 and passed through algorithms 104 and 106. Data from a test fleet can create bifurcations, such as through a labeling process that creates sections or divisions between groups of drivers according to their behavior. In the case of data from users, this bifurcations can then be used to classify the user data.

[0023] The system 102 may be or may include a vehicle telemetry collection system that collects vehicle telemetry data from a fleet of vehicles 112. Such data may include, but is not limited to, location information (e.g., longitude or latitude), speed, acceleration, lane position, or yaw rate. The vehicle telemetry data may include sensor readings from any or all sensors in the vehicle. For example, the vehicle telemetry data may reflect or otherwise indicate a situation related to the vehicle and / or an action taken by the driver. The vehicle telemetry data may reflect or otherwise indicate the occurrence of one or more events and / or driver triggers in the presence of one or more context parameters. For example, the vehicle telemetry data may reflect or otherwise indicate a lane change event. As another example, the vehicle telemetry data may reflect or otherwise indicate that the driver has taken (or not taken) one or more actions that would trigger a response from the vehicle. As another example, the vehicle telemetry data may reflect or otherwise 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, vehicle telemetry data may include sensor data reflecting how a person drives a vehicle. For example, this may allow a person's driving preferences and driving characteristics to be analyzed and taken into account when customizing a driver assistance system. In some implementations, vehicle telemetry data may include sensor data reflecting a user's response to how a driver assistance system controls the vehicle. For example, a user may provide feedback by taking over control of the vehicle from a driver assistance system.

[0024] The fleet of vehicles 112 may be referred to as a captive fleet, in the sense that the vehicles are subject to reporting some or all of their sensor registration or other telemetry data to the system 100. To name just a few examples, the vehicles 112 may all be of the same make, type, or model, or one or more of the vehicles 112 may be of a different make / type / model. The vehicle telemetry data 114 collected from the vehicles 112 may span a wide range of driving conditions and / or a variety of driving scenarios. In some implementations, the vehicles 112 are a fleet of test vehicles owned and operated by the manufacturer of the vehicles 112.

[0025] Arrow 116 here generally indicates that one or more operations may be performed on vehicle telemetry data 114. Vehicle telemetry data 114 may be filtered. In some implementations, filtering may be performed based on the usefulness or requirements of algorithm 104 or 106. For example, usefulness filtering may involve checking whether the data is highly relevant or whether it appears corrupted (e.g., due to a sensor failure). As another example, if vehicle telemetry data 114 lacks data from highway driving in rainy weather, data from rainy conditions may be preferred. In this manner, vehicle telemetry data 114 may be filtered to generate filtered vehicle telemetry data.

[0026] The vehicle telemetry data 114 may be augmented. In some implementations, the augmentation is performed based on a simulation 118. The simulation 118 may represent a fictitious environment corresponding to one or more edge case scenarios that may occur only rarely or not at all in the vehicle telemetry data 114. The augmentation may then provide sensor output values ​​or other data that reflect the simulated situation or conditions. The augmentation may enable the algorithm 104 or 106 to recognize a wider range of situations. In this manner, the vehicle telemetry data 114 may be augmented to generate augmented vehicle telemetry data.

[0027] The system 108 may perform user driving profile classification. In doing so, the system 108 may apply the algorithms 104 and 106 to the vehicle telemetry data 114 to define groups of driver profiles and then classify the vehicle driver as belonging to one of the groups. In some implementations, the system 108 applies the algorithm 104 to perform dimensionality reduction on the vehicle telemetry data 114 to generate dimensionally reduced telemetry data. Dimensionality reduction may be useful in understanding feature combinations that may provide the greatest benefit and / or may be useful in reducing computational time for training. The vehicle telemetry data 114 may include numerous fields. Some fields (e.g., the output of one or more particular sensors or other vehicle components) may not be particularly useful for characterizing the vehicle driver's profile. Thus, such less useful fields may be ignored or removed from the vehicle telemetry data 114. Performing dimensionality reduction on the vehicle telemetry data 114 may include projecting the vehicle telemetry data 114 into an abstract space. The abstract space may have reduced dimensionality compared to the original dataset of vehicle telemetry data 114. This may improve efficiency and simplify data analysis.

[0028] In some implementations, projecting into an abstract space may involve adding dimensions to the vehicle telemetry data 114 that may not have significance in the real world. The vehicle telemetry data 114 may also include information about vehicle spacing gaps in adjacent lanes that the driver accepts as large enough for a lane change, and speed information about how fast the vehicle 112 is traveling at the time the driver considers merging into that nearby lane. The vehicle spacing gap, here the distance between the rear of one vehicle and the front of the vehicle behind it, is measured as a physical entity having a dimension of distance. Speed ​​information, in contrast, is not a distance but rather a physical entity having a dimension of speed (e.g., miles per hour or meters per second). That is, the vehicle spacing gap and the speed information have different physical units. Therefore, combining these values ​​(e.g., by adding the values ​​together) may not correspond to any physical entity in the real world (e.g., it may not be a physically intuitive concept), but the system 108 may perform this projection into an abstract space to assist in classifying users into specific groups of driver profiles. Other combinations may be used in addition or instead. For example, the spacing between vehicles in adjacent lanes (i.e., distance measurement) and the speed at which a driver executes a lane change (i.e., speed measurement) may be combined. Any of several methods of combining parameter values ​​having different physical units may be used. For example, the combination may involve weighted summation. Dimensionality reduction (e.g., projection into one or more abstract spaces) may be performed in an automated manner. For example, principal component analysis may be used.

[0029] Projection into an abstract space can add a layer of anonymity to the data, for example, the data may support certain inferences about a driver differently based on knowing the latitude or longitude location data of a vehicle's journey, say.

[0030] Projecting to an abstract space can reduce or prevent engineering bias toward certain parameters of the data. For example, engineers may otherwise tend to overemphasize certain parameters based on empirical understanding. In prior approaches, engineers may have employed heuristics that attempted to classify vehicles 112 by looking at parameters that the engineers were trained to address, such as speed, acceleration, lateral distance, or vehicle displacement. Engineers may unconsciously or intentionally have biases toward or against any of the well-known parameters based on prior experience. Therefore, reducing or preventing engineering bias is useful. This may be even more important considering that the system 100 may ultimately be attempting to learn the driver's subconscious preferences and thereby be able to tailor the driver's driving assistance to those preferences. Unless mitigated, engineering bias can negate or obscure such hidden preferences and sabotage efforts.

[0031] In some implementations, dimensionality reduction may be omitted. For example, if the vehicle telemetry data 114 contains only a few (e.g., two) parameters, this may not be sufficient for classification into one group or another. Therefore, dimensionality reduction may be omitted if it would result in a loss of representation of the data.

[0032] The algorithm 106 may include a clustering algorithm for the vehicle telemetry data 114. When the data is projected into an abstract space, the data may be clustered into one of several abstract groups. The clusters may correspond to respective driving behaviors in one or more aspects. For example, groups of drivers may behave similarly under certain conditions. Here, the algorithm 106 is shown schematically clustering the vehicle telemetry data 114 into each of groups 106A, 106B, or 106C. More or fewer groups than those shown may be used. The groups 106A-106C may, but do not necessarily, correspond to driver characterizations such as conservative, average, or aggressive drivers, respectively; or characterizations such as fast or slow reaction times. Rather, the groups into which the algorithm 106 clusters the vehicle telemetry data 114 may be any classification that groups drivers exhibiting similar behaviors or having similar performance into a common bucket. For example, if the abstraction dimension is a (weighted) sum of speed and distance, the groups 106A-106C may reflect how the behavior of an individual driver of the vehicle 112 falls within that space. That is, the groups 106A-106C may serve as an abstraction of the typical driving profile of the driver who generated the vehicle telemetry data 114.

[0033] In some implementations, one or more engineering preferences may be applied when executing the algorithm 106. For example, the number of clusters (e.g., three groups or a different number) may be specified. As another example, the algorithm 106 may specify the accuracy of the clusters. The preferences may be defined taking into account the requirements of the customization process and / or resource constraints. For example, clustering into fewer groups may be a faster operation than clustering into more groups. Thus, clustering the vehicle telemetry data 114 into groups 106A-106C may include specifying the desired number of groups (e.g., three).

[0034] Application of the above-exemplified algorithms 104 and 106 can produce the above-mentioned branching, where vehicle telemetry data 114 from a fleet of vehicles 112 is used in developing tuning parameters for one or more individual drivers, an example of the latter being described here.

[0035] The system 102 for vehicle telemetry collection may also involve collecting data from a vehicle 120 driven by a user. The vehicle 120 may be one of the vehicles 112 used at a different time than when the telemetry data 114 was collected, or the vehicle 120 may be a separate vehicle that is not part of a fleet. The vehicle 120 may be of the same make, type, or model as one or more of the vehicles 112, or the vehicle 120 may be of a different make / type / model.

[0036] Here, the system 102 collects vehicle telemetry data 122 from the vehicle 120. The vehicle telemetry data 122 may include, but is not limited to, location information (e.g., longitude or latitude), speed, acceleration, lane position, or yaw rate. The vehicle telemetry data 122 may span a wide range of driving conditions and / or a variety of driving scenarios. The vehicle telemetry data 122 may not be specifically labeled for any particular driving condition. For example, this may maintain the generality of the data and the anonymity of the driver. The vehicle telemetry data 122 may provide a balanced data set of driving tendencies of the user operating the vehicle 120 for which the driver assistance system is customized.

[0037] Event detection can be performed to collect vehicle telemetry data 122. Examples of event detection are provided below. In some implementations, event detection can be used to record specific scenarios and speed up data set generation for a user. For example, highway driving and / or hard braking or hard acceleration or sharp turns events can be detected.

[0038] System 108 may project vehicle telemetry data 122 into the same dimensions (e.g., the same abstract space) as vehicle telemetry data 114. For example, algorithm 104 may be used to reduce the number of dimensions. System 108 may classify vehicle telemetry data 122 based on the groups generated using algorithm 106. In some implementations, it may be determined which of groups 106A-106C vehicle telemetry data 122 best fits into. Fleet vehicle telemetry data 114 defines the dimensions against which individual user data can be used. For example, here classification 124 schematically indicates that vehicle telemetry data 122 is closest to and classified into group 106A. That is, the classification always associates vehicle telemetry data 122 with one of the groups resulting from clustering vehicle telemetry data 114 by algorithm 106.

[0039] The cluster (i.e., a subset of data categorized under a single cluster) may then serve as a baseline dataset 126 for training of machine learning algorithms 128 by system 110. The baseline dataset 126 may be characterized as a curated dataset in that algorithms 104 and / or 106 may have improved vehicle telemetry data 122 in one or more respects. That is, system 110 may use it for parameter learning from the baseline dataset 126. The baseline dataset 126 may be used to train machine learning algorithms 128. Once trained, each of machine learning algorithms 128 provides baseline tuning parameter values ​​130 for the driver assistance system. Training may be performed within a vehicle having a driver assistance system or remotely from the vehicle (sometimes referred to as offline training). For example, a computer cluster operated by the vehicle manufacturer may perform the offline training. As another example, offline training may be performed in a distributed manner using cloud computing resources.

[0040] The training of the machine learning algorithm 128 is indicated schematically here using arrow 132. The machine learning algorithm 128 may include a regression algorithm. In some implementations, a regression analysis may be performed on vehicle telemetry data to determine one or more numerical values ​​related to vehicle motion or other characteristics. For example, the regression may generate values ​​for time, duration, distance, speed, acceleration, and / or jerk related to the vehicle.

[0041] The machine learning algorithms 128 may include classification algorithms. In some implementations, classification may be performed to apply labels related to vehicle motion or other characteristics to vehicle telemetry data. For example, classification may label the time, duration, distance, speed, acceleration, and / or jerk of the vehicle.

[0042] During training, the association between the baseline data set 126 and the driver of the vehicle 120 may be obfuscated. For example, a unique hash function may be applied to the vehicle identification number (VIN) and a user identifier for the driver of the vehicle 120. The user identifier (e.g., registered by a driver monitoring system in the vehicle) may be useful as part of the vehicle telemetry data 122 because, for example, the user identifier may enable customization of a driver assistance system for more than one driver of the vehicle.

[0043] Feature generation may be performed. In some implementations, the baseline dataset 126 may be used to train a dedicated feature generation algorithm. Here, training of the feature generation algorithm 134 (e.g., a generalized adversarial network, or GAN) is indicated schematically using arrow 136. The training may be performed in combination with user-specific driving data. For example, this may further fine-tune certain comfort parameters for the features. In some implementations, the baseline dataset 126 may be used in conjunction with the GAN to generate candidate parameter values. For example, such candidates may include, but are not limited to, a time gap (e.g., relative to a vehicle ahead of the vehicle being driven) and / or a lane-change duration parameter (e.g., the amount of time it takes a driver to change from one lane to another). In the future, if more complex features are used, the feature generation algorithm 134 may provide candidate values ​​for the features.

[0044] The baseline tuning parameter values ​​130 may be provided to a driver assistance system of a vehicle 138 controlled by the driver of vehicle 120. That is, the baseline tuning parameter values ​​130 are now applied to customize the driver assistance system according to classifying this driver into one of the abstract driver profiles defined from the fleet data. Vehicle 138 may be one of vehicles 112 or 120, or vehicle 138 may be a separate vehicle that is not part of a fleet and was not used in generating vehicle telemetry data 114 or 122. Vehicle 138 may be of the same make, type, or model as one or more of vehicles 112 or 120, or vehicle 138 may be of a different make / type / model.

[0045] The baseline tuning parameter values ​​130 may control at least one aspect of the driver assistance system. In some implementations, the aspect may include one or more of the distance between the vehicle 138 and an object, the speed of the vehicle 138, the trajectory of the vehicle 138, or the acceleration of the vehicle 138, to name just a few.

[0046] The examples described above may include a computer-implemented method including receiving first telemetry data (e.g., vehicle telemetry data 114) generated by sensors of each first vehicle (e.g., vehicle 112) in a fleet; clustering (e.g., using algorithm 106) the first telemetry data into groups (e.g., groups 106A-106C), each group representing a profile of one or more first drivers of the first vehicles in the fleet; receiving second telemetry data (e.g., vehicle telemetry data 122) generated by sensors of a second vehicle (e.g., vehicle 120) controlled by a second driver; classifying (e.g., providing a subset of the first telemetry data corresponding to the first cluster as a baseline dataset (e.g., baseline dataset 126) for training a machine learning algorithm (e.g., machine learning algorithm 128); generating baseline tuning parameter values ​​(e.g., baseline tuning parameter values ​​130) using the trained machine learning algorithm; and providing the baseline tuning parameter values ​​to a driver assistance system of a third vehicle (e.g., vehicle 138) controlled by the second driver.

[0047] 2 shows a flowchart of an example 200 of data collection for data-driven customization of a driver assistance system. Example 200 may be used in conjunction with one or more other examples described elsewhere herein. Example 200 and / or one or more of its components may be operated by at least one processor executing instructions stored on a computer-readable medium, for example, as described below with reference to FIG. 8. In some implementations, example 200 may be used in collecting information regarding driving history for a fleet of test vehicles for use in performing a classification of a vehicle driver and providing at least one parameter to a driver assistance system for that driver.

[0048] Example 200 involves a component 204 that can perform event detection. In some implementations, component 204 can detect behaviors and / or maneuvers performed by the driver. In some implementations, component 204 can monitor driver behavior and identify maneuvers as members of one or more distinct sets. Examples include, but are not limited to, changing lanes, following a lead vehicle in a lane, staying in a lane without a lead vehicle, sudden braking, or a decrease or increase in a time gap. Component 204 can identify quantitative or qualitative endogenous 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 gap relative to a lead vehicle when following, determining the speed at which a driver stays in a lane when no lead vehicle is present, and / or determining the rate of deceleration when creating a gap in front of the ego vehicle to allow another vehicle to enter the lane. Component 204 can include one or more aspects of a machine learning algorithm. In some implementations, component 204 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 the driver assistance system. In some implementations, component 204 may identify at least one event in the vehicle telemetry data and apply a tag to the identified event.

[0049] Example 200 involves a component 210 for context identification. Component 210 may detect external operating conditions based on which a driver performs (or does not perform) an action detected as an event. In some implementations, component 210 may collect quantitative or qualitative exogenous metrics related to the event. In some implementations, component 210 may tag weather, traffic conditions, road curvature, and / or road conditions. Component 210 may include one or more aspects of a machine learning algorithm.

[0050] Data 202 enters example 200. In some implementations, data 202 may be characterized as raw, real-time vehicle data. The data may come from one or more sensors in the vehicle (e.g., from a group of sensors dedicated to a driver assistance system).

[0051] Data 202 may be provided to one or more aspects of example 200. Data 202 may be provided to component 204. In some implementations, component 204 may be responsible for detecting events in data 202 and tagging the data according to the detection. For example, component 204 may apply one or more aspects of a machine learning algorithm during its operation. Data 202 may be provided to cloud 206.

[0052] Data 208 enters example 200. In some implementations, data 208 may be characterized as raw, real-time exogenous data and may be contextual data related to the vehicle being monitored. The data may come from one or more sensors in the vehicle (e.g., from a group of sensors dedicated to a driver assistance system) and / or from external sources (e.g., a weather reporting service, a mapping service, or a road condition reporter).

[0053] Data 208 may be provided to one or more aspects of example 200. Data 208 may be provided to component 210. In some implementations, component 210 may be responsible for detecting context within data 208 and tagging the data according to that detection. For example, component 210 may apply one or more aspects of a machine learning algorithm during its operation. Data 208 may be provided to cloud 206.

[0054] The component 204 may generate an output 212. In some implementations, the output 212 reflects the behavior or operation of the vehicle by the driver. The output 212 may be provided in a suitable format and stored in a database 214.

[0055] Component 210 may generate output 216. In some implementations, output 216 reflects the qualitative or quantitative context of output 212 (e.g., as related to the behavior or operation by the driver of the vehicle). Output 216 may be provided in a suitable format and stored in database 214.

[0056] Database 214 may 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, this may result in updates to database 214 occurring one minute or several minutes apart from each other. As data accumulates in database 214, software algorithms may update one or more driving envelopes to increase the accuracy or precision of their boundaries. In this manner, database 214 may be used to collect information that constitutes vehicle telemetry data 114 and / or 122.

[0057] 3 shows a flowchart of an example 300 for providing baseline tuning parameter values ​​to a driver assistance system of a vehicle. Example 300 may be used in conjunction with one or more other examples described elsewhere herein. Example 300 and / or one or more of its components may be operated by at least one processor executing instructions stored on a computer-readable medium, for example, as described below with reference to FIG. 8. In some implementations, example 300 may be configured to provide at least one customized parameter to a driver assistance system for a vehicle driver based on a classification of the driver.

[0058] Here, the driver assistance system 302 (DA) is determining whether to take action in the context currently represented by the situation 304. As just one example, the driver assistance system 302 may be trying to determine whether to institute a lane change maneuver. The driver assistance system 302 may formulate a query 306 to the cluster component 307. In some implementations, the query 306 indicates the intended maneuver. The driver assistance system 302 may query the cluster component 307 in an effort to ensure that the intended behavior and maneuver are acceptable to the driver. For example, this may involve ensuring that the vehicle is not traveling at a higher speed, is not positioned closer to other vehicles, and / or is not turning at a sharper angle than the driver would operate the vehicle themselves. This query may attempt to ensure that the driver feels safe and comfortable during the maneuver. For example, this may enhance the user's operation of the driver assistance system 302 and improve the driver's overall satisfaction with the vehicle and experience.

[0059] Responding to query 306 may involve cluster component 307 accessing one or more databases or other repositories of baseline tuning parameter values. Cluster component 307 may provide baseline tuning parameter values ​​308 in response to query 306, or baseline tuning parameter values ​​308 may be a predetermined response (e.g., a large data set) provided in response to query 306. In some implementations, baseline tuning parameter values ​​308 may include one or more constraints on the application or implementation of actions contemplated by driver assistance system 302. For example, baseline tuning parameter values ​​308 may include a speed limit. As another example, baseline tuning parameter values ​​308 may include limits on longitudinal and / or lateral acceleration. In some implementations, a combination of constraints may be used. The result of applying the baseline tuning parameter values ​​308 may be that the driver assistance system 302 will only initiate a lane change if the gap in adjacent lanes (i.e., the distance between vehicles) is at least x feet and the driver assistance system 302 has y seconds or more of time at its disposal to complete its action.

[0060] Assuming the driver assistance system 302 decides to initiate an action, the driver assistance system 302 may provide one or more outputs. In some implementations, the driver assistance system 302 outputs information corresponding to a trajectory 310. The baseline tuning parameter values ​​308 may specify or adjust one or more aspects of the trajectory 310. The trajectory 310 may correspond to causing the vehicle to assume a particular position, velocity, acceleration, and rate of change of acceleration (sometimes referred to as "jerk"). For example, the trajectory 310 may be achieved by setting the steering angle of the wheels and the torque output of the traction motors. Execution 312 conceptually represents here the baseline tuning parameter values ​​308 being used to execute an action based on the trajectory 310. The driver 314 is a human being, represented here schematically using a circle. The driver 314 is the target of the execution 312 of the action planned and executed by the driver assistance system 302.

[0061] The cluster components 307 and / or the driver assistance system 302 may benefit from input from a real-time data provider 316. The real-time data provider 316 may provide one or more pieces of information that are taken into account when generating the baseline tuning parameter values ​​308. In some implementations, the comfort preference for an event (e.g., a lane change) may depend on the situation at hand, which may be reflected by input from the real-time data provider 316. For example, traffic density or the speed of the vehicle. At lower speeds, the driver's 314 comfort level may not be an important factor, but at higher speeds, comfort may become an important factor. The driver assistance system 302 may be provided with information that substantially indicates the parameter values ​​that will be applied under visible conditions. If the weather changes, this may trigger the driver assistance system 302 to submit a query 306. That is, the driver assistance system 302 installed in the vehicle may consider real-time data about the vehicle when deciding whether to provide a query to the configuration manager before taking action.

[0062] 4-7 illustrate examples 400, 500, 600, and 700 of applying baseline tuning parameter values ​​when performing actions with respect to a vehicle. Examples 400, 500, 600, and 700 may be used in conjunction with one or more other examples described elsewhere herein. In example 400, vehicle 402 is currently traveling on roadway 404 with one-way traffic proceeding in either of two adjacent lanes. Here, vehicle 406 is also present on roadway 404. In particular, vehicle 402 is currently located in the right lane, and vehicles 406A-406B are currently located in the left lane. Here, the terms right and left are used from the perspective of the driver of vehicle 402.

[0063] Assume that the driver of vehicle 402 wishes to make a lane change, moving from the right lane to the left lane. In this example, there is currently a distance 408 between vehicles 406A-406B along roadway 404. Relevant data may also indicate the current conditions of roadway 404 (e.g., traffic density, road quality, weather) and the current conditions of vehicle 402 (e.g., speed, occupancy). Lane change 410 is shown here diagrammatically with an arrow from the right lane to the left lane. Baseline tuning parameter values ​​for the driver of vehicle 402 may be applied to a driver assistance system installed on vehicle 402. The driver assistance system may obtain relevant parameters before determining whether or how to perform a lane change. For example, the baseline tuning parameter values ​​may inform the driver assistance system that it may perform the lane change as long as the distance between vehicles 406A-406B is at least equal to a specified distance, and / or another condition. When the driver assistance system takes action, this may subject the vehicle 402 to certain longitudinal and lateral accelerations according to the range that is acceptable to the driver according to the abstract driver profile into which the driver is classified.

[0064] Example 400 also illustrates learnable parameters related to vehicle motion parameters. Lane change 410 may be characterized using one or more motion parameters, including, but not limited to, parameters reflecting lateral motion, indicated generally here by arrow 412 perpendicular to the lane direction of roadway 404. For example, the parameters may characterize lateral velocity during lane change 410 (e.g., limits on such lateral velocity). As another example, the parameters may characterize lateral acceleration during lane change 410 (e.g., limits on such lateral acceleration). As another example, the parameters may characterize lateral jerk (i.e., rate of change of acceleration) during lane change 410 (e.g., limits on such lateral jerk). In this manner, baseline tuning parameter values ​​for the driver of vehicle 402 may be applied to a driver assistance system onboard vehicle 402 to control parameters related to lateral motion during lane change 410.

[0065] Next, example 500 relates in part to adaptive cruise control. When vehicle 502 is traveling behind vehicle 504 in the same lane, the driver assistance system maintains at least approximately distance 506 between vehicles 502 and 504. If vehicle 504 accelerates, the driver assistance system may respond by accelerating vehicle 502 (optionally, up to a predefined maximum speed). If vehicle 504 decelerates, the driver assistance system may respond by braking vehicle 502 to maintain at least distance 506 between them. Distance 506 and / or the rate of acceleration or deceleration may be defined by baseline tuning parameter values.

[0066] Example 500 also illustrates lane bias. Here, vehicle 508 is on the roadway. Vehicle 508 and vehicle 502 are currently alongside each other on the roadway. For example, vehicle 508 and vehicle 502 may be traveling at the same speed, or either vehicle 502 or 508 may currently be overtaking the other vehicle. Vehicle 502 is currently located in the left lane, and vehicle 508 is currently located in the right lane. Here, the terms right and left are used from the perspective of the driver of vehicle 502 or 508. Distance 510 between vehicles 502 and 508 may be referred to as lane bias. In some implementations, distance 510 may instead correspond to the spacing between vehicle 502 and other objects, including, but not limited to, lane markings, road boundaries, guardrails, or another landmark. Lane bias is an example of a use case for which one or more learnable parameters may be determined. In this manner, baseline tuning parameter values ​​for the driver of vehicle 502 may be applied to the driver assistance systems onboard vehicle 502 to control distance 510.

[0067] Example 600 involves the distance from a roadway exit to a lane change location. Vehicle 602 is currently traveling on highway 604. Vehicle 602 may be executing lane change 606, which is shown schematically here with an arrow from the current lane to the next lane. The purpose of lane change 606 may be to position vehicle 602 in the right-most lane of highway 604 in preparation for exiting highway 604 at an upcoming exit 608. Lane change 606 may be initiated when there is at least distance 610 between the current position of vehicle 602 and exit 608. For example, distance 610 may depend on factors such as the volume and speed of traffic, the width or number of lanes, and / or the size of exit 608 or the angle it forms with highway 604. The distance from the exit to the lane change is an example of a use case for which one or more learnable parameters may be determined. In this manner, baseline tuning parameter values ​​for the driver of vehicle 602 may be applied to the driver assistance systems onboard vehicle 602 to control distance 610.

[0068] Example 700 involves parking distance. Vehicle 702 may be currently located in parking spot 704. Vehicle 702 may already be parked in parking spot 704 or may be in the process of parking. Parking may be characterized by one or more distances 706, 708, 710, or 712 between vehicle 702 and parking spot 704. In some implementations, any or all of distances 706, 708, 710, or 712 may instead correspond to a spacing between vehicle 702 and something else, including, but not limited to, another vehicle or another structure. Parking distance is an example of a use case for which one or more learnable parameters may be determined. In this manner, baseline tuning parameter values ​​for the driver of vehicle 702 may be applied to a driver assistance system onboard vehicle 702 to control one or more of distances 706, 708, 710, or 712.

[0069] FIG. 8 illustrates an example architecture of a computing device 800 that may be used to implement aspects of the present disclosure, including any of the systems, devices, and / or techniques described herein or any other systems, devices, and / or techniques that may be utilized in various possible embodiments.

[0070] The computing device illustrated in FIG. 8 may be used to execute the operating system, application programs, and / or software modules (including software engines) described herein.

[0071] In some embodiments, computing device 800 includes at least one processing device 802 (e.g., processor), such as a central processing unit (CPU). Various processing devices are available from various manufacturers, such as Intel or Advanced Micro Devices. In this example, computing device 800 also includes a system memory 804 and a system bus 806 that couples various system components, including the system memory 804, to the processing device 802. The system bus 806 is one of any number of types of bus structures that can be used, including, but not limited to, a memory bus or memory controller; a peripheral bus; and a local bus, using any of a variety of bus architectures.

[0072] Examples of computing devices that may be implemented using computing device 800 include a desktop computer, a laptop computer, a tablet computer, a mobile computing device (such as a smartphone, touchpad mobile digital device, or other mobile device), or other device configured to process digital instructions.

[0073] The system memory 804 includes a read-only memory 808 and a random access memory 810. A basic input / output system 812, containing the basic routines that act to transfer information within the computing device 800, such as during start-up, may be stored in the read-only memory 808.

[0074] In some embodiments, computing device 800 also includes a secondary storage device 814, such as a hard disk drive for storing digital data. The secondary storage device 814 is connected to system bus 806 by a secondary storage interface 816. The secondary storage device 814 and its associated computer-readable media provide non-volatile and non-transitory storage of computer-readable instructions (including application programs and program modules), data structures, and other data for computing device 800.

[0075] Although the exemplary environment described herein employs a hard disk drive as the secondary storage device, other types of computer-readable storage media are used in other embodiments. Examples of these other types of computer-readable storage media include a magnetic cassette, a flash memory card, a digital video disk, a Bernoulli cartridge, a compact disk read-only memory, a digital versatile disk read-only memory, a random access memory, or a read-only memory. Some embodiments include non-transitory media. For example, a computer program product may be tangibly embodied in a non-transitory storage medium. Additionally, such computer-readable storage media may include local storage or cloud-based storage.

[0076] A number of program modules may be stored in secondary storage device 814 and / or system memory 804, including an operating system 818, one or more application programs 820, other program modules 822 (such as the software engines described herein), and program data 824. Computing device 800 may utilize any suitable operating system, such as Microsoft Windows®, Google Chrome® OS, Apple® OS, Unix®, or Linux® and variants, and any other operating system suitable for a computing device. Other examples may include Microsoft®, Google®, or Apple® operating systems used in tablet computing devices, or any other suitable operating system.

[0077] In some embodiments, a user provides input to the computing device 800 through one or more input devices 826. Examples of input devices 826 include a keyboard 828, a mouse 830, a microphone 832 (e.g., for voice and / or other audio input), a touch sensor 834 (e.g., a touchpad or touch-sensitive display), and a gesture sensor 835 (e.g., for gesture input). In some implementations, the input devices 826 provide presence, proximity, and / or motion-based detection. In some implementations, a user may walk into their home, which may trigger input to the processing device. For example, in this case, the input device 826 may facilitate an automated experience for the user. Other embodiments include other input devices 826. The input devices may be connected to the processing device 802 through an input / output interface 836 coupled to the system bus 806. These input devices 826 may be connected by any number of input / output interfaces, such as a parallel port, a serial port, a game port, or a universal serial bus. In some contemplated embodiments, wireless communication between the input device 826 and the input / output interface 836 is also possible, including infrared, BLUETOOTH® wireless technology, 802.11a / b / g / n, cellular, ultra-wideband (UWB), ZigBee®, or other radio frequency communication systems, to name just a few.

[0078] In this exemplary embodiment, a display device 838, such as a monitor, liquid crystal display device, light emitting diode display device, projector, or touch-sensitive display device, is also connected to system bus 806 via an interface, such as a video adapter 840. In addition to the display device 838, computing device 800 may also include various other peripheral devices (not shown), such as speakers or a printer.

[0079] Computing device 800 may be connected to one or more networks through network interface 842. Network interface 842 may provide wired and / or wireless communication. In some implementations, network interface 842 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), network interface 842 may include an Ethernet interface. Other possible embodiments use other communication devices. For example, some embodiments of computing device 800 include a modem for communicating across the network.

[0080] Computing device 800 may include at least some form of computer-readable media. Computer-readable media includes any available media that can be accessed by computing device 800. By way of example, computer-readable media include computer-readable storage media and computer-readable communication media.

[0081] Computer-readable storage media include volatile and nonvolatile, 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, including, but not limited to, random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory, or other memory technology, compact disk read-only memory, digital versatile disk, or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage, or other magnetic storage device, or any other medium that can be used to store the desired information and that can be accessed by computing device 800.

[0082] Computer-readable communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, computer-readable communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared and other wireless media. Combinations of any of the above are also included within the scope of computer-readable media.

[0083] The computing device shown in FIG. 8 is also an example of a programmable electronic device that may include one or more such computing devices, which, when multiple computing devices are included, may be coupled together with a suitable data communications network to collectively perform various functions, methods, or operations disclosed herein.

[0084] As used throughout this specification, the terms "substantially" and "about" are used to describe and take into account small variations, such as those due to processing variations. For example, they can refer to less than or equal to ±5%, such as less than or equal to ±2%, such as less than or equal to ±1%, such as less than or equal to ±0.5%, such as less than or equal to ±0.2%, such as less than or equal to ±0.1%, such as less than or equal to ±0.05%. Also, as used herein, indefinite articles such as "a" or "an" mean "at least one."

[0085] It should be understood that all combinations of the above concepts, and additional concepts discussed in more detail below, (provided that such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as being part of the inventive subject matter disclosed herein.

[0086] Although several implementations have been described, it will nevertheless be understood that various modifications may be made without departing from the spirit and scope of the specification.

[0087] Additionally, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. Additionally, other processes may be provided or processes may be eliminated from the described flows, and other components may be added to or removed from the described systems. Accordingly, other implementations are within the scope of the following claims.

[0088] While certain features of the described implementations have been shown and described herein, many modifications, substitutions, changes, and equivalents will now occur to those skilled in the art. It should therefore be understood that the appended claims are intended to cover all such modifications and variations that fall within the scope of these implementations. They have been presented by way of example only, and not limitation, and it should be understood that various changes in form and detail may be made. Except for mutually exclusive combinations, any portion of the apparatus and / or methods described herein may be combined in any combination. The implementations described herein may include various combinations and / or subcombinations of the functions, components, and / or features of the different implementations described. (Other possible items) (Item 1) receiving first telemetry data generated by a sensor of each first vehicle in the fleet; clustering the first telemetry data into groups, each of the groups representing a profile of one or more first drivers of the first vehicles in the fleet; receiving second telemetry data generated by a sensor of a second vehicle controlled by a second driver; classifying the received second telemetry data to associate the second driver with a first one of the groups; providing a subset of the first telemetry data corresponding to a first cluster as a baseline data set for training a machine learning algorithm; generating baseline tuning parameter values ​​using a trained machine learning algorithm; and providing the baseline tuning parameter values ​​to a driver assistance system of a third vehicle controlled by the second driver. 1. A computer-implemented method comprising: (Item 2) 2. The computer-implemented method of claim 1, further comprising filtering the first telemetry data into filtered telemetry data, wherein clustering the first telemetry data into the groups comprises clustering the filtered telemetry data into the groups. (Item 3) 3. The computer-implemented method of claim 1, further comprising: expanding the first telemetry data into expanded telemetry data, wherein clustering the first telemetry data into the groups comprises clustering the expanded telemetry data into the groups. (Item 4) 4. The computer-implemented method of claim 1, further comprising: performing dimensionality reduction on the received first telemetry data to generate dimensionally reduced telemetry data, wherein clustering the first telemetry data into the groups comprises clustering the dimensionally reduced telemetry data into the groups. (Item 5) Item 5. The computer-implemented method of item 4, wherein performing the dimensionality reduction on the received first telemetry data comprises projecting the received first telemetry data into an abstract space. (Item 6) 6. The computer-implemented method of claim 5, wherein projecting the received first telemetry data into the abstract space includes combining first and second values ​​with each other, the first and second values ​​having different physical units. (Item 7) 6. The computer-implemented method of claim 5, wherein classifying the received second telemetry data comprises projecting the received second telemetry data into the abstract space. (Item 8) 8. The computer-implemented method of claim 1, wherein the baseline tuning parameter values ​​control at least one aspect of the driver assistance system, the aspect including one or more of a distance between the third vehicle and an object, a speed of the third vehicle, a trajectory of the third vehicle, or an acceleration of the third vehicle. (Item 9) 9. The computer-implemented method of any one of items 1 to 8, wherein the third vehicle is the second vehicle. (Item 10) 10. The computer-implemented method of any one of items 1 to 9, wherein receiving the second telemetry data comprises performing event detection and recording a particular scenario. (Item 11) 11. The computer-implemented method of any one of items 1 to 10, wherein clustering the first telemetry data into groups comprises specifying a desired number of groups. (Item 12) 12. The computer-implemented method of claim 1, further comprising obfuscating an association between the baseline data set and the second driver prior to providing the baseline data set for the training of the machine learning algorithm. (Item 13) Item 13. The computer-implemented method of item 12, wherein obfuscating the association between the baseline data set and the second driver comprises applying a hash function to (i) a vehicle identification number of the second vehicle, and (ii) a user identifier for the second driver. (Item 14) Item 14. The computer-implemented method of any one of items 1 to 13, further comprising training a feature generation algorithm using the second telemetry data. (Item 15) Item 15. The computer-implemented method of item 14, wherein the feature generation algorithm is trained to generate candidate parameter values ​​for at least one of: (i) time gap; (ii) lane change duration parameter; (iii) distance from exit to lane change; (iv) lane bias; (v) speed, acceleration, or jerk in the lateral direction; or (vi) parking distance. (Item 16) Item 16. The computer-implemented method of any one of items 1 to 15, wherein the machine learning algorithm comprises at least one of a regression algorithm or a classification algorithm. (Item 17) 1. A computer program comprising instructions that, when executed, cause a processor to perform operations, said operations being: receiving first telemetry data generated by a sensor of each first vehicle in the fleet; clustering the first telemetry data into groups, each of the groups representing a profile of one or more first drivers of the first vehicles in the fleet; receiving second telemetry data generated by a sensor of a second vehicle controlled by a second driver; associating the second driver with a first one of the groups by classifying the received second telemetry data; providing a subset of the first telemetry data corresponding to a first cluster as a baseline data set for training a machine learning algorithm; generating baseline tuning parameter values ​​using a trained machine learning algorithm; and providing the baseline tuning parameter values ​​to a driver assistance system of a third vehicle controlled by the second driver. 1. A computer program comprising: (Item 18) 20. The computer program product of claim 17, wherein the operations further include filtering the first telemetry data into filtered telemetry data, where clustering the first telemetry data into the groups includes clustering the filtered telemetry data into the groups. (Item 19) 19. The computer program of any one of items 17 to 18, wherein the operations further include a step of extending the first telemetry data into extended telemetry data, wherein the step of clustering the first telemetry data into the groups includes a step of clustering the extended telemetry data into the groups. (Item 20) 20. The computer program of any one of items 17 to 19, wherein the operations further include performing dimensionality reduction on the received first telemetry data to generate dimensionally reduced telemetry data, wherein the step of clustering the first telemetry data into groups includes the step of clustering the dimensionally reduced telemetry data into the groups. (Item 21) 21. The computer program of claim 17, wherein the operations further comprise obfuscating an association between the baseline data set and the second driver before providing the baseline data set for the training of the machine learning algorithm. (Item 22) 22. The computer program according to any one of items 17 to 21, wherein the operations further comprise training a feature generation algorithm using the second telemetry data.

Claims

1. receiving first telemetry data generated by a sensor of each first vehicle in the fleet; clustering the first telemetry data into groups, each of the groups representing a profile of one or more first drivers of the first vehicles in the fleet; receiving second telemetry data generated by a sensor of a second vehicle controlled by a second driver; classifying the received second telemetry data to associate the second driver with a first one of the groups; providing the first subset of telemetry data corresponding to the first group as a baseline data set for training a machine learning algorithm to generate a trained machine learning algorithm; generating baseline tuning parameter values ​​using the trained machine learning algorithm; and providing the baseline tuning parameter values ​​to a driver assistance system of a third vehicle controlled by the second driver.

1. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, further comprising filtering the first telemetry data into filtered telemetry data, wherein clustering the first telemetry data into the groups comprises clustering the filtered telemetry data into the groups.

3. 2. The computer-implemented method of claim 1, further comprising: augmenting the first telemetry data into extended telemetry data, wherein clustering the first telemetry data into the groups comprises clustering the extended telemetry data into the groups.

4. 2. The computer-implemented method of claim 1, further comprising: performing dimensionality reduction on the received first telemetry data to generate dimensionally reduced telemetry data, wherein clustering the first telemetry data into the groups comprises clustering the dimensionally reduced telemetry data into the groups.

5. The computer-implemented method of claim 4 , wherein performing the dimensionality reduction on the received first telemetry data comprises projecting the received first telemetry data into an abstract space.

6. 6. The computer-implemented method of claim 5, wherein projecting the received first telemetry data into the abstract space includes combining first and second values ​​with each other, the first and second values ​​having different physical units.

7. The computer-implemented method of claim 5 , wherein classifying the received second telemetry data comprises projecting the received second telemetry data into the abstract space.

8. 2. The computer-implemented method of claim 1, wherein the baseline tuning parameter values ​​control at least one aspect of the driver assistance system, the aspect including one or more of a distance between the third vehicle and an object, a speed of the third vehicle, a trajectory of the third vehicle, or an acceleration of the third vehicle.

9. The computer-implemented method of claim 1 , wherein the third vehicle is the second vehicle.

10. The computer-implemented method of claim 1 , wherein receiving the second telemetry data comprises performing event detection to record a particular scenario.

11. The computer-implemented method of claim 1 , wherein clustering the first telemetry data into groups comprises specifying a desired number of groups.

12. 2. The computer-implemented method of claim 1, further comprising obfuscating an association between the baseline data set and the second driver prior to providing the baseline data set for the training of the machine learning algorithm.

13. 13. The computer-implemented method of claim 12, wherein obfuscating the association between the baseline data set and the second driver comprises applying a hash function to (i) a vehicle identification number of the second vehicle, and (ii) a user identifier for the second driver.

14. The computer-implemented method of claim 1 , further comprising training a feature generation algorithm using the second telemetry data.

15. 15. The computer-implemented method of claim 14, wherein the feature generation algorithm is trained to generate candidate parameter values ​​for at least one of: (i) time gap; (ii) lane change duration parameter; (iii) distance from exit to lane change; (iv) lane bias; (v) speed, acceleration, or jerk in a lateral direction; or (vi) parking distance.

16. The computer-implemented method of claim 1 , wherein the machine learning algorithm comprises at least one of a regression algorithm or a classification algorithm.

17. A computer program comprising instructions that, when executed, cause a processor to perform operations, said operations being: receiving first telemetry data generated by a sensor of each first vehicle in the fleet; clustering the first telemetry data into groups, each of the groups representing a profile of one or more first drivers of the first vehicles in the fleet; receiving second telemetry data generated by a sensor of a second vehicle controlled by a second driver; classifying the received second telemetry data to associate the second driver with a first one of the groups; providing the first subset of telemetry data corresponding to the first group as a baseline data set for training a machine learning algorithm to generate a trained machine learning algorithm; generating baseline tuning parameter values ​​using the trained machine learning algorithm; and providing the baseline tuning parameter values ​​to a driver assistance system of a third vehicle controlled by the second driver.

1. A computer program comprising:

18. 20. The computer program product of claim 17, wherein the operations further comprise filtering the first telemetry data into filtered telemetry data, wherein clustering the first telemetry data into the groups comprises clustering the filtered telemetry data into the groups.

19. 20. The computer program product of claim 17, wherein the operations further comprise: augmenting the first telemetry data into extended telemetry data, wherein clustering the first telemetry data into the groups comprises clustering the extended telemetry data into the groups.

20. 20. The computer program product of claim 17, wherein the operations further comprise: performing dimensionality reduction on the received first telemetry data to generate dimensionally reduced telemetry data, wherein clustering the first telemetry data into the groups comprises clustering the dimensionally reduced telemetry data into the groups.

21. 20. The computer program product of claim 17, wherein the operations further comprise obfuscating an association between the baseline data set and the second driver prior to providing the baseline data set for the training of the machine learning algorithm.

22. 22. The computer program product of claim 17, wherein the operations further comprise training a feature generation algorithm using the second telemetry data.

Images