VEHICLE SYSTEMS AND METHODS FOR IDENTIFYING AND DEDUPLICATION OF ROAD OBJECTS

Abstract

A vehicle system comprises a vehicle control module and a control module. The control module is configured to receive data from vehicles over a specified period, cluster the received data into groups, identify at least one set of duplicate groups within those groups, merge the duplicate groups into a single group or remove at least one of the duplicate groups to form a set of deduplicate groups associated with the at least one object, and determine an expected location of the at least one object based on the set of deduplicate groups. The vehicle control module is configured to receive the expected location of the at least one object and generate a control signal to control at least one operation of the vehicle based on the expected location of the at least one object. Other exemplary systems and methods are also disclosed.

Description

INTRODUCTION

[0001] The information in this section serves to present the general context of the disclosure. Works of the inventors mentioned herein, insofar as they are described in this section, as well as aspects of the description that may not have been prior art at the time of filing, are neither expressly nor implicitly admitted as prior art against the present disclosure.

[0002] The present disclosure relates to vehicle systems and methods for identifying and deduplicating roadway objects.

[0003] Vehicles often rely on maps for navigation and / or display. These maps can be created using crowdsourcing algorithms that aggregate and group data collected over time by multiple vehicles. For example, vehicles might collect data from one or more onboard sensors (e.g., cameras) while traveling along a particular stretch of road. Such data can include location data of various objects (e.g., traffic signs, billboards, rocks, potholes, vehicles parked at the roadside, etc.), data on speed limits displayed on traffic signs, and so on. A system receives the collected data from the vehicles and data from other sources (e.g., aerial imagery, etc.), gathers and groups the data, analyzes it to identify locations and / or other details related to objects along roads, and then creates maps based on the analyzed data.The maps and details of the objects along the roads can then be made available to individual vehicles (e.g., in real time) so that each vehicle can be controlled and / or these maps and details can be displayed. SUMMARY

[0004] A vehicle system comprises a vehicle control module and a control module that communicates with the vehicle control module. The control module is configured to: receive data from a multitude of vehicles over a specified period, wherein the data includes detected locations of at least one object along a vehicle lane; cluster the received data into a multitude of groups; detect at least one set of duplicate groups from the multitude of groups; merge the duplicate groups into a single group or remove at least one of the duplicate groups to form a set of deduplicate groups associated with the at least one object; and determine an expected location of the at least one object based on the set of deduplicate groups.The vehicle control module is configured to receive the expected location of the at least one object and to generate a control signal to control at least one operation of the vehicle based on the expected location of the at least one object.

[0005] In other features, the control module is configured to merge the duplicate groups into a single group by averaging the latitude and longitude values.

[0006] In other features, the control module is configured to remove at least one of the duplicate groups based on the number of the multitude of vehicles that detect the locations of the at least one object, or on the sampling frequency of the multitude of vehicles that detect the locations of the at least one object.

[0007] In other features, the control module is configured to determine a weighted value that is assigned to each group from the set of duplicate groups, and to remove at least one of the duplicate groups based on the weighted value and a threshold.

[0008] In other features, the weighted value assigned to each group is based on a standard deviation of the locations of the object specific to the group, a standard deviation of the directions of the object specific to the group, and a standard deviation of the heights of the object specific to the group.

[0009] In other features, at least one object is a traffic sign, and the data contains information about the traffic sign.

[0010] Other features of the information on the traffic sign include speed limit values.

[0011] In other features, the control module is configured to detect a contradiction between one or more of the speed limit values ​​of the traffic sign and determine an expected speed limit value based on a number of previous contradictions for the traffic sign.

[0012] In other features, the control module is configured to determine whether a speed limit value is within a defined threshold of a typical detected speed for the vehicle lane, and selects the speed limit value as the expected speed limit value of the speed limit sign.

[0013] In other features, the control module is configured to determine whether a speed limit value is within a defined threshold of a typical speed limit for a variety of roads, including the vehicle carriageway, and selects the speed limit value as the expected speed limit value of the speed limit sign.

[0014] In other features, the control module is located outside the vehicle.

[0015] In other features, the control module is configured to transmit the expected location of at least one object to a variety of vehicle control modules, including the vehicle control module.

[0016] A vehicle system comprises a vehicle control module and a control module that communicates with the vehicle control module. The control module is configured to: receive data from a multitude of vehicles over a specified period, wherein the data includes detected locations and speed limit values ​​of at least one speed limit sign along a vehicle lane; cluster the received data into a multitude of groups; detect at least one set of duplicate groups from the multitude of groups; merge the duplicate groups into a single group or remove at least one of the duplicate groups to form a set of deduplicate groups associated with the at least one speed limit sign; and determine an expected speed limit value of the at least one speed limit sign based on the set of deduplicate groups.and determining an expected location of the at least one speed limit sign based on the set of deduplicated groups. The vehicle control module is configured to receive the expected speed limit value and the expected location of the at least one speed limit sign and to generate a control signal to control at least one operation of the vehicle based on the expected speed limit value and the expected location of the at least one speed limit sign.

[0017] In other features, the control module is configured to detect a contradiction between one or more of the received speed limit values ​​from at least one speed limit sign.

[0018] In other features, the control module is configured to determine the expected speed limit value based on a number of previous contradictions for the at least one speed limit sign.

[0019] In other features, the control module is configured to: determine whether a speed limit value of the received speed limit values ​​is within a defined threshold of a typical detected speed for the vehicle lane, and select the speed limit value as the expected speed limit value of the at least one speed limit sign.

[0020] In other features, the control module is configured to: determine whether a speed limit value of the received speed limit values ​​is within a defined threshold of a typical speed limit for a variety of roads, including the vehicle lane, and select the speed limit value as the expected speed limit value of the at least one speed limit sign.

[0021] A vehicle control procedure comprises: receiving data from a multitude of vehicles over a specified period, wherein the data includes captured locations of at least one object along a vehicle lane; clustering the received data into multiple groups; capturing at least one set of duplicate groups from the multitude of groups; merging the duplicate groups into a single group or removing at least one of the duplicate groups to form a set of deduplicate groups associated with the at least one object; determining an expected location of the at least one object based on the set of deduplicate groups; and generating a control signal to control at least one operation of a vehicle based on the expected location of the at least one object.

[0022] In other features, merging the duplicate groups into a single group involves averaging the latitude and longitude values ​​for the duplicate groups.

[0023] In other features, removing at least one of the duplicate groups includes removing at least one of the duplicate groups based on the number of the multitude of vehicles capturing locations of the at least one object, or the sampling frequency of the multitude of vehicles capturing locations of the at least one object.

[0024] In other features, removing at least one of the duplicate groups involves determining a weighted value assigned to each group from the set of duplicate groups, where the weighted value assigned to each group is based on a standard deviation of the locations of the group-specific object, a standard deviation of the directions of the group-specific object, and a standard deviation of the heights of the group-specific object.

[0025] In other characteristics, at least one of the duplicate groups is removed based on the weighted value and a threshold.

[0026] In other cases, the at least one object is a speed limit sign, and the data includes speed limit values ​​from the speed limit sign.

[0027] Further applications of this disclosure will become apparent from the detailed description, the claims, and the drawings. The detailed description and specific examples serve only for illustration and are not intended to limit the scope of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The present disclosure will become more fully apparent from the detailed description and the accompanying drawings, whereby the following applies: Fig. Figure 1 is a block diagram of an exemplary vehicle system with multiple vehicle control modules and a control module according to the present disclosure; Fig. 2 is a vehicle with parts of the vehicle system from Fig. 1, according to the present revelation; Fig. Figure 3 is a block diagram of an exemplary procedure for implementing a deduplication process with the vehicle system of Fig. 1, according to the present revelation; Fig. Figure 4 is a block diagram of an exemplary procedure for implementing a contradiction resolution process with the vehicle system of Fig. 1, according to the present revelation; Fig. Figure 5 is a flowchart of an exemplary control process for the deduplication of clustered groups of traffic signs along roadways and the identification of the expected locations of the traffic signs, according to the present disclosure; Fig. Figure 6 is a flowchart of an exemplary control process for detecting and resolving inconsistencies in traffic signs, according to the present disclosure; Fig. Figures 7-10 are flowcharts of exemplary control processes for deduplication of clustered groups, according to the present disclosure; and Fig.Figures 11-13 are flowcharts of an exemplary control process for resolving inconsistencies in traffic signs, according to the present disclosure.

[0029] Reference numbers can be reused in the drawings to designate similar and / or identical elements. DETAILED DESCRIPTION

[0030] Vehicles often rely on maps for vehicle control and / or display. These maps can be created using crowdsourcing algorithms that aggregate and group data collected over time from sensors across multiple vehicles. However, in some cases, different vehicles may report different locations for a particular object (e.g., a traffic sign), due to the vehicles' positions when detecting the object and / or sensor bias. Furthermore, a vehicle may report different locations (e.g., on the same or different trips) for a particular object due to vehicle positioning errors, sensor detection errors (e.g., a camera), environmental factors (e.g., fog, rain, snow, etc.). Often, the locations reported for a given object are close to each other and can be effectively aggregated and grouped.However, if the reported locations for a particular object are widely dispersed, grouping the data can lead to duplicate groups (e.g., clusters). Furthermore, in some cases, the collected data may contain a combination of true and false positive object detections or inconsistencies. For example, the collected data (from the same or different vehicles) might include speed limit values ​​of 35 MPH and 85 MPH for a single traffic sign in a residential area (e.g., a low-speed zone). Such data inconsistencies and duplicate groups can lead to inefficiency in computer resources, as well as ambiguities and reduced confidence in the objects for mapping and vehicle control.

[0031] The vehicle systems and methods described herein provide solutions for efficiently identifying duplicate groups (e.g., clusters), detecting inconsistencies in collected data, and subsequently resolving such duplicate groups and inconsistencies. As further explained herein, the vehicle systems and methods can, for example, dynamically detect duplicate road objects (e.g., traffic signs, etc.) originating from crowdsourced information from multiple vehicles and then identify certain duplicates that can be merged and others that can be discarded, thereby improving the quality of the crowdsourced object database. Furthermore, the vehicle systems and methods can dynamically detect inconsistent data regarding closely located road objects and then identify true / false positive results of the inconsistent data.In this way, the positions and details of objects along roads are accurately identified and used for map creation and vehicle control.

[0032] In Fig. Figure 1 shows a block diagram of an exemplary vehicle system 100. The vehicle system 100 generally comprises a control module 102 and vehicle control modules 106, 114, 120, 126, located in vehicles 104, 112, 118, and 124, respectively. Furthermore, each vehicle 104, 112, 118, and 124 has one or more sensors 108, 116, 122, and 128, respectively. In such examples, the sensors 108, 116, 122, and 128 can acquire data representing the properties of objects along the roadway. Although in Fig. 1. Where the vehicle system 100 is represented with special modules, one or more other modules can also be used if desired.

[0033] In various embodiments, the modules and sensors of the vehicle system 100 can communicate with each other and exchange parameters via one or more networks. For example, each vehicle 104, 112, 118, 124 can contain a local network, such as a Controller Area Network (CAN), for communication between the respective sensors and vehicle control modules. This allows various data from a specific module and / or sensor to be made available to other modules and / or sensors in each individual vehicle via its local network (e.g., one or more data buses of the network). Furthermore, each vehicle 104, 112, 118, 124 can communicate with the control module 102 via another network (e.g., a mobile network, etc.).In such examples, the vehicle control modules 106, 114, 120, 126 (or another suitable control module) of vehicles 104, 112, 118, 124 can contain a transmitter and a receiver for communication with control module 102. This allows data collected by one of the sensors 108, 116, 122, 128 to be exchanged internally (e.g., within a corresponding vehicle) and / or externally with control module 102.

[0034] In the example of Fig.1. Sensors 108, 116, 122, 128 can include any suitable sensor for detecting one or more properties of objects along the roadway. For example, sensors 108, 116, 122, 128 can include cameras, radar sensors, etc. Furthermore, the objects can be any suitable object on or near a road, such as traffic signs, billboards, road markings, stones, potholes, vehicles at the roadside, construction sites, etc. The traffic signs can be, for example, speed limit signs, yield signs, stop signs, merge signs, etc.

[0035] In various embodiments, the data from sensors 108, 116, 122, 128 can represent features of the objects. In such examples, the features can include the locations (e.g., location data) of the objects and the information displayed on the objects (e.g., speed limits, upcoming road events, etc.).

[0036] The vehicle system 100 of Fig. 1 can be used in any suitable vehicle, such as an electric vehicle (e.g., a pure electric vehicle, a plug-in hybrid electric vehicle, etc.), a vehicle with an internal combustion engine, etc. Furthermore, the vehicle system 100 can be used for an autonomous vehicle, a semi-autonomous vehicle, etc. Fig. 2 is, for example, a vehicle 200 with the vehicle control module 106, the sensors 108 (in Fig. 2 as sensors 108-1, 108-2) and the control module 110 from Fig. 1 shown. In the example of Fig. The sensors can be 108-1, 108-2 cameras.

[0037] In various embodiments, the vehicle system can be 100 of Fig.1. Use the control module 102 to implement the functions described here. In such examples, the control module 102 can be an external module (e.g., outside of vehicles 104, 112, 118, 124) and / or implemented using cloud computing. As explained below, the control module 102 can, for example, collect data for objects along roadways from one or more of the vehicles 104, 112, 118, 124 (and / or other vehicles not shown), group or cluster the collected data, detect or otherwise identify duplicate groups within the groups, and perform a deduplication process to resolve some or all of the duplicate groups. In various embodiments, the control module 102 can then determine the expected locations of the objects.The expected locations and / or maps containing the expected locations can then be transferred to one or more of the vehicles 104, 112, 118, 124 (and / or other vehicles not shown) for use in vehicle control applications.

[0038] Alternatively, some or all of the functions described here can be implemented with a control module in one or more of the vehicles 104, 112, 118, 124. As in Fig. As shown in Figure 1, vehicle 104, for example, contains a control module 110, depicted with a dashed line. The control module 110 can perform some or all of the functions described below in relation to the control module 102.

[0039] In Fig. 3 is, for example, a procedure 300 for carrying out a deduplication process with the control module 102 from Fig.Figure 1 illustrates this. As shown, procedure 300 generally comprises steps 302, 304, and 306. In step 302, the control module 102 receives data containing the captured positions of an object along a vehicle track 308 over a specific period. The collected data can be considered crowdsourced data, gathered from multiple vehicles, such as vehicles 104, 112, 118, and 124. Fig. 1 and / or additional vehicles, if desired.

[0040] In some examples, the data can be collected in sets for specific time periods, which can be referred to as capture events. For example, each capture event can represent a data record collected for a particular period. Just as examples: a first capture event might occur on day A in period B, a second capture event on day C in period D, a third capture event on day E in period F, and so on. Each capture event can contain a capture count, which indicates the number of vehicle passes during a specific period. For example, the first capture event might have a capture count of 85 vehicle passes, the second capture event a capture count of 305 vehicle passes, and the third capture event a capture count of 20 vehicle passes.

[0041] In the example of Fig.In step 302, the collected data are represented as records 310, 312, 314, and 316. In this example, each record 310, 312, 314, and 316 can represent data collected from another vehicle via one or more data collection events, another data collection event (e.g., multiple vehicles at a specific time), and so on.

[0042] In step 304, the collected data from records 310, 312, 314, and 316 are then clustered into three groups (or clusters) 318, 320, and 322 using a conventional clustering algorithm. For example, the clustering algorithm can group the received data into different clusters, where the data in one cluster (or group) are more similar to each other than in another cluster (or group). In this example, record 310 is clustered into group 318, record 312 into group 320, and records 314 and 316 into group 322. Fig. Figure 3 shows each group 318, 320, 322 with a (geometric) center of gravity or centroid. The clustering algorithm can, for example, perform density-based clustering, centroid-based clustering, k-means clustering, etc., based on the captured locations.

[0043] In step 306, groups 318, 320, and 322 (e.g., clusters) are analyzed using a deduplication process to detect duplicate groups. For example, control module 102 can compare the location data in groups 318, 320, and 322 and determine that one group / cluster is close to another, thus identifying the groups / clusters as duplicates. Control module 102 can then invoke various actions to resolve some or all of the duplicate groups and create a set of deduplicated groups associated with the object. In the example of Fig.In step 3, group 318 is removed, as shown in step 306, and groups 320 and 322 are merged into group 324. This creates one or more deduplicated groups (e.g., group 324) that are assigned to the object along a roadway 308.

[0044] In various embodiments, the control module 102 can combine duplicate groups into a single group in any suitable way. For example, if the centers of gravity, boundaries, etc., of the duplicate groups (or clusters) are close to each other (e.g., within a distance threshold), the groups can be merged. In such examples, the control module 102 can combine the duplicate groups into a single group by calculating the average of the latitude and longitude values ​​in the groups for the object.

[0045] Additionally and / or alternatively, control module 102 can remove at least one of the duplicate groups in any suitable way. For example, if the centers of gravity, boundaries, etc., of the duplicate groups (or clusters) are not close to each other (e.g., greater than a distance threshold), one or more of the groups can be removed.

[0046] In other embodiments, the control module 102 can merge and / or remove duplicate groups based on one or more features associated with the acquisition events in which data is collected. For example, the control module 102 can remove one of the duplicate groups based on the number of vehicles sensing the object's location and / or based on the sampling frequency of the vehicles sensing the object's location. For example, if the first acquisition event contains clustered data for the object from 85 vehicles traveling on lane 308, and the second acquisition event contains clustered data for the object from 305 vehicles traveling on lane 308, the control module 102 can remove (or disregard) the clustered data from the first acquisition event.

[0047] However, if the first and second data acquisition events contain clustered data from the same number of vehicles (e.g., 100), control module 102 can consider the sample count (e.g., the sampling frequency) of the vehicles to determine whether removal is appropriate. For example, if the first data acquisition event includes a sample count of 50 data samples per vehicle and the second data acquisition event includes a sample count of 150 data samples per vehicle, control module 102 can remove (or disregard) the clustered data from the first data acquisition event.

[0048] In other embodiments, the control module 102 can merge and / or remove duplicate groups based on weighted values ​​for the groups. For example, a weighted function can be used to predict which groups are the most accurate and should therefore be considered reliable. Equation (1) below is an example of a weighted function that can be implemented. In equation (1), f(D) represents i ) represents a function of the normalized recording figures (e.g., the number of vehicle passes for a specific period), f(S i ) a function of the normalized sample count (e.g., the number of samples collected per vehicle per pass for a given period), f(P sdi ) a function of the standard deviation of the object locations (e.g., a traffic sign), f(H sdi ) a function of the standard deviation of the object's direction and f(E sdi) a function of the standard deviation of the object's height. WeightFactor(wi)=ƒ(Di)+ƒ(Si)+ƒ(Psdi)+ƒ(Hsdi)+ƒ(Esdi)

[0049] In various embodiments, the control module 102 can select a group from the double groups based on the weighted factor or value W. i and remove a threshold value. For example, if the value W i for a specific group smaller than a threshold (W min The group can be removed or discarded. Additionally, control module 102 can calculate a weighted average of the remaining groups to determine a merged or consolidated site.

[0050] With continued reference to Fig. 1. The control module 102 and / or the control module 110 can use the data from the deduplicated groups to determine an expected location of the object (e.g. the traffic sign, etc.).

[0051] For example, control module 102 and / or control module 110 can implement one or more models (e.g., linear regression models, etc.) to predict the expected position of a speed limit sign or other suitable object based on a set of deduplicated groups. In such examples, one model can be created and implemented to obtain a longitude coordinate of the expected location, and another model can be created and implemented to obtain a latitude coordinate of the expected location.

[0052] Furthermore, as explained below, the control module 102 can detect or otherwise identify inconsistencies in the collected data (e.g., conflicting speed limit values, etc., for a single sign) and perform a resolution process to resolve some or all of these inconsistencies. The control module 102 can then determine expected information about the objects (e.g., a speed limit value). The expected information (along with the expected locations from above) and / or maps containing the expected information (and locations) can then be transmitted to one or more of the vehicles 104, 112, 118, 124 (and / or other vehicles not shown) for use in vehicle control applications.

[0053] In Fig.Figure 4, for example, shows a procedure 400 for carrying out an objection resolution process using the control module 102. As shown, the procedure 400 generally comprises steps 402 and 404. In step 402, the control module 102 receives data (e.g., crowdsourced data) for objects along lanes 406 and 408 from several vehicles, such as vehicles 104, 112, 118, and 124. Fig. 1 and / or additional vehicles, if desired. The received data may include, for example, recorded locations and information about the objects. The data or data records in Fig. 4. Data can be collected using data collection events, where data is collected for specific time periods, as explained above.

[0054] In various implementations, the collected data can be clustered using a conventional clustering algorithm, as explained above. Additionally, the groups (e.g., clustered data) can be analyzed using a deduplication process to identify duplicate groups, and then some or all of the duplicate groups can be removed and / or merged to form a set of deduplicated groups, as explained above.

[0055] In the example of Fig.In the objects, 410-1, 410-2, and 412 are speed limit signs, and the information on the objects is speed limit values. After clustering the collected data and forming a set of deduplicated groups, some data indicate that sign 410-1 has a speed limit of 85 MPH, while other data indicate that sign 410-2 has a speed limit of 35 MPH. Additionally, some data indicate that sign 412 specifies a speed limit of 45 MPH.

[0056] At 404, the received data, in conjunction with the speed limit values ​​and the locations of the speed limit signs 410-1, 410-2, and 412, is analyzed using a resolution process to resolve any inconsistencies. For example, the control module 102 can first identify signs with the same location. In this way, the data associated with signs in a general neighborhood can be used to resolve inconsistencies. The general neighborhood can be determined, for example, based on the following criteria: whether the distance between the sign locations is less than a threshold, whether the sign locations are on the same side of the road, whether the sign locations are on different roads, whether the sign locations are at a similar height, whether the sign locations have a matching direction, etc. In the example of Fig.Signs 410-1 and 410-2 are located in close proximity to each other and can therefore be considered in the contradiction analysis. Sign 412, however, can be disregarded for the contradiction analysis, as it is generally located outside the close proximity of signs 410-1 and 410-2 (e.g., greater than a distance threshold, along various roads 406, 408, etc.).

[0057] Next, control module 102 can analyze the collected data and detect inconsistencies between the information on the remaining signs 410-1 and 410-2 at the same location. For example, control module 102 can compare portions of the collected data for one or more objects to identify inconsistencies. In the example of Fig.4. The control module 102 can detect a discrepancy between signs 410-1 and 410-2 at the same location, where some data indicates a speed limit of 85 MPH, while other data indicates a speed limit of 35 MPH. After identification, the control module 102 can use one or more discrepancy tables to resolve the discrepancy.

[0058] For example, a table can initially be created based on traffic regulations such as speed limits for a specific region (e.g., city, county, state, etc.), streets, and so on. Traffic regulations might stipulate, for instance, that the speed limit on residential streets must be between 15 and 50 MPH, and on access roads (e.g., non-residential streets) a maximum speed of 75 MPH. The table can then be initially set up with such values ​​for streets and locations. Additionally, initial results (e.g., expected speed limit values), the number of discrepancies encountered, and the review status can be stored. Table 1 below is an example of a discrepancy table initially created based on traffic regulations. Table 1 Contradiction pairs Location roadway Result Happen Verified 35 MPH vs. 85 MPH (Latitude, Longitude) Living area 35 MPH KA Yes 5 MPH vs. 25 MPH (Latitude, Longitude) Living area 25 MPH KA Yes

[0059] Once the discrepancy between the signs at the same location, 410-1 and 410-2, has been identified, the control module 102 can use the discrepancy table shown above to select or otherwise determine an expected speed limit value (e.g., a result). For example, the control module 102 can search the discrepancy table (e.g., a lookup table) for a similar discrepancy pair to the identified discrepancy. The detected discrepancy might be, for example, 85 MPH versus 35 MPH when driving on a residential street. If a similar discrepancy pair is found, the control module 102 can determine whether to use the stored result as the expected speed limit value. For example, if a similar discrepancy pair is found at the same location, the control module 102 can use the stored result as the expected speed limit value. In the example of Fig.4. Using the contradiction table, control module 102 determines that the value of 85 MPH is a false positive and the value of 35 MPH is a true positive. Therefore, the speed limit of 85 can be removed from the contradiction table for sign 410-1.

[0060] In other examples, control module 102 can implement a function to determine an expected speed limit value for the identified contradiction. Control module 102 can make this determination, for example, based on the number of previous occurrences of the same contradiction in the same location, the number of previous occurrences of the same contradiction in different locations, verification of the result (e.g., verification by a backend server, user verification, etc.), and so on.

[0061] Furthermore, the contradiction table (e.g., Table 1, see above) can be updated each time a contradiction is detected in various implementations. This can improve the strength and confidence in the determined expected speed limit value and help the system learn new contradictory cases. Table 2 below is an example of a contradiction table updated over time. In this example, the occurrences in the table can be incremented and reported to a backend server for further review. As can be seen from Table 2, the contradiction pair 35 MPH vs. 85 MPH has occurred 25 times, and the contradiction pair 5 MPH vs. 25 MPH has occurred 50 times. Table 2 Contradiction pairs Location roadway Result Happen Verified 35 mph vs. 85 mph (Latitude, Longitude) Living area 35 mph 25 times Yes 5 mph vs. 25 mph (Latitude, Longitude) Living area 25 mph 50 times Yes

[0062] In some embodiments, an identified contradiction may be unknown (e.g., not present in the contradiction table). In such examples, the control module 102 can determine an expected speed limit value of the speed limit sign based on various speed parameters, e.g., a typical detected speed for a particular lane or a typical speed limit for several roads of a similar type (e.g., residential streets, access-controlled streets, etc.). For example, the control module 102 can determine whether a speed limit value among the received speed limit values ​​(e.g., 35 MPH, 85 MPH, etc.) is within a defined threshold of a typical detected speed for a lane (e.g., lane 406 of Fig.4). If this is the case, the control module 102 can select this speed limit value as the expected speed limit value of the speed limit sign. In other embodiments, the control module 102 can determine whether a speed limit value of the received speed limit values ​​(e.g., 35 MPH, 85 MPH, etc.) is within a defined threshold of a typical speed limit for several similar roads (e.g., roads 406, 408 of Fig. 4). If this is the case, the control module 102 can select this speed limit value as the expected speed limit value of the speed limit sign.

[0063] In various embodiments, the determined locations of the objects and / or the determined information about the objects can be used for vehicle control applications. For example, the control module 102 (or the control module 110) of Fig. 1. The expected locations of speed limit signs and the expected speed limit values ​​for each sign are transmitted to the vehicle control module 106 of the vehicle 104. The vehicle control module 106 can then control one or more vehicle functions of the vehicle 104 based on the sign's position and the speed limit value. For example, the vehicle control module 106 can generate a control signal based on the sign's location and the speed limit value and then control an operation of the vehicle 104, such as movement and / or trajectory, based on the control signal.

[0064] Additionally, in some examples, control module 102 (or control module 110) can create a map based on the determined locations of the objects and / or the determined information about the objects. In such examples, the map can be displayed on a display module in vehicle 104, used for vehicle control, etc.

[0065] Fig. Figures 5-13 illustrate exemplary control processes 500, 600, 700, 800, 900, 1000, 1100, 1200, 1300, which control the vehicle system 100 of Fig. 1 can be applied. Although the exemplary control processes 500, 600, 700, 800, 900, 1000, 1100, 1200, 1300 with regard to the vehicle system 100 of Fig. 1. Each of the control processes 500, 600, 700, 800, 900, 1000, 1100, 1200, 1300 can be used by another suitable system and / or module (e.g., the control module 110) of the vehicle system 100, which can be described by the control module 102 and the vehicle control module 106.

[0066] The control process 500 is used to deduplicate clustered groups of traffic signs (or other suitable objects) along roadways and to identify the expected locations of the traffic signs. As in Fig.As shown in Figure 5, the control process 500 begins at 502 by receiving data from multiple vehicles over a specific period. As explained above, this data could be crowdsourced data collected through data capture events, where the data is gathered over a period of time, e.g., several days. The control process 500 then proceeds to 504, where the control module 102 can filter out unsuitable data from the collected data. For example, if some data does not meet a minimum accuracy threshold or is unsuitable for other reasons, this data can be filtered out of further processing. The control process 500 then proceeds to 506, where the control module 102 clusters the data into groups (e.g., clusters) for a traffic sign. In various embodiments, the control module 102 can apply a conventional clustering algorithm to cluster the data as desired.The tax process 500 then proceeds to 508.

[0067] At process 508, control module 102 checks for duplicate groups within the clustered groups. As explained above, control module 102 might, for example, compare location data within the clustered groups and determine that one group / cluster is located near another, thus identifying the groups / clusters as duplicates. If so, control process 500 continues with process 510. Otherwise, if no duplicate groups are found, control process 500 continues with process 512.

[0068] At 510, control module 102 performs a deduplication process to resolve the duplicate groups and create a set of deduplicated groups for the traffic sign. As explained above, control module 102 can, for example, remove one or more duplicate groups if the centers, boundaries, etc., of the duplicate groups (or clusters) are not close together (e.g., greater than a distance threshold) and / or based on a specific weighted factor. Furthermore, control module 102 can merge one or more duplicate groups if the centers, boundaries, etc., of the duplicate groups (or clusters) are close together (e.g., within a distance threshold). Then, after a set of deduplicated groups for the traffic sign has been created at 510, control process 500 continues with 512.

[0069] At process 512, control module 102 determines the expected location of the traffic sign. As explained above, control module 102 can, for example, implement one or more models (e.g., linear regression models, etc.) to predict the expected location of the traffic sign based on the set of deduplicated groups. Control process 500 then proceeds to process 514.

[0070] At 514, the vehicle control module generates 106 of Fig. 1. One or more control signals based on the expected location of the traffic sign. For example, the control module 102 can transmit the expected location of the traffic sign to the vehicle control module 106, which then generates the control signal(s). The control process 500 then proceeds to 516, where the vehicle control module 106 controls at least one operation of the vehicle 104 based on the control signal(s).

[0071] The tax process 600 of Fig.6 resembles the tax process 500 of Fig. 5, but includes additional steps for identifying and resolving contradictory pairs of traffic sign information. Although the exemplary tax process 600 of Fig. While section 6 relates to the identification of conflicting speed limits on traffic signs, the control process 600 can also be used to identify other conflicting information on traffic signs and / or conflicting information on objects along roads. As described in Fig. As shown in Figure 6, the tax process begins at 502 of 600. Fig. 5 and then continues to 504, 506, 508, 510 of Fig. 5, all of which have been explained above. Then, after a set of deduplicated groups for the traffic sign has been formed at 510, the control process continues at 600 with 612.

[0072] At process 612, control module 102 identifies signs with the same location that are assigned to the set of deduplicated groups. For example, as explained above, control module 102 can first identify signs with the same location that are in a general neighborhood. Deduplicated groups with data linked to other signs outside the general neighborhood can be excluded from consideration. Control process 600 then proceeds to process 614.

[0073] At step 614, control module 102 determines whether any of the remaining deduplicated groups contain conflicting speed limit values ​​for signs at the same location. As explained above, control module 102 can, for example, compare portions of the collected data for signs at the same location to detect inconsistencies. If conflicting speed limit values ​​are detected at step 614, control process 600 proceeds to step 616. Otherwise, if no conflicting speed limit values ​​are found, control process 600 proceeds to step 618.

[0074] At 616, control module 102 performs a contradiction resolution process to resolve the identified conflicting speed limit values. For example, after identifying conflicting speed limit values, control module 102 can use a contradiction table to resolve the contradiction, as explained above. If the identified contradiction is a known contradiction, control module 102 at 616 can select a contradiction result stored in the contradiction table as the expected speed limit. Alternatively, if the identified contradiction is unknown (e.g., not present in the contradiction table), control module 102 at 616 can determine an expected speed limit value based on various speed parameters, e.g.,a typical recorded speed for a particular roadway or a typical speed limit for several roads of a similar type (e.g. residential streets, access-controlled roads, etc.), as explained above.

[0075] At 618, control module 102 determines an expected speed limit value for the traffic sign if no conflicting speed limit values ​​exist. For example, control module 102 can implement one or more models (e.g., linear regression models, etc.) to predict an expected speed limit value based on the set of deduplicated groups.

[0076] After determining an expected speed limit value at 616 or 618, the control process 600 then proceeds to 514, 516 from Fig.5. For example, at 514 the vehicle control module 106 generates one or more control signals based on the expected speed limit value of the traffic sign, and at 516 the vehicle control module 106 then controls at least one operation of the vehicle 104 based on the control signal(s).

[0077] The tax process 700 of Fig. Figure 7 is an exemplary implementation of a deduplication process to resolve the duplicate groups and form a set of deduplicated groups for the traffic sign, as described in step 510 of Fig. 5. As in Fig.As shown in Figure 7, the control process 700 begins at step 702 by determining whether the road type in question is an access-controlled road. The control module 102 can, for example, rely on existing maps, known data, traffic regulations, etc., to identify a road as either an access-controlled road (e.g., a high-speed road such as a motorway, a highway, etc.) or an access-uncontrolled road (e.g., a low-speed road such as a residential street, etc.). If the road is an access-controlled road, the control process 700 continues with step 704. If the road is not an access-controlled road, the control process 700 continues with step 706.

[0078] In 704, the control module 102 performs a deduplication process for an access-controlled roadway to identify and resolve duplicate groups. An example of a deduplication process for an access-controlled roadway is the control process 800 described below. Fig. 8. At 706, control module 102 performs a deduplication process for a non-access-controlled roadway to identify and resolve duplicate groups. An example of a deduplication process for a non-access-controlled roadway is control process 900 in Fig. 9, which is described below. After the corresponding deduplication process for a roadway has been carried out in 704 or 706, the control process 700 then transitions to 708.

[0079] At step 708, control module 102 updates a data table to reflect the resolution of duplicate groups. The data table might be updated, for example, to remove and / or merge groups. Control process 700 then proceeds to step 710, where the updated data table is output or otherwise made available for use in determining expected locations.

[0080] The tax process 800 in Fig. Figure 8 is an example of the implementation of a deduplication process for an access-controlled lane for identifying and resolving duplicate groups. In various embodiments, some or all steps of the control process 800 can be found in Figure 704. Fig. 7 can be used. As in Fig.As shown in Figure 8, the control process 800 begins at module 802, where control module 102 receives or otherwise accesses a set of clustered data, for example, in a clustered data table. In such examples, the clustered data table might be created after crowdsourced data from multiple vehicles has been received over a specific period and clustered into groups (or clusters), as explained above. The control process 800 then proceeds to module 804.

[0081] At process 804, control module 102 identifies the highest detected speed limit value for a sign in the clustered data table. Control process 800 then proceeds to process 806, where control module 102 determines whether the highest detected speed limit value for the sign is less than or equal to a maximum threshold. In some examples, the maximum threshold might be a maximum speed limit for an access-controlled lane, set by a traffic regulation for a city, county, state, etc. For example, the maximum speed limit (e.g., the maximum threshold) could be 65 MPH, 70 MPH, 75 MPH, 80 MPH, etc.

[0082] If the highest detected speed limit value for the sign is greater than the maximum threshold (no, as in 806), control process 800 continues with 808. In 808, control module 102 replaces the sign with the maximum threshold value with the highest detected speed limit value in the clustered data table. Control process 800 then proceeds to 810.

[0083] However, if the highest detected speed limit value for the sign is less than or equal to the maximum threshold (yes at 806), control process 800 continues with 810. At 810, control module 102 determines whether the clustered data table contains more than one row of data. For example, each row in the clustered data table might contain data associated with a detection event for a specific time period, as explained above. If the clustered data table has one row or fewer (no at 810), there are no duplicate groups or no data in the table. In such cases, control process 800 continues with 824. However, if the clustered data table has more than one row (yes at 810), control process 800 continues with 812.

[0084] At process 812, control module 102 checks or identifies the highest capture count for the capture events in the clustered data table. As explained above, for example, each capture event contains a capture count indicating the number of vehicle passes during a specific time period. Control process 800 then proceeds to process 814, where control module 102 determines whether the highest capture count is equal to another capture count for a different capture event in the clustered data table. If it is not at process 814, control process 800 continues to process 816. If it is at process 814, control process 800 continues to process 818.

[0085] At 816, control module 102 retains the record in the clustered data table associated with the capture count with the highest value and deletes or removes the record in the clustered data table associated with the capture count with the lowest value. A capture count with a higher value is likely to contain more accurate data than a capture count with a lower value. For example, if one capture count has 35 vehicle pass-bys and another has 85 vehicle pass-bys, the record associated with the 85-vehicle capture count is retained (and used), while the record associated with the 35-vehicle capture count is deleted or removed. The 85-vehicle capture count thus includes more vehicles providing data (e.g., captured sign locations, captured sign speed limit values, etc.) than the 35-vehicle capture count.The tax process 800 then continues to 824.

[0086] At 818, the control module 102 checks or identifies the highest sample count among the same acquisition counts. For example, each acquisition count (e.g., the number of vehicle passes) can have a different sampling frequency based on the number of samples received from each vehicle during each pass. For instance, one vehicle pass might collect 10 samples, while another pass might collect 100 samples.

[0087] Control process 800 then proceeds to 820, where control module 102 determines whether the highest sample count is equal to the sample count for the other identical capture count. If the answer at 816 is "yes," control process 800 continues to 822. If the answer at 820 is "no," control process 800 continues to 816. At 816, control module 102 retains the record in the clustered data table associated with the sample count with the highest value and deletes or removes the other record(s) in the clustered data table associated with the capture sample(s) with lower values. For example, and continuing to refer to the example above, the record in the clustered data table associated with the 100 sample rate is retained (and used), while the record in the clustered data table associated with the 10 sample rate is deleted or removed.The tax process 800 then continues to 824.

[0088] In process 822, control module 102 performs a corrective action depending on the type of data involved. For example, if the data records with the same sample counts (and the same capture counts) refer to captured locations of the sign, control module 102 can calculate an average of the latitude values ​​and an average of the longitude values ​​and update the clustered data table with this merged data. In other examples, the data records with the same sample counts might refer to speed limit values. In such examples, control module 102 can initiate a process to identify and resolve inconsistencies, as explained here, leave the data records with the same sample counts unchanged, and so on. Control process 800 then proceeds to 824.

[0089] At step 824, control module 102 outputs the clustered data table containing all updates created in steps 808, 816, and 822. In various embodiments, the clustered data table at step 824 includes the set of deduplicated groups (e.g., without duplicate groups), as explained above. This clustered data table can then be used to determine the expected locations of signs (or other objects) and the expected speed limit values ​​of the signs (or other information about the signs or other objects), as explained above.

[0090] The tax process 900 in Fig. Figure 9 is an example of implementing a deduplication process for a non-access-controlled lane to identify and resolve duplicate groups. In various embodiments, some or all steps of the control process 900 can be found in Figure 706. Fig.7 can be used. The tax process 900 of Fig. 9 is essentially similar to the tax process 800 from Fig. 8, but it includes fewer steps. For example, the tax process 900 includes 802, 810, 812, 814, 816, 818, 820, 822, 824, as above in relation to the tax process 800 of Fig. 8 explained.

[0091] The tax process 1000 of Fig. Figure 10 is an example implementation for updating a table of clustered data. As shown in Fig. As shown in 10, the tax process begins 1000 of Fig.At 1000, control module 102 receives or otherwise accesses a set of clustered data, for example, in a table of clustered data, as explained above. Control process 1000 then proceeds to 1004, where control module 102 performs a duplicate detection process to identify duplicate groups (or clusters) and non-duplicate groups (or clusters). The duplicate groups are shown at 1006, while the non-duplicate groups are shown at 1008.

[0092] Subsequently, control module 102 performs a deduplication process on the duplicate groups from 1006 at 1010. This deduplication process can resolve the duplicate groups by removing and / or merging them, as explained above. During the deduplication process, control module 102 can delete the duplicate groups at 1012 and retain the valid (merged) groups at 1014.

[0093] Then, at module 1016, control module 102 generates metadata for the groups discarded / duplicated at module 1012 and reports this data. In other words, control module 102 can create a dataset of unwanted duplicate entries of objects (e.g., signs). This metadata can be used to improve future crowdsourcing processes.

[0094] At 1018, the control module 102 generates and outputs a data table containing the non-duplicate groups from 1008 and the valid groups (merged groups) from 1014. This data table can then be used to determine the expected locations of signs (or other objects) and the expected speed limit values ​​of the signs (or other information about the signs or other objects), as explained above.

[0095] The tax process 1100 in Fig.11 is an exemplary implementation for detecting and resolving inconsistencies (e.g., incorrect data entries). As in Fig. As shown in 11, the tax process begins at 1100. Fig. At point 10 at 802, control module 102 receives or otherwise accesses a set of clustered data, for example, in a table of clustered data, as explained above. Control process 1100 then proceeds to 1104, where control module 102 analyzes the clustered data to identify signs with the same location that are associated with, for example, a set of deduplicated groups (or clusters). For example, as explained above, control module 102 might first identify signs with the same location that are in a general neighborhood of each other. Control process 1100 then proceeds to 1106.

[0096] At step 1106, control module 102 checks for conflicting speed limit values ​​for signs at the same location. As explained above, control module 102 can, for example, compare parts of the collected data for signs at the same location to detect inconsistencies. If conflicting speed limit values ​​are detected at step 1106, control process 1100 continues with step 1108. However, if no conflicting speed limit values ​​are found, control process 1100 continues with step 1114.

[0097] At step 1108, control module 102 determines whether the identified conflicting speed values ​​represent a known conflict. For example, control module 102 can search a conflict table of known conflicts to determine if the identified conflicting speed values ​​are known. If the conflicting speed values ​​represent a known conflict, control process 1000 proceeds to step 1110, where control module 102 performs a known conflict resolution process to resolve the conflicting speed values, as explained above.Otherwise, if the conflicting speed values ​​are due to an unknown conflict, control process 1000 continues with 1112, where control module 102 performs a conflict resolution process for a new conflict to resolve the conflicting speed values, as explained above. After the conflict resolution process for a known or unknown conflict is complete, control process 1100 continues with 1114.

[0098] At 1114, control module 102 updates the contradiction table to reflect the resolution of conflicting speed values. For example, a contradiction can be added if it was previously unknown, an occurrence of a known contradiction can be incremented, and so on. In some examples, incrementing the occurrences can provide greater confidence in a contradiction resolution (e.g., selecting one of the conflicting speed values) in future processes.

[0099] The tax process 1200 of Fig. Figure 12 is an example of a process for resolving a contradiction when a new contradiction arises. In various embodiments, some or all steps of the control process 1200 can be taken from Figure 1112. Fig. 11 can be used. As in Fig.As shown in Figure 12, the control process 1200 begins at 1202, where the control module 102 receives or accesses new (or unknown) conflicting values. The control process 1200 then proceeds to 1204. At 1204, the control module 102 determines whether the conflicting values ​​contradict the speed limits. If not, the control process 1200 continues to 1205, where the control module 102 can implement a conflict resolution process unrelated to speed limits. An example of such a conflict resolution process is the control process 1300 in Figure 12. Fig. 13, which is described below. In other examples, the tax process 1200 can be terminated on request. If the answer to step 1204 is "yes", the tax process 1200 continues with steps 1206 and 1208.

[0100] At 1206, control module 102 compares each conflicting speed limit value with a typical vehicle speed for a road associated with the conflicting values. The typical vehicle speed could be, for example, an average vehicle speed, a vehicle speed at the 85th percentile, etc. Then, at 1208, control module 102 determines whether any of the conflicting speed limit values ​​are close to the typical vehicle speed. For example, control module 102 can determine whether the difference between any of the conflicting speed limit values ​​and the typical vehicle speed is below a certain threshold.If so, control process 1200 continues to 1210, where control module 102 selects the conflicting speed limit value, which is close to the typical vehicle speed, as the expected speed limit value of the speed limit sign. Control process 1200 then proceeds to 1220.

[0101] If the answer at 1208 is "no", the control process continues at 1200 with steps 1212 and 1214. At step 1212, control module 102 compares each conflicting speed limit value with a typical speed limit for the road category associated with the corresponding road where the signs are located. For example, control module 102 might compare the conflicting speed limits with a typical speed for similar roads, such as an average speed for highways, an average speed for residential streets, etc. Then, at step 1214, control module 102 determines whether any of the conflicting speed limit values ​​are close to the typical speed limit for the road category.For example, control module 102 can determine whether the difference between one of the conflicting speed limit values ​​and the typical speed limit value is below a threshold. If not, control process 1200 continues to 1218, where the controller waits for further data. Control process 1200 then returns to 1202. If "yes" is true at 1214, control process 1200 continues to 1216, where control module 102 selects the conflicting speed limit value that is close to the typical speed limit as the expected speed limit value of the speed limit sign. Control process 1200 then proceeds to 1220.

[0102] At 1220, the control module 102 verifies the selected expected speed limit value, e.g. with a backend server, a user, etc., and then updates a contradiction table to include the new contradiction speed values ​​and a result (e.g. the expected speed limit value).

[0103] At 1220, the control module 102 verifies the selected expected speed limit value, e.g. with a backend server, a user, etc., and then updates a contradiction table to include the new contradiction speed values ​​and a result (e.g. the expected speed limit value).

[0104] The tax process 1300 of Fig. 13 is an example of a process for resolving a contradiction when a new contradiction arises. In various embodiments, some or all steps of the control process 1300 can be taken from 1112. Fig.11 are used. As shown, the tax process begins at 1300. Fig. Control process 1300 then proceeds to control module 1304, where control module 102 receives or accesses clustered data. Control process 1300 then continues to control module 1304, where control module 102 determines whether the clustered data contains any inconsistencies for an object.

[0105] If the answer to step 1304 is "no", the control process 1300 continues with step 1306. At step 1306, the control module 102 populates a data table with the non-contradictory values ​​for later use (e.g., in vehicle control applications, etc.). Then, the control process 1300 returns to step 1302.

[0106] If the answer at 1304 is "yes", the control process 1300 continues to 1308. At 1308, the control module 102 determines a resolution of the contradiction, as explained here. The control process 1300 then proceeds to 1310, where the control module 102 sends a request to verify the determined resolution of the contradiction to, for example, a backend server, a user, etc. The control process 1300 then proceeds to 1312. At 1312, the control module 102 determines whether the determined resolution of the contradiction is verified. If not, the control process 1300 continues to 1314, where the controller waits for further data. The control process 1300 then returns to 1302. If the answer at 1312 is "yes", the control process 1300 continues to 1316. At 1316, the control module 102 updates a contradiction table to include the new contradictions and a result (e.g., the verified resolution of the contradiction).

[0107] The foregoing description is merely explanatory and is not intended to limit the disclosure, its application, or use. The comprehensive teachings of the disclosure can be implemented in a multitude of forms. Although this disclosure contains certain examples, the true scope of the disclosure should therefore not be so limited, since other modifications are evident upon study of the drawings, the description, and the following claims. It is understood that one or more steps within a process may be carried out in a different order (or simultaneously) without altering the principles of the present disclosure.Although each of the embodiments above is described with specific features, any one or more of these features described in relation to any embodiment of the disclosure can be implemented in one of the other embodiments and / or combined with features of another embodiment, even if this combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and permutations of one or more embodiments with each other remain within the scope of this disclosure.

[0108] Spatial and functional relationships between elements (e.g., between modules, circuit elements, semiconductor layers, etc.) are described using various terms, such as "connected," "interlocking," "coupled," "adjacent," "next to," "on," "above," "below," and "arranged." If a relationship between a first and a second element is not explicitly described as "direct" in the above disclosure, this relationship may be a direct relationship in which no other intervening elements exist between the first and the second element, or it may be an indirect relationship in which one or more intervening elements (either spatial or functional) exist between the first and the second element.As used herein, the phrase “at least one of A, B and C” should be interpreted as a logical (A OR B OR C) using a non-exclusive logical OR and not as “at least one of A, at least one of B and at least one of C”.

[0109] In the diagrams, the direction of an arrow, as indicated by the arrowhead, generally shows the flow of information (e.g., data or instructions) that is relevant to the illustration. For example, if Element A and Element B exchange a variety of information, but the information transferred from Element A to Element B is relevant to the illustration, the arrow may point from Element A to Element B. This unidirectional arrow does not imply that no further information is transferred from Element B to Element A. Furthermore, Element B may send requests for or acknowledgments of information to Element A in return for information sent from Element A to Element B.

[0110] In this application, including the definitions below, the term "module" or the term "controller" may be replaced by the term "circuit". The term "module" may refer to, be part of, or include: an application-specific integrated circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a combinational logic circuit; a field-programmable gate array (FPGA); a processor circuit (common, dedicated, or group) that executes code; a memory circuit (common, dedicated, or group) that stores the code executed by the processor circuit; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, e.g., in a system-on-a-chip.

[0111] The module may contain one or more interface circuits. In some examples, the interface circuits may include wired or wireless interfaces connected to a local area network (LAN), the internet, a wide area network (WAN), or combinations thereof. The functionality of any module of this disclosure may be distributed across multiple modules connected via interface circuits. For example, multiple modules may enable load balancing. In another example, a server module (also called a remote or cloud module) may perform some functions on behalf of a client module.

[0112] The term "code," as used above, can include software, firmware, and / or microcode, and can refer to programs, routines, functions, classes, data structures, and / or objects. The term "shared processor circuit" refers to a single processor circuit that executes some or all of the code of multiple modules. The term "group processor circuit" refers to a processor circuit that, in combination with other processor circuits, executes some or all of the code of one or more modules. References to "multiple processor circuits" include multiple processor circuits on discrete chips, multiple processor circuits on a single chip, multiple cores of a single processor circuit, multiple threads of a single processor circuit, or a combination of the above.The term "shared memory circuit" refers to a single memory circuit that stores some or all of the code from multiple modules. The term "group memory circuit" refers to a memory circuit that, in combination with other memory devices, stores some or all of the code from one or more modules.

[0113] The term "memory circuit" is a subset of the term "computer-readable medium." The term "computer-readable medium," as used here, does not include transitory electrical or electromagnetic signals that propagate through a medium (e.g., on a carrier wave); the term "computer-readable medium" can therefore be considered tangible / material and non-transient. Non-restrictive examples of a non-transient, tangible, computer-readable medium are non-volatile memory circuits (e.g., a flash memory circuit, a erasable programmable read-only memory circuit, or a mask read-only memory circuit), volatile memory circuits (e.g., a static random-access memory circuit or a dynamic random-access memory circuit), magnetic storage media (e.g., an analog or digital magnetic tape or a hard disk drive), and optical storage media (e.g.,a CD, a DVD or a Blu-ray Disc).

[0114] The devices and methods described in this application can be implemented partially or completely by a specialized computer formed by configuring a general-purpose computer to perform one or more specific functions embodied in computer programs. The functional blocks, flowchart components, and other elements described above serve as software specifications that can be translated into computer programs through the routine work of an experienced technician or programmer.

[0115] The computer programs contain processor-executable instructions stored on at least one non-transient, tangible, machine-readable medium. The computer programs may also contain or access stored data. The computer programs may include a basic input / output system (BIOS) that interacts with the hardware of the specialized computer, device drivers that interact with specific devices of the specialized computer, one or more operating systems, user applications, background services, background applications, etc.

[0116] The computer programs can contain: (i) descriptive text to be parsed, e.g., HTML (Hypertext Markup Language), XML (Extensible Markup Language), or JSON (JavaScript Object Notation); (ii) assembly code; (iii) object code generated from the source code by a compiler; (iv) source code for execution by an interpreter; (v) source code for compilation and execution by a just-in-time compiler, etc. The source code can, for example, use the syntax of languages ​​such as C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, Javascript®, HTML5 (Hypertext Markup Language 5th revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, MATLAB, Simulink, and others. It must be written in Python®.

Claims

[1] Vehicle system, comprising: a vehicle control module of a vehicle; and a control module that communicates with the vehicle control module, the control module being configured to: Receiving data from a large number of vehicles over a specific period of time, wherein the data includes captured locations of at least one object along a vehicle lane; Clustering the received data into a multitude of groups; Identifying at least one set of duplicate groups from the multitude of groups; Merging the duplicate groups into a single group or removing at least one of the duplicate groups to form a set of deduplicated groups associated with the at least one object; and Determining an expected location of the at least one object based on the set of deduplicated groups, where the vehicle control module is configured to: Receiving the expected location of at least one object; and Generating a control signal to control at least one operation of the vehicle based on the expected location of the at least one object. [2] Vehicle system according to claim 1, wherein the control module is configured to merge the duplicate groups into a single group by averaging the latitude and longitude values. [3] Vehicle system according to claim 1, wherein the control module is configured to remove at least one of the duplicate groups based on a number of the plurality of vehicles detecting locations of the at least one object, or a sampling frequency of the plurality of vehicles detecting locations of the at least one object. [4] Vehicle system according to claim 1, wherein the control module is configured to determine a weighted value to be assigned to each group from the set of duplicate groups and to remove at least one of the duplicate groups based on the weighted value and a threshold value. [5] Vehicle system according to claim 1, wherein the at least one object is a traffic sign and the data contains information on the traffic sign. [6] Vehicle system according to claim 5, wherein: the information on the traffic sign includes speed limit values; and The control module is configured to detect a contradiction between one or more of the speed limit values ​​of the traffic sign and determines an expected speed limit value based on a number of previous contradictions for the traffic sign. [7] Vehicle system according to claim 5, wherein: the information on the traffic sign includes speed limit values; and The control module is configured to determine whether a speed limit value is within a defined threshold of a typical detected speed for the vehicle roadway and selects the speed limit value as the expected speed limit value for the speed limit sign. [8] Vehicle system according to claim 5, wherein: the information on the traffic sign includes speed limit values; and The control module is configured to determine whether a speed limit value is within a defined threshold of a typical speed limit for a variety of roads, including the vehicle carriageway, and selects the speed limit value as the expected speed limit value for the speed limit sign. [9] Vehicle system according to claim 1, wherein: the control module is located outside the vehicle; and The control module is configured to transmit the expected location of at least one object to a multitude of vehicle control modules, including the vehicle control module. [10] Vehicle system, comprising: a vehicle control module of a vehicle; and a control module that communicates with the vehicle control module, the control module being configured to: Receiving data from a large number of vehicles over a specific period of time, wherein the data includes captured locations and speed limit values ​​from at least one speed limit sign along a roadway; Clustering the received data into a multitude of groups; Identifying at least one set of duplicate groups from the multitude of groups; Merging the duplicate groups into a single group or removing at least one of the duplicate groups to form a set of deduplicated groups associated with the at least one speed limit sign; Determining an expected speed limit value of the at least one speed limit sign based on the set of deduplicated groups; and Determining an expected location of at least one speed limit sign based on the set of deduplicated groups, where the vehicle control module is configured to: Receiving the expected speed limit value and the expected location of at least one speed limit sign; and Generating a control signal to control at least one operation of the vehicle based on the expected speed limit value and the expected location of the at least one speed limit sign.

Images