Patent Application
20220398463
The following relates generally to a system and method for reconfiguring a machine learning model that is used to classify objects based on data received from an ultra-sonic sensor system.
Vehicles may include systems and sensors to detect stationary or mobile obstacles. However, vehicle systems may not be able to distinguish between the various stationary vehicles. For instance, ultrasonic sensors may be used within a vehicle system to detect obstacles near a vehicle during parking, blind spot detection, or maneuvering. Current vehicle systems employing ultrasonic sensors may employ rule-based empirical classifiers that are partly based on geometric relations of the detected obstacle echoes. Rule-based classifiers, however, may (1) generate weak true positives and false positive performance; (2) be difficult to adapt to specific vehicle variants; or (3) have a high dependence on the number and type of object classes.
A method and system is disclosed for creating a machine learning model that is reconfigurable. A fixed parameter model is created to include fixed feature values obtained during a training process for the machine learning model. The fixed parameter model may include a fixed base classifier used by the machine learning model to classify objects detected by an ultra-sonic system within a vicinity of a vehicle. A configurable parameter model may be created to include feature values that are different from the fixed feature values, the configurable parameter model including a modified base classifier. A vehicle controller may receive and update the fixed parameter model with the configurable parameter model. The machine learning model may be updated to use the configurable parameter model to classify the objects detected by the ultra-sonic system.
It is contemplated the fixed parameter model and the configurable parameter model may be designed using a decision tree arrangement that includes, fixed feature values, split thresholds between different classes of data, invalid value assignments, and missing value assignments.
The controller may receive the configurable parameter model using a wireless communication protocol (e.g., Wi-Fi, Bluetooth, or Cellular) or by wired communication protocol (e.g., Controller Area Network (CAN) or Local Interconnect Network (LIN)). The configurable parameter model may be tested by the machine learning model prior to updating the fixed parameter model with the configurable parameter model. Lastly, the fixed parameter model may be designed to include static values which are updated by the values provided within the configurable parameter model.
As required, detailed embodiments are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary and may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present embodiments.
Currently, ultrasonic sensor systems employed within mobile applications may be operable to detect the distances of obstacles near a vehicle during parking, blind spot detection, or maneuvering. For instance,
Alternatively, ultrasonic system 100 may be employed to provide parking assist to a driver. For instance, ultrasonic system 100 may provide parking assistance where the vehicle 106 parks the vehicle automatically without the need for the driver to provide steering guidance. Instead, the driver may only be required to provide acceleration and braking assistance during the parking procedure.
For parking applications, blind spot detection, or maneuvering traditional ultrasonic sensor systems generally employ a rule-based empirical classifiers that are partly based on geometric relations of the detected obstacle echoes. Rule-based classifiers, however, may (1) generate weak true positives and false positive performance; (2) be difficult to adapt to specific vehicle variants; or (3) have a high dependence on the number and type of object classes.
As such, it may be desirable to provide an ultrasonic sensor system and method that is operable to classify the traversibility of obstacles using machine learning methods on ultrasonic object data. With regards to classification, however, false classification of the ultrasonic system could lead to false warnings or false braking of a vehicle. For instance, if system 100 were to falsely classify the given distance of the curb 112 or classify a rock within the road as the curb 112, vehicle 106 may apply the brake before parking was complete. Such a false classification may prohibit the vehicle 106 from parking within the parking space, or the vehicle 106 may not be parked correctly within the parking space.
It is also contemplated that false classification may be rated differently by an ultrasonic system (e.g., system 100) from a user point-of-view based on the distance from where the classification may occur. False classification in a “far” field may be tolerated because the determination or impact on the vehicle may be small. But, false warnings in a “close” field may lead to undesirable outcomes such as a potential vehicle crash or false braking during maneuvering. For instance, if vehicle 208 illustrated in
It is therefore contemplated that the acceptable distance for correct classification may be object dependent (i.e., obstacle dependent). Correct classification may be required because the contour, shape, or type of a given object may differ. For instance, correct classification of a bush or wood fence may not be as necessary as correct classification of a vehicle (e.g., vehicle 208) or cement/brick wall. So if system 200 incorrectly classified a bush, vehicle 206 may not be damaged as severe as incorrect classification of vehicle 208. It is also contemplated correct classification of objects with specific geometries (e.g., small reflection cross-section) may have physical detection limitations and can only be detected in a limited proximity field.
It is contemplated a given user (e.g., an automotive original equipment manufacturer or “OEM”) may assess the importance of obstacles and acceptable ranges differently. For instance, one user may determine the appropriate detection of vehicle 208 from vehicle 206. Machine learning training routines may not, however, incorporate those dependencies inherently and consequently the performance of the machine learning classifier may not be in accordance with a given user requirement. It is therefore also desirable to provide an ultrasonic sensor system and method that may be operable to tune the machine learning classifier to adapt to specific input requirements (e.g., user requirements from a OEM).
Once the ultrasonic data is classified using a machine learning algorithm and classified based on user input requirements, it is desirable for the proposed machine learning algorithm to output a classifier consisting of multiple decision trees. It is also desirable that the machine learning algorithm calculate a class probability based on the decision trees. It is contemplated these aspects of the machine learning algorithm may be hard coded constituent parts of the software that are compiled before runtime and deployed to a control unit (e.g., electronic control unit “ECU” or controller) within a vehicle.
It is also desirable that the ultrasonic sensor system may require a validation of the parking software in the parking performance after a software freeze. Any adaptation to vehicles after software freeze (i.e., when vehicle is placed into production and software changes are no longer permitted) may be done by means of parameters steering the performance. But it is contemplated that the validation should not change or degrade the integrity of the software. It is also contemplated that additional efforts in verifying and validating the software may be reduced. The same software may also be used for a given bundle or class of vehicles. This may also provide a reduction in cost for management of different software versions with different part numbers for a user or OEM.
Lastly, the classifier may be adapted to new vehicle variants if training data for those vehicles is also available. If the data is not available before software freezes, it is contemplated training may also be done after software freeze with the implication of changing a hard-coded portion or segment of the software. However, such changes may introduce additional costs to the ultrasonic sensor system. It is therefore desirable to set up the machine learning classifier using parameters that may be modified after a software freeze.
The controller 302 may be in communication with various sensors, modules, and vehicle systems both within and remote from a vehicle. The system 300 may include such sensors, such as various cameras, a light detection and ranging (LIDAR) sensor, a radar sensor, an ultrasonic sensor, or other sensor for detecting information about the surroundings of the vehicle, including, for example, other vehicles, lane lines, guard rails, objects in the roadway, buildings, pedestrians, etc. In the example shown in
The processors 312-314 may be like ECU 302 described above. The USS 304-310 may further include memory like described above. It is contemplated ECU 302 or processors 312-314 may be operable to execute the machine learning algorithm for classifying and identifying ultrasonic object data. By operating the machine learning algorithm on processors 312-314 it is contemplated that resource consumption may be reduced (e.g., less than 200 DMIPS) and hardware accelerators may not be required. As discussed below, performance of classifying the traversibility of obstacles may be tunable according to the available processors 312-314 without much intervention when compared to rule-based classifiers.
It is contemplated that
It is also contemplated sensors 304-310 may each be configured to measure a distance to a target arranged external and proximal to the vehicle. As described further below, sensors 304-310 may be operable to classify a target as a vehicle, curb, roadblock, buildings, pedestrian, etc. It is also contemplated sensors 304-310 may work in conjunction with other vehicle components, such as the ECU and other sensors, to further enhance the classification of various targets outside of the vehicle.
As explained,
Right-side USS 308 and left-side USS 310 may be used to classify and determine vehicles or objects on the right-side or left-side. Each USS 308-310 may also be utilized to help or enhance various vehicle safety systems. USS 308-310 may be mounted or built into a right-hand or left-hand mirror assembly to determine objects on either side of the vehicle. While it is contemplated USS 308-310 may be mounted in a right-side/left-side mirror of the vehicle, it is also contemplated USS 308-310 may be positioned or located at other locations on a vehicle to operably capture objects on either side of the vehicle.
Again, USS 304-310 may be individually or combined to determine if objects are in a driver's blind spot, as well as detecting vehicles or objects approaching from the rear on the left and right when reversing. Such functionality may allow a driver to navigate around other vehicles when changing lanes or reversing out of a parking space, as well as assist in autonomous emergency braking to avoid collisions that may be imminent.
The system 300 may also include a global positioning system (GPS) 320 that detects or determines a current position of the vehicle. In some circumstances, the GPS 320 may be utilized to determine a speed that the vehicle is traveling. The system 300 may also include a vehicle speed sensor (not shown) that detects or determines a current speed that the vehicle is traveling. The system 300 may also include a compass or three-dimensional (3D) gyroscope that detects or determines a current direction of the vehicle. Map data may be stored in the memory. The GPS 320 may update the map data. The map data may include information that may be utilized with an advanced driver assistance system (ADAS). Such ADAS map data information may include detailed lane information, slope information, road curvature data, lane marking-characteristics, etc. Such ADAS map information may be utilized in addition to traditional map data such as road names, road classification, speed limit information, etc. The controller 302 may utilize data from the GPS 320, as well data/information from the gyroscope, vehicle speed sensor, and map data, to determine a location or current position of the vehicle.
The system 100 may also include a human-machine interface (HMI) display 322. The HMI display 322 may include any type of display within a vehicle cabin. Such HMI display may include a dashboard display, navigation display, multimedia display, heads-up display, thin-film transistor liquid-crystal display (TFT LCD), rear-view mirror indicators, etc. The HMI display 322 may also be connected to speakers to output sound related to commands or the user interface of the vehicle. The HMI display 322 may be utilized to output various commands or information to occupants (e.g. driver or passengers) within the vehicle. For example, in an automatic braking scenario, the HMI display 322 may display a message that the vehicle is prepared to brake and provide feedback to the user regarding the same. The HMI display 322 may utilize any type of monitor or display utilized to visualize relevant information to the occupants.
In addition to providing visual indications, the HMI display 322 may also be configured to receive user input via a touch-screen, user interface buttons, etc. The HMI display 322 may be configured to receive user commands indicative of various vehicle controls such as audio-visual controls, autonomous vehicle system controls, certain vehicle features, cabin temperature control, etc. The controller 302 may receive such user input and in turn command a relevant vehicle system of the component to perform in accordance with the user input.
The controller 302 can receive information and data from additional various vehicle components (e.g., LIDAR sensors, radar sensors, cameras). The controller 302 may utilize the additional data received from these sensors to provide vehicle functions that may relate to driver assistance or autonomous driving. For example, data collected by the LIDAR sensors and cameras may be utilized in context with the GPS data and map data to provide or enhance functionality related to adaptive cruise control, automatic parking, parking assist, automatic emergency braking (AEB), etc. The controller 302 may be in communication with various systems of the vehicle (e.g. the engine, transmission, brakes, steering mechanism, display, sensors, user interface device, etc.). For example, the controller 302 can be configured to send signals to the brakes to slow the vehicle (e.g., vehicle 1000, or the steering mechanism to alter the path of vehicle, or the engine or transmission to accelerate or decelerate the vehicle. The controller 302 can be configured to receive input signals from the various vehicle sensors to send output signals to the display device, for example. The controller 302 may also be in communication with one or more databases, memory, the internet, or networks for accessing additional information (e.g. maps, road information, weather, vehicle information).
Again, it is contemplated that each USS 304-310 may operate individually or in combination to perform classification based on received object data. While USS 304-310 may operate using an individual ultra-sonic sensor, it is preferable USS 304-310 include a plurality of ultra-sonic sensors to perform classification based on received object level data. For instance, USS 304 may include 4-6 ultrasonic sensors spread across the front bumper of the vehicle to perform classification based on received object level data.
For instance,
To carry out classification on the object level, USS 304 may begin at operating level 402 where ultra-sonic sensors 410-418 collect data under different environmental, operating and system conditions by approaching the ego-vehicle towards different object types from various trained machine learning systems. While operating level illustrates four ultra-sonic sensors 410-416, it is contemplated more ultra-sonic sensors (as represented by sensor 418) or less sensors may be used based on a given application and location within or around the vehicle.
At operating level 404, signal processing algorithms 420-428 may be performed on the data collected by each individual sensor 410-418. For instance, signal processing algorithms 420-428 may include echo preprocessing steps (e.g., amplitude filtering) and calculating features on the echo level. More specifically, algorithms 420-428 may calculate features for each individual sensor 410-418 that include mean amplitude, significance, correlation of echoes and number of echoes received.
At operating level 406, one or more signal processing algorithms 430 may be performed on the output of each signal processing algorithm 420-428. The signal processing algorithms 430 may combine the output of each signal processing algorithm 420-428. For instance, signal processing algorithm 430 may include trilateration, object generation of the shape and matching the type of an object. The signal processing algorithm 430 may further calculate features on multiple sensor inputs (e.g., cross-echo reception rate). Lastly, algorithm 430 may be operable to calculate features based on geometric relations from object matching.
For example, the signal processing algorithms 430 may calculate a reception of echoes from one or more of the data provided by sensors 410-418. The reception of echoes determined by signal processing algorithms 430 may include the number of sensors contributing to the obstacle or the cross-echo reception rate. Algorithm 430 may also calculate geometric relations based on trilateration (e.g.,) mean lateral error of the measured trilateration. Or, algorithm 430 may calculate geometric relations from based on point-like or line-like reflection characteristics.
At operating level 408, one or more signal processing algorithms 432 may be performed on the output of the combined signal processing algorithms 430 calculated at operating level 406. Algorithm 432 may be operable to statistically aggregate the calculated features on an object level. Algorithm 432 may also be operable to classify traverse ability based on aggregated features.
However, it is further contemplated that for machine learning (ML) or deep learning (DL) algorithms used within advanced driver-assistance systems (ADAS) that may be operable to assist drivers in driving and parking functions, the algorithms or methods employed may be trained on raw sensor data (e.g., for classification on video streams). The ML/DL classifiers employed for such applications may employ a neural network (e.g., convolutional neural networks (CNNs), recurrent neural networks (RNN), artificial neural networks (ANN)) or similar calculation frameworks. Such frameworks, however, typically require high resource consumption and may not be applicable to the limited computational resources of ultrasonic systems.
It is therefore contemplated that a compute efficient tree based machine learning model may be employed using an extreme gradient boosting (“XGBoost”) algorithm. The XGBoost may be an ensemble learning method that comprises a series of boosters. The booster may be a decision tree that provides a classification output. The XGBoost may also include multiple decision trees and an aggregated output from all the trees may be computed to give the final classification result. Lastly, XGBoost may be a standard machine learning algorithm that provides high levels of accuracy for structured data (i.e., features are engineered), but XGBoost may not operate at such a high level of accuracy when applied in native form to height classification for ultrasonic systems.
For improved height classification when employed within an ultrasonic system (e.g., system 300), a data preprocessing model may be employed before training the ML/DL algorithm (i.e., model). The data preprocessing may be designed to remove noisy signals that are captured by the ultrasonic system. In addition to removing noisy signals, the data may be filtered to ensure the ultrasonic system measurements that appear from approaching an obstacle may only be considered in the training dataset.
After the data preprocessing, a training model may be employed for the employed machine learning model (e.g, XGBoost). It is also contemplated that training the XGBoost classifier may involve additional components in addition to the data. For instance, the additional components may include tunable object class weights. Another component may include weights to individual samples of the data. The individual weights may be a function of object importance (which may be assigned by a user), range goal, and the distance at which the input sample may be collected by the ultrasonic system. An objective function may also be designed as a function of user selected object importance and range goals. Additional components may also include automatic feature selections or a computationally efficient sigmoid function for final classification of the output.
At step 606, a machine learning classifier may be trained with user requirement specific weights. In other words, the weight inputs (weighted by user requirements) may be used to train the XGBoost classifier with a weighted binary cross entropy loss function. At step 608, the machine learning classifier may be optimized with user requirement specific weights based cost functions. For instance, a loss function may be employed that is flexible and can include additional terms corresponding to regularization (like L2 regularization). At step 610, the machine learning classifier may be evaluated using new metrics that consider user requirements. For instance, the model complexity can be modified based on performance requirements as well as computational constraints such as the depth of the trees, number of boosters, or ensembles of trees. Lastly, it is contemplated that in addition to binary classifiers, a multi-class classifier may be employed for classifying multiple object classes.
It is contemplated that when classification of the ultrasonic system data is complete, the machine learning algorithm may need to be adaptable during the tuning process of one or more of the machine learning classifiers. Being adaptable during the tuning process, the machine learning algorithm may improve the tradeoff on true and false classifications. The tuning process may also be designed to provide an adaption of the classifier based on specific user requirements (e.g., OEM requirements) or may be adaptable to a specific application. For instance, the tuning process may provide adaptability for a specific car variant (e.g., Sports-Utility-Vehicle or Minivan). Or a given OEM (e.g., Ford Motor Company) may require a specific tuning process for their entire fleet of vehicles.
It is also contemplated that the machine learning algorithm may be operable to modify the standard classification loss function (e.g., cross-entropy) to include weighting parameters and range goals for each object class as individual inputs for the tuning routine. The tuning process may therefore provide a set of hyper-parameters that represent tunable weights associated with each object class. The tunable weights may operably be obtained based on the specific customer requirements provided. The customer inputs provided may then be input to the machine learning algorithm at multiple stages of the tuning process. Additionally, a tuning objective function may also operably take into account the customer inputs. The performance of the data classification may therefore be improved, since the best tradeoff may be based and determined using the specific customer requirements. Furthermore, the machine learning algorithm may be easily adaptable to changes in the requirements, thereby reducing the time and cost to implement or based on given applications.
Again,
At step 706 ranges may be established for tuning parameters based on user requirements. It is contemplated the base classifier may be trained with a loss function (e.g., weighted loss function) where the weights may be computed based on received inputs (i.e., customer inputs). At step 708, the classifier may be trained with tuning parameters and objective function weighted by user requirements. It is contemplated the performance of the tuned (i.e., trained) classifier is evaluated using a suitable objective function (e.g. squared distance to object (DTO) error in our case) which is specifically designed to cater to a particular user requirement and/or input. If the weights need to be re-tuned, the flow diagram 700 may proceed to step 712 where the classifier may be re-tuned using parameters with user requirements based on the objective function.
At step 706 ranges may be established for tuning parameters based on user requirements. It is contemplated the base classifier may be trained with a loss function (e.g., weighted loss function) where the weights may be computed based on received inputs (i.e., customer inputs). At step 708, the classifier may be trained with tuning parameters and objective function weighted by user requirements. It is contemplated the performance of the tuned (i.e., trained) classifier is evaluated using a suitable objective function (e.g. squared distance to object (DTO) error in our case) which is specifically designed to cater to a particular user requirement and/or input. At step 710, it is determined whether the weights need to be re-tuned. If yes, the flow diagram 700 may return to step 706. If no, the flow diagram may proceed to step 712 where the classifier may be tuned using parameters with user requirements based on the objective function.
Lastly, it is contemplated the trained classifier may be restructured to achieve a fully parametrized machine learning model which may be operable for reconfiguration post deployment within a real-world application. For instance, in automotive applications there may be a point where no more changes may be permitted to occur for software and stored values (i.e., software freeze). The software freeze may include trained classifiers stored (or to be stored) within an ECU of a vehicle. After the software freeze (e.g., after the vehicle has been sold to a customer), it may be desirable to restructure or update the vehicle with new classifier values. It is therefore also desirable to have a fully adaptable classifier that may include a set of parameters operable for training new vehicle variants or object classes after a software freeze. If there exists a defect in a released software, the present method and system may be operable to change the performance on defects by changing the parameters. Such changes may simplify the handling of defects.
It is contemplated the disclosed system and method may use a given machine learning model that includes a fixed structure. The fixed structure may comprise a varying number of trees and/or depth with fully populated leaves where all nodes of the trees (e.g., if/else expression) consist of parameters. In one example, a node that is expressed as “feature_value >threshold value” may be comprised of 3 parameters that individually include: (1) “feature_value”; (2) “>”; and (3) “parameter_value”. It is also contemplated the parameters may be determined and assigned during the configuration process. However, it is contemplated that the system and method may need to account for handling invalid feature values and non-populated leaves.
With reference to
It is contemplated the different features and associated split threshold values may be completely parameterized. For instance, a parameterized model (block 806) may be created to include full decision trees where each node comprises of variables for both the feature names and the split values thresholds at each node. At block 804, the variables in the configurable model may be assigned to the features and split thresholds that are static values from the fixed parameters model.
The reconfigurable machine learning model may operate using tree-based models that are not simple binary trees. Depending on the features that may be used, additional parameters like invalid values and missing values may be employed. Logic may be implemented into each node of the configurable model file. Block 812 illustrates the parameters may be assigned based on the information received from the fixed model file (block 802), actual feature values, or the received runtime measurements/data (block 810). It is also contemplated block 812 may execute during runtime to assign such parameters in the configurable model.
The processes, methods, or algorithms disclosed herein can be deliverable to/implemented by a processing device, controller, or computer, which can include any existing programmable electronic control unit or dedicated electronic control unit. Similarly, the processes, methods, or algorithms can be stored as data, logic, and instructions executable by a controller or computer in many forms including, but not limited to, information permanently stored on non-writable storage media such as ROM devices and information alterably stored on writeable storage media such as floppy disks, magnetic tapes, CDs, RAM devices, and other magnetic and optical media. The processes, methods, or algorithms can also be implemented in a software executable object. Alternatively, the processes, methods, or algorithms can be embodied in whole or in part using suitable hardware components, such as Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), state machines, controllers or other hardware components or devices, or a combination of hardware, software and firmware components.
While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of various implementing embodiments may be combined to form further embodiments of the invention.
