Determining objective ground characteristics from vehicle records

Abstract

To provide a method.SOLUTION: A ground objective characteristic is determined based on a vehicle record by: detecting a vehicle reaction of the vehicle, the vehicle reaction being triggered by a reading threshold of at least one trigger sensor of the vehicle; in response to detection of the vehicle reaction, recording output of the at least one trigger sensor of the vehicle and at least one associated sensor; and determining the ground objective characteristic based on the recorded output with respect to the at least one trigger sensor, the recorded output with respect to the at least one associated sensor, and at least one characteristic of the vehicle.SELECTED DRAWING: Figure 5

Description

[Background technology]

[0001] In-vehicle sensors are becoming more and more commonplace. With the advent of autonomous driving, vehicles are adding not only traditional cameras but also arrays of sensors such as LiDAR that complement existing sensors such as GPS. The combination of these sensors allows the vehicle to obtain a detailed representation of the world around the vehicle. Connecting to the Internet allows the vehicle to communicate with a centralized server. While much of the sensor data that makes up this representation is overwritten due to storage issues, some of the information is stored for the purpose of creating simulation environments for training and prediction of ADAS, maps, etc. using live, actionable information or historical information. The usefulness of this information increases with its quality. Generally, as the quality of information increases, so does the required data transfer and storage capacity. [Brief explanation of the drawings]

[0002] Aspects of the present disclosure are best understood from the following detailed description when read in conjunction with the accompanying figures. It should be noted that, according to standard industry practice, various features have not been drawn to scale. In fact, the dimensions of various features may be arbitrarily increased or decreased for clarity of illustration.

[0003] [Figure 1] FIG. 1 is a schematic diagram of a system for query content capture in a mobile computing network, according to at least some embodiments of the subject disclosure. [Figure 2] FIG. 2 is an illustration of a graphical user interface (GUI) for querying content on a mobile computing network, according to at least some embodiments of the subject disclosure. [Figure 3] FIG. 3 is an illustration of a data structure for a content acquisition task, according to at least some embodiments of the subject disclosure. [Figure 4] FIG. 4 is a schematic diagram of a query content acquisition system according to at least some embodiments of the subject disclosure. [Figure 5] FIG. 5 is an operational flow for determining objective characteristics of a ground surface based on vehicle recordings, according to at least some embodiments of the subject disclosure. [Figure 6] FIG. 6 is an operational flow for detecting a vehicle response according to at least some embodiments of the subject disclosure. [Figure 7] FIG. 7 is an operational flow for recording the output of a sensor according to at least some embodiments of the subject disclosure. [Figure 8] FIG. 8 is a diagram of a hardware configuration for determining objective characteristics of a ground surface based on vehicle event recordings, according to at least some embodiments of the subject disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0004] The following disclosure provides numerous different embodiments or examples that implement various features of the provided subject matter. To simplify the disclosure, specific examples of components, values, operations, materials, arrangements, or the like are described below. Of course, these are merely examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, or the like are contemplated. For example, in the following description, forming a first feature above or on a second feature may include embodiments in which the first and second features are formed in direct contact, and may also include embodiments in which an additional feature may be formed between the first and second features such that the first and second features may not be in direct contact. Additionally, the present disclosure may repeat reference numerals and / or letters in various examples. This repetition is for the purposes of brevity and clarity and does not, in itself, dictate a relationship between the various embodiments and / or configurations described.

[0005] Additionally, spatially relative terms such as "lower," "below," "belower than," "upper," "above," and the like may be used herein for ease of description to describe the relationship of one element or feature to another element or feature as shown in the figures. Spatially relative terms are intended to encompass various orientations of the device in use or operation in addition to the orientation depicted in the figures. The device may be otherwise oriented (rotated 90 degrees or at other orientations) and the spatially relative descriptions used herein may be similarly interpreted accordingly.

[0006] Users, such as software developers, insurance providers, market researchers, and law enforcement officers, can use the on-demand data acquisition (ODDR) system to input data requests into a user interface, such as a graphical user interface (GUI). The software developer, for example, is a software developer who develops applications, middleware, or an operating system (OS) that run on the vehicle. Exemplary applications include automated driving system applications, such as object recognition applications, road recognition applications, sensor fusion applications, localization applications, path planner applications, and controller applications. The data requests are analyzed and stored on a server and then sent to the vehicle by the server. At the server, the data requests are stored in a storage unit, and a request queue is generated based on the stored requests. The user can view or request updates on the status of the data request. For example, while the data request is still in the server before being sent to the vehicle, the status may be indicated as “pending.” Once the server sends the data request to the vehicle, the status may be updated to “sent.” This allows the user to view and track the status of data requests made to the vehicle. While the description refers to a vehicle for clarity, those skilled in the art will recognize that the description is applicable to fleets of vehicles in addition to single vehicles. The description is also applicable to non-vehicle computing devices that are equipped with at least one sensor and connected in some manner.

[0007] The user interface for generating a data request includes forms associated with the vehicle that identify the information, the data type being requested, the start time, and the end time. In some embodiments, the requested data type includes a text field for syntax entry, allowing for more complex queries, such as a request for data collected only while making a "left turn on a red light." In some embodiments, the start and end times are absolute times, e.g., UNIX time, which is the time elapsed since UNIX epoch time. In some embodiments, the start and end times are relative to the time the data request is received by the vehicle. In some embodiments, the start and end times are relative to a trigger event. The trigger event is an event within the vehicle or in the vehicle's environment about which the user desires data, or the receipt of the data request by the vehicle. For example, trigger events arising from the vehicle's environment include sudden acceleration, sudden braking, capturing an image of the target of the data request, detecting the target of the data request, or other suitable events. The user information for monitoring the status of the data request includes identifying the information in the data request and the status of the data request, e.g., pending or sent.

[0008] In some embodiments, when a data request is received by a vehicle, the data request is processed to make the data request agnostic with respect to the source of the data request. In some embodiments, a data request identification (ID) is assigned to the received data request by the vehicle, for example, by a request extractor in the vehicle. In some embodiments, the data request ID is assigned to the data request prior to transmission of the data request to the vehicle. In some embodiments, the data request is generated by an application running in the vehicle, and the application assigns the data request ID. In other words, the data is processed in a consistent manner regardless of the program or system that sends the data request to the vehicle. In some embodiments, the data request is generated by a software component stored within the vehicle, and the data is processed consistently with data requests received from external devices. This facilitates sharing the same data collection software components between triggered data collection, where an application generates data collection requests to a logger and ODDR-based external data collection requests.

[0009] In some embodiments, when a data request is received by the vehicle, the data request is processed to make the data request agnostic to sensors and a server within the vehicle. In some embodiments, the data request is generated by an application running in the vehicle. In some embodiments, an application programming interface (API) can be used to make the data request from the application agnostic to information from sensors or a server within the vehicle. This helps maximize data collection for users without having to program requests for specific sensor models. The data request is then forwarded to a data collection unit, and the requested data is collected in response to the occurrence of a trigger event. In situations where a trigger event, such as a traffic accident, has already occurred, the data request is fulfilled based on data stored in a storage device within the vehicle. The time frame for the collected data, i.e., start time and end time, is determined based on the data request. The collected data is forwarded back to the server.

[0010] The collected data is then stored on the server and a notification is sent to the user regarding the completion of the data request, for example, the status of the data request is updated to "completed" on the user interface.

[0011] In some examples, a budgeting or payment system is implemented on the server side or vehicle side to charge the user a fee for data requests. The fee can be paid either at the time of sending the request or upon completion of data collection. The fee can be adjusted based on the type and amount of data requested. In some embodiments, if the total fee charged to the user reaches a maximum threshold for the user's budget, the data request from the user is denied.

[0012] The ODDR system allows users to access information collected by vehicles on an on-demand basis. That is, data is not necessarily collected continuously, but can be collected to meet a user's specific needs. In some embodiments, the ODDR system helps users, such as software developers, collect data and update their software design, implementation, and parameter adjustments in an experimental manner based on the collected data, allowing users to continuously improve their software by delivering updates from a server to their vehicles over a network, for example, as over-the-air (OTA) updates. In some embodiments, the ODDR system helps machine learning developers developing machine learning models for applications collect data to train their models with data that was not available when the models were initially developed, allowing machine learning developers to update their models to continuously correct weaknesses and issues. In some examples, insurance providers can collect data related to traffic accidents. In some examples, law enforcement can collect information related to crimes or traffic accidents.

[0013] Vehicles that undergo triggered responses to extreme situations, such as antilock braking system (ABS) engagement in response to heavy braking, seatbelt locking and / or airbag deployment in response to extreme deceleration, traction control activation in response to wheel slip, other operational design domain (ODD) limitations, etc., have information that is useful for warning other vehicles. However, the information currently used to determine the situation and the response itself is insufficient to determine whether other vehicles should be warned and to which vehicles the warning is applicable.

[0014] For example, when traction control is activated, the information required for activation, such as detecting that all power is going to the right wheel while the left wheel is stationary, may be insufficient to determine whether the wheel slip is an isolated incident or due to ground characteristics such as a weather event. Even if the slip is due to ground characteristics such as extreme weather, the information required for activation may be insufficient to determine whether other vehicles are also experiencing wheel slip.

[0015] At least some embodiments of the subject disclosure utilize existing triggers that react under extreme conditions and record events from a sensor perspective, including sensors used to determine the trigger and additional sensors, to gather enough information to understand its relevance to other vehicles.

[0016] 1 is a schematic diagram of a request acquisition system 100, according to some embodiments. The request acquisition system 100 includes a user interface (UI) 110. The UI 110 is configured to receive a user request for data from a vehicle 140. The request acquisition system 100 further includes a server 120, which is configured to receive the user request from the UI 110, transmit the user request to the vehicle 140, receive data from the vehicle 140, and provide the data to the user via an accessible console 150. The server 120 includes a communication section 130 that communicates with the UI 110 and the vehicle 140. The request acquisition system 100 further includes the accessible console 150 that is configured to communicate data collected from the vehicle 140 to the user.

[0017] The UI 110 is configured to receive input instructions from a user. In some embodiments, the user includes a software developer. In some embodiments, the user includes a machine learning model developer. In some embodiments, the user includes an insurance provider. In some embodiments, the user includes law enforcement personnel. In some embodiments, the user includes a market research company. The UI 110 provides options for the user to select the type of vehicle and type of data being requested. In some embodiments, the UI 110 can identify the information, the data type being requested, a start time, and an end time and generate a data request using a form related to the vehicle. In some embodiments, the start time and end time are absolute times, such as UNIX time, which is the time elapsed since UNIX epoch time. In some embodiments, the start time and end time are relative to the time the data request is received by the vehicle. In some embodiments, the start time and end time are relative to a trigger event. In some embodiments, the UI 110 also provides the user with options to select a trigger event and a data collection duration for the trigger event. In some embodiments, the UI 110 includes information related to the type of vehicle for which data is requested. In some embodiments, the UI 110 includes a vehicle ID that can uniquely identify a vehicle as the target of the request. For example, the vehicle ID includes a universally unique identifier (UUID) format. In some embodiments, the UI 110 includes a data type that can identify the source of data the user wants to collect. For example, the data type includes a sensor ID for a sensor from which sensor data will be collected and an application ID for an application from which application logs will be collected. In some embodiments, the sensor ID and application ID format includes a universally unique identifier (UUID) format. In some embodiments, the UI 110 includes a drop-down menu. In some embodiments, the UI 110 includes editable fields that accept information related to the data request. In some embodiments, the UI 110 includes fields for input for a query language such as SQL.In some embodiments, the UI 110 provides information about which data option types are available to the user. In some embodiments, the available data option types depend on the user. For example, in some embodiments, law enforcement may have more data options to choose from than insurance providers.

[0018] In some embodiments, the UI 110 includes a graphical user interface (GUI). In some embodiments, the UI 110 includes a mobile terminal, such as a mobile phone, that can connect to the server 120. In some embodiments, the UI 110 includes a web interface, such as a RESTful API. In some embodiments, the UI 110 includes a computer that can connect to the server 120. In some embodiments, the UI 110 can connect to the server 120 wirelessly. In some embodiments, the UI can connect to the server 120 via a wired connection. The UI 110 can also provide updates to the user regarding the status of the data request. In some embodiments, the UI 110 provides status updates regarding the data request in response to further queries by the user. In some embodiments, the UI 110 provides status updates regarding the data request automatically, without user interaction, upon receiving update information from the server 120. In some embodiments, the status update causes the UI 110 to trigger an alert to the user. In some embodiments, the alert includes an audio alert or a visual alert.

[0019] In some embodiments, the UI 110 includes a means for accepting payment of a fee from a user. In some embodiments, the UI 110 includes a data entry field that allows a user to enter payment card information. In some embodiments, the UI 110 includes a reader for detecting payment card information, such as a magnetic stripe reader, a bar code reader, a chip reader, or another suitable reader.

[0020] Server 120 includes a communications section 130 configured to communicate with UI 110 and vehicle 140. Communications section 130 includes a receiver 131 configured to receive data requests from UI 110. In some embodiments, receiver 131 includes a wireless receiver. In some embodiments, receiver 131 is configured to receive data requests via a wired connection. In some embodiments, receiver 131 is further configured to perform initial processing on the received data requests. In some embodiments, the received data requests include priority level information. In some embodiments, receiver 131 is configured to assign a priority level to the data request based on the identity of the user who sent the data request or a fee paid by the user who sent the data request. In some embodiments, receiver 131 is configured to assign a request identification (ID) number to each received data request. In some embodiments, server 120 is configured to restrict access to certain sensors in vehicle 140 based on the identity of the user. For example, in some embodiments, third-party users are prevented from accessing sensors related to safety features of vehicle 140.

[0021] Communications section 130 further includes a memory unit 132 configured to store data requests received by receiver 131. In some embodiments, memory unit 132 includes random access memory, solid state memory, or another type of memory. In some embodiments, memory unit 132 is configured to store the data requests along with their status. In some embodiments, the status of the data request includes pending (before sending the data request to vehicle 140), sent (after sending the data request to vehicle 140), and completed (after receiving the requested data from vehicle 140). In some embodiments, memory unit 132 is accessible by a user. In some embodiments, updates to information in memory unit 132 trigger a notification to the user associated with the information updated in memory unit 132. In some embodiments, memory unit 132 stores the data requests along with timestamp data indicating the time the data request was received. In some embodiments, memory unit 132 stores the data requests in association with a priority level. In some embodiments, the priority level is determined based on the identity of the user. For example, in some embodiments, law enforcement has a higher priority than insurance providers, which in turn have a higher priority than regular users, such as software developers. In some embodiments, the priority level is determined based on a fee paid by the user. For example, in some embodiments, a user can pay a fee to increase the priority level of their request to obtain the requested data more quickly. In some embodiments, the priority level and the amount of the fee are determined based on dynamic pricing. In some embodiments, the amount of the fee is directly proportional to the priority level. In some embodiments, the priority level and the amount of the fee are determined based on individually set limits, caps, and an analysis of resource availability. In some embodiments, the priority level of a data request increases as the amount of time between the initial storage of the data request and the transmission of the data request to the vehicle increases.

[0022] Communications section 130 further includes transmitter 133. Transmitter 133 is configured to transmit the status of the data request to UI 110. In some embodiments, the status of the data request is transmitted wirelessly to UI 110. In some embodiments, the status of the data request is transmitted to UI 110 via a wired connection, for example, when the vehicle is plugged in at a dealership. In some embodiments, transmitter 133 is configured to automatically provide updates to the data request in response to updates in memory unit 132. In some embodiments, transmitter 133 is configured to provide updates to the data request in response to an update request received from a user. In some embodiments, transmitter 133 is configured to automatically transmit a request ID upon initially saving the data request to memory unit 132. In some embodiments, the status of the data request includes a priority level of the data request. In some embodiments, the status of the data request includes an estimated time until the data request will be transmitted to vehicle 140.

[0023] Communications section 130 further includes a query queue 134 configured to store data requests in a priority order for transmission to vehicle 140. In some embodiments, query queue 134 is incorporated within memory unit 132. In some embodiments, query queue 134 is separate from memory unit 132. In some embodiments, query queue 134 is configured to retrieve data requests from memory unit 132 based on priority level and timestamp information. In some embodiments, query queue 134 is configured to sort data requests based on priority level and, for data requests having the same priority level, sort data requests by time since they were first stored in memory unit 132.

[0024] The communication section 130 further includes a transmitter 135 configured to transmit data requests from the query queue 134 to the vehicle 140. The transmitter 135 is configured to transmit the data requests to the vehicle 140 based on the order of the data requests in the query queue 134. In some embodiments, the data requests are transmitted wirelessly to the vehicle 140. In some embodiments, the data requests are transmitted to the vehicle 140 via a wired connection. The data requests transmitted to the vehicle 140 include trigger event information, data duration information relating to a period before and after the trigger event during which data should be collected, and sensor information indicating a certain type of sensor on the vehicle 140 should collect data. In some embodiments, the data requests transmitted to the vehicle 140 include priority level information. In some embodiments, the transmitter 135 is configured to transmit the data requests to the vehicle 140 when the vehicle 140 sends a request to the server 120 to transmit the data request to the vehicle 140. In some embodiments, transmitter 135 is configured to transmit a data request to vehicle 140 any time communication section 130 has sufficient connectivity to vehicle 140 to transmit the data request, unless communication section 130 has received information indicating that vehicle 140 is unable to accept a new data request. In some embodiments, transmitter 135 is configured to periodically transmit data requests to vehicle 140, as long as vehicle 140 is able to receive a new data request and transmitter 135 has sufficient connectivity to vehicle 140. In some embodiments, transmitter 135 is configured to transmit data requests to vehicle 140 in batches, for example, in groups of five data requests, twenty data requests, or some other number of data requests. In some embodiments, transmitter 135 is configured to request confirmation of receipt of the data request from vehicle 140. In some embodiments, transmitter 135 is configured to retransmit a data request in response to not receiving confirmation of receipt from the vehicle within a predetermined period of time. In some embodiments, the status of the data request stored in memory unit 132 is updated to indicate transmission to vehicle 140 in response to communication section 130 receiving confirmation of receipt of the data request from vehicle 140.

[0025] Communications section 130 further includes receiver 136 configured to receive notification of the occurrence of a trigger event from vehicle 140. In some embodiments, the occurrence of the trigger event is the receipt of a data request. In some embodiments, receiver 136 is configured to receive notification of the trigger event wirelessly. In some embodiments, receiver 136 is configured to receive notification of the trigger event via a wired connection. In some embodiments, receiver 136 is configured to send a signal to memory unit 132 updating the status of a data request associated with the notified trigger event.

[0026] Communications section 130 further includes receiver 137 configured to receive data from vehicle 140 in response to a data request transmitted by transmitter 135. In some embodiments, vehicle 140 divides the data into data packets, which are units of transmission from vehicle 140 to server 120, and receiver 137 receives the data packets from vehicle 140. In some embodiments, receiver 137 is configured to receive data wirelessly. In some embodiments, receiver 137 is configured to receive data via a wired connection. In some embodiments, receiver 137 is configured to transmit a signal to memory unit 132 updating the status of the data request related to receipt of the requested data. In some embodiments, data in response to a single data request is received from vehicle 140 in a single packet. In some embodiments, data in response to a single data request is received from vehicle 140 in multiple packets. Receiver 137 forwards the received data to preprocessor 122.

[0027] Server 120 further includes a preprocessor 122 configured to receive data from receiver 137 and perform preprocessing on the data to generate collected data. In some embodiments, preprocessing includes modifying data from multiple packets to compile the data according to a data request. In some embodiments, preprocessing includes deserializing the data to compile structured data from a received byte array. In some embodiments, preprocessing includes decompressing the data if it was compressed by vehicle 140 before transmission. In some embodiments, preprocessing includes error correction with an error correcting code (ECC), such as a Reed-Solomon (RS) code, a Bose-Chaudhuri-Bockenheim (BCH) code, a low-density parity check (LDPC) code, and the like. In some embodiments, preprocessing includes smoothing the data by removing outliers to reduce the risk of reporting erroneous data to a user. In some embodiments, preprocessing includes associating data request ID information, priority level information, or other suitable information with the received data from receiver 137. In some embodiments, the pre-processing includes aggregating query results from one or more vehicles. In some embodiments, the pre-processing includes one or more processes that are offloaded from a server. In some embodiments, the data is pre-processed so that the information is provided to the user in a format that is easy to understand and does not rely on specialized knowledge or equipment to identify the information.

[0028] Server 120 further includes data storage 126 configured to store collected data generated by data preprocessor 122. In some embodiments, data storage 126 is incorporated into memory unit 132. In some embodiments, data storage 126 is separate from memory unit 132. In some embodiments, data storage 126 includes a solid-state drive (SSD), random access memory, or another suitable memory. In some embodiments, data storage 126 is accessible by a user, for example, using UI 110 or accessible console 150. In some embodiments, data storage 126 is configured to notify a user in response to the availability of data related to a data request. In some embodiments, the notification includes an alert to the user. In some embodiments, the alert includes an audio alert or a visual alert. In some embodiments, data storage 126 is configured to cause UI 110 or accessible console 150 to automatically display a notification of the availability of collected data. In some embodiments, data storage 126 is accessible by a user using accessible console 150 without the user having to submit a data request. In some embodiments, the data in data storage 126 is searchable by a user via an accessible console 150. In some embodiments, the collected data is visualized in the console 150.

[0029] The request acquisition system 100 further includes a vehicle 140. The vehicle 140 includes sensors for detecting both the interior conditions of the vehicle 140 and the external environment surrounding the vehicle 140. In some embodiments, the sensors include a camera, a light ranging (LiDAR) sensor, a radio ranging (RADAR) sensor, a sound navigation and ranging (SONAR) sensor, an accelerometer, a steering wheel position, a speedometer, or another suitable sensor. The vehicle 140 can receive data requests either wirelessly or via a wired connection.

[0030] In some embodiments, upon receiving a data request, vehicle 140 is configured to assign a data request ID to the received data request, and the data request is processed in a manner that is agnostic to the system or program that generated the data request. In another embodiment, communication section 130 assigns the data request ID on behalf of vehicle 140, and the data request ID is included in the data request sent from communication section 130 to vehicle 140. Making the data request agnostic to the system or program that generated the data request helps expand the ability of vehicle 140 to receive and process a wide range of data requests from various users and systems. Vehicle 140 includes a processor that processes the data request and determines the type of information that sensors available in vehicle 140 can use to fulfill the data request. In at least some embodiments, vehicle 140 includes a mobile computing network that is a network of processors, controllers, or combinations thereof, such as a controller area network (CAN). In at least some embodiments, each processor is an electronic control unit (ECU). In at least some embodiments, a microcontroller unit (MCU) is present. Vehicle 140 further includes memory that stores data from the sensors. In some embodiments, a processor accesses the memory to determine whether any stored data can satisfy a data request. Vehicle 140 can also transmit data that it believes will satisfy a data request to server 120, either wirelessly or via a wired connection. In some embodiments, the processor is configured to attempt to satisfy received data requests in a prioritized order based on the received priority level of the data request. In some embodiments, vehicle 140 is configured to transmit data to the server in a prioritized order based on the received priority level of the data request.

[0031] In some embodiments, the memory and processor of vehicle 140 are configured to store and execute software applications in an electronic control unit (ECU) within vehicle 140. In some embodiments, the data request is generated by the software application stored in the ECU. In some embodiments, the data request is generated in response to a trigger event, such as sudden acceleration, sudden braking, capturing sensor data including a particular object or scene predetermined in the software application, a “crash” of the software application, an anomaly detected in the software application, or another suitable detected occurrence. In some embodiments, vehicle 140 is configured to generate a notification to a maintainer of the software application, e.g., a user, in response to detecting a trigger event associated with the software application. In some embodiments, the notification is sent directly to the user, for example, through UI 110, either wirelessly or via a wired connection. In some embodiments, the notification is sent to the user through server 120, either wirelessly or via a wired connection. In some embodiments, the notification includes an audio notification or a visual notification. In some embodiments, the notification is configured to cause UI 110 to automatically display the notification without user interaction.

[0032] Request acquisition system 100 further includes accessible console 150. Accessible console 150 allows a user to access the collected data stored in data storage 126. In some embodiments, accessible console 150 is incorporated into UI 110. In some embodiments, accessible console 150 is separate from UI 110. In some embodiments, accessible console 150 comprises a separate server separate from server 120. In some embodiments, accessible console 150 automatically receives collected data associated with a data request from a user when data storage 126 receives the collected data. In some embodiments, accessible console 150 allows a user to search data storage 126 to determine whether any of the collected data stored in data storage 126 is useful to the user without the user having to submit a data request.

[0033] Use of the request acquisition system 100 allows a user to obtain information from one or more vehicles 140 in a format that is easy to understand without relying on specialized equipment to request or read the received data. The ability to prioritize data requests in the request acquisition system 100 helps ensure that data is available to law enforcement or other users while also allowing users to pay a fee to obtain data more quickly. This flexibility helps improve the usability of the request acquisition system 100 for a wide range of users.

[0034] FIG. 2 is a diagram of graphical user interfaces (GUIs) 200 and 250 for a request acquisition system, according to some embodiments. In some embodiments, GUI 200 is usable as UI 110 in request acquisition system 100 (FIG. 1). In some embodiments, GUI 200 is usable to generate data requests to be received by receiver 131 (FIG. 1). GUI 200 includes multiple information types 210 that identify types of information that GUI 200 can accept from a user. GUI 200 further includes multiple fields 220 configured to accept information related to the corresponding information types 210 of GUI 200. GUI 200 also includes a send button 230 that is configured to send a data request to a server, e.g., server 120 (FIG. 1), based on the information in fields 220. Those skilled in the art will recognize that the names and number of multiple information types 210 are merely exemplary and that different numbers and types of information are within the scope of the present disclosure.

[0035] In some embodiments, fields 220 include fields for a user to enter a vehicle ID, a data type, a start time, and an end time. In some embodiments, fields 220 further include a field for a user to enter a priority level for the data request. In some embodiments, GUI 200 further includes information related to how a user can increase the priority level of the data request, for example, information indicating a fee associated with each available priority level. In some embodiments, GUI 200 includes field 220 that allows a user to enter login information to establish the user's identity. In some embodiments, GUI 200 is configured to display the user's priority level after receipt of the login information. In some embodiments, GUI 200 further includes field 220 that accepts payment information related to a fee for establishing the priority level of the data request. In some embodiments, fields 220 include fields for input for a query language, such as SQL. In some embodiments, GUI 200 is configured to utilize real or production samples to display sample data, enabling query trials and planning. In some embodiments, GUI 200 is configured to utilize a "REPL" such as SciPy / NumPy / Matplotlib or R, or a console such as Jupyter notebook.

[0036] GUI 250 is configured to be displayed to a user after the user selects send button 230 on GUI 200. In some embodiments, GUI 250 is usable as GUI 110 in ODDR system 100 (FIG. 1). GUI 250 includes information indicating that a data request has been received. GUI 250 includes a query ID label 260 and a query ID field 270. The information entered in query ID field 270 is received from a server, e.g., server 120 (FIG. 1), after the server receives and stores the data request. In some embodiments, GUI 250 includes vehicle ID information. In some embodiments, GUI 250 includes information related to the priority level of the data request. In some embodiments, GUI 250 includes information related to the status of the data request, e.g., pending, sent, completed, etc. In some embodiments, GUI 250 includes information related to an estimated time until the data request will be sent to a vehicle, e.g., vehicle 140 (FIG. 1). In at least some embodiments, GUI 250 includes information related to an estimated time until the requested data will be received. In at least some embodiments, GUI 250 includes information related to estimated energy consumption for receiving the requested data. In some embodiments, GUI 250 is displayed automatically in response to receiving query ID information from a server. In some embodiments, GUI 250 is displayed in response to a user submitting a request for an update to an uploaded data request.

[0037] 3 is a diagram of a data structure 300 for a get request command 310, according to some embodiments. In some embodiments, the get request command 310 is sent from the server 120 to the vehicle 140 (FIG. 1). The get request command 310 includes information related to the type of data sought by the data request to the vehicle, e.g., the vehicle 140 (FIG. 1).

[0038] The get request command 310 includes a transfer priority parameter 311 that indicates the priority level of the data request. The get request command 310 also includes a log level parameter 312 that indicates the type of data, if any, to be retrieved from other applications in the vehicle. For example, in some embodiments, the get request command 310 retrieves data from an object recognition application. The log level parameter 312 determines the type of data to retrieve from other applications, such as an error level or a critical level. In some embodiments, the log level parameter 312 is omitted from the get request command 310, or the log level parameter 312 is set to a null state. The get request command 310 also includes a collection time range parameter 313 that indicates a period of time before and / or after a trigger event for collecting data. In some embodiments, the time range corresponds to a start time and an end time entered by the user into the GUI 200 (FIG. 2). The get request command 310 also includes a uniform resource locator (URL) endpoint parameter 314 that indicates the destination of the data to be collected in response to the data request. The get request command 310 further includes a frequency parameter 315 that indicates how often, if any, data should be sampled from the time range 313. For example, if the event time is t=100 seconds, the time range has a start time=-1 second and an end time=2 seconds, and the frequency is 10 Hz (100 millisecond cycles), then data at t=99.0 seconds, 99.1 seconds, 99.2 seconds, ..., 101.9 seconds, and 102.0 seconds will be collected by the get request command. The get request command 310 also includes a log ID parameter 316 that indicates the type of sensor and / or application that can be used to collect the data requested by the data request. In some embodiments, a unique ID (such as a universally unique identifier (UUID)) is pre-assigned to every sensor and application, and the unique ID from which the user wants to collect data is specified in the log ID parameter 316. The get request command 310 also includes a requester ID parameter 317 that indicates the identity of the user making the data request. The get request command 310 further includes an event ID parameter 318 that indicates the triggering event associated with the data request.The get request command 310 further includes a budget ID parameter 319 that indicates the amount of resources of the vehicle, e.g., vehicle 140 (FIG. 1), that should be allocated to fulfill the data request. Those skilled in the art will appreciate that additional parameters are possible in the get request command 310. For example, in some embodiments, the get request command 310 includes a vehicle location parameter that indicates a geographic area in which a trigger event can occur. Those skilled in the art will also appreciate that the get request command 310 does not always include all of the parameters of FIG. 3. For example, in some embodiments, the budget ID parameter 319 is omitted.

[0039] 4 is a block diagram of a request acquisition system 400, according to some embodiments. In some embodiments, the request acquisition system 400 is part of the request acquisition system 100 (FIG. 1). In some embodiments, the request acquisition system 400 is usable together with the request acquisition system 100 (FIG. 1). In some embodiments, the request acquisition system 400 is separate from the request acquisition system 100 (FIG. 1).

[0040] The request acquisition system 400 includes a detection vehicle system 410 configured to capture information about the vehicle or its surroundings. The detection vehicle system 410 captures information about the vehicle and its surroundings and transmits the information to a server. The request acquisition system 400 further includes a server 440 configured to receive the information, encode the information, and stream the information to a user terminal 460.

[0041] The detection vehicle system 410 includes an electronic control unit (ECU) 420 configured to receive data from sensors 414, a global positioning system (GPS) 416, and a map 418. The ECU 420 includes a situation detector 422, a data specifier 432, a log collector 434, and a log transmitter 436. The situation detector 422 includes a vehicle control monitor 424, an object detector 426, and a scene detector 428.

[0042] In some embodiments, ECU 420 further includes a localization unit configured to receive data from GPS 416 and map 418 to determine the vehicle's position relative to detected and / or known object and / or road locations, as well as the vehicle's attitude and state. Attitude is the vehicle's orientation relative to a reference point, such as the roadway. In some embodiments, vehicle position also refers to the vehicle's position vector. Vehicle attitude and state refer to the vehicle's speed and heading. In some embodiments, vehicle attitude and state also refer to the vehicle's velocity vector, acceleration vector, and jerk vector. In some embodiments, the position vector, velocity vector, acceleration vector, and jerk vector include an angular vector. In some embodiments, the vehicle state also refers to whether the vehicle's engine or motor is running.

[0043] Sensor 414 is configured to capture information, e.g., images, of the environment surrounding the vehicle. In some embodiments, sensor 414 includes a visible light camera, an IR camera. In some embodiments, sensor 414 is replaced by or further accompanied by a Light Detection and Ranging (LiDAR) sensor, a Radio Detection and Ranging (RADAR) sensor, an Acoustic Navigation and Ranging (SONAR) sensor, or another suitable sensor. In some embodiments, sensor 414 includes additional cameras positioned elsewhere in the vehicle. For example, in some embodiments, additional cameras are positioned on the sides of the vehicle to detect larger portions of the environment to the left and right of the observing vehicle. Because vehicle occupants can look out the side windows of the vehicle, using additional cameras to detect larger portions of the environment around the vehicle helps increase the accuracy of detecting objects or scenes around the vehicle. For example, in some embodiments, additional cameras are positioned on the rear of the vehicle to detect larger portions of the environment behind the vehicle. This information helps capture information about objects. In some embodiments, the data from the sensor 414 includes a timestamp or other metadata to help synchronize the data from the sensor 414 with data from other components.

[0044] The GPS 416 is configured to determine the location of the vehicle. Knowing the location of the observing vehicle is useful for associating objects or scenes with the determined locations on the map 418.

[0045] Map 418 includes information related to roadways and known objects along the roadways. In some embodiments, map 418 can be used in conjunction with GPS 416 to determine the vehicle's location and heading. In some embodiments, map 418 is received from an external device, such as server 440. In some embodiments, map 418 is updated periodically based on information from sensors 414 and / or GPS 416. In some embodiments, map 418 is updated periodically based on information received from external devices. In some embodiments, map 418 is generated from sensor data by a simultaneous localization and mapping (SLAM) algorithm. Including map 418 helps determine whether an object is a known object. Including map 418 with known objects helps increase the accuracy of new object detection.

[0046] The condition detector 422 is configured to generate information related to the performance of the vehicle and the performance of systems within the vehicle. The condition detector 422 may collect information from components within the vehicle, such as sensors 414, the braking system, the acceleration system, and other suitable components. Using this information, the condition detector 422 may determine the performance of the vehicle. In some embodiments, the condition detector 422 is further configured to monitor the performance of software and networking operations within the vehicle. For example, in some embodiments, the condition detector 422 is configured to receive information related to software or application "crashes" within the vehicle. In some embodiments, the condition detector 422 is configured to collect information related to the storage capacity of memory devices within the vehicle. In some embodiments, the condition detector 422 is configured to receive information related to the processing power of a processor within the vehicle.

[0047] Vehicle control monitor 424 is configured to receive sensor data and control logs related to the current operation of the vehicle. In some embodiments, the sensor data includes information related to vehicle speed, acceleration, jerk, braking, steering, pitch, roll, yaw, hazard light flashing, horn honking, or other suitable information. Vehicle control monitor 424 is configured to determine whether any of the received sensor data indicates that criteria for satisfying a request are met, for example, whether a trigger event is detected.

[0048] The object detector 426 is configured to receive sensor data from the sensor 414 and determine whether any anomalous objects are located in the roadway. In some embodiments, the object detector 426 is further configured to determine whether any objects are present along or adjacent to the roadway. In some embodiments, the sensor data from the sensor 414 includes images, and the object detector 426 is configured to perform image recognition on the received images, for example, using a trained neural network, to identify anomalous objects. In some embodiments, the object detector 426 is configured to compare any identified objects with information from the GPS 416 and the map 418 to help determine the type of identified object. In some embodiments, the object detector 426 is configured to identify objects, such as tires, car parts, animals, potholes, traffic control signs, emergency vehicles, vehicles with active hazard lights, or other suitable objects, as objects.

[0049] The scene detector 428 is configured to receive sensor data from the sensors 414 and determine whether any scenes meeting the conditions to satisfy the request are located in the environment surrounding the vehicle. In some embodiments, the scene detector 428 is configured to determine that a vehicle accident is occurring in response to detecting two or more vehicles in contact with each other or a vehicle surrounded by multiple falling objects. In some embodiments, the scene detector 428 is configured to determine that construction is occurring based on detecting multiple construction vehicles in close proximity. In some embodiments, the scene detector 428 is configured to determine that a vehicle is parked on the shoulder based on determining that a vehicle is located adjacent to a roadway and is not moving or is moving significantly slower than other vehicles. In some embodiments, the scene detector 428 is configured to determine the content of the scene surrounding the vehicle using image recognition, such as through a trained neural network.

[0050] In some embodiments, each of the object detector 426 and the scene detector 428 is active during the entire operation of the vehicle, for example, when the vehicle engine or motor is running. In some embodiments, at least one of the object detector 426 or the scene detector 428 is activated in response to the vehicle control monitor 424 determining that a particular behavior, for example, a trigger event, has been detected.

[0051] The data specifier 432 is configured to receive a determination that fulfillment of the request has occurred or that a trigger event has been detected. The data specifier 432 is configured to analyze the received information and determine, based on the received data, which sensor data from the sensors 414 should be collected. For example, in some embodiments where an abnormal steering behavior by the driver is detected, the data specifier 432 is configured to determine that image data from the front camera of the sensor 414 should be captured. Further, the data specifier 432 is configured to determine a period of time over which data from the determined sensors should be collected based on the time of the detection event. In some embodiments, the data specifier 432 is configured to determine which sensors 414 should collect data based on instructions in the request received from the user.

[0052] In some embodiments, the data designator 432 is configured to determine a region of the received sensor data that is associated with the detected situation. In some embodiments, the region of the received sensor data is identified based on object recognition performed on the sensor data, for example, by the object detector 426 or the scene detector 428. In some embodiments, the data designator 432 is configured to crop received images from the sensor data or remove extraneous data from the sensor data if the sensor data is not an image, to reduce the amount of information in the abnormal situation log. In some embodiments, the data designator 432 is configured to remove personal information, such as license plates, human faces, etc., from the sensor data.

[0053] Log collector 434 is configured to receive data from data specifier 432. In some embodiments, log collector 434 is configured to receive data directly from sensors 414, GPS 416, or situation detector 422 based on information provided by data specifier 432. Log collector 434 is also configured to determine what information is useful in identifying the type and location of an object, for example, location information from GPS 416 or map 418, image information from sensor 414, truncated or reduced information from data specifier 432, timestamp information associated with the time the object or scene was detected, or other suitable information.

[0054] Log collector 434 generates log data based on the received interrelated data, such as the cropped image and location data. Log collector 434 also associates timestamp information with the log data to aid in synchronization of collected data and for queue priorities within server 440. In some embodiments, log collector 434 generates the log data to further include world coordinates associated with the cropped image. In some embodiments, log collector 434 generates the log data to further include a map location associated with the cropped image. In some embodiments, log collector 434 includes additional information to aid in increasing the accuracy of determining an object or scene.

[0055] While the above description relates to generating log data based on images from sensor 414, one skilled in the art will understand that log collector 434 is not limited to generating log data based solely on images. In some embodiments, log collector 434 is configured to generate log data based on information from other sensors mounted on the vehicle, such as a RADAR, a LiDAR, or other suitable sensors. In some embodiments in which the occupant is wearing smart glasses, log collector 434 is further configured to generate log data based on information received from the smart glasses.

[0056] Log transmitter 436 is configured to receive log data from log collector 434 and transmit the log data to server 440. In some embodiments, log transmitter 436 is configured to transmit the log data wirelessly. In some embodiments, log transmitter 436 is configured to transmit the log data via a wired connection. In some embodiments, log transmitter 436 is configured to transmit the log data directly to user terminal 460. In some embodiments, log transmitter 436 is configured to transmit the log data to a mobile device accessible by a user, which then transmits the log data to server 440. In some embodiments, log transmitter 436 is configured to transmit the log data to the mobile device using Bluetooth® or another suitable wireless technology. In some embodiments, ECU 420 is configured to determine whether a data transfer rate from the mobile device to server 440 is higher than a transfer rate from log transmitter 436 to server 440. In response to determining that the data transfer rate from the mobile device to the server 440 is higher, the log transmitter 436 is configured to transmit to the mobile device the log data to be transmitted to the server 440. In response to determining that the data transfer rate from the mobile device to the server 440 is not higher, the log transmitter 436 is configured to transmit the log data from the vehicle system 410 directly to the server 440 without transferring the log data to the mobile device.

[0057] In some embodiments, the detection vehicle system 410 further includes a memory configured to store sensor data from sensors mounted on the vehicle. In some embodiments, the memory is further configured to store information associated with previously detected objects or scenes. In some embodiments, in response to detecting an object or scene matching a previous object or scene, the data specifier 432 is configured to provide results based on the matching object or scene. In some embodiments, the detection vehicle system 410 is further configured to determine whether the detection vehicle has received information from the server 440 related to an object or scene matching the object or scene determined from the situation detector 422. In some embodiments, in response to detecting that the detection vehicle has already received information related to the determined object or scene, the detection vehicle system 410 is configured to prevent transmission of log data to the server 440. Avoiding sending redundant information to the server 440 helps reduce data sent to the server 440 and minimize power consumption by the detection vehicle system 410. In some embodiments, storing previous requests is referred to as caching. Those skilled in the art will understand caching as using hardware or software to store data so that future requests for that data can be fulfilled more quickly.

[0058] Server 440 includes a log data receiver 442 configured to receive log data from log transmitter 436. In some embodiments, log data receiver 442 is configured to receive log data from a mobile device. Server 440 further includes a log encoder 444 configured to encode the log data. Server 440 further includes a log forwarder 446 configured to transmit the encoded log data to user terminal 460. Server 440 further includes a request / rule receiver 448 configured to receive requests or rules from user terminal 460.

[0059] The log data receiver 442 is configured to receive the log data from the log transmitter 436. In some embodiments, the log data receiver 442 is configured to receive the log data from a mobile device. In some embodiments, the log data receiver 442 is configured to receive the log data wirelessly. In some embodiments, the log data receiver 442 is configured to receive the log data over a wired connection. In some embodiments, the log data receiver 442 is configured to add a timestamp to the log data regarding the time the log data was received.

[0060] The log encoder 444 is configured to encode the received log data according to a predetermined encoding protocol. Encoding the log data according to a predetermined encoding protocol helps ensure that the user terminal 460 can reliably decode the log data for use by the user terminal 460. In some embodiments, the log encoder 444 is configured to perform compression, image encoding, thumbnail image generation, or other suitable encoding protocol on the log data. In some embodiments, the log encoder 444 is configured to perform encryption of the log data. In some embodiments, the log encoder 444 is further configured to perform super-resolution to make the data more perceptible to a user. Those skilled in the art will understand that super-resolution is the process of receiving a high-resolution image from a low-resolution image. Improving the resolution of the log data helps reduce false positives or false negatives.

[0061] In some embodiments, server 440 further includes a database that stores the received log data. In some embodiments, the log data is stored in the database before and / or after encoding by log encoder 444. In some embodiments, the log data is stored in the database in priority queues. In some embodiments, the priority of the priority queues is determined based on the time an object or scene, e.g., a trigger event, was detected, the time the log data was received by log data receiver 442, the type of object or scene, the identity of the driver of the detected vehicle, or other suitable priority criteria.

[0062] Log transporter 446 is configured to receive encoded log data from log encoder 444. Log transporter 446 is configured to transmit the encoded log data to user terminal 460. In some embodiments, log transporter 446 is configured to transmit the encoded log data to a mobile device accessible by a user. In some embodiments, log transporter 446 is configured to transmit the encoded log data wirelessly. In some embodiments, log transporter 446 is configured to transmit the encoded log data over a wired connection. In some embodiments, log transporter 446 is configured to transmit encoding protocol information along with the encoded log data. Transmitting the encoding protocol information for the encoded log data helps the mobile device or user terminal 460 accurately decode the encoded log data for use by user terminal 460.

[0063] Request / rules receiver 448 is configured to receive new or updated rules or requests for data from a user. In some embodiments, request / rules receiver 448 is configured to receive new or updated rules or requests wirelessly. In some embodiments, request / rules receiver 448 is configured to receive new or updated rules or requests via a wired connection. In some embodiments, request / rules receiver 448 is by UI 110 (FIG. 1).

[0064] In some embodiments, server 440 is configured to receive formation locations from multiple vehicles. In some embodiments, server 440 is configured to receive navigation plans from multiple vehicles. In some embodiments, log forwarder 446 is configured to limit transmission of encoded log data to only vehicles within a predetermined distance of a detected trigger event.

[0065] In some embodiments, server 440 is configured to transmit only log data associated with newly detected trigger events, i.e., if a trigger event has already been reported by server 440, the trigger event is not reported again. Limiting repeated reporting of trigger events helps reduce redundant data received by user terminals to server 440.

[0066] User terminal 460 is a user terminal accessible by a user associated with a request to be satisfied. In some embodiments, user terminal 460 includes a GUI. In some embodiments, user terminal 460 is configured to automatically generate an alert in response to data received from server 440. In some embodiments, the alert includes an audio alert or a visual alert.

[0067] Those skilled in the art will understand that modifications to request acquisition system 400 are within the scope of this disclosure. For example, in some embodiments, detection vehicle system 410 can transmit log data directly to user terminal 460 over a network, such as a wireless network. In some embodiments, mobile devices of occupants in the detection vehicles can transmit log data directly to user terminal 460 over a wireless network, etc.

[0068] By automatically identifying and distributing information related to meeting rules or requirements detected within the vehicle or in the environment surrounding the vehicle, a user can improve the performance of applications or software executed using the vehicle's processing systems, such as ECU 420. In some embodiments, a user can object to information related to events such as accidents.

[0069] FIG. 5 illustrates a ground motion map based on vehicle records, according to at least some embodiments of the subject disclosure. objective The operational flow for determining the characteristics is based on the vehicle event record. objective A method for determining a characteristic is provided. In at least some embodiments, the method is performed by a vehicle, such as vehicle 140 shown in FIG. 1 or detection vehicle system 410 shown in FIG. 4. In at least some embodiments, the method is performed by a controller of the detection vehicle system, such as ECU 420 shown in FIG. 4 or controller 802 shown in FIG.

[0070] At S550, the detection section of the controller detects a vehicle response. In at least some embodiments, the detection section detects a vehicle response of the vehicle, where the vehicle response is triggered by a read threshold of at least one trigger sensor of the vehicle. In at least some embodiments, the read threshold is based on an operational design domain (ODD). In at least some embodiments, when the vehicle approaches an ODD limit of the at least one trigger sensor, a vehicle action, such as a safety feature, ABS, airbag, etc., is triggered. In at least some embodiments, an existing trigger may be utilized as the basis for recording an event. Further, in at least some embodiments, a specific query from the programmer may be used as the trigger. In at least some embodiments, the programmer may individually specify which sensors to record and which not to record, depending on a programmer-defined recording trigger. In at least some embodiments, the detection section adjusts the read threshold based on the amount of available storage. In at least some embodiments, the detection section performs the operations illustrated in FIG. 6, described below.

[0071] At S552, a recording section of the controller records the output of the sensors. In at least some embodiments, the recording section records the output of at least one trigger sensor and at least one associated sensor of the vehicle in response to detecting the vehicle response. In at least some embodiments, the at least one associated sensor comprises a GPS sensor. In at least some embodiments, the associated sensor includes one or more of a sensor that detects gear ratio, such as in the event of a wheel slip triggered vehicle response, a temperature sensor, a rain detection sensor, a snow detection sensor, a speed sensor, a tire wear estimation sensor, a GPS sensor, a driver view camera, etc. In at least some embodiments, the recording section performs the operational flow of FIG. 7, described below.

[0072] In S554, the controller decision section objectiveIn at least some embodiments, the determination section determines a characteristic of the ground based on the recorded output for each of the at least one trigger sensor, the recorded output for the at least one associated sensor, and at least one characteristic of the vehicle. objective In at least some embodiments, the at least one characteristic of the vehicle comprises at least one of a static characteristic based on the make and model of the vehicle, or a dynamic characteristic of the vehicle at the time of recording. In at least some embodiments, the recorded information of the event is analyzed to normalize the state with respect to vehicle characteristics, including static characteristics, e.g., vehicle weight, road clearance, gear ratio, drive train, etc., dynamic characteristics, e.g., load weight, tire pressure, current gear, current speed, etc., or both. In at least some embodiments, for example, if a road clearance sensor detects that the ground is at 80% clearance, the 80% is converted to an actual height by comparing the 80% with a known maximum clearance height for the vehicle model. This allows for the determination of the ground clearance independently of the vehicle recording the event. objective Characteristics are effectively revealed. In at least some embodiments, for example, the information may reveal that the ground is icy by considering temperature and rain or snow detection in the event of a wheel slip triggered vehicle response. In at least some embodiments, the information revealed about the ground itself may be utilized even in only one instance. However, in at least some embodiments, the information revealed about the ground itself may be improved by aggregating events recorded from multiple vehicles in the same geographic location.

[0073] In S556, the sending section of the controller is objective In at least some embodiments, the transmitting section transmits the characteristics over a network. objective 4. Send the characteristics to a server. In at least some embodiments, the sending section: objective Transmitting characteristics directly to another vehicle.

[0074] 6 is an operational flow for detecting a vehicle response, according to at least some embodiments of the subject disclosure. The operational flow provides a method for detecting a vehicle response. In at least some embodiments, a detection section adjusts a read threshold based on the amount of available storage. In at least some embodiments, the method is performed by a vehicle, such as vehicle 140 shown in FIG. 1 or detection vehicle system 410 shown in FIG. 4. In at least some embodiments, the method is performed by a detection section of a controller, such as ECU 420 shown in FIG. 4 or controller 802 shown in FIG. 8.

[0075] At S660, the detection section or a subsection thereof determines whether the amount of available storage is decreasing. In at least some embodiments, the detection section determines whether the amount of available storage is decreasing. In response to the detection section determining that the amount of available storage is not decreasing, operational flow proceeds to a decision regarding increasing available storage at S661. In response to the detection section determining that the amount of available storage is decreasing, operational flow proceeds to increasing the trigger sensor threshold at S664.

[0076] In S661, the detection section or a subsection thereof determines whether available storage is increasing. In at least some embodiments, the detection section determines whether the amount of available storage is increasing. In response to the detection section determining that the amount of available storage is not increasing, operational flow proceeds to a determination as to whether a trigger sensor reading threshold has been reached in S666. In response to the detection section determining that the amount of available storage is increasing, operational flow proceeds to a decrease in the trigger sensor threshold in S662.

[0077] At S662, the detection section or a subsection thereof decreases the threshold of the trigger sensor. In at least some embodiments, the detection section decreases the reading threshold of at least one trigger sensor. In at least some embodiments, the detection section decreases the reading threshold of each trigger sensor by a fraction of the detection range of the trigger sensor.

[0078] At S664, the detection section or a subsection thereof increases the threshold of the trigger sensor. In at least some embodiments, the detection section increases the reading threshold of at least one trigger sensor. In at least some embodiments, the detection section increases the reading threshold of each trigger sensor by a fraction of the detection range of the trigger sensor.

[0079] At S666, the detection section or a subsection thereof determines whether a trigger sensor reading threshold has been reached. In at least some embodiments, the detection section determines whether a reading threshold has been reached or exceeded for at least one trigger sensor of the vehicle. In response to the trigger sensor reading threshold not being reached, operational flow returns to the decision regarding the reduction of available storage at S660. In response to the trigger sensor reading threshold being reached, operational flow ends and proceeds to recording of the sensor output, such as operation S552 of FIG. 5.

[0080] 7 is an operational flow for recording a vehicle response according to at least some embodiments of the subject disclosure. The operational flow provides a method for recording a detected vehicle response. In at least some embodiments, the method is performed by a vehicle, such as vehicle 140 shown in FIG. 1 or detection vehicle system 410 shown in FIG. 4. In at least some embodiments, the method is performed by a recording section of a controller, such as ECU 420 shown in FIG. 4 or controller 802 shown in FIG. 8.

[0081] At S770, the recording section or a subsection thereof checks whether a vehicle response is detected. If vehicle response is detected, the operational flow proceeds to recording the output to storage at S772. If a vehicle response is not detected, the operational flow ends.

[0082] At S772, the recording section or a subsection thereof records the output in storage. In at least some embodiments, the recording section records the output of at least one trigger sensor and at least one associated sensor of the vehicle in response to detecting a vehicle reaction. In at least some embodiments, the recording section records the output of the at least one trigger sensor and at least one associated sensor in storage. In at least some embodiments, an ECU monitoring such sensors is programmed with additional tasks to record the output of this sensor, the associated sensors, etc.

[0083] At S774, the recording section or a subsection thereof determines whether a buffer record is available. In at least some embodiments, the recording section determines whether a buffer memory record of the sensor is available. In at least some embodiments, the buffer memory record always holds a few seconds / minutes of previous records for all sensors. In response to a buffer record being available, the operational flow proceeds to copying the buffer record in S776. In response to a buffer record not being available, the operational flow ends.

[0084] At S776, the recording section or a subsection thereof copies the buffer records. In at least some embodiments, the recording section copies the buffer records of the at least one trigger sensor and the at least one associated sensor to storage. In at least some embodiments, in the event of a trigger, the buffer memory records of the associated sensors are copied into storage to constitute the beginning of the recording event, making available the moment before the trigger.

[0085] FIG. 8 is a diagram of a hardware configuration for determining a program operation sequence that reduces the potential disclosure of personally identifiable information, according to at least some embodiments of the subject disclosure.

[0086] A preferred hardware configuration includes a detection vehicle system 800 that interacts with an input device 809 and communicates with the input device 809 and a server 810 over a network 808. In at least some embodiments, the detection vehicle system 800 is a computer or other computing device that receives input or commands from the input device 809 and the server 810. In at least some embodiments, the detection vehicle system 800 is integrated into the input device 809. In at least some embodiments, the detection vehicle system 800 detects the ground conditions based on vehicle records. objective A computer system that executes computer-readable instructions to perform operations related to determining the characteristic.

[0087] The detection vehicle system 800 includes a controller 802, a storage unit 804, an input / output interface 806, and a communication interface 807. In at least some embodiments, the controller 802 includes a processor or programmable circuitry that executes instructions and causes the processor or programmable circuitry to perform operations in accordance with the instructions. In at least some embodiments, the controller 802 includes analog or digital programmable circuitry, or any combination thereof. In at least some embodiments, the controller 802 includes physically separate storage or circuitry that communicates through communications. In at least some embodiments, the storage unit 804 includes a non-volatile computer-readable medium capable of storing executable and non-executable data accessed by the controller 802 during execution of instructions. The communication interface 807 sends and receives data to a network 808. The input / output interface 806 connects to various input and output units, such as input devices 809 via parallel ports, serial ports, keyboard ports, mouse ports, monitor ports, and the like, to accept commands and present information. In some embodiments, the storage unit 804 is external to the server 800 .

[0088] The controller 802 includes a detection section 820, a recording section 822, a decision section 824, and a transmission section 826. The storage unit 804 stores the sensor outputs 830, buffer records 832, and objective characteristics 834 and vehicle characteristics 836.

[0089] The detection section 820 is circuitry or instructions in the controller 802 configured to detect a vehicle response. In at least some embodiments, the detection section 820 is configured to detect a vehicle response of a vehicle, where the vehicle response is triggered by a threshold reading of at least one trigger sensor in the vehicle. In at least some embodiments, the detection section 820 utilizes information in the storage unit 804, such as the sensor output 830. In at least some embodiments, the detection section 820 includes subsections that perform additional functions as described in the flowcharts above. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0090] Recording section 822 is circuitry or instructions in controller 802 configured to record sensor outputs. In at least some embodiments, recording section 822 is configured to record the output of at least one trigger sensor and at least one associated sensor of the vehicle in response to detecting a vehicle reaction. In at least some embodiments, recording section 822 utilizes information in storage 804, such as sensor output 830, and records information in storage unit 804, such as buffer record 832. In at least some embodiments, recording section 822 includes subsections that perform additional functions as described in the flowcharts above. In at least some embodiments, such subsections are referenced by names associated with their corresponding functions.

[0091] Decision Section 824 of the ground objective In at least some embodiments, the determining section 824 determines the ground surface characteristics based on the recorded output for the at least one trigger sensor, the recorded output for the at least one associated sensor, and at least one characteristic of the vehicle. objectiveIn at least some embodiments, the determination section 824 utilizes information in the storage unit 804, such as sensor outputs 830, buffer records 832, and vehicle characteristics 836, to determine the vehicle characteristics. objective and records information such as characteristics 834 in storage unit 804. In at least some embodiments, decision section 824 includes subsections that perform additional functions as described in the flowcharts above. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0092] Transmission Section 826 objective In at least some embodiments, the transmitting section 826 may be configured to transmit the characteristics over a network. objective In at least some embodiments, the sending section 826 is configured to: objective In at least some embodiments, the transmitting section 826 is configured to: objective Transmit information from storage unit 804, such as characteristics 834, to network 808. In at least some embodiments, transmission section 826 includes subsections that perform additional functions as described in the flowcharts above. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions. It is referenced in.

[0093] In at least some embodiments, the apparatus is a separate device capable of processing logical functions to perform the operations herein. In at least some embodiments, the controller and storage unit need not be entirely separate devices, and in some embodiments, share circuitry or one or more computer-readable media. In at least some embodiments, the storage unit includes a hard drive that stores both computer-executable instructions and data accessed by the controller, and the controller includes a central processing unit (CPU) and RAM combination, where the computer-executable instructions are copyable in whole or in part for execution by the CPU during performance of the operations herein.

[0094] In at least some embodiments where the device is a computer, programs installed on the computer can cause the computer to function as or perform operations associated with the device embodiments described herein, and in at least some embodiments, such programs are executable by a processor to cause the computer to perform specific operations associated with some or all of the flowchart blocks and block diagrams described herein.

[0095] At least some embodiments are described with reference to flowcharts and block diagrams, where the blocks represent (1) steps in a process in which an operation is performed or (2) sections of a controller responsible for performing an operation. In at least some embodiments, particular steps and sections are implemented by dedicated circuitry, programmable circuitry provided with computer-readable instructions stored on a computer-readable medium, and / or a processor provided with computer-readable instructions stored on a computer-readable medium. In at least some embodiments, dedicated circuitry includes digital and / or analog hardware circuitry, including integrated circuits (ICs) and / or discrete circuits. In at least some embodiments, programmable circuitry includes reconfigurable hardware circuitry, such as field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), etc., comprising logical AND, OR, XOR, NAND, NOR, and other logic operations, flip-flops, registers, memory elements, etc.

[0096] In at least some embodiments, a computer-readable storage medium comprises a tangible device capable of holding and storing instructions for use by an instruction execution device. In some embodiments, a computer-readable storage medium includes, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card or a ridge-in-a-groove structure having instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0097] In at least some embodiments, the computer-readable program instructions described herein can be downloaded to each computing / processing device from a computer-readable storage medium or can be downloaded to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. In at least some embodiments, the network includes copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. In at least some embodiments, a network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0098] In at least some embodiments, the computer-readable program instructions for performing the operations described above are either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, and traditional procedural programming languages ​​such as the “C” programming language or similar programming languages, modern systems languages ​​such as Rust, or interface languages ​​such as Dart. In at least some embodiments, the computer-readable program instructions execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In at least some embodiments, in the latter scenario, the remote computer is connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or is connected to an external computer (e.g., over the Internet using an Internet Service Provider). In at least some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) executes computer-readable program instructions by utilizing state information of the computer-readable program instructions to individualize the electronic circuitry to perform aspects of the subject disclosure.

[0099] Although disclosed embodiments of the subject matter have been described, the scope of any claimed subject matter is not limited to the above-described embodiments. Those skilled in the art will understand that various modifications and improvements to the above-described embodiments are possible. Those skilled in the art will also understand from the claims that additional embodiments incorporating such modifications or improvements are within the scope of the present invention.

[0100] Unless an order is indicated by "first," "before," or the like, and unless output from a previous process is used in a later process, the operations, procedures, steps, and stages of each process performed by the apparatus, system, program, and method depicted in the claims, embodiments, or figures may be performed in any order. Even when a claim, embodiment, or figure describes a process flow using phrases such as "first" or "then," such description does not necessarily imply that the process must be performed in the order described.

[0101] In at least some embodiments, the ground surface is objective The determining of the characteristic includes detecting a vehicle response of the vehicle, the vehicle response being triggered by a reading threshold of at least one trigger sensor of the vehicle; recording an output of the at least one trigger sensor and at least one associated sensor of the vehicle in response to detecting the vehicle response; and determining a ground surface condition based on the recorded output of the at least one trigger sensor, the recorded output of the at least one associated sensor, and at least one characteristic of the vehicle. objective and determining the characteristics.

[0102] Some embodiments include instructions in a computer program, a method performed by a processor executing the instructions of the computer program, and an apparatus for performing the method. In some embodiments, the apparatus includes a controller including circuitry configured to perform the operations in the instructions.

[0103] The foregoing outlines features of some embodiments so that those skilled in the art may more fully appreciate aspects of the present disclosure. Those skilled in the art should understand that they may readily use this disclosure as a basis for designing or modifying other processes and structures that carry out the same purposes and / or achieve the same advantages as the embodiments incorporated herein. Those skilled in the art should also understand that such equivalent structures do not depart from the spirit and scope of the present disclosure, and that various changes, substitutions, and alterations may be made by those skilled in the art without departing from the spirit and scope of the present disclosure.

Claims

1. 1. A method comprising: Detecting a vehicle response of a vehicle, the vehicle response being triggered by a reading threshold of at least one trigger sensor of the vehicle; recording an output of the at least one trigger sensor and at least one associated sensor of the vehicle in response to detecting the vehicle response; determining an objective characteristic of the ground surface based on the recorded output of the at least one trigger sensor, the recorded output of the at least one associated sensor, and at least one characteristic of the vehicle; adjusting the read threshold based on the amount of available storage; A method comprising:

2. The recording comprises: recording the output of the at least one trigger sensor and the output of the at least one associated sensor in storage; copying a buffer record containing a record of the at least one trigger sensor and the at least one associated sensor from a predetermined time ago to the storage; The method of claim 1 , comprising:

3. The method of claim 1 or 2, further comprising transmitting the objective characteristics to a server over a network.

4. The method of claim 1 or 2, further comprising transmitting the objective characteristic directly to another vehicle.

5. The adjusting step comprises: Decreasing the read threshold in response to an increase in the amount of available storage; or The method of claim 1 or 2, further comprising at least one of: increasing the read threshold in response to a decrease in the amount of available storage.

6. The method of claim 1 or 2, wherein the at least one associated sensor comprises a GPS sensor.

7. The method of claim 1 or 2, wherein the at least one characteristic of the vehicle comprises at least one of a static characteristic based on the make and model of the vehicle, or a dynamic characteristic of the vehicle at the time of the recording.

8. The method according to claim 1 or 2, wherein the read threshold is based on a condition set in an operational design domain (ODD).

9. A non-transitory computer-readable medium having instructions recorded thereon, the instructions comprising: Detecting a vehicle response of a vehicle, the vehicle response being triggered by a reading threshold of at least one trigger sensor of the vehicle; recording an output of the at least one trigger sensor and at least one associated sensor of the vehicle in response to detecting the vehicle response; determining an objective characteristic of the ground surface based on the recorded output of the at least one trigger sensor, the recorded output of the at least one associated sensor, and at least one characteristic of the vehicle; adjusting the read threshold based on the amount of available storage; 1. A non-transitory computer-readable medium executable by one or more processors to perform operations, comprising:

10. The recording comprises: recording the output of the at least one trigger sensor and the at least one associated sensor in storage; copying a buffer record containing a record of the at least one trigger sensor and the at least one associated sensor from a predetermined time ago to the storage; 10. The non-transitory computer-readable medium of claim 9, comprising:

11. The non-transitory computer-readable medium of claim 9 or 10, wherein the actions further comprise transmitting the objective characteristic to a server over a network.

12. The non-transitory computer-readable medium of claim 9 or 10, wherein the action further comprises transmitting the objective characteristic directly to another vehicle.

13. The adjusting step comprises: Decreasing the read threshold in response to an increase in the amount of available storage; or The non-transitory computer-readable medium of claim 9 or 10, further comprising at least one of: increasing the read threshold in response to a decrease in the amount of available storage.

14. The non-transitory computer-readable medium of claim 9 or 10, wherein the at least one associated sensor comprises a GPS sensor.

15. 11. The non-transitory computer-readable medium of claim 9 or 10, wherein the at least one characteristic of the vehicle comprises at least one of a static characteristic based on the make and model of the vehicle or a dynamic characteristic of the vehicle at the time of the recording.

16. The non-transitory computer-readable medium of claim 9 or 10, wherein the read threshold is based on a condition set in an operational design domain (ODD).

17. 1. An apparatus comprising a controller including circuitry, the circuitry comprising: Detecting a vehicle response of a vehicle, the vehicle response being triggered by a reading threshold of at least one trigger sensor of the vehicle; recording an output of the at least one trigger sensor and at least one associated sensor of the vehicle in response to detecting the vehicle response; determining an objective characteristic of the ground surface based on the recorded output of the at least one trigger sensor, the recorded output of the at least one associated sensor, and at least one characteristic of the vehicle; adjusting the read threshold based on the amount of available storage; The apparatus is configured to:

18. The circuitry configured to record comprises: recording the outputs of the at least one trigger sensor and the at least one associated sensor in storage; 18. The apparatus of claim 17, further configured to copy a buffer record containing a predetermined time prior record of the at least one trigger sensor and the at least one associated sensor to the storage.

Images