Remote vehicle condition assessment system and method

Abstract

1. A method for adjusting a vehicle information transmitter associated with a vehicle, the method comprising: establishing a first reference point and a second reference point at a remote location; defining a line connecting the first reference point and the second reference point; traversing a route relative to the line by the vehicle; storing a plurality of position data points associated with the route by the vehicle information transmitter; transmitting the plurality of position data points to a computing system by the computing system; interpolating the plurality of position data points by the computing system; and calculating, by the computing system, an elevation of the vehicle information transmitter relative to the first reference point and the second reference point.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 62 / 804,585, filed February 12, 2019, entitled "Remote Vehicle Status And Terrain Elevation Estimation Systems And Methods," which is incorporated herein by reference in its entirety. [Background technology]

[0002] The present disclosure relates to systems and methods for determining the state of a vehicle in substantially real time, thereby enabling remote monitoring of a single vehicle or a fleet of vehicles.

[0003] Commercial fleet deployments require a set of vehicles to be present within a particular operational area at a particular time. For example, a fleet of construction vehicles at a construction site work together to perform assigned functions to complete a particular construction job within a particular timeframe. In such cases, monitoring the status of each vehicle in the fleet allows the fleet owner to remotely observe how each vehicle is performing and, for example, remotely determine whether a vehicle is idling excessively. Additionally, it would be beneficial to be able to remotely measure the terrain elevation associated with a vehicle while the vehicle is performing its designated job. An example of such a job would be changing terrain elevation during an earthmoving job. Summary of the Invention [Problem to be solved by the invention]

[0004] Therefore, a need exists for a system that can remotely determine the state of one or more vehicles. [Means for solving the problem]

[0005] An embodiment of a method for determining a vehicle's state includes collecting data associated with the vehicle. The data is recorded and transmitted to a data server. The data stored in the data server is retrieved and processed to extract vehicle information from the data. The state of the vehicle is determined based on the vehicle information, where the vehicle state may include any combination of vehicle position, vehicle speed, vehicle acceleration, and terrain elevation. Embodiments may include a vehicle information transmitter associated with the vehicle, where the vehicle information transmitter is calibrated prior to use. The calibration process may include defining first and second reference points relative to the vehicle. The calibration process may also include evaluating the elevation of the vehicle information transmitter above ground. The vehicle information transmitter may be continuously recalibrated.

[0006] Some embodiments determine whether the vehicle is moving, idling, or has an engine off. A binary variable is generated, the binary variable assuming a non-zero value if a speed associated with the vehicle is non-zero, and a zero value if the speed is zero.

[0007] An embodiment of an apparatus configured to determine a vehicle's state may include a vehicle information transmitter physically connected to the vehicle and a data server communicatively connected to the vehicle information transmitter. The data server may include a database and a computing system. In embodiments, the vehicle information transmitter collects and records data related to the vehicle and transmits the data to the data server. The data server stores the data. The data server extracts vehicle information from the data and determines the state of the vehicle based on the vehicle information. In certain embodiments, the vehicle information transmitter is identified by a unique device ID. The vehicle information transmitter includes a GPS and an IMU, and may also include a solar panel. In some embodiments, the data server includes a database that stores the data and a computing system that performs computing operations on the data.

[0008] Non-limiting, non-exhaustive embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like parts throughout the various drawings unless otherwise specified. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram illustrating an embodiment of a remote vehicle condition assessment system. [Figure 2] FIG. 2 is a block diagram illustrating an embodiment of a vehicle information transmitter. [Figure 3] FIG. 1 is a flow diagram illustrating an embodiment of a method for determining a state of a vehicle. [Figure 4] FIG. 1 is a schematic diagram illustrating a vehicle calibration and state measurement configuration. [Figure 5] FIG. 1 is a flow diagram illustrating an embodiment of a method for adjusting a vehicle information transmitter. [Figure 6A] FIG. 1 is a flow diagram illustrating an embodiment of a method for retuning a vehicle information transmitter. [Figure 6B] FIG. 1 is a flow diagram illustrating an embodiment of a method for retuning a vehicle information transmitter. [Figure 7A] 1 is a flow diagram illustrating an embodiment of a method for determining an idling state of a vehicle. [Figure 7B] 1 is a flow diagram illustrating an embodiment of a method for determining an idling state of a vehicle. [Figure 8A] FIG. 1 is a flow diagram illustrating an embodiment of a method for performing server-side RTK positioning. [Figure 8B] FIG. 1 is a flow diagram illustrating an embodiment of a method for performing server-side RTK positioning. [Figure 9] FIG. 1 is a flow diagram illustrating an embodiment of a method for RTK positioning using a mobile device. [Figure 10A] FIG. 1 is a flow diagram illustrating an embodiment of a method for implementing link loss tolerance using a vehicle information transmitter. [Figure 10B]FIG. 1 is a flow diagram illustrating an embodiment of a method for implementing link loss tolerance using a vehicle information transmitter. [Figure 11] FIG. 1 is a flow diagram illustrating an embodiment of a method for implementing link loss tolerance using a computing system. [Figure 12] FIG. 1 is a flow diagram illustrating an embodiment of a method for implementing RTK positioning. [Figure 13] FIG. 1 is a flow diagram illustrating an embodiment of a method for detecting the source of a negative charge. [Figure 14] FIG. 1 is a block diagram illustrating an embodiment of a RTK positioning system. [Figure 15] FIG. 2 is a block diagram illustrating an embodiment of a processing system that can be used to implement certain functions of a vehicle information transmitter. [Figure 16] FIG. 1 is a diagram showing an isometric view of a vehicle information transmitter. DETAILED DESCRIPTION OF THE INVENTION

[0010] In the following description, reference is made to, and forms a part of, the accompanying drawings, which illustrate specific exemplary embodiments in which the present disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the concepts disclosed herein, and it is understood that modifications can be made to the various disclosed embodiments and that other embodiments can be used without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be understood in a limiting sense.

[0011] Throughout this specification, the references "one embodiment," "embodiment," "one example," or "example" mean that a particular feature, structure, or characteristic described in connection with the embodiment or example is included in at least one embodiment of the present disclosure. Thus, the appearances of "one embodiment," "embodiment," "one example," or "example" in various places throughout this specification do not necessarily all refer to the same embodiment or example. Furthermore, particular features, structures, databases, or characteristics may be combined in any suitable combination and / or subcombination in one or more embodiments or examples. Additionally, the drawings provided herein are for illustrative purposes to persons skilled in the art and are not necessarily drawn to scale.

[0012] Embodiments of the present disclosure may be embodied as an apparatus, a method, or a computer program product. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, generally referred to herein as a "circuit," "module," or "system." Furthermore, embodiments of the present disclosure may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.

[0013] Any combination of one or more computer usable or computer readable media can be used. For example, computer readable media can include portable computer diskettes, hard disks, random access memory (RAM) devices, read-only memory (ROM) devices, erasable programmable read-only memory (EPROM or flash memory) devices, portable compact disc read-only memories (CDROMs), optical storage devices, magnetic storage devices, and any other storage medium now known or later discovered. Computer program code for carrying out the operations of the present disclosure can be written in any combination of one or more programming languages. Such code can be compiled from source code into machine language or computer readable assembly language suitable for the computer or device on which the code will be executed.

[0014] Embodiments may also be implemented within a cloud computing environment. For purposes of this specification and claims, "cloud computing" may be defined as a model that enables ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be quickly set up through virtualization, released with minimal management effort or service provider interaction, and scaled accordingly. The cloud model may consist of a variety of characteristics (e.g., on-demand self-service, broad network access, resource pooling, rapid elasticity, counted services, etc.), service models (e.g., Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), etc.), and deployment models (e.g., private cloud, community cloud, public cloud, hybrid cloud, etc.).

[0015] The flow diagrams and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. Each block in the flow diagrams or block diagrams represents a module, segment, or portion of code that includes one or more executable instructions for implementing specific logical functions. Each block in the flow diagrams and / or block diagrams, and combinations of blocks in the flow diagrams and / or block diagrams, can be implemented by a dedicated hardware-based system that performs the specified functions or actions, or by a combination of dedicated hardware and computer instructions. These computer program instructions can be stored in a computer-readable medium and can instruct a computer or other programmable data processing apparatus to function in a specific manner, where the instructions stored in the computer-readable medium produce an article of manufacture that includes instruction means, which implements the function(s) / action(s) identified in the block(s) of the flow diagrams and / or block diagrams.

[0016] Systems and methods described herein relate to remotely determining the state of one or more vehicles. In some embodiments, a vehicle information transmitter is associated with the vehicle. The vehicle information transmitter can be configured to collect and record data related to the vehicle and transmit the data from the vehicle to a remote data server. The vehicle data is processed to determine the state of the vehicle from the data.

[0017] FIG. 1 is a block diagram illustrating an embodiment of a remote vehicle condition assessment system 100. In some embodiments, the remote vehicle condition assessment system 100 includes multiple vehicle information transmitters, namely, vehicle information transmitter 112, vehicle information transmitter 114, and vehicle information transmitter 116. In some embodiments, each of vehicle information transmitters 112, 114, and 116 is associated with a unique vehicle (not shown in FIG. 1). In certain embodiments, one or more of vehicle information transmitters 112, 114, and 116 may be physically connected (fixed) to their respective vehicles.

[0018] In some embodiments, each of the vehicle information transmitters 112-116 is configured to communicate with the data server 102 over a public network 110. One example of the public network 110 is the Internet. In some embodiments, the data server 102 is located remotely from the vehicle information transmitters 112-116. In some embodiments, each of the vehicle information transmitters 112-116 can communicate with the data server using a wireless communication protocol, such as a wireless mobile data protocol or a wireless data service (wireless internet).

[0019] In some embodiments, each vehicle information transmitter of vehicle information transmitters 112-116 is configured to collect data related to the respective vehicle corresponding to vehicle information transmitter 112-116. In some embodiments, this data includes vehicle status, where the vehicle status for each vehicle includes vehicle position, vehicle speed, vehicle acceleration, and terrain elevation associated with the vehicle. In certain embodiments, terrain elevation is a relative measurement of the elevation of the terrain on which the vehicle is located. In embodiments, the relative measurement of the elevation of the terrain may be referenced to sea level.

[0020] In some embodiments, each vehicle information transmitter of vehicle information transmitters 112-116 is configured to record data associated with a corresponding vehicle. The data for each vehicle is time-stamped and stored within each associated vehicle information transmitter. In embodiments, each vehicle information transmitter of vehicle information transmitters 112-116 is configured to transmit the recorded data to data server 102 over public network 110.

[0021] In some embodiments, the data server 102 receives recorded data from each of the vehicle information transmitters 112-116 and stores the data in a database 104 included within the data server 102. The data stored in the database 104 may include data (i.e., recorded data, or data sets) related to multiple vehicles. In some embodiments, a computing system 106 included in the data server 102 reads the data from the database 104 and processes the data to extract vehicle information for each vehicle from the data corresponding to each vehicle. In some embodiments, the vehicle information includes vehicle position, vehicle speed, and vehicle acceleration. In embodiments, the computing system 106 is configured to determine the state of the vehicle based on the vehicle information. The computing system 106 may also be configured to perform other computing functions related to the operation of the remote vehicle state assessment system 100 described herein.

[0022] In some embodiments, a user interface 108 is communicatively coupled to the computing system 106. The user interface 108 is configured to allow a user to interact with the data server 102. In particular, the user interface 108 allows a user to input commands to the computing system 106, for example, via a keyboard, mouse, voice command, etc. User input commands may include requests to view, list, or sort data sets or data subsets associated with a particular vehicle. For example, a user may wish to view data corresponding to a particular vehicle information transmitter for a particular time window. The computing system 106 processes the user request, retrieves the requested data from the database 104, and presents the requested data to the user via the user interface 108 in an appropriate format. The user can view this data on a video display monitor or print the data using a printing device.

[0023] In some embodiments, the data server 102 and the vehicle information transmitters 112-116 are located in geographically separate locations. That is, the data server 102 is configured to remotely receive and process data transmitted by each of the vehicle information transmitters 112-116. Each of the vehicle information transmitters 112-116 transmits vehicle-related information, such as vehicle location, to the data server 102. The computing system 106 uses this data to determine the status of the vehicle associated with each vehicle information transmitter. This allows a user associated with the user interface 108 to remotely monitor the status of each vehicle associated with a vehicle information transmitter 112-116. In other embodiments, the user interface 108 can be co-located with a particular vehicle information transmitter and receive the vehicle status on a video display monitor on the vehicle itself.

[0024] An example of the remote vehicle condition assessment system 100 is a fleet of vehicles at a construction or mining site. In some embodiments, one or more vehicles are each equipped with a vehicle information transmitter, and each vehicle is tasked with a specific mining or construction job. One or more vehicles are tasked with modifying the terrain (moving or removing earth) associated with the construction or mining site. In these examples, a user can monitor the condition associated with each vehicle to determine how well each vehicle is performing its designated task. Unwanted activity, such as excessive vehicle idling, which can cost the fleet operational time and money, can be detected in substantially real time, if desired. For example, a remote monitoring option using the user interface 108 allows a user to remotely monitor the vehicles associated with each vehicle information transmitter, 112-116, in substantially real time.

[0025] In some embodiments, terrain elevation is a measurement included in the vehicle state associated with each vehicle. As the vehicle traverses the terrain, changes in terrain height (i.e., terrain elevation) are measured and recorded by corresponding vehicle information transmitters using the systems and methods described herein. If the route history of each vehicle in a fleet of vehicles operating within a designated area is known (from the vehicle state), then the corresponding terrain elevation history can be correlated against such route history to generate a three-dimensional map of the terrain associated with the designated area. Alternatively, in mining or earthmoving operations, a substantially real-time readout of terrain elevation provides a measure of how quickly the operation is progressing, because the terrain elevation along the area traversed by the vehicle can be used as a measure of how much earth has been removed, excavated, cut, or filled by the vehicle. A substantially real-time readout of terrain elevation can serve as a temporary record of how much terrain volume has been moved at a particular point in time. This can then be used to direct billing to customers or other third parties related to the operation.

[0026] FIG. 2 is a block diagram illustrating an embodiment of the vehicle information transmitter 200. The embodiments of the vehicle information transmitters 112 through 116 can be similar to the vehicle information transmitter 200. In some embodiments, the vehicle information transmitter 200 includes a GPS 202. The GPS 202 is a Global Positioning System receiver configured to acquire and track signals from multiple GPS satellites in real time and provide position measurements of the vehicle information transmitter 200 and the vehicle associated with the vehicle information transmitter 200. In some embodiments, the GPS 202 is configured to generate GNSS data. When the vehicle information transmitter 200 is associated with a vehicle, the position measurements of the vehicle information transmitter 200 also provide position measurements of the vehicle. The IMU 204 is an inertial measurement unit included in some embodiments of the vehicle information transmitter 200. In some embodiments, the IMU 204 is configured to measure linear and rotational accelerations and linear and rotational forces acting on the vehicle information transmitter 200. Information from the IMU 204 is used to calculate vehicle position and velocity in three dimensions and to determine the idling status of a vehicle associated with the vehicle information transmitter 200 described herein.

[0027] Some embodiments of the vehicle information transmitter 200 include a connection interface 206, which allows the vehicle information transmitter 200 to connect to or communicate with other different devices. For example, the connection interface 206 may include a network interface that allows the vehicle information transmitter 200 to connect to the Internet, for example, via a 4G connection, a Wi-Fi connection, or other wireless connection method. The connection interface 206 may include an interface that allows the vehicle information transmitter 200 to connect to local devices, for example, via Bluetooth or other wired or wireless network protocols. In some embodiments, the connection interface 206 may include radio frequency (RF) circuitry (such as amplifiers, mixers, and other RF-related elements) and one or more antennas that facilitate the transmission and reception of RF signals. In certain embodiments, the connection interface 206 may include a USB interface or an Ethernet interface that allows a user to communicate with the vehicle information transmitter 200 via a wired connection. This configuration allows a user to, for example, perform diagnostic or debug operations on the vehicle information transmitter 200.

[0028] Certain functions of the vehicle information transmitter 200, such as data routing, are performed by a processing system 208 included in some embodiments of the vehicle information transmitter 200. In some embodiments, the processing system 208 may also be responsible for routing data from the GPS 202 to the connection interface 206, for example. The processing system 208 may also be used to perform other operations, such as on-board real-time kinematic (RTK) calculations described herein. Some embodiments of the vehicle information transmitter 200 include a device ID 210, which is a unique identifier that uniquely identifies a particular vehicle information transmitter (e.g., the vehicle information transmitter 200) and serves to distinguish this vehicle information transmitter from other vehicle information transmitters. In some embodiments, the device ID 210 generates a device ID code unique to the vehicle information transmitter 200. This device ID code is transmitted with each transmission from the vehicle information transmitter 200. In some embodiments, the computing system 106 associated with the data server 102 uses the received device ID code to identify which vehicle information transmitter transmitted the associated data. This allows the computing system 106 to uniquely identify a particular vehicle associated with a particular vehicle information transmitter. Some embodiments of the vehicle information transmitter 200 include a memory 212 that allows temporary or permanent data storage by the vehicle information transmitter 200. In some embodiments, data is continuously recorded by the vehicle information transmitter 200 and continuously or periodically transmitted to the data server 102 via the connection interface 206. The memory 212 can be any combination of flash memory, disk drive, read-only memory, random access memory, and can include both volatile and non-volatile memory elements.

[0029] Some embodiments of the vehicle information transmitter 200 are powered by a combination of a solar panel 214 and a battery 216. In certain embodiments, the solar panel 214 generates power from sunlight to charge the battery 216 or to power the vehicle information transmitter 200. A power distribution system 218 routes power from any combination of the solar panel 214 and the battery 216 to the associated subsystems of the vehicle information transmitter 200.

[0030] 3 is a flow diagram illustrating an embodiment of a method 300 for determining a vehicle state. In some embodiments, the method 300 involves a computing system 106 associated with the data server 102 calculating the state of a vehicle associated with a vehicle information transmitter (e.g., vehicle information transmitter 112-vehicle information transmitter 116) based on information transmitted to the data server 102 by the corresponding vehicle information transmitter.

[0031] At 302, the vehicle information transmitter collects and records data related to the vehicle. In some embodiments, this data can be any combination of GPS data, IMU data, or other vehicle-related data, such as engine data, vehicle weight data, etc. In particular embodiments, this data is recorded in a memory, such as memory 212, providing a time-stamped history, among other features. Next, at 304, the vehicle information transmitter transmits the data to a database (such as database 104) associated with a data server (such as data server 102). The database serves to store the data until the data server needs it. At 306, a computing system (such as computing system 106) associated with the data server retrieves the data from the database, and at 308, the computing system processes the data to extract vehicle information from the data. This vehicle information can include vehicle position data, IMU data, or other vehicle-related data. Finally, at 310, the computing system uses the vehicle information to calculate the vehicle's status. This vehicle status is displayed to a user via a user interface (such as user interface 108), allowing the user to remotely monitor the vehicle's status.

[0032] FIG. 4 is a schematic diagram illustrating a vehicle calibration and state measurement setup 400. In some embodiments, before a vehicle information transmitter can be used to monitor the state of an associated vehicle, the vehicle information transmitter must undergo a calibration process. This calibration process takes into account its spatial mounting position on the vehicle. Once this calibration process is complete, a process similar to the calibration process is used to measure the state (position) of the vehicle information transmitter, i.e., the vehicle. In some embodiments, the vehicle calibration and state measurement setup 400 is used to calibrate and measure the state of a vehicle.

[0033] In some embodiments, the vehicle calibration and state measurement configuration 400 includes a vehicle 404 and a mounting point P R The vehicle 404 includes a vehicle information transmitter 402 physically connected (i.e., attached) to the terrain. The vehicle 404 may be stationary on the terrain or may move along the terrain. To calibrate the vehicle information transmitter 402, the vehicle 404 is steered to cross a line 408 connecting a first reference point P1 and a second reference point P2, each of which is a known reference point on the terrain. That is, the three-dimensional coordinates associated with each of the first reference point P1 and the second reference point P2 are known. In some embodiments, the point O and the attachment point P R A point O is selected on the line 408 so that the line 406 connecting is perpendicular to the line 408. Details of the calibration and measurement process associated with the vehicle information transmitter 402 are provided herein.

[0034] 5 is a flow diagram illustrating an embodiment of a method 500 for adjusting a vehicle information transmitter. At 502, a computing system (such as computing system 106) establishes a first reference point and a second reference point at a remote location. In some embodiments, the first reference point is first reference point P1 illustrated in FIG. 4, and the second reference point is second reference point P2 illustrated in FIG. 4. In particular embodiments, the first reference point and the second reference point are located at a remote location (e.g., a work site) relative to the computing system. In some embodiments, the computing system is similar to computing system 106.

[0035] At 504, the computing system defines a line connecting the first reference point and the second reference point. In some embodiments, this line is similar to line 408. Next, at 506, a vehicle (such as vehicle 404) traverses a path relative to line 408. At 508, a vehicle information transmitter associated with the vehicle (e.g., vehicle information transmitter 402) stores a plurality of position data points associated with the path. In some embodiments, the vehicle information transmitter generates a plurality of position data points using one or more sensors, such as GPS 202 and IMU 204, and stores these position data points in memory 212.

[0036] At 510, the vehicle information transmitter transmits a plurality of location data points to the computing system. In some embodiments, this transmission is performed over public network 110. In embodiments, the plurality of location data points may be first stored in a database, such as database 104, before being retrieved by the computing system. Finally, at 512, the computing system interpolates the plurality of location data points to calculate the height of the vehicle information transmitter relative to the first and second reference points. In some embodiments, this height is related to a length relative to line 406. Using interpolation, the computing system calculates a point P directly above line 408. R At this time, the height of the terrain below the vehicle is calculated using line 408. Finally, the height of the terrain is subtracted from the height of the vehicle information transmitter to obtain the height of the vehicle.

[0037] Essentially, measurements associated with the vehicle information transmitter 402 include the elevation of the terrain below the vehicle above sea level (also referred to herein as "terrain elevation"). These measurements also include the length of the line 406, which is substantially equal to the vehicle's elevation above the terrain at the point where the vehicle information transmitter is located. That is, the elevation measurements generated by the vehicle information transmitter 402 include a combination of the terrain elevation and the length of the line 406. When vehicle position data points are transmitted to the computing system, these position data points include a positive bias and terrain elevation, which is substantially equal to the vehicle's elevation at which the vehicle information transmitter is located. This positive bias is also referred to as the "calibration height." Method 500 is directed to calculating this calibration height and accounts for this calibration height in subsequent measurements associated with routine measurement operations. For example, the terrain elevation can be measured directly by subtracting the calibration height from the elevation measurement.

[0038] In some embodiments, the first reference point P1 and the second reference point P2 are known reference points associated with the terrain, i.e., the computing system has prior knowledge of parameters (such as altitude above sea level) associated with each of these reference points. In some embodiments, during the calibration process associated with method 500, the vehicle's path may intersect line 408. In other embodiments, the vehicle's path does not intersect line 408.

[0039] When a calibration routine is running as illustrated in method 500, the vehicle height is defined as the vehicle's calibration height. On the other hand, when a measurement routine is running (e.g., during normal vehicle monitoring operation), the vehicle height is included in the vehicle system state, taking into account the calibration height (i.e., bias) calculated during the calibration process. In some embodiments, line 408 is also referred to as the "calibration gate."

[0040] While Figure 4 illustrates two reference points P1 and P2 on the terrain, this approach can also be configured to include multiple reference points that collectively form a polygon in three dimensions. Additionally, this method, as described herein, can be used to realign one or more vehicles in a fleet during routine operation. These known lines, surfaces, and points defining the three-dimensional shape are continually updated with measurements performed by other surface height measurement devices as well as the mobile fleet.

[0041] In some embodiments, after the vehicle information transmitter is calibrated, the vehicle information transmitter can be deployed in a use case where the vehicle information transmitter measures and records data related to the vehicle and transmits this data to a remote server for further processing.

[0042] FIG. 6A is a flow diagram illustrating an embodiment of a method 600 for recalibrating a vehicle information transmitter. At 602, the method performs a calibration of the vehicle and vehicle information transmitter using a method similar to method 500. Next, at 604, the method stores a set of checkpoints (i.e., one or more) in a database, such as database 104. In some embodiments, the checkpoints are known locations on a given terrain area that are static in time. In particular embodiments, the known terrain area is also stored in the database along with the checkpoints. In embodiments, the checkpoints are stored in the database as points depicted in a three-dimensional (3D) coordinate system, and the terrain area is stored in the database as a polygon in the same 3D coordinate system. In some embodiments, the checkpoints and terrain area are pre-generated using surveying methods, including, for example, proprietary equipment or drone surveying used for external verification.

[0043] At 606, the method calculates machine-derived surface updates related to the terrain. In some embodiments, these updates, called "surface updates," are generated using a vehicle information transmitter on the vehicle when the vehicle passes over one or more checkpoints or terrain regions stored in a database. At 608, the method calculates the error (i.e., difference) between the checkpoint and the altitude captured by the vehicle information transmitter (e.g., via the update). At 610, the method stores the error as a residual error, for example, in a database. At 612, the method checks whether the calculations related to the surface update are complete. If the calculations are not complete, the method returns to 606. However, if the calculations are complete at 612, the method proceeds to A and continues with the description of FIG. 6B.

[0044] 6B is a flow diagram illustrating a continued description of method 600. Beginning at A, the method proceeds to 614 where one or more residual errors are converted to a statistical confidence measure, such as a mean, standard deviation, or 95% confidence interval. At 616, the method checks whether the average or peak error associated with the statistical confidence measure and the residual error is greater than a threshold. If the average or peak error is not greater than the threshold, the method interprets the data as substantially accurate and the method ends at 620. On the other hand, if at 616 the average or peak error is greater than the threshold, the method proceeds to 618 where the data is flagged as inaccurate and the method ends at 620.

[0045] Method 600 can be configured to include multiple vehicles. In one example, if two or more vehicles pass over a checkpoint area with low residual error (as validated) and a third vehicle's vehicle information transmitter exhibits a residual error greater than a threshold, the calibration of the faulty vehicle information transmitter is automatically recalculated by subtracting the associated average residual error.

[0046] Other features of remote vehicle condition assessment systems, such as remote vehicle condition assessment system 100, include volumetric calculation methods used in applications such as construction sites and mining, where volumes of earth must be moved by one or more vehicles or machines. Such surface-to-surface volumetric calculations require calculating how much volume has moved within a finite time interval. For example, this technique can be used to answer a user question: "How much volume has moved on this area of my job site in the last 24 hours?" These surface-to-surface volumes are calculated using a Riemann sum over height samples in a bounding polygon region. The sampling and aggregation for a single volumetric calculation can be distributed across multiple servers (e.g., multiple versions of a data server) and thereby calculated in parallel using, for example, a map-reduce algorithm, reducing the overall time to calculate the results. The resulting volumetric amounts can be charted over time to track progress and productivity trends. For example, charting the volume moved within an area by day for a week allows a fleet owner to monitor overall progress and productivity, thereby enabling the owner to make informed decisions to improve overall efficiency and reduce costs.

[0047] Because volume calculations are expensive to compute, the results are cached in some embodiments of the remote vehicle state assessment system. A unique fingerprint (hash) is generated for a particular volume calculation. This hash is generated from a combination of the surface, bounding polygon, and other data. The results are presumed to be deterministic, so for a given surface-to-surface volume request, e.g., {Surface A, Surface B, Polygon}, the associated volume result (e.g., cubic meters of change) will be the same. Therefore, a hash is created from {Surface A, Surface B, Polygon} and used as a lookup in a cache of pre-computed values to avoid recomputation.

[0048] FIG. 7A is a flow diagram illustrating an embodiment of a method 700 for determining a vehicle's idle state. At 702, a vehicle information transmitter associated with a vehicle periodically reads information from an inertial measurement unit (IMU) associated with the vehicle information transmitter (e.g., IMU 204). Next, at 704, a processing system associated with the vehicle information transmitter (e.g., processing system 208) measures vibration amplitude associated with the vehicle. In some embodiments, the vibration amplitude is received by the processing system as output data from one or more accelerometers and gyroscopes associated with the IMU. In particular embodiments, this output data is received by the processing system as vibration data at a rate of 200 Hz. That is, the processing system polls the IMU for data at the 200 Hz rate. At 706, the processing system applies a threshold to the vibration data (e.g., vibration amplitude measurements) to determine whether an engine associated with the vehicle is running and generates a binary variable (engine running or not running) responsive to the thresholding process. At 708, the vehicle information transmitter stores a plurality of location data points associated with the vehicle's location. These location data points are generated by a GPS receiver (e.g., GPS 202) associated with the vehicle information transmitter. At 710, the vehicle information transmitter transmits the plurality of location data points and the binary variables to a database (e.g., database 104) associated with a data server (e.g., data server 102). The method then proceeds to A and continues with the description of FIG. 7B.

[0049] 7B is a flow diagram illustrating a continuing description of method 700. Beginning at A, the method proceeds to 712, where a computing system associated with a data server (e.g., computing system 106) processes a plurality of position data points and binary variables. In some embodiments, the computing system performs real-time kinematic (RTK) GPS processing on the position data points using position data from reference data points. This allows for more accurate vehicle position calculations to be performed. Using these measurements and calculations, the method proceeds to 714, where the computing system correlates these measurements and calculations with vehicle speed determined by RTK-GPS processing and classifies vehicle movement into three categories.

[0050] A binary variable = Driving and vehicle speed > 0 (vehicle moving) indicates that the vehicle is in operation.

[0051] A binary variable = driving and vehicle speed = 0 (vehicle stationary) indicates that the vehicle is idling.

[0052] A binary variable = Not Driven and vehicle speed = 0 (vehicle stationary) indicates that the vehicle engine is off.

[0053] This method is useful for remotely monitoring vehicle status while idling, which can cost the vehicle operator time and money, resulting in unnecessary delays in the progress of work.

[0054] FIG. 8A is a flow diagram illustrating an embodiment of a method 800 for performing server-side RTK positioning. Real-time kinematic (RTK) positioning improves the accuracy of GPS measurements by correcting them with GPS positioning data derived from one or more known reference points. To implement server-side RTK positioning, at 802, a vehicle information transmitter (e.g., vehicle information transmitter 112) associated with a vehicle determines the vehicle's GPS position, for example, using GPS 202. Next, at 804, the vehicle information transmitter transmits data related to the GPS position (i.e., GPS data) to a database (e.g., database 104) associated with a data server (e.g., data server 102). In some embodiments, the data server is located at a different physical location (i.e., a remote location) from the vehicle. At 806, a computing system (e.g., computing system 106) associated with the data server retrieves data related to the GPS position from the database. Next, at 808, the computing system receives reference GPS data associated with one or more reference points whose locations are precisely known. The method then proceeds to A and continues with the description of FIG. 8B.

[0055] FIG. 8B is a flow diagram illustrating a continuing description of method 800. Beginning at A, the method proceeds to 810, where the computing system calculates corrected GPS data associated with the GPS location (i.e., associated with the location of the vehicle information transmitter) based on the reference GPS data and data associated with the GPS location. At 812, the computing system stores the corrected GPS data in a local database, such as database 104. This stored data is viewable by an operator of the system using an appropriate display device (e.g., via user interface 108). At 814, the computing system transmits the corrected GPS data to a display or other display device associated with the vehicle. In some embodiments, GPS measurements are accurate to within approximately 1 cm. Because RTK processing is performed by a computing system associated with the data server, the method is referred to as server-side RTK positioning and can be performed in near real time.

[0056] FIG. 9 is a flow diagram illustrating an embodiment of a method 900 for RTK positioning using a mobile device. Rather than transmitting data related to a GPS location to a remote server as performed in method 800, the vehicle information transmitter can utilize processing power available on the mobile device and, for example, use a Bluetooth communication link to transmit data related to the GPS location to the mobile device for RTK processing. Method 900 describes such operations. At 902, a vehicle information transmitter (vehicle information transmitter 112) associated with a vehicle determines the vehicle's GPS location, for example, using GPS 202. Then, at 904, the vehicle information transmitter transmits data related to the GPS location (i.e., GPS data) to the mobile device. In some embodiments, the mobile device can be a cell phone, tablet, laptop, or any other similar mobile device. In certain embodiments, the mobile device is owned or accessible by or located within the vehicle driver. At 906, the mobile device receives reference GPS data associated with one or more reference points having precisely determined locations. At 908, the mobile device calculates corrected GPS data related to the GPS position based on the reference GPS data and the data related to the GPS position. Finally, at 910, the mobile device displays the corrected GPS data to the vehicle operator in near real time with centimeter-level accuracy. An advantage of performing RTK processing on the mobile device, as opposed to server-side RTK positioning, is that by performing it on the mobile device, any network-related latency associated with server-side RTK positioning can be avoided.

[0057] 10A is a flow diagram illustrating an embodiment of a method 1000 for implementing link loss tolerance using a vehicle information transmitter. In some embodiments, a vehicle information transmitter (e.g., vehicle information transmitter 112) transmits data to a data server (e.g., data server 102) using a public network (e.g., public network 110). This data can be transmitted in bursts or continuously streamed. In either case, there is a risk of data loss due to link loss or link interruption. To address this, link loss tolerance is incorporated into some embodiments of a remote vehicle condition assessment system using a vehicle information transmitter. Method 1000 relates to a series of operations of a vehicle information transmitter with link loss tolerance.

[0058] At 1002, the vehicle information transmitter retrieves GNSS (i.e., GPS) observations, the vehicle information transmitter associated with the vehicle, the GNSS observations associated with the vehicle information transmitter being appropriately calibrated as described herein. In some embodiments, the GNSS observations (i.e., measurements) are generated by GPS 202. At 1004, the vehicle information transmitter stores the GNSS observations in memory, such as memory 212. In some embodiments, the memory is a first-in, first-out (FIFO) queue buffer implemented in flash memory. In particular embodiments, the memory can store several days' worth of GNSS observations. Next, at 1006, the vehicle information transmitter checks to determine the availability of a wireless link. In some embodiments, the wireless link can be a 4G network communication link that allows the vehicle information transmitter to communicate with a data server over a public network. If a wireless link is available at 1008, the method proceeds to 1010, where the vehicle information transmitter transmits all GNSS observations stored from the previous successful transmission, thereby emptying the contents of the FIFO memory. In some embodiments, these observations are transmitted to a computing system that is part of a data server (e.g., computing system 106). The algorithm then proceeds to A and continues with the description of FIG. 10B. However, if a wireless link is not available at 1008, the method returns to 1002, where the next set of GNSS observations is read and stored in the FIFO memory.

[0059] FIG. 10B is a flow diagram illustrating a continuation of method 1000. Starting at A, the method proceeds to 1012, where the vehicle information transmitter checks whether a data receipt confirmation code is available from the computing system. In some embodiments, the data receipt confirmation code is an HTTP 200 OK status code upon successful receipt of data by the computing system. If a data receipt confirmation code is available at 1014 (e.g., if the data receipt confirmation code is successfully received from the computing system), the method proceeds to 1018, where the vehicle information transmitter retrieves the GNSS observation and stores the GNSS observation as new GNSS data. The method then proceeds to B, where the algorithm returns to point B in FIG. 10A. On the other hand, if a data receipt confirmation code is not available at 1014, the method proceeds to 1016, where the vehicle information transmitter retrieves the GNSS observation and appends the GNSS observation to the existing GNSS data. The algorithm then proceeds to B, where the algorithm returns to point B in FIG. 10A.

[0060] 11 is a flow diagram illustrating an embodiment of a method 1100 for implementing link loss tolerance using a computing system (e.g., computing system 106). In some embodiments, method 1100 is a workflow that runs on a computing system in parallel with method 1000. That is, method 1000 is a workflow that runs on an associated vehicle information transmitter, and method 1100 is a corresponding workflow that runs on a computing system referenced in method 1000.

[0061] At 1102, a computing system associated with a data server (e.g., data server 102) checks to determine the availability of a wireless link that allows the computing system to receive GNSS observations from a vehicle information transmitter associated with the vehicle. In some embodiments, the wireless link can be a 4G network communication link that allows the vehicle information transmitter to communicate with the data server over a public network. At 1104, if the wireless link is not available, the computing system returns to 1102 and continues polling the wireless link to determine availability.

[0062] On the other hand, if a wireless link is available at 1104, the method proceeds to 1106, where the computing system retrieves any available GNSS observations from the vehicle information transmitter via the wireless link. At 1108, the computing system processes the GNSS observations, and at 1110, the method checks to determine whether the received data is complete and error-free. If the data is incomplete or erroneous, the algorithm returns to 1102, where the computing system does not send a data receipt confirmation code (e.g., an HTTP200OK code) to the vehicle information transmitter. As shown in method 1000, if the vehicle information transmitter does not receive a data receipt confirmation code, it appends new data, if necessary, and attempts to retransmit the data. On the other hand, if the computing system determines that complete and error-free data has been received at 1110, the method proceeds to 1112, where the computing system sends a data receipt confirmation code (e.g., an HTTP200OK code) to the vehicle information transmitter. Finally, at 1114, based on the processed GNSS observations, the computing system determines one or more parameters related to the vehicle (e.g., the vehicle's position, or whether the vehicle's engine is running or not). The method returns to 1102, where the computing system continues to process GNSS observations received from the vehicle information system until the input queue associated with the data server is empty (eg, due to loss of a radio link).

[0063] In the event of a radio link loss and subsequent re-establishment, the historical GNSS data stored in the FIFO on the vehicle information transmitter is transmitted over the radio link at the maximum speed possible for the radio link, thereby allowing the processed data stream to keep up in real time. A double buffering scheme, which can be implemented using a server input queue on the data server and a FIFO on the vehicle information transmitter, ensures that no data loss occurs, thus implementing a link-loss tolerant data buffering scheme.

[0064] FIG. 12 is a flow diagram illustrating an embodiment of a method 1200 for implementing RTK positioning. Referring to the RTK positioning process described above in method 800, another method that can be used to implement RTK positioning is to enable a vehicle information transmitter to perform on-board RTK-related calculations. A flow diagram illustrating this process is shown in FIG. 12. At 1202, a vehicle information transmitter associated with a vehicle (e.g., vehicle information transmitter 112) receives GNSS data regarding the vehicle's location. In some embodiments, the vehicle information transmitter receives this GNSS data from GPS 202. At 1204, the vehicle information transmitter stores the GNSS data, for example, in memory 212. Then, at 1206, the vehicle information transmitter determines the vehicle's GPS location based on the GNSS data. In some embodiments, the determination of the vehicle's GPS location is performed on the GPS itself. In other embodiments, the raw GNSS data is stored in memory for post-processing, for example, by processing system 208.

[0065] At 1208, the vehicle information transmitter receives reference GPS data associated with one or more reference points. In some embodiments, the reference GPS data can be received from a database 104 associated with the data server 102. In other embodiments, the reference GPS data can be received from one or more GPS base stations over a network, such as the Internet. In some embodiments, the reference GPS data is associated with one or more reference points whose coordinates are precisely known. At 1210, the vehicle information transmitter calculates corrected GPS data associated with the GPS position based on the GNSS data and the reference GPS data. This step may involve performing RTK processing on the vehicle information transmitter itself and may be performed on the processing system 208. Finally, at 1212, the vehicle information transmitter transmits the corrected GPS data to a display device associated with the vehicle. In some embodiments, the display device is a video display terminal, such as an LCD display, within the vehicle. In other embodiments, the display device is a display device associated with a mobile device or other computing device owned by the driver of the vehicle. That is, the vehicle information transmitter transmits the corrected GPS data to a cell phone, laptop, tablet, or similar device owned by the vehicle driver, for example, via a Bluetooth connection or other wireless or wired connection.

[0066] FIG. 13 is a flow diagram illustrating an embodiment of a method 1300 for detecting a cause of a negative charge. Some embodiments of a vehicle information transmitter are powered by one or more solar cells or panels. Method 1300 is configured to detect, for example, abnormal operation associated with a solar panel that results in a negative charge or a net negative charge. At 1302, a solar panel voltage and a solar panel current associated with the vehicle information transmitter are monitored. In some embodiments, the solar panel voltage and current are measured every 30 seconds. At 1304, the vehicle information transmitter transmits data associated with the solar panel voltage and the solar panel current to a database, such as database 104. At 1306, time series associated with the solar panel voltage and the solar panel current are processed to assess net solar charge and net energy consumption. In some embodiments, the time series are generated by (voltage x current) power generation products, and a computing system (e.g., computing system 106) integrates (i.e., processes) the time series of the power generation products to assess net solar charge and net energy consumption.

[0067] At 1308, the method checks to determine whether the net charge calculated using the time series of power generation products is negative for a particular period (e.g., one week). If the net charge generated is not negative, the method returns to 1302. On the other hand, if the net charge is negative at 1308, the method proceeds to 1310 and alerts the user. In some embodiments, the user is alerted using a messaging system such as SMS, mobile push notification, email, or other transactional communication platform. In some embodiments, the processing functions associated with method 1300 are performed by computing system 106.

[0068] The time series is analyzed to determine the cause of the negative charge at 1312. In some embodiments, the negative charge can be caused by any combination of the following:

[0069] If the peak charge current is low and decreases over time, one or more solar panels associated with the vehicle information transmitter are probably obscured by soil and the user is advised to clean the solar panels.

[0070] If the net charge hours per day are low, it may be that the vehicle information transmitter is being used in an area with insufficient sunlight or the photovoltaic cell / solar panel is obscured for part of the day. This data can be cross-referenced with predicted solar irradiance and weather observations from a third-party source (API) given the geographic location of the vehicle information transmitter derived from GPS.

[0071] If the energy input to a battery associated with a vehicle information transmitter is significantly higher than the energy used, the battery (e.g., battery 216) is not operating efficiently. This is likely due to low ambient temperatures and can be confirmed by reviewing time series temperature data from a thermometer mounted on the device. In some embodiments, freezing temperatures adversely affect battery performance.

[0072] FIG. 14 is a block diagram illustrating an embodiment of an RTK positioning system 1400. The advantage of allowing the vehicle information transmitter to perform on-board RTK processing is that it reduces latency and provides resilience to communication link losses. For example, FIG. 8 illustrates a server-side RTK processing algorithm in which GNSS data is transmitted to a computing system over a public network. The scheme illustrated in FIG. 8 poses two challenges. The first challenge is the latency associated with transmitting and receiving data over the public network. The second challenge is the possibility that the communication link associated with the public network may become unavailable. This potential second challenge poses the following additional challenges:

[0073] 1. RTK data is not available, and

[0074] 2. GNSS data overflow on the vehicle information transmitter.

[0075] Processing RTK data on the vehicle information transmitter itself reduces latency and the likelihood of results being compromised due to public network unavailability. Such an algorithm is presented in FIG. 12. A block diagram illustrating the implementation of the RTK algorithm implemented on multiple vehicle information transmitters is shown in FIG. 14 as RTK positioning system 1400. In some embodiments, RTK positioning system 1400 includes multiple vehicle information transmitters, namely, vehicle information transmitter 1412, vehicle information transmitter 1414, and vehicle information transmitter 1416. Each of vehicle information transmitters 1412, 1414, and 1416 is communicatively coupled to multiple RTK base stations, namely, base station 1402, base station 1404, and base station 1406, via a Wi-Fi gateway 1410 and a public network 1408 (e.g., the Internet). Each of base stations 1402, 1404, and 1406 stores one or more positioning reference points (e.g., reference GPS data) whose coordinates are precisely known. This data is available to each of the vehicle information transmitters 1412-1416 and enables RTK processing on each of the vehicle information transmitters 1412-1416 in substantially real time.

[0076] In some embodiments, each of vehicle information transmitters 1412-1416 is communicatively coupled to Wi-Fi gateway 1410 via a Wi-Fi communication link.

[0077] 15 is a block diagram illustrating an embodiment of a processing system 208 that can be used to implement certain functionality of the vehicle information transmitter. In some embodiments, the processing system 208 includes a communications manager 1502 configured to manage associated communications and communications protocols with external peripherals as well as communications with other elements within the processing system 208. For example, the communications manager 1502 can be responsible for creating and maintaining communications interfaces between the processing system 208 and other elements of the vehicle information transmitter 200, such as the memory 212.

[0078] In some embodiments, the processing system 208 includes a memory 1504 configured to store data related to the operation of the vehicle information transmitter 200. In particular embodiments, the memory 1504 includes both long-term and short-term memory. The memory 1504 can be comprised of any combination of a hard disk drive, flash memory, random access memory, read-only memory, solid-state drive, and other memory elements.

[0079] Some embodiments of the processing system 208 include a GPS interface 1506 that allows the processing system to read GPS data from the GPS 202 or other GPS receiver. This GPS data can be used for on-board RTK processing associated with the vehicle information transmitter 200. Some embodiments of the processing system 208 include an IMU interface 1508 that allows the processing system 208 to interface with the IMU 204. The IMU interface 1508 allows the processing system 208 to read linear and angular acceleration measurements captured by the IMU 204.

[0080] In some embodiments, the processing system 208 includes a processor 1510 configured to perform functions including generalized processing functions, arithmetic functions, etc. In embodiments, the processor 1510 may be responsible for performing on-board RTK calculation operations such as those described in method 1200.

[0081] Some embodiments of the processing system 208 include a user interface 1512 that allows a user to interact with the processing system 208 and different elements of the vehicle information transmitter 200. For example, a user can connect to the vehicle information transmitter remotely or via a local wired connection (e.g., USB or Ethernet). The user can then access different functions of the vehicle information transmitter, perform diagnostic functions, etc.

[0082] Some embodiments of the processing system 208 include a power monitor 1514 configured to monitor power generated by the solar panel 214 or the battery 216. In some embodiments, the power monitor 1514 can monitor different elements of the vehicle information transmitter 200 and one or more functions of the power distribution system 218. The power monitor 1514 can also receive data related to the implementation of the method 1300. Some embodiments of the processing system 208 include a data bus 1516 that communicatively couples and transfers data and other signals between different elements of the processing system 208.

[0083] 16 is a line diagram illustrating an isometric view 1600 of a vehicle information transmitter. The isometric view 1600 shows a vehicle information transmitter 1602. Some embodiments of the vehicle information transmitter 1602 are called DirtMates, abbreviated as "DM." In some embodiments, the vehicle information transmitter 1602 includes a first solar panel 1604 and a second solar panel 1606, each configured to generate power from sunlight. This power is used to power the vehicle information transmitter 1602 and associated components or to charge a rechargeable battery included in some embodiments of the vehicle information transmitter 1602.

[0084] In some embodiments, the vehicle information transmitter 1602 includes an antenna 1608 that enables the vehicle information transmitter 1602 to perform wireless communication using a wireless communication modality such as Wi-Fi, mobile internet (e.g., 4G or 5G), Bluetooth, etc. The antenna 1608 enables the vehicle information transmitter 1602 to communicate with, for example, the data server 102 over the public network 110. A power switch 1610 enables the vehicle information transmitter 1602 to be powered on or off. A power LED 1612 is lit to indicate that the vehicle information transmitter 1602 is powered on, and is switched off when the vehicle information transmitter 1602 is powered off. A network LED 1614 indicates network access by the vehicle information transmitter 1602.

[0085] Advantages provided by the deployment of one or more vehicle information transmitters include:

[0086] 1. 100% continuous tracking (visualization and analysis) of productivity and job site progress in near real-time and with near survey-grade accuracy.

[0087] a) Monitor 100% of daily operations at all times with enough accuracy to make good planning decisions;

[0088] b) automatically monitor the activities of all subcontractors, helping to avoid disputes involving all parties;

[0089] c) Localize any machine / vehicle / asset at any time;

[0090] d) Evaluate and optimize the use of resources to achieve goals;

[0091] e) Evaluate and ensure the performance quality of each machine / operator;

[0092] f) Ensuring safety on haul roads and optimizing fuel costs; This makes it possible.

[0093] 2. Provide managers with real-time feedback, enabling them to perform their jobs more efficiently.

[0094] 3. Avoid unnecessary costs due to rework by giving managers near real-time alerts.

[0095] a) Avoid working overtime.

[0096] b) Avoid disputes with customers and subcontractors regarding what has been transferred when:

[0097] DM+Observer (+Mobile App) Implementation

[0098] DM continuously measures the speed and 3D position of every machine on the jobsite with near-survey-grade accuracy (<15 cm) and high frequency (1-5 Hz) using solar-powered on-machine positioning sensors. It then adds the measurement data, along with installation data (detailed sensor placement on the machines), to a remote database whenever a wireless connection is available. The system's associated application software (called Propeller software or the Propeller mobile app) continuously processes input from the fleet of machines, updates a surface model of the actual jobsite, and provides near-real-time visibility into project status and progress to any authorized personnel within the company. Via the wireless connection, the Propeller mobile app reads and displays local design surface data, live feedback, and alerts on handheld or machine-mounted displays, enabling workers to execute every job according to the technical design.

[0099] DM key differentiators

[0100] Full fleet coverage: DM is designed to be installed on 100% of the vehicle fleet. Unlike current jobsite vehicle GPS, which only monitor specific vehicles, DM operates on all machines that enter the jobsite.

[0101] Easy to install and calibrate: DM is very easy to install on mixed-brand and mixed-owner fleets and requires no human intervention to operate. The system alerts the manager or machine operator whenever human intervention is required. Calibration (re-adjustment) occurs automatically and frequently.

[0102] Seamless Data Transfer: DM extracts DM values from seamless data transfer, processing and integration into a jobsite surface tracking platform that allows users to visualize, measure and compare current, historical and designed surfaces.

[0103] Survey-Grade Accuracy: DM uses similar technology to vehicle positioning systems that are suited to theft detection, driver compliance, and safety monitoring. However, with its high positioning accuracy and frequent updates, DM can also provide valuable job site survey data.

[0104] Very low cost: DM is relatively inexpensive compared to other survey-grade worksite surface measurement tools, including drones, GPS / laser-based site positioning systems, and machine controls. DM is very inexpensive compared to machine controls because continuous surface measurement:

[0105] Requires only one-way, potentially intermittent communication to add surface measurement data,

[0106] Requires minimal integration with machines,

[0107] This is because it can be integrated into current machine control systems and sacrifices the (many) two-way update continuity and real-timeness that are strictly necessary for the automatic operation of machine blades on human-operated machines.

[0108] Components operating within the complete value chain:

[0109] Solar-powered high frequency position measurement with centimeter-level accuracy.

[0110] Automatic data offloading to an online database over intermittent wireless connections.

[0111] Heavy-duty, secure mounting harness for connecting to machinery.

[0112] How to quickly attach and detach position sensors to machines and deploy them as survey-grade surface measurement tools.

[0113] · How to quickly and frequently (re)calibrate position sensors as surveying-grade surface measurement tools.

[0114] · How to ensure 100% fleet coverage.

[0115] A system that continuously reconstructs the worksite surface using mobile, distributed position sensors based on an assessment of the quality of each data source and weighting its contribution to the surface model.

[0116] A system that licenses / permits the use of data from machines owned by different owners, rental machines, etc. at a given work site.

[0117] A system for (continuously) visualizing, querying, and comparing past, present, and designed surfaces.

[0118] Another way to express the benefit / novelty over off-the-shelf fleet / asset management is that it is available to customers who are reluctant to invest in machine control for every machine. In some embodiments, the term "machine control" includes machine control using three-dimensional guidance (also called three-dimensional machine control), where the machine reads a design surface profile and the machine operator can see the location of the design surface relative to the tool (such as a bucket or blade) used to cut the design surface. The machine operator then steers the tool to automatically match the predetermined surface design. In some embodiments, the machine operator controls the movement of the machine, not the tool, and the tool moves autonomously based on the design surface profile and the predetermined surface design via an intelligent control system associated with the machine. The following are features related to machine control:

[0119] A system for continuous monitoring of job site activity and work progress of a mixed make and owner fleet of earthmoving machinery and other vehicles.

[0120] A fully automated (no-touch) system for continuously surveying work sites.

[0121] -Two-axle road grade measurement tool for haul road vehicles.

[0122] Although the present disclosure has been described with reference to particular examples and embodiments, other embodiments apparent to those skilled in the art given the benefit of this disclosure, including embodiments that do not provide all of the benefits and features set forth herein, are also within the scope of the present disclosure. It is understood that other embodiments can be utilized without departing from the scope of the present disclosure.

Claims

1. A vehicle information transmitter is adjusted based on a first reference point having known three-dimensional coordinates and a second reference point having known three-dimensional coordinates, said adjustment being performed taking into account a spatial mounting position of said vehicle information transmitter on said vehicle relative to a terrain on which said vehicle is located, said first reference point and said second reference point being located on said terrain, The adjustment further comprises: the vehicle traverses a path relative to a line connecting the first reference point and the second reference point; the vehicle information transmitter stores a plurality of location data points associated with the route; the vehicle information transmitter transmitting the plurality of location data points to a data server; the data server interpolates the plurality of position data points to calculate a height of the vehicle information transmitter relative to the first reference point and the second reference point; the height of the vehicle information transmitter relative to the first reference point and the second reference point is used by the data server to calculate the height of the vehicle information transmitter above the terrain on which the vehicle is located; This includes: determining a state of the vehicle using the adjusted vehicle information transmitter; A method comprising: The determination is collecting data related to the vehicle, the data being collected by the vehicle information transmitter; The vehicle information transmitter records the data, The vehicle information transmitter transmits the data to the data server; the data server processes the data; the data server extracts vehicle information from the data in response to the processing, the vehicle information including terrain elevation; The data server determines the state of the vehicle based on the vehicle information; the data server generates a temporal history associated with the state; the data server generating a three-dimensional map of the terrain based on the temporal history; A method comprising:

2. Furthermore, the current 3D map is compared with a previously generated 3D map; determining a progress rate of the terrain modification operation associated with the terrain based on the comparison; 2. The method of claim 1, comprising:

3. 3. The method of claim 2, further comprising determining productivity associated with the vehicle, wherein the productivity is determined based on the progress rate.

4. further measuring engine vibrations associated with the vehicle; processing measurements of vibration of said engine; determining whether the vehicle is moving, idling, or has its engine stopped based on the processing; 2. The method of claim 1, comprising:

5. 5. The method of claim 4, wherein the engine vibrations are measured by any combination of accelerometers and gyroscopes located on the vehicle.

6. 5. The method of claim 4, further comprising generating a binary variable, the binary variable assuming a non-zero value when an engine associated with the vehicle is running, and the binary variable assuming a zero value when the engine is stopped.

7. 10. The method of claim 1, further comprising: said data server generating said three-dimensional map based on data received from a plurality of vehicles.

8. 2. The method of claim 1, wherein the vehicle state includes any combination of vehicle position, vehicle speed, vehicle acceleration, and terrain elevation.

9. 10. The method of claim 1, further comprising performing real-time kinematic (RTK) positioning to improve position measurements relative to the vehicle.

10. 1. A device for determining a state of a vehicle, the device comprising: a vehicle information transmitter physically connected to the vehicle; a data server communicably connected to the vehicle information transmitter; Including, the vehicle information transmitter is adjusted based on a first reference point having known three-dimensional coordinates and a second reference point having known three-dimensional coordinates; The adjustment is performed taking into account a spatial mounting position of the vehicle information transmitter on the vehicle relative to a terrain in which the vehicle is located; The adjustment further comprises: the vehicle traverses a path relative to a line connecting the first reference point and the second reference point; the vehicle information transmitter stores a plurality of location data points associated with the route; the vehicle information transmitter transmitting the plurality of location data points to a data server; the data server interpolates the plurality of position data points to calculate a height of the vehicle information transmitter relative to the first reference point and the second reference point; the height of the vehicle information transmitter relative to the first reference point and the second reference point is used by the data server to calculate the height of the vehicle information transmitter above the terrain on which the vehicle is located; This includes: the first reference point and the second reference point are located on the terrain; the adjusted vehicle information transmitter collects data related to the vehicle; The adjusted vehicle information transmitter records the data; The adjusted vehicle information transmitter transmits the data to the data server; The data server, storing the data; extracting vehicle information from the data, the vehicle information including terrain elevation; determining a state of the vehicle based on the vehicle information; generating a time history associated with said state; generating a three-dimensional map of the terrain based on the time history; An apparatus characterized by being configured as follows.

11. 11. The device of claim 10, wherein the vehicle information transmitter is identified by a unique device ID.

12. The apparatus of claim 10, wherein the vehicle information transmitter includes a GPS and an IMU.

13. further comprising any combination of an accelerometer and a gyroscope configured to measure vibrations of an engine associated with the vehicle; The data server, receiving measurements of vibrations of the engine; processing measurements of vibration of said engine; 11. The apparatus of claim 10, further comprising determining whether the vehicle is moving, idling, or has its engine stopped.

14. 14. The apparatus of claim 13, wherein the data server generates a binary variable, the binary variable assuming a non-zero value when an engine associated with the vehicle is running, and the binary variable assuming a zero value when the engine is stopped.

15. 11. The apparatus of claim 10, wherein the vehicle state includes any combination of vehicle position, vehicle speed, vehicle acceleration, and terrain altitude.

16. The apparatus of claim 10, wherein the data server generates the three-dimensional map based on data received from a plurality of vehicles.

17. 11. The apparatus of claim 10, wherein the data server is configured to perform real-time kinematic (RTK) positioning to improve position determination relative to the vehicle.

18. The data server further Comparing the current 3D map with a previously generated 3D map; determining a progress rate of mining operations associated with said terrain; 11. The device according to claim 10, configured to:

19. 20. The apparatus of claim 18, wherein the data server determines productivity associated with the vehicle, the productivity being determined based on the progress rate.

20. 3. The method of claim 2, wherein the terrain altering operation is one of a mining operation, a quarrying operation, and an earthmoving operation.

Images