Patent Description:
Off-road vehicles, including industrial vehicles such as agricultural vehicles (e.g., tractors, harvesters, combines, etc.), construction vehicles (e.g., loaders, excavators, bulldozers, etc.), and forestry vehicles (e.g., feller-bunchers, tree chippers, knuckleboom loaders, etc.), military vehicles (e.g., combat engineering vehicles (CEVs), etc.), snowmobiles, and all-terrain vehicles (ATVs), are used on soft, slippery and/or irregular grounds (e.g., soil, mud, sand, ice, snow, etc.) for work and/or other purposes. To enhance their traction and floatation on such grounds, certain off-road vehicles are equipped with track systems. In some cases, off-road vehicles may also be operable on paved roads.

For example, agricultural vehicles can travel in agricultural fields to perform agricultural work and possibly on paved roads (e.g., to travel between agricultural fields). Numerous factors affect performance of the agricultural vehicles and efficiency of agricultural work they do, including their components (e.g., track systems) and their environments (e.g., grounds on which they operate). While some of these factors may be managed by users (e.g., operators) of the agricultural vehicles, this may lead to suboptimal agricultural work, greater wear or other deterioration of components of the agricultural vehicles, and/or other issues in some cases.

Similar considerations may arise in relation to other off-road vehicles (e.g., construction vehicles, snowmobiles, ATVs, etc.) in some cases.

For these and other reasons, there is a need to improve monitoring tracks and track systems of off-road vehicles.

An example of wear measurement system using a computer model can be found in <CIT>.

In accordance with various aspects of this disclosure, a vehicle (e.g., an agricultural vehicle or other off-road vehicle) comprising a track system can be monitored to obtain information regarding the vehicle, including information regarding the track system, such as an indication of a physical state (e.g., wear, damage and/or other deterioration) of a track and/or other component of the track system based on at least one image of the track and/or other component of the track system, respectively, which can be used for various purposes, such as, for example, to: convey the information to a user (e.g., an operator of the vehicle); control the vehicle (e.g., a speed of the vehicle, operation of a work implement, etc.); transmit the information to a remote party (e.g., a provider such as a manufacturer or distributor of the track system, the track and/or another component thereof, and/or of the vehicle; a service provider for servicing (e.g., maintenance or repair of) the track system, the track and/or another component thereof, etc.).

The presently claimed invention relates to a system for monitoring a track for traction of a vehicle according to claim <NUM>.

In accordance with another aspect not forming part of the claimed subject matter, a method of monitoring a track for traction of a vehicle may be provided. The method comprises receiving data regarding at least one image of the track. The method also comprises processing the data regarding the at least one image of the track to obtain an indication of a physical state of the track. The method also comprises generating a signal based on the indication of the physical state of the track.

In accordance with yet another aspect not forming part of the claimed subject matter, a system for monitoring a component of a track system for traction of a vehicle may be provided. The system comprises an interface configured to receive data regarding at least one image of the component of the track system. The system also comprises a processor configured to process the data regarding the at least one image of the component of the track system to obtain an indication of a physical state of the component of the track system. The processor is also configured to generate a signal based on the indication of the physical state of the component of the track system.

In accordance with yet another aspect not forming part of the claimed subject matter, a method of monitoring a component of a track system for traction of a vehicle may be provided. The method comprises receiving data regarding at least one image of the component of the track system. The method also comprises processing the data regarding the at least one image of the component of the track system to obtain an indication of a physical state of the component of the track system. The method also comprises generating a signal based on the indication of the physical state of the component of the track system.

In accordance with yet another aspect not forming part of the claimed subject matter, a track system monitoring system may be provided. The system comprises an image data capture device configured to capture image data relating to a track system component. The system also comprises an image processing device, in data communication with the image capture device. The image processing device is configured to receive captured image data from the image data capture device and process the captured image data to determine at least one physical characteristic of the track system component.

In accordance with yet another aspect not forming part of the claimed subject matter, a track system monitoring system may be provided. The system comprises a 3D scanning device configured to generate a 3D scan relating to a track system component. The system also comprises a processing device, in data communication with the 3D scanning device. The processing device is configured to receive the 3D scan from the 3D scanning device and process the 3D scan to determine at least one physical characteristic of the track system component.

In accordance with yet another aspect not forming part of the claimed subject matter, a track system monitoring system may be provided. The system comprises an image data capture device configured to capture image data relating to a track system component. The system also comprises an image processing device in data communication with the image capture device. The image processing device is configured to receive captured image data from the image data capture device and generate a 3D model of at least a portion of the track system component based on the image data. The image processing device is also configured to compare the 3D model to at least one known 3D model of a track system component to determine at least one aspect of the physical state of the track system component.

A detailed description of embodiments is provided below, by way of example only, with reference to accompanying drawings, in which:.

<FIG> shows an example of a vehicle <NUM> comprising example track systems <NUM><NUM>-<NUM><NUM>. In this embodiment, the vehicle <NUM> is a heavy-duty work vehicle for performing agricultural, construction or other industrial work, or military work. More particularly, in this embodiment, the vehicle <NUM> is an agricultural vehicle for performing agricultural work. Specifically, in this example, the agricultural vehicle <NUM> is a tractor. In other examples, the agricultural vehicle <NUM> may be a harvester, a planter, or any other type of agricultural vehicle.

In this embodiment, the vehicle <NUM> comprises a frame <NUM>, a powertrain <NUM>, a steering mechanism <NUM>, a suspension <NUM>, and an operator cabin <NUM> that enable a user to move the vehicle <NUM> on the ground, including on an agricultural field and possibly on a paved road (e.g., between agricultural fields), using the track systems <NUM><NUM>-<NUM><NUM> and perform work using a work implement <NUM>.

As further discussed later, in this embodiment, the agricultural vehicle <NUM>, including the track systems <NUM><NUM>-<NUM><NUM>, can be monitored (e.g., while the agricultural vehicle <NUM> is parked, inspected or otherwise at rest and/or during operation of the agricultural vehicle <NUM>) to obtain information regarding the agricultural vehicle <NUM>, including information regarding the track systems <NUM><NUM>-<NUM><NUM>, such as indications of physical states of tracks and/or other components of the track systems <NUM><NUM>-<NUM><NUM> (e.g., information indicative of wear or other degradation thereof) that is derivable from one or more images of the tracks and/or other components of the track systems <NUM><NUM>-<NUM><NUM>, which can be used for various purposes, such as, for example, to: convey the information to a user (e.g., the operator); control the agricultural vehicle <NUM> (e.g., a speed of the agricultural vehicle <NUM>, operation of the work implement <NUM>, etc.); transmit the information to a remote party (e.g., a provider such as a manufacturer or distributor of the track systems <NUM><NUM>-<NUM><NUM> or their tracks or other components and/or of the agricultural vehicle <NUM>; a service provider for servicing (e.g., maintenance or repair of) the track system, the track and/or another component thereof, etc.); etc. This may be useful, for example, to gain knowledge about the agricultural vehicle <NUM>, the track systems <NUM><NUM>-<NUM><NUM>, and/or their environment to enhance efficiency of agricultural work performed by the agricultural vehicle <NUM> and to help prevent excessive wear or other deterioration of the track systems <NUM><NUM>-<NUM><NUM>, to schedule maintenance or replacement of the track system <NUM><NUM>-<NUM><NUM> or individual components thereof, to effectively manage the wear of the track system <NUM><NUM>-<NUM><NUM> or individual components thereof, for the agricultural vehicle <NUM> or a fleet of such agricultural vehicles, to achieve any of various other outcomes herein described, and/or for various other reasons.

The powertrain <NUM> is configured to generate power for the agricultural vehicle <NUM>, including motive power for the track systems <NUM><NUM>-<NUM><NUM> to propel the vehicle <NUM> on the ground. To that end, the powertrain <NUM> comprises a power source <NUM> (e.g., a primer mover) that includes one or more motors. For example, in this embodiment, the power source <NUM> comprises an internal combustion engine. In other embodiments, the power source <NUM> may comprise another type of motor (e.g., an electric motor) or a combination of different types of motor (e.g., an internal combustion engine and an electric motor). The powertrain <NUM> can transmit power from the power source <NUM> to one or more of the track systems <NUM><NUM>-<NUM><NUM> in any suitable way (e.g., via a transmission, a differential, a direct connection, and/or any other suitable mechanism). In some embodiments, at least part of the powertrain <NUM> (e.g., a motor and/or a transmission) may be part of one or more of the track systems <NUM><NUM>-<NUM><NUM>.

The operator cabin <NUM> is where the user sits and controls the vehicle <NUM>. More particularly, the operator cabin <NUM> comprises a user interface <NUM> allowing the user to steer the vehicle <NUM> on the ground, operate the work implement <NUM>, and control other aspects of the vehicle <NUM>. In this embodiment, the user interface <NUM> comprises input devices, such as an accelerator, a brake control, and a steering device (e.g., a steering wheel, a stick, etc.) that are operated by the user to control motion of the vehicle <NUM> on the ground. The user interface <NUM> also comprises output devices such as an instrument panel (e.g., a dashboard) which provides indicators (e.g., a speedometer indicator, a tachometer indicator, etc.) to convey information to the user.

The work implement <NUM> is used to perform agricultural work. For example, in some embodiments, the work implement <NUM> may include a combine head, a cutter, a scraper pan, a tool bar, a planter, or any other type of agricultural work implement.

The track systems <NUM><NUM>-<NUM><NUM> engage the ground to provide traction to the vehicle <NUM>. More particularly, in this embodiment, front ones of the track systems <NUM><NUM>-<NUM><NUM> provide front traction to the vehicle <NUM>, while rear ones of the track systems <NUM><NUM>-<NUM><NUM> provide rear traction to the vehicle <NUM>.

In this embodiment, each of the front ones of the track systems <NUM><NUM>-<NUM><NUM> is pivotable relative to the frame <NUM> of the vehicle <NUM> about a steering axis <NUM> by the steering mechanism <NUM> (e.g., in response to input of the user at the steering device of the user interface <NUM>) to change the orientation of that track system relative to the frame <NUM> in order to steer the vehicle <NUM> on the ground. The orientation of each of the front ones of the track systems <NUM><NUM>-<NUM><NUM> relative to a longitudinal axis <NUM> of the vehicle <NUM>, which defines a steering angle θ of that track system, is thus changeable. In this example, the steering mechanism <NUM> includes a steering unit <NUM> (e.g., comprising a steering knuckle) on each side of the vehicle <NUM> dedicated to each of the front ones of the track systems <NUM><NUM>-<NUM><NUM> and defining the steering axis <NUM> for that track system. Each of the front ones of the track systems <NUM><NUM>-<NUM><NUM> is therefore steerable.

With additional reference to <FIG> and <FIG>, in this embodiment, each track system <NUM>i comprises a track <NUM> and a track-engaging assembly <NUM> that is configured to drive and guide the track <NUM> around the track-engaging assembly <NUM>. In this example, the track-engaging assembly <NUM> comprises a frame <NUM> and a plurality of track-contacting wheels which includes a drive wheel <NUM> and a plurality of idler wheels <NUM><NUM>-<NUM><NUM>, which includes leading idler wheels <NUM><NUM>, <NUM><NUM>, trailing idler wheels <NUM><NUM>, <NUM><NUM>, and roller wheels <NUM><NUM>-<NUM><NUM> between the leading idler wheels <NUM><NUM>, <NUM><NUM> and the trailing idler wheels <NUM><NUM>, <NUM><NUM>. The track system <NUM>i has a front longitudinal end <NUM> and a rear longitudinal end <NUM> that define a length of the track system <NUM>i. A width of the track system <NUM>i is defined by a width WT of the track <NUM>. The track system <NUM>i has a longitudinal direction, a widthwise direction, and a heightwise direction.

The track <NUM> engages the ground to provide traction to the vehicle <NUM>. A length of the track <NUM> allows the track <NUM> to be mounted around the track-engaging assembly <NUM>. In view of its closed configuration without ends that allows it to be disposed and moved around the track-engaging assembly <NUM>, the track <NUM> can be referred to as an "endless" track. Referring additionally to <FIG>, the track <NUM> comprises an inner side <NUM> facing the wheels <NUM>, <NUM><NUM>-<NUM><NUM> and defining an inner area of the track <NUM> in which these wheels are located. The track <NUM> also comprises a ground-engaging outer side <NUM> opposite the inner side <NUM> for engaging the ground on which the vehicle <NUM> travels. Lateral edges <NUM><NUM>, <NUM><NUM> of the track <NUM> define its width WT. The track <NUM> has a top run <NUM> which extends between the longitudinal ends <NUM>, <NUM> of the track system <NUM>i and over the track-engaging assembly <NUM>, and a bottom run <NUM> which extends between the longitudinal ends <NUM>, <NUM> of the track system <NUM>i and under the track-engaging assembly <NUM>. The track <NUM> has a longitudinal direction, a widthwise direction, and a thicknesswise direction.

The track <NUM> is elastomeric, i.e., comprises elastomeric material, allowing it to flex around the wheels <NUM>, <NUM><NUM>-<NUM><NUM>. The elastomeric material of the track <NUM> can include any polymeric material with suitable elasticity. In this embodiment, the elastomeric material includes rubber. Various rubber compounds may be used and, in some cases, different rubber compounds may be present in different areas of the track <NUM>. In other embodiments, the elastomeric material of the track <NUM> may include another elastomer in addition to or instead of rubber (e.g., polyurethane elastomer). The track <NUM> can be molded into shape in a mold by a molding process during which its elastomeric material is cured.

More particularly, the track <NUM> comprises an elastomeric belt-shaped body <NUM> underlying its inner side <NUM> and its ground-engaging outer side <NUM>. In view of its underlying nature, the body <NUM> can be referred to as a "carcass". The carcass <NUM> comprises elastomeric material <NUM> which allows the track <NUM> to flex around the wheels <NUM>, <NUM><NUM>-<NUM><NUM>.

In this embodiment, the carcass <NUM> comprises a plurality of reinforcements embedded in its elastomeric material <NUM>. One example of a reinforcement is a layer of reinforcing cables <NUM><NUM>-<NUM>C that are adjacent to one another and that extend in the longitudinal direction of the track <NUM> to enhance strength in tension of the track <NUM> along its longitudinal direction. In some cases, a reinforcing cable may be a cord or wire rope including a plurality of strands or wires. In other cases, a reinforcing cable may be another type of cable and may be made of any material suitably flexible longitudinally (e.g., fibers or wires of metal, plastic or composite material). Another example of a reinforcement is a layer of reinforcing fabric <NUM>. Reinforcing fabric comprises pliable material made usually by weaving, felting, or knitting natural or synthetic fibers. For instance, a layer of reinforcing fabric may comprise a ply of reinforcing woven fibers (e.g., nylon fibers or other synthetic fibers). Various other types of reinforcements may be provided in the carcass <NUM> in other embodiments.

The carcass <NUM> may be molded into shape in the track's molding process during which its elastomeric material <NUM> is cured. For example, in this embodiment, layers of elastomeric material providing the elastomeric material <NUM> of the carcass <NUM>, the reinforcing cables <NUM><NUM>-<NUM>C and the layer of reinforcing fabric <NUM> may be placed into the mold and consolidated during molding.

In this embodiment, the inner side <NUM> of the track <NUM> comprises an inner surface <NUM> of the carcass <NUM> and a plurality of wheel-contacting projections <NUM><NUM>-<NUM>N that project from the inner surface <NUM> to contact at least some of the wheels <NUM>, <NUM><NUM>-<NUM><NUM> and that are used to do at least one of driving (i.e., imparting motion to) the track <NUM> and guiding the track <NUM>. In that sense, the wheel-contacting projections <NUM><NUM>-<NUM>N can be referred to as "drive/guide projections", meaning that each drive/guide projection is used to do at least one of driving the track <NUM> and guiding the track <NUM>. Also, such drive/guide projections are sometimes referred to as "drive/guide lugs" and will thus be referred to as such herein. More particularly, in this embodiment, the drive/guide lugs <NUM><NUM>-<NUM>N interact with the drive wheel <NUM> in order to cause the track <NUM> to be driven, and also interact with the idler wheels <NUM><NUM>-<NUM><NUM> in order to guide the track <NUM> as it is driven by the drive wheel <NUM>. The drive/guide lugs <NUM><NUM>-<NUM>N are thus used to both drive the track <NUM> and guide the track <NUM> in this embodiment.

The drive/guide lugs <NUM><NUM>-<NUM>N are spaced apart along the longitudinal direction of the track <NUM>. In this case, the drive/guide lugs <NUM><NUM>-<NUM>N are arranged in a plurality of rows that are spaced apart along the widthwise direction of the track <NUM>. The drive/guide lugs <NUM><NUM>-<NUM>N may be arranged in other manners in other embodiments (e.g., a single row or more than two rows). Each of the drive/guide lugs <NUM><NUM>-<NUM>N is an elastomeric drive/guide lug in that it comprises elastomeric material <NUM>. The drive/guide lugs <NUM><NUM>-<NUM>N can be provided and connected to the carcass <NUM> in the mold during the track's molding process.

The ground-engaging outer side <NUM> of the track <NUM> comprises a ground-engaging outer surface <NUM> of the carcass <NUM> and a plurality of traction projections <NUM><NUM>-<NUM>M that project from the outer surface <NUM> and engage and may penetrate into the ground to enhance traction. The traction projections <NUM><NUM>-<NUM>M, which can sometimes be referred to as "traction lugs", are spaced apart in the longitudinal direction of the track system <NUM>i. The ground-engaging outer side <NUM> comprises a plurality of traction-projection-free areas <NUM><NUM>-<NUM>F (i.e., areas free of traction projections) between successive ones of the traction projections <NUM><NUM>-<NUM>M. In this example, each of the traction projections <NUM><NUM>-<NUM>M is an elastomeric traction projection in that it comprises elastomeric material <NUM>. The traction projections <NUM><NUM>-<NUM>M can be provided and connected to the carcass <NUM> in the mold during the track's molding process.

The track <NUM> may be constructed in various other ways in other embodiments. For example, in some embodiments, the track <NUM> may comprise a plurality of parts (e.g., rubber sections) interconnected to one another in a closed configuration, the track <NUM> may have recesses or holes that interact with the drive wheel <NUM> in order to cause the track <NUM> to be driven (e.g., in which case the drive/guide lugs <NUM><NUM>-<NUM>N may be used only to guide the track <NUM> without being used to drive the track <NUM>), and/or the ground-engaging outer side <NUM> of the track <NUM> may comprise various patterns of traction projections.

The drive wheel <NUM> is rotatable about an axis of rotation <NUM> for driving the track <NUM> in response to rotation of an axle of the vehicle <NUM>. In this example, the axis of rotation <NUM> corresponds to the axle of the vehicle <NUM>. More particularly, in this example, the drive wheel <NUM> has a hub which is mounted to the axle of the vehicle <NUM> such that power generated by the power source <NUM> and delivered over the powertrain <NUM> of the vehicle <NUM> rotates the axle, which rotates the drive wheel <NUM>, which imparts motion of the track <NUM>.

In this embodiment, the drive wheel <NUM> comprises a drive sprocket engaging the drive/guide lugs <NUM><NUM>-<NUM>N of the inner side <NUM> of the track <NUM> in order to drive the track <NUM>. In this case, the drive sprocket <NUM> comprises a plurality of drive members <NUM><NUM>-<NUM>T (e.g., bars, teeth, etc.) distributed circumferentially of the drive sprocket <NUM> to define a plurality of lug-receiving spaces therebetween that receive the drive/guide lugs <NUM><NUM>-<NUM>N of the track <NUM>. The drive wheel <NUM> may be configured in various other ways in other embodiments. For example, in embodiments where the track <NUM> comprises recesses or holes, the drive wheel <NUM> may have teeth that enter these recesses or holes in order to drive the track <NUM>. As yet another example, in some embodiments, the drive wheel <NUM> may frictionally engage the inner side <NUM> of the track <NUM> in order to frictionally drive the track <NUM>.

The idler wheels <NUM><NUM>-<NUM><NUM> are not driven by power supplied by the powertrain <NUM>, but are rather used to do at least one of supporting part of a weight of the vehicle <NUM> on the ground via the track <NUM>, guiding the track <NUM> as it is driven by the drive wheel <NUM>, and tensioning the track <NUM>. More particularly, in this embodiment, the leading and trailing idler wheels <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, <NUM><NUM> maintain the track <NUM> in tension, and can help to support part of the weight of the vehicle <NUM> on the ground via the track <NUM>. The roller wheels <NUM><NUM>-<NUM><NUM> roll on the inner side <NUM> of the track <NUM> along the bottom run <NUM> of the track <NUM> to apply the bottom run <NUM> on the ground. The idler wheels <NUM><NUM>-<NUM><NUM> may be arranged in other configurations and/or the track system <NUM>i may comprise more or less idler wheels in other embodiments.

The frame <NUM> of the track system <NUM>i supports components of the track system <NUM>i, including the idler wheels <NUM><NUM>-<NUM><NUM>. More particularly, in this embodiment, the front idler wheels <NUM><NUM>, <NUM><NUM> are mounted to the frame <NUM> in a front longitudinal end region of the frame <NUM> proximate the front longitudinal end <NUM> of the track system <NUM>i, while the rear idler wheels <NUM><NUM>, <NUM><NUM> are mounted to the frame <NUM> in a rear longitudinal end region of the frame <NUM> proximate the rear longitudinal end <NUM> of the track system <NUM>i. The roller wheels <NUM><NUM>-<NUM><NUM> are mounted to the frame <NUM> in a central region of the frame <NUM> between the front idler wheels <NUM><NUM>, <NUM><NUM> and the rear idler wheels <NUM><NUM>, <NUM><NUM>. Each of the roller wheels <NUM><NUM>-<NUM><NUM> may be rotatably mounted directly to the frame <NUM> or may be rotatably mounted to a link which is pivotally mounted to the frame <NUM> to which is rotatably mounted an adjacent one of the roller wheels <NUM><NUM>-<NUM><NUM> (e.g., forming a "tandem").

The frame <NUM> of the track system <NUM>i is supported at a support area <NUM>. More specifically, in this embodiment, the frame <NUM> is supported by the axle of the vehicle <NUM> to which is coupled the drive wheel <NUM>, such that the support area <NUM> is intersected by the axis of rotation <NUM> of the drive wheel <NUM>.

In this example of implementation, the track system <NUM>i comprises a tensioner <NUM> for tensioning the track <NUM>. For instance, in this embodiment, the tensioner <NUM> comprises an actuator (e.g., a hydraulic actuator) mounted at one end to the frame <NUM> of the track system <NUM>i and at another end to a hub of the leading idler wheels <NUM><NUM>, <NUM><NUM>. This allows the tensioner <NUM> to modify a distance between the front idler wheels <NUM><NUM>, <NUM><NUM> and the rear idler wheels <NUM><NUM>, <NUM><NUM> in the longitudinal direction of the track system <NUM>i.

<FIG> shows a schematic block diagram of an image processing system <NUM> for use with a system <NUM> for monitoring off-road vehicles such as one or more track vehicles like the agricultural vehicle <NUM>. In some embodiments, one or more images captured by an electronic device <NUM> can be processed using the image processing system <NUM>. For example, in some embodiments, the electronic device <NUM> may transmit image information relating to a track or other component of a track system of a vehicle, such as the track <NUM> or another component of the track system <NUM>i of the vehicle <NUM>, through a communication network <NUM>, to an image processing entity <NUM> over a communication link, which may be implemented over a cellular network, a WiFi network or other wireless LAN, a WiMAX network or other wireless WAN, etc..

In some examples, the electronic device <NUM> can be a smartphone, a tablet, a smartwatch, a computer, etc., of a user, who may be the operator of the vehicle or another person having access to the vehicle. In other examples, the electronic device <NUM> may be integrated with the vehicle.

In some embodiments, the image processing entity <NUM> can be an application running on a server. In other embodiments, the image processing entity <NUM> can be a dedicated network appliance. In yet other embodiments, the image processing entity <NUM> may be an application running on the electronic device <NUM>. In the embodiment of <FIG>, the image processing entity <NUM> comprises a memory <NUM> for storing image information and instructions for processing images, a processor <NUM> implementing a plurality of computing modules <NUM>x (for example, Artificial Intelligence, or "Al", modules) for performing image recognition, pattern recognition and 3D model matching in order to assess a level and nature of wear, degradation and/or other deterioration of the track <NUM> or other track system component. In some embodiments, the computing modules <NUM>x can be implemented using a processor <NUM>. In some embodiments, the computing modules <NUM>x me be implemented by way of an Application Program Interface (API) that results in the computing modules <NUM>x being implemented on a separate device or system.

Computing modules <NUM>x may for example be implemented using known computer vision products, such as, AutoML Vision™ and/or Vision API™, each provided by Google™. In other embodiments, computing modules <NUM>x may comprise standalone AI or machine-learning solutions forming part of image processing entity <NUM>. As defined herein, AI refers to some implementation of artificial intelligence and/or machine learning (e.g., heuristics, support vector machines, artificial neural networks, convolutional neural networks, etc.) in software, hardware or some combination of both.

In some embodiments, complex algorithms, like artificial intelligence, are used to categorize what may be considered uncategorizable data. For example, the system <NUM> can be configured for generating conclusions about a physical state of a track based on one or more images of the track itself. This analysis can include whether or not there is a defect in the track, according to some embodiments. In some embodiments, this can include indications as to the physical state of the track and/or useful life remaining. As will be described below, a machine learning algorithm may be trained to identify a defect or other characteristic in a track by way of image analysis.

In some embodiments, computing modules <NUM>x are first taught how to identify parameters in a training mode (sometimes referred to as supervised learning mode). This is done by analyzing a given set of values, making quantitative comparisons, and cross-referencing conclusions with known results. Iterative refinement of these analyses and comparisons allows an algorithm to achieve greater predictive certainty. This process is continued iteratively until the solution converges or reaches a desired accuracy.

In this embodiment, computing modules <NUM>x can compare image data for a given track to a previously-analyzed mass of known data. When placed in a supervised learning mode, information can be generated from already populated track data provided to the computing modules <NUM>x. For example, this data could contain images of tracks, along with determinations of the remaining life of the tracks. In other words, in the supervised learning mode, both the inputs and the outputs are provided to the system <NUM>. The system <NUM> can process the given inputs and compare the calculated outputs according to its algorithm to the provided outputs. Based on this comparison, the system <NUM> can determine a metric to represent the percentage of error between calculated and provided outputs. Using this error metric, the system <NUM> can adjust its method of calculating an output. During training, the system <NUM> can continuously repeat analysis of different inputs and provided outputs in order to fine-tune its method of determining track information.

In some embodiments, while the computing modules <NUM>x may require initial supervised learning, as the computing modules <NUM>x continue to gain access to data, they may be able to further refine their predictive analytics based on new inputs. For example, if a user is able to confirm that an assessment (e.g. broken/exposed reinforcing cables <NUM><NUM>-<NUM>C) or prediction (e.g. <NUM> months of use left in a given track) made by the system <NUM> is/was incorrect, the user can upload to the system <NUM> what the correct conclusion/prediction was. This allows the computing modules <NUM>x to continue to improve accuracy in their analysis.

In some embodiments, multiple computing modules <NUM>x can be configured to determine different characteristics of a given track. Each of these modules can offer a different analysis for a given input. The processor may direct these modules to be used independently or concurrently based on an operational parameter determined by a given user. For example, the system <NUM> may use a different analytical technique to determine track life compared to drive wheel misalignment. Based on an image communicated to the system <NUM> from an electronic device, the system <NUM> may analyze a given for track life, drive wheel misalignment, or other forms of wear and/or damage.

In some embodiments, the computing modules <NUM>x are configured to assess a level of wear, damage and/or other deterioration of the track <NUM> or other track system component. For example, a computing module <NUM>x can be configured to determine that the traction projections <NUM><NUM>-<NUM>M are worn to <NUM>% of the level of wear that would require replacement of the track. In some embodiments, the computing modules <NUM>x are configured to assess the nature of damage to the track <NUM> or other track system component. For example, a computing module <NUM>x can be configured to determine that a midroller (or any other track system component, such as a sprocket) is damaged or missing.

In some embodiments, the computing modules <NUM>x are further configured to predict the cause of the wear and/or damage to the track <NUM> or other track system component. In one specific example, a computing module <NUM><NUM> is configured to predict whether a specific wear pattern of the elastomeric material of a track <NUM> is caused by a misaligned drive wheel. In another specific example, a computing module <NUM><NUM> is configured to predict whether a specific wear pattern of the elastomeric material of a traction projections <NUM><NUM>-<NUM>M is caused by excessive roading (i.e. traversing a paved road). In another specific example, another computing module <NUM><NUM> is configured to predict whether a specific wear pattern of the track (e.g. the abnormal relative position of two adjoining track links) is caused by a broken reinforcing cable <NUM><NUM>-<NUM>C. As will be appreciated, each computing module <NUM>x can be implemented using a combination of deep learning, supervised or unsupervised machine learning, image recognition and/or machine vision.

In some embodiments, the system <NUM> is configured to capture one or more 2D images to detect specific patterns of wear and/or damage. For example, the system <NUM> may be configured to implement one or more computer vision (CV) models to detect specific visible wear/damage features. Examples of such visible wear/damage features include, but are not limited to, broken and/or exposed reinforcing cables <NUM><NUM>-<NUM>C, linear recesses in the carcass <NUM> caused by delamination and changes in the shape of drive wheel <NUM> (sprocket) teeth, evidencing sprocket tooth wear caused by debris and/or normal engagement with drive/guide lugs <NUM><NUM>-<NUM>N.

In some embodiments, the image processing system <NUM> may produce a three-dimensional (3D) scan to generate a 3D model of at least part of the track <NUM> or other track system component. For example, in some embodiments, the image data received by the electronic device <NUM> or any other image capture means are processed by way of photogrammetry in order to create the 3D model of the track <NUM> and/or track component. In some embodiments, as described in more detail below, laser line scanners are instead used to generate the 3D model of the track <NUM> and/or track component.

Such precise 3D models can be compared to 3D models of unworn and/or undamaged tracks in order to precisely measure wear, damage and/or other deterioration. For example, by comparing the 3D model of a worn track <NUM> to the 3D model of a new, unworn track, it is possible to precisely measure a volumetric loss of material of the worn track <NUM>, and thereby assess the wear and/or other deterioration of the worn track <NUM>, very precisely.

With reference to <FIG>, in some embodiments, the system <NUM> may generate a 3D model <NUM> of a track <NUM>, or track system <NUM>x component, using any of the above methods, or a combination thereof. In some embodiments, the system <NUM> can then be superimposed onto an image of the track <NUM> captured by electronic device <NUM>. Such superimposition may be achieved using known augmented reality (AR) techniques and processes.

As described above, in some embodiments, the system <NUM> can implement a 2D recognition technique. In some embodiments, the system <NUM> can implement a 3D recognition technique. In some embodiments, the system <NUM> can implement a combination of a 2D recognition technique and a 3D recognition technique.

In some embodiments, the 3D recognition technique used is based on generating a 3D model using a point cloud. For example, as shown in <FIG>, method <NUM> can be used to identify track component wear/damage and/or the extent thereof. At step <NUM>, a plurality of images of the track system component can be acquired using the electronic device <NUM>, before sending the images to the image processing entity <NUM> at step <NUM>. At step <NUM>, the system <NUM> generates a 3D point cloud using the plurality of images. This can be accomplished by system <NUM> using, for example, open source algorithms, such as those available from Point Cloud Library (PCL). Alternatively, the point cloud can be generated a third party, through use of an Application Program Interface (API) by system <NUM>. At step <NUM>, the system <NUM> uses the generated 3D point cloud to generate a 3D model of the track system component. Once generated, the 3D model is matched to known 3D models of track system components in a track system components database at step <NUM>. Once matched, at step <NUM>, wear, damage and/or the extent thereof can be identified by comparing the generated 3D model to the known 3D model, as described in more detail below.

2D recognition techniques include four basic steps, namely image acquisition, image processing, feature extraction and classification. Such techniques include, but are not limited to, Optical Character Recognition (OCR), feature detection, image gradient analysis, pattern recognition algorithms and feature/pattern classification algorithms.

In some embodiments, the system <NUM> can be configured to implement the method of <FIG>. In particular, at step <NUM>, the electronic device <NUM> can acquire one or more images of a track system component, before sending the images to the image processing entity <NUM> at step <NUM>. In some embodiments, the image processing entity <NUM> can perform image processing steps prior to feature extraction. For example, in some embodiments, the image processing entity <NUM> can be configured to perform image processing including the use of fiducial markers. Then, at step <NUM>, the image processing entity <NUM> can perform feature extraction in order to detect and isolate various portions or shapes (features) of the image or images. Feature extraction can include, but is not limited to, edge detection, corner detection, blob detection, ridge detection, scale-invariant feature transform, thresholding, blob extraction, Haar-like feature extraction, template matching, Hough transforms and generalized Hough transforms.

Then at step <NUM>, the system <NUM> can perform feature classification. In some embodiments, feature classification can include, but is not limited to, the use of nearest neighbor classification, cascading classifiers, neural networks, statistical classification techniques and/or Bayesian classification techniques. Once the features have been classified, it is possible to separate, at step <NUM>, features which represent undamaged/unused parts of the track system component, and features (e.g. cracks, exposed cables, etc.) which represent patterns of wear or damage. Once features relating to patterns of wear or damage have been detected, it is possible for the system <NUM> to perform further feature classification on the wear or damage pattern.

As shown in <FIG>, in some embodiments, system <NUM> is configured to use the system of <FIG> in order to detect damage or wear patterns in track system components. For example, as shown in <FIG>, system <NUM> can be configured to detect partially embedded (though exposed) cables <NUM>A using the 2D analysis method described with reference to <FIG>. Similarly, as shown in <FIG>, system <NUM> can be configured to recognize a narrow (though potentially deep) crack <NUM>B in carcass <NUM>. As will be appreciated by the skilled reader, such patterns are difficult to detect using volumetric analysis alone. As such, the 3D recognition techniques of the present disclosure can be combined with any of the 2D recognition techniques in order to facilitate track system component matching, as well as wear and/or damage recognition and characterization. Moreover, the 2D recognition techniques of the present disclosure can be used on images generated by the system <NUM> of various views of the 3D model generated using the 3D recognition techniques of the present disclosure.

As shown in the method of <FIG>, once a plurality of images are acquired at step <NUM>, the system <NUM> can sequentially use 3D recognition at step <NUM> and then 2D recognition at step <NUM> in order to detect patterns of wear and/or damage on a track system component. In some embodiments, 2D recognition may be performed before 3D recognition. Advantageously however, 3D recognition is performed first, as in such an arrangement, the system <NUM> may be configured to superimpose 2D features onto 3D models, thereby allowing a more precise classification of the type of wear and/or damage.

As shown in <FIG>, in some embodiments the system <NUM> is configured to generate a 3D model <NUM> of a used and/or damaged track and compare it to a 3D model <NUM> of an unused and undamaged track. The 3D model <NUM> of an unused and undamaged track may be generated by the system <NUM> based on a previously-scanned track, may be acquired by the system <NUM> from a database of 3D models of tracks, or may be acquired by the system in any other suitable way. Once the 3D model <NUM> of an unused and undamaged track is acquired or generated by the system <NUM>, it can be compared to the 3D model <NUM> of a used and/or damaged track generated by the system <NUM> using various volumetric comparison techniques. For example, the system <NUM> may compare the models by calculating the amount of missing material of a given track feature (e.g. traction projections <NUM><NUM>-<NUM>M). For example, volumetric comparison of the 3D model <NUM> of a used and/or damaged track and a 3D model <NUM> of an unused and undamaged track can establish that a given traction projection <NUM>x has been worn to <NUM>% of its original volume.

In some embodiment, the cause and/or nature of the wear and/or damage of the track <NUM>, or other track system component, can be established by the system <NUM> performing a volumetric comparison of the 3D model <NUM> of a used and/or damaged track and a 3D model <NUM> of an unused and undamaged track.

For example, as shown in <FIG>, based on a comparison of the 3D model <NUM> of a used track and a 3D model <NUM> of an unused track, in some embodiments the system <NUM> can determine a pattern of tread wear that is indicative of the cause and/or nature of the tread wear. In particular, the trailing edge wear pattern detected by the system <NUM> in the traction projections <NUM><NUM>-<NUM>M of <FIG> is typically caused by a weight balance bias towards the rear of a vehicle <NUM>. The "wheel path" wear pattern detected by the system <NUM> in the traction projections <NUM><NUM>-<NUM>M of <FIG> is caused by an increase in wear in the area under the highest load (known as the wheel path).

As shown in <FIG>, based on a comparison of the 3D model <NUM> of a damaged track and a 3D model <NUM> of an undamaged track, in some embodiments the system <NUM> can determine a pattern of damage that is indicative of the cause and/or nature of the damage. In particular, the minor delamination damage detected by the system <NUM> in the traction projections <NUM><NUM>-<NUM>M of <FIG> is typically caused by incomplete or improper curing, contamination of source material and/or poor quality source material. The "chunking" damage detected by the system <NUM> in the traction projections <NUM><NUM>-<NUM>M of <FIG> is typically caused by highly abrasive or hard/irregular ground conditions.

As shown in <FIG>, based on a comparison of the 3D model <NUM> of a used track and a 3D model <NUM> of an unused track, in some embodiments the system <NUM> can determine a pattern of non-tread wear that is indicative of the cause and/or nature of the non-tread wear. In particular, in the case of some agricultural and construction vehicle track systems, the wear pattern detected by the system <NUM> in the drive/guide lugs <NUM><NUM>-<NUM>N of <FIG> relates to typical drive/guide lug break-in wear. The wear pattern detected by the system <NUM> on the inside of the carcass <NUM> of <FIG> relates to typical carcass wear due to use of the vehicle <NUM> for abrasive/construction applications.

As shown in <FIG>, based on a comparison of the 3D model <NUM> of a damaged track and a 3D model <NUM> of an undamaged track, in some embodiments the system <NUM> can determine a pattern of damage that is indicative of the cause and/or nature of the damage. In particular, the straight crack located near a joint area at the outer diameter of the track <NUM> detected by the system <NUM> in the carcass <NUM> of <FIG> is typically caused by incomplete or improper curing, contamination of source material and/or poor quality source material.

For example, as shown in <FIG>, based on a comparison of the 3D model <NUM> of a used track system component and a 3D model <NUM> of an unused track system component, in some embodiments the system <NUM> can determine a pattern of track system component wear that is indicative of the cause and/or nature of the wear. In particular, the sprocket (drive wheel <NUM>) wear pattern detected by the system <NUM> in the sprocket teeth of <FIG> is typically caused by normal operation. By determine the extent of the wear using the techniques described above, the system <NUM> can determine if and when a sprocket requires replacing.

As shown in <FIG>, based on a comparison of the 3D model <NUM> of a damaged track and a 3D model <NUM> of an undamaged track, in some embodiments the system <NUM> can determine a pattern of damage that is indicative of the cause and/or nature of the damage. In particular, the tread delamination or carcass <NUM> layer separation detected by the system <NUM> in the carcass <NUM> of <FIG> is typically caused by poor adhesion of the layer delaminating layer due to contamination or improper curing of the track.

As shown in <FIG>, based on a comparison of the 3D model <NUM> of a used track and a 3D model <NUM> of an unused track, in some embodiments the system <NUM> can determine a pattern of non-tread wear that is indicative of the cause and/or nature of the non-tread wear. In particular, in the case of construction vehicle track systems, the central wear pattern detected by the system <NUM> in the drive bars of <FIG> relates to a drive wheel <NUM> that is not adapted to the track <NUM>, possibly because the teeth of the drive wheel <NUM> itself are worn beyond a threshold.

As described above, and as shown in <FIG>, system <NUM> can use the 2D recognition technique described above to recognize and characterize the presence of exposed track cables <NUM>A. Also, as shown in <FIG>, the system <NUM> can use the 2D recognition technique described above to recognize and characterize the presence of a crack <NUM>B in the carcass of track <NUM>.

Once the computing modules <NUM>x has determined the cause, level and/or nature of the wear and/or damage of the track <NUM> or other track system component, the image processing entity <NUM> may send data relating to the cause, level and/or nature of the wear and/or damage of the track <NUM> or other track system component back to electronic device <NUM> for further processing and/or notification to a user. By using this information, electronic device <NUM> may determine that an event arising from usage of a track system <NUM>x, such as a usage threshold event (e.g. an amount of tread wear, an amount of time such as a number of hours the track <NUM> has been used), wear threshold event (e.g. the number of exposed reinforcing cables caused by chunking) and/or damage event (e.g. one or more severed reinforcing cables), has occurred.

According to some embodiments, the computing modules <NUM>x may have access to information stored elsewhere on the internet. For example, the computing modules <NUM>x may be configured to query databases stored on external servers by sending requests over the network in order to analyze the image based on pertinent cross-referential data. This may include weather, humidity, or information about the vehicle or track that can be periodically updated.

<FIG> illustrates a schematic network diagram of a system <NUM> for monitoring vehicles such as one or more track vehicles like the agricultural vehicle <NUM>, according to one embodiment. In the embodiment of <FIG>, the system <NUM> includes an electronic device <NUM>, a network <NUM>, and a system server <NUM> that can implement the image processing entity <NUM> of <FIG>. The server includes a memory <NUM>, processor <NUM>, and network interface <NUM>.

The electronic device <NUM> may include elements such as a processor, a memory, a display, a data input module, and a network interface. The electronic device <NUM> may include other components, but these have been omitted for the sake of brevity. In operation, the electronic device <NUM> is configured to perform the operations described herein. The electronic device <NUM> processor may be configured to execute instructions stored in memory. The instructions, when executed, cause the electronic device <NUM> to perform the operations described herein. In some embodiments, the instructions may be part of a software application downloaded into memory by the electronic device <NUM>. Alternatively, some or all of the functionality described herein may be implemented using dedicated circuitry, such as an ASIC, a GPU, or a programmed FPGA for performing the operations of the processor.

In some embodiments, an application ("app", i.e., software) may be installed on the electronic device <NUM> to interact with the system server <NUM> and or the vehicle <NUM>. For example, in some embodiments, such as where the electronic device <NUM> is a smartphone, a tablet, a computer, etc., the user (e.g., the operator) may download the app from a repository (e.g., Apple's App Store, iTunes, Google Play, Android Market, etc.) or any other website onto the electronic device <NUM>. Upon activation of the app on the electronic device <NUM>, the user may access certain features relating to the system server <NUM> and/or the vehicle <NUM> locally on the electronic device <NUM>.

In operation, a user can use the electronic device <NUM> to generate data about the vehicle <NUM>. For example, for embodiments where the electronic device is a smart phone equipped with a camera, the user can take one or more images of a track <NUM> of the vehicle <NUM>. The system <NUM> may then take the image data captured by the electronic device <NUM> and transmit the image data over a network <NUM> to a system server <NUM>.

According to some embodiments, the electronic device <NUM> may be a portable electronic device with multiple uses such as a mobile phone, tablet or laptop. According to other embodiments, the electronic device may be a single-use electronic device, such that the device is designed to only be used in operation with the system <NUM>. Further, the electronic device <NUM> may also be capable of establishing a communicable link with an accessory device. This communicable link be may be wireless, wired, or partly wireless and partly wired (e.g., Bluetooth or other short-range or near-field wireless connection, WiFi or other wireless LAN, WiMAX or other wireless WAN, cellular, Universal Serial Bus (USB), etc.).

According to other embodiments, the electronic device <NUM> may integrated into an internal computer <NUM> in the off-road vehicle (as shown in <FIG>). The internal computer <NUM> may have a vehicle memory <NUM>, processor <NUM>, network interface <NUM>, and internal sensor network <NUM>. In some embodiments, vehicle internal computer <NUM> can communicate and upload images to system server <NUM> independently.

The internal sensor network <NUM> can include sensors to provide information about the vehicle or the track of the vehicle. For example, this may include a camera positioned to take images of the track. In some embodiments where the electronic device is integrated into an internal computer in the off-road vehicle, the system <NUM> may be configured to continuously monitor the track. This can be achieved by continuously capturing data, for example, images of the vehicle track, at various intervals. The electronic device <NUM> can then automatically upload the data over the network <NUM> to the system server <NUM> for image processing. After processing, the image processing entity <NUM> can automatically communicate over the network <NUM> if a fault state has been determined.

The electronic device <NUM> can also send additional data to the image processing entity <NUM> over the network <NUM>. For example, this can include (but is not limited to) GPS location, date and time, or any information from an onboard computer within the vehicle. This data can be cross-referenced and analyzed within the computing modules <NUM>x. For example, given GPS and date and time data, the AI module can access the specific weather and weather history for the vehicle location. In some embodiments, such information may be used in, for example, determining the end-of-life of a track (i.e. the amount of time until a track is expected to fail or until the likelihood of track failure rises above a predetermined threshold).

This may be achieved by a separate electronic device <NUM> being communicably linked to an internal computer <NUM> of a vehicle <NUM>. The internal computer <NUM> may periodically receive and record information relating to the vehicle <NUM> and/or track systems <NUM><NUM>-<NUM><NUM> determined by the internal sensor network <NUM>. For example, the internal sensor network <NUM> may include an image taken of the track or information about the vehicle <NUM>, such as the speed of the vehicle <NUM>.

According to some embodiments, the electronic device <NUM> may communicate a unique identifier for a specific track under inspection. In some embodiments, the unique identifier can be a serial number of the track. This allows the server <NUM> and/or internal computer <NUM> to catalog the inspection and produce a history of a given track. According to some embodiments, the internal computer <NUM> and/or the server <NUM> may store data about the serial numbers of the tracks installed on the vehicle <NUM>.

According to some embodiments, the electronic device <NUM> may be capable of determining a serial number from a track based on an image of the track. This can be done by the electronic device <NUM> capturing an image of an embossed serial number on a surface of the track, and using the image processing entity <NUM> to determine the specific characters of the serial number. This can be cross-referenced with a database stored in server memory <NUM> (or otherwise accessible by system server <NUM>) to determine elements such as the model and date of manufacture of the track.

Serial number analysis may be performed using AI techniques employed by the computing modules <NUM>x, may be performed using techniques such as optical character recognition (OCR), or a combination thereof. These techniques may include preprocessing of an image in order to improve the ability to analyze the target components, such as de-skewing, layout analysis, and binarization. In some embodiments, a track system and/or track system component (such as a track) can be identified by way of another marking or tag suitable for communicating information relating to the track system and/or track system component. Such markings or tags can include, but are not limited to, barcodes, Quick Response (QR) codes or other matrix barcodes and Radio Frequency Identification (RFID) tags.

Another method of track identification that can be performed by the electronic device <NUM> is track pattern recognition. The electronic device <NUM> may be configured to analyze the tread pattern and measure track width to determine a number of characteristics about the track. The electronic device <NUM> may then send this data and information to the system server <NUM> for further data analysis to identify the type of track. The type of track may be a track brand, model number, or any other suitable information capable of identifying a track.

According to some embodiments, the vehicle may be capable of communicating all the necessary data over the network without the use of an external electronic device <NUM> such as a mobile phone. For example, the vehicle <NUM> may be equipped with a network interface capable of independently communicating with the system server <NUM> over the network <NUM>.

According to some embodiments, a system server <NUM> hosts the image processing entity <NUM>. Server processor <NUM> is able to access instructions stored in the memory <NUM> that can initialize the image processing entity <NUM>. This initialization can include operational parameters that include which AI module <NUM>x to use.

Image processing entity <NUM> can store instructions relating to a specific AI module <NUM>x within the memory <NUM>. The processor <NUM> may instruct the server to save the data received from the network via the network interface <NUM> in memory <NUM>. The processor <NUM> may analyze the data in memory <NUM> and determine information about the track <NUM>. Based on the data analysis, the processor <NUM> may send a communication to the electronic device <NUM> over the network <NUM> via the network interface <NUM>.

<FIG> illustrates a schematic network diagram of a system <NUM> for monitoring off road vehicles, according to another embodiment. According to this embodiment, the system <NUM> can communicate with multiple vehicles <NUM>A-<NUM>N. While this figure shows the vehicles <NUM>A-<NUM>N communicating independently with the system server <NUM> over the network <NUM>, the vehicles may alternatively each be communicably linked with an electronic device <NUM> as described with reference to <FIG>. According to this embodiment, the system server <NUM> may communicate with an electronic device <NUM> located at a dispatch center <NUM>, a service center <NUM>, or a parts supplier <NUM>.

In operation, based on the analysis determined by the image processing entity <NUM>, the system server <NUM> may communicate with the user via an electronic device <NUM> or the vehicle <NUM>, a dispatch center <NUM>, a service center <NUM>, or a parts supplier <NUM>. The system <NUM> may also communicate with any combination of these, or any other suitable device registered within the system <NUM>. This communication can contain information such as that indicating the determination of track wear and/or damage concluded by the image processing entity <NUM>. Based on this information, the dispatch center <NUM> or user may schedule maintenance with the service center <NUM>. Based on the conclusion on track wear and/or damage (for example, that the track needs to be replaced) and vehicle information (track type, vehicle type) available, the system <NUM> can determine the amount of time required or parts available at the service center <NUM> and facilitate scheduling a maintenance appointment or a shipment from the parts supplier <NUM>. This can be done by maintaining a database of inventory at the service center, along with a calendar.

<FIG> to <FIG> illustrate representations of different databases that may be generated by the server processor <NUM> based on information stored in memory <NUM>. The server memory <NUM> can store a history of all information necessary for performance of the system <NUM>, including a record of all inspections and conclusions made. These databases, or the information stored within them, may be accessible to users and administrators of the system <NUM>, or to software able to interact with the system <NUM> through the use of an application programming interface (API).

<FIG> shows an example of a visual representation of a database that can be generated by the system <NUM> according to an embodiment directed towards a specific track manufacturer. This includes an indication of track model, a serial number for the track, the date of an inspection, the type of inspection, along with the registered owner. This database representation gives the manufacturer access to all registered tracks sold and registered within the system <NUM>, and allows access to information on track wear and damage.

<FIG> shows an example of a visual representation of a database that can be generated by the system <NUM> according to an embodiment directed towards a vehicle fleet manager. The database includes an indication of track model, a unique identifier for the vehicle itself, the date of an inspection, track status, and an additional field for manager notes. This database representation gives the fleet manager access to all vehicles registered within the system <NUM>, and allows them to access a history of information on track wear and/or damage.

<FIG> shows an example of a visual representation of a database that can be generated by the system <NUM> according to an embodiment directed towards a specific vehicle manufacturer. This includes an indication of vehicle model, track model, a date of an inspection, track status, and an additional field for manager notes. This database representation gives the vehicle manufacturer access to all of their vehicles registered within the system <NUM>, and allows them to access a history of information on track wear and/or damage.

The disclosed embodiments of database representations are structured merely by way of example for illustrative purposes, and a skilled reader would know that these visual representations can be changed to include more or less information available to the system <NUM>.

<FIG> shows an example flowchart of the use of the system <NUM> which could be used (e.g., by the operator of the vehicle <NUM>, in a rental market, etc.) to monitor usage of track system components.

In operation, a user can use the electronic device <NUM> to generate image data relating to the track <NUM> and/or track system <NUM>x of the vehicle <NUM>. According to some embodiments, the electronic device <NUM> may also access internal information stored on the vehicle onboard computer <NUM>. The electronic device <NUM> may then communicate both the data captured and the information retrieved by the electronic device <NUM> over the network <NUM> to the system server <NUM> to be stored in memory <NUM>. Using both the data captured and the information retrieved the processor <NUM> may determine information about the track <NUM>. Based on the data analysis, the processor <NUM> may send a communication to the electronic device <NUM> over the network <NUM> via the network interface <NUM>.

At step <NUM>, the system <NUM> determines that an event arising from use of a track system <NUM>x, such as a usage threshold event (e.g. an amount of time such as a number of hours the track <NUM> has been used) or adeterioration threshold event (e.g. chunking or other loss of elastomeric material of the track, the number of exposed reinforcing cables, one or more severed reinforcing cables, etc.), has occurred. As described above, the system <NUM> can make these determinations by analysis of the images taken by the image capture devices described above.

At step <NUM>, the system <NUM> identifies the track system component for which the usage threshold event or deterioration threshold event has occurred. In some embodiments, the track system component information and information relating to the usage threshold event and deterioration threshold event is conveyed to the operator of the vehicle by the system <NUM> in order to facilitate scheduling of track system component servicing and/or other maintenance.

For purposes of this example, it is assumed that the usage threshold event or deterioration threshold event is for the track <NUM>.

For example, the system <NUM> may issue a notification conveying this information to the operator via the user interface of the operator cabin <NUM> of the vehicle <NUM> and/or the electronic device <NUM>. According to embodiments wherein the electronic device <NUM> is a mobile phone, this could be in the form of a push notification sent to the app over the network <NUM>. In other embodiments, the system <NUM> conveys the track system component information and information relating to the usage threshold event and deterioration threshold event to an organization providing maintenance services. For example, the system <NUM> may issue a notification conveying this information to a system server <NUM> associated with the organization via a network <NUM> (e.g. which may be implemented by the Internet, a cellular connection, and/or any other network infrastructure). Once the information is received, the organization can schedule maintenance of the vehicle at step <NUM>, and subsequently replace or repair the track system component. Accordingly, track system component maintenance operations can be initiated and scheduled without the need for input from the vehicle operator.

As shown in <FIG>, the system <NUM> may allow organizations to provide track-as-a-service type payment/usage models, in which tracks are not purchased, but are rather provided as a service to vehicle operators in exchange for a subscription fee. For example, for a monthly fee, an organization may provide vehicle operators with tracks, as well as usage rights to the system <NUM> described herein which will allow the organization to ensure that the vehicle operator is never without an operable/functional track, regardless of how much and how (i.e. under what circumstances) the vehicle operator uses the track.

This can lead to significant savings in term of vehicle downtime and logistics. For example, at step <NUM>, the system <NUM> determines that an event arising from usage of a track system <NUM>x, such as a usage threshold event (e.g. an amount of tread wear, an amount of time such as a number of hours the track <NUM> has been used), deterioration threshold event (e.g. the number of exposed reinforcing cables) and/or deterioration event (e.g. one or more severed reinforcing cables), has occurred. At step <NUM>, the system <NUM> identifies the track system component for which the usage threshold event, deterioration threshold event and/or deterioration event has occurred. At step <NUM>, vehicle location information relating to the geographic location of the vehicle is determined. This can be achieved by any suitable means including, but not limited to, Global Positioning System (GPS) receivers. In some embodiment, the system <NUM> conveys the track system component information, vehicle location information and information relating to the usage threshold event, deterioration threshold event and/or deterioration event to the track-as-a-service organization.

As shown in above, the system <NUM> may communicate with the system server <NUM> of the track-as-a-service organization over a network <NUM> (e.g. which may be implemented by the Internet, a cellular connection, and/or any other network infrastructure). Then, at step <NUM>, the track-as-a-service organization ships a replacement track system component to a location related to the geographic location of the vehicle. For example, the track-as-a-service location could ship the replacement track system component to the nearest maintenance service dispatch location or third party maintenance organization. At step <NUM>, the track-as-a-service organization can schedule a maintenance of the track system. In some embodiments, the track-as-a-service organization schedules a third party mobile maintenance team to perform onsite maintenance based on the geographic location of the vehicle. Finally, at step <NUM>, the track-as-a-service organization, or an agent thereof, replaces the track system component. In some embodiments, this can be performed onsite, based at least in part on the vehicle location information received from the track-as-a-service organization.

<FIG> shows an example flowchart of the use of the system <NUM> which could be used, for example, by a fleet manager to monitor usage of track system components. In this system <NUM>, the preferences of a given fleet manager can be included in any part purchase or system maintenance request. For example, a fleet manager may consider a specific track to be superior to all other on the market. The fleet manager may want to only purchase that specific brand of track. Another example of purchase preferences may include only to purchase a specific track if the supplier inventory and price database indicates that the part is available with a discount. Further, if there is no supply of a first preferred track in the inventory, the user may store a preference for an alternate track to be purchased. In this embodiment, steps <NUM> and <NUM> are the same as those described in steps <NUM>, <NUM>, and <NUM>, <NUM> respectively.

At step <NUM>, the system <NUM> will query the memory to determine if the specific user has a purchase preference stored in the system <NUM>. If the system <NUM> has a purchase preference stored for the given user, the system <NUM> will order the track system component for replacement based on the saved preference at step <NUM>. If the system <NUM> does not find a purchase preference for the given user, the system <NUM> may send a communication to the user's electronic device <NUM> with information indicating the part purchase options and information about the parts (for example the various options of price and part characteristics). The system <NUM> may also send a communication instructing the electronic device <NUM> to prompt the user to store a purchase preference. Based on this information, the system <NUM> will order the track system component at step <NUM>.

At step <NUM>, the system <NUM> may schedule maintenance with a given service center or technician. At this step user preferences may also be considered. For example, a user may be able to store in their profile a preference for scheduling. This may include a preference for the first available time to service the vehicle. Alternatively, a fleet manager may try and coordinate scheduling of maintenance with other vehicles within a fleet. This could include wanting all vehicles to be serviced at the same time, or to stagger vehicle services. Scheduling preferences may also include a time of day preference for the user to have maintenance scheduled. Based on these preferences, the user may be automatically scheduled for maintenance.

According to other embodiments, the system <NUM> may prompt the user via a date and time entry interface, such as a calendar interface, on the electronic device <NUM> to input a date and time for maintenance. Based on this input data, the system <NUM> can schedule maintenance with a technician or service center.

Finally, at step <NUM>, the track-as-a-service organization, or an agent thereof, replaces the track system component. In some embodiments, this can be performed onsite, based at least in part on the vehicle location information received from the track-as-a-service organization.

<FIG> shows an example flowchart of the use of the system <NUM> which could be used, for example, by a fleet manager to monitor usage of track system components. According to this embodiment, inventory of the track system components at a given service center can be monitored. The system <NUM> allows organizations managing large fleets (e.g. vehicle rental companies, construction companies, forestry companies, etc.) to ensure that maintenance operations can be scheduled and carried out effectively and efficiently. For example, by monitoring the wear of track system components, it is possible to more precisely predict when a track system component will fail and/or when a replacement track system component should be ordered and/or shipped.

Moreover, for an organization managing a fleet of vehicles, knowing which vehicles will shortly require maintenance and/or replacement parts contributes to efficient and effective deployment of vehicles and maintenance resources. For example, at step <NUM>, the system <NUM> determines that an event arising from usage of a track system <NUM>x, such as a usage threshold event (e.g. an amount of tread wear, an amount of time such as a number of hours the track <NUM> has been used), deterioration threshold event (e.g. the number of exposed reinforcing cables) and/or deterioration event (e.g. one or more snapped or broken reinforcing cables), has occurred. At step <NUM>, the system <NUM> identifies the track system component for which the usage threshold event, deterioration threshold event and/or deterioration event has occurred. In some embodiments, as shown in <FIG>, the system <NUM> conveys the track system component information and information relating to the usage threshold event, deterioration threshold event and/or deterioration event to an automated fleet management system. The system <NUM> may communicate with the automated fleet management system over a network <NUM> (e.g. which may be implemented by the Internet, a cellular connection, and/or any other network infrastructure). At step <NUM>, the automated feet management system queries a track system component supply database to determine whether the identified track system component is available or needs to be ordered.

The track system component supply database can be managed by the fleet management system, or can be managed by a third-party track system component supplier. If the identified track system component is available, the vehicle can be scheduled for maintenance. If, on the other hand, the track system component is not available, the fleet management system can cause the track system component to be ordered at step <NUM>, before scheduling maintenance of the vehicle at step <NUM>. This system may also include ordering based on stored user preference as previously described.

In some embodiments, the scheduling of the vehicle maintenance is at least in part based on the estimated delivery time for an ordered track system component. In other embodiments, the dispatching of the vehicle relating to the identified track system component can, at least partially, be based on a pre-scheduled maintenance. This system <NUM> may also include scheduling based on stored user preference as previously described. Finally, at step <NUM>, the maintenance operation is carried out and the track system component is replaced or repaired.

<FIG> shows an example flowchart of the use of the system <NUM> which could be used, for example, by a vehicle operator to monitor usage of track system components. According to this embodiment, the system <NUM> has determined a critical error to have taken place or imminent. In this embodiment, steps <NUM> and <NUM> are similar to those described in steps <NUM>, <NUM>, and <NUM>, <NUM> respectively.

If the system <NUM> has determined that a critical error has taken place or is imminent, it can prompt the user to establish an audiovisual and/or textual connection with a technician at <NUM>. This could be achieved by using a Voice Over IP (VoIP) system, a phone call over a cellular network, or any other means of text, audio or video communication. This will allow the vehicle operator to communicate with the technician and get or receive pertinent information to vehicle maintenance. For example, the technician may instruct the user to drive the vehicle to a safe location and wait for the technician to arrive. In the case of a video call, the technician may be able to instruct the user to point the camera of the electronic device at a specific component of the vehicle <NUM> in order to provide the technician with more information about the vehicle status.

<FIG> shows an example flowchart of the use of the system <NUM> which could be used, for example, by a vehicle operator to monitor usage of track system components. According to this embodiment, the system <NUM> has determined a critical status of the track and/or track system. In this embodiment, steps <NUM> and <NUM> are similar to those described in steps <NUM>, <NUM>, and <NUM>, <NUM> respectively.

At step <NUM>, the system <NUM> alerts relevant parties of the critical status. This can include fleet managers, technicians or other operators. For example, the system <NUM> may send a text message, email or app push notification to any interested party that the status and operability of a given vehicle with a unique identifier has reached a certain threshold of wear or damage. Based on the information determined by the system <NUM>, the vehicle operator or fleet manager may override the decision determined by the system <NUM> and continue to operate the vehicle. Alternatively, the system <NUM> may have the capability to safely disable the vehicle given specific parameters. For example, the system <NUM> may only allow the vehicle to operate for another specific distance or time, or may not allow the vehicle to restart after it has switched off without an appointment with a technician.

<FIG> shows an example flowchart of the use of the system <NUM> by, for example, a vehicle operator to monitor usage of track system components. According to this embodiment, the system <NUM> is able to determine a specific track brand or type, and cross-reference this brand or type with a database of compatible brands stored in a memory. In this embodiment, steps <NUM> and <NUM> are similar to those described in steps <NUM>, <NUM>, and <NUM>, <NUM> respectively.

According to this embodiment, the system <NUM> is able to identify the track characteristics <NUM>. These characteristics may include thickness, length, weight, width, tread pattern, internal cable strength, etc. Based on an analysis of the vehicle's track, the system <NUM> can determine track alternatives at step <NUM>. This can be done using a pre-populated database stored on a server of all major available track brands and products, along with compatible alternatives. Once the system <NUM> has determined the track and track characteristics, it can query the database to find all other products that could be used for the vehicle.

The system <NUM> can then communicate the tracks to the user at step <NUM>. This can be done by sending the information over the network to the electronic device. The user may determine that an alternative track could be used for the vehicle. If the user selects the alternative track, the system <NUM> will send that message back to the server over the network and proceed to organize any part replacement using the user's selection.

As shown in <FIG>, image data capture is shown according to different embodiments. According to some embodiments, the electronic device <NUM> can display an instruction to the user to position and/or move the electronic device <NUM> in order to optimally capture the image.

<FIG> shows an embodiment in which the system <NUM> may instruct the user to take an image of the vehicle <NUM>. The electronic device <NUM> will communicate this image along with any other information to be communicated to the system server <NUM> for analysis, as described above.

As shown in <FIG>, the system <NUM> may also or instead instruct the user to take a video of the track <NUM>. The electronic device <NUM> may then communicate this video along with any other information to be communicated to the system server <NUM> for data analysis, as described above.

As shown in <FIG>, the system <NUM> can instruct the user to use an accessory device <NUM> in conjunction with the vehicle <NUM> in order to generate data about the track <NUM> and or track system. According to this embodiment, the accessory device <NUM> can be an optical sensor communicatively linked to the electronic device <NUM>. The accessory device <NUM> can communicate the image data captured to the electronic device <NUM>. The electronic device <NUM> may communicate this data along with any other information to be communicated to the system server <NUM> for analysis, as described above.

As shown in <FIG>, the electronic device <NUM> can be communicably linked to the vehicle, according to some embodiments. According to this embodiment, the electronic device <NUM> communicates with an onboard computer <NUM> in the vehicle <NUM> in order to generate data about the vehicle. The electronic device <NUM> may communicate this data along with any other information to be communicated to the system server <NUM> for analysis, as described above.

As shown in <FIG>, the information determined about the vehicle based on the analysis conducted by the system <NUM> is communicated to the electronic device <NUM> over the network <NUM>. According to this embodiment, the information was a length of time before the track needed to be replaced.

As shown in <FIG>, the system <NUM> has already communicated to the electronic device that based on the data analysis, vehicle maintenance is required. The electronic device <NUM> can then prompt the user to schedule the maintenance. If the user decides to schedule the maintenance, the electronic device <NUM> can communicate directly with a service center <NUM> in order to schedule the maintenance over the network <NUM>. For example, the user may have access to a booking calendar for the service center and select a time. Based on this selection, the parties will be notified that maintenance has been booked. According to some embodiments, the system <NUM> may have access to information about the service center <NUM>, such as parts inventory. Based on this inventory, the system <NUM> can calculate any lead time if required that can be factored into the booking span.

According to other embodiments such as those shown in <FIG>, the system <NUM> can order new parts through the network <NUM> by creating a request to a retailer or parts center <NUM>. In this embodiment, if the service center requires a unique part that they do not have, the system <NUM> may create a request to the parts center to ship the part to the service center in advance of the booked maintenance time.

According to another embodiment, the system <NUM> may have access to pricing information or alternative replacement parts available at the parts center <NUM>. The system <NUM> may present the user with pricing options, sale information for different components they may require ordering for replacement. The user may then inform the system <NUM> of their preference and the system <NUM> will submit the order to the parts center accordingly.

As shown in <FIG>, according to some embodiments, the system <NUM> is configured to schedule a maintenance request over the network <NUM> without requiring a user to select a time. This time may be based on a user preference saved in the server memory for a given vehicle owner. For example, an owner may have a preference that all vehicles are scheduled for maintenance one month before the system <NUM> determined date. Accordingly, the system <NUM> can notify the user of scheduled maintenance as it is automatically scheduled.

Similarly, according to some embodiments, the system <NUM> is able to make purchase requests over the network <NUM> without requiring the user to select a part component. This choice may be based on a user preference saved in the server memory for a given vehicle owner. For example, an owner may have a preference for a specific brand of vehicle parts. Accordingly the system <NUM> can notify the user of the part purchase as it is automatically scheduled.

As shown in <FIG>, the electronic device may be communicably linked to a technician <NUM>. Alongside the user of the electronic device, the technician can also be notified over the network <NUM> of any determined vehicle information, scheduled maintenance, parts purchased, location of maintenance etc. Based on the user selection the user can be connected to a technician <NUM> via the network <NUM>. This connection could be by way of a telephone call, wherein the system <NUM> communicates a phone number over the network for the electronic device. Alternatively, the system <NUM> may use a Voice Over IP (VoIP) connection between the user and the technician. According to other embodiments, the communication between user and technician established could be a video call, wherein the technician is able to view a feed coming from a camera module within the user's electronic device.

According to the embodiments disclosed in <FIG>, the system <NUM> may determine that the vehicle has a critical malfunction. This could be determined through information captured form the onboard computer's internal sensor network or through data captured via the electronic device. For example, the vehicle track may have been damaged to the point where further driving would cause greater permanent damage to the vehicle and may endanger the safety of the driver. Using the communication link between the electronic device and the vehicle, the system <NUM> can instruct the electronic device to prompt a user with a notification of the critical malfunction and request instruction for whether or not the vehicle should be allowed to continue to operate. Based on this decision, the electronic device can instruct an onboard computer in the vehicle that the vehicle should not be operated again until the system <NUM> has determined the vehicle is no longer in a critical malfunction state.

According to another embodiment and shown in <FIG>, the electronic device may offer the user a choice to immediately disable the vehicle. Based on this decision, the electronic device can instruct an onboard computer in the vehicle that the vehicle should not be operated again until the system <NUM> has determined that the vehicle, track system and/or track is no longer in a critical state.

According to another embodiment and shown in <FIG>, the electronic device may not offer the user a choice and immediately disable the vehicle. Based on this decision, the electronic device can instruct an onboard computer in the vehicle that the vehicle should not be operated again until the system <NUM> has determined the vehicle, track system and/or track is no longer in a critical state.

According to yet another embodiment and shown in <FIG>, the electronic device may not offer the user a choice and may disable the vehicle once the vehicle has been returned to a specific location. This can be done by using a location coordinate determined by either the electronic device <NUM> or in the vehicle itself. While the vehicle may be continued to be used to complete the current job, when the location coordinate of the vehicle is determined to be the same as a specific location such as a storage facility, the electronic device can instruct an onboard computer in the vehicle that the vehicle should not be operated again until the system <NUM> has determined that the vehicle, track system and/or track is no longer in a critical state.

In some embodiments, with additional reference to <FIG>, in addition to or instead of the electronic device <NUM>, the system server <NUM> may receive image data from an inspection station for inspecting vehicles such as the vehicle <NUM> when they are in proximity.

For example, in some embodiments, as shown in <FIG>, the system <NUM> may include a imaging inspection station <NUM> for inspecting track systems of vehicles <NUM>x. In some embodiments, the imaging inspection station <NUM> comprises camera systems <NUM>x arranged to capture images of each of the track system <NUM><NUM>, <NUM><NUM> and their environment. The captured images can then be optionally processed and analyzed locally or remotely in system <NUM>. The camera systems <NUM>x can include directional cameras having any configuration of lenses suitable for inspecting the system <NUM><NUM>, <NUM><NUM> and their environment.

In other embodiments, with additional reference to <FIG>, the system server <NUM> may receive image data from a scanning inspection station <NUM> for inspecting track systems of vehicles <NUM>x. In some embodiments, the inspection station <NUM> comprises laser line scanner and/or laser area scanner systems <NUM>x arranged to scan each of the track system <NUM><NUM>, <NUM><NUM> and their environment as each vehicle <NUM>x moves past the inspection station <NUM>. The information generated by the laser line scanner and/or laser area scanner systems <NUM>x can then be optionally processed and analyzed locally or remotely by system server <NUM>. This embodiment is particularly advantageous for producing 3D scanning data suitable for subsequent volumetric analysis, as described in more detail above.

In some embodiments, with additional reference to <FIG> and <FIG>, the system server <NUM> may receive image data from a drone <NUM> for inspecting the track <NUM> and/or other components of each of the track systems <NUM><NUM>, <NUM><NUM> and/or their environment (e.g., detecting the presence of debris, etc.), so that information derived from the drone <NUM> may be relayed to the operator of the vehicle <NUM> and/or another remote device or person. The vehicle <NUM> may comprise a drone mount <NUM> configured to mount the drone <NUM> to the vehicle <NUM> and release the drone <NUM> when the drone <NUM> is to monitor the vehicle <NUM> by moving around it.

In some embodiments, the drone <NUM> is arranged to follow the vehicle, capture and analyze images of each of the track system <NUM><NUM>, <NUM><NUM> and their environment. In other embodiments, the drone <NUM> is equipped with a laser line scanner for scanning the track system <NUM><NUM>, <NUM><NUM> and their environment. Communication between the drone <NUM> and the vehicle <NUM> (e.g., between the drone <NUM> and the processing entity <NUM>) can be provided for by any suitable means, including but not limited to any combination of Global Positioning System (GPS) signals, Radio Frequency (RF) signals, Bluetooth signals, LIDAR, and RADAR signals. This embodiment is particularly advantageous for producing 3D scanning data suitable for subsequent volumetric analysis, as described in more detail above.

In this embodiment, the drone <NUM> is an aerial drone configured to fly about the vehicle <NUM>. While the drone <NUM> shown in <FIG> is a multi-rotor flying drone, other drones are possible, including but not limited to fixed-wing drones, or any other type of unmanned aerial vehicle. Also, in other embodiments, the drone <NUM> may be a land drone configured to travel on the ground about the vehicle <NUM> (e.g., on wheels or on tracks).

In some embodiments, with additional reference to <FIG>, in addition to or instead of the electronic device <NUM>, the system server <NUM> may receive image data from a vehicle-mounted inspection device <NUM> for inspecting the track systems <NUM><NUM>, <NUM><NUM> of the vehicle <NUM>. In particular, the system <NUM> may include one or more vehicle-mounted inspection device <NUM> for inspecting track systems <NUM><NUM>, <NUM><NUM> of vehicles by way of image data. In some embodiments, each track system <NUM><NUM> and <NUM><NUM> is provided with a vehicle-mounted inspection device <NUM>.

In some embodiments, the vehicle-mounted inspection device <NUM> comprises a camera system arranged to capture images of the track system <NUM><NUM>, <NUM><NUM> and its environment as the track <NUM> moves around the track-engaging assembly <NUM>. The information generated by the camera system can then be optionally processed and analyzed locally or remotely by the system server <NUM>.

In some embodiments, the vehicle-mounted inspection device <NUM> comprises a laser line scanner system and/or a laser area scanner system arranged to scan the track system <NUM><NUM>, <NUM><NUM> and its environment as the track <NUM> move around the track-engaging assembly <NUM>. The information generated by the laser line scanner and/or laser area scanner systems can then be optionally processed and analyzed locally or remotely by system server <NUM>. This embodiment is particularly advantageous for producing 3D scanning data suitable for subsequent volumetric analysis, as described in more detail above.

In some embodiments, as shown in <FIG>, a given component mentioned herein (e.g., the electronic device <NUM>, the image processing entity <NUM>, the server <NUM>, etc.) may comprise a computing system <NUM> comprising suitable hardware and/or software (e.g., firmware) configured to implement functionality of that given component. The computing system <NUM> comprises an interface <NUM>, a processor <NUM>, and a memory <NUM>.

The interface <NUM> comprises one or more inputs and outputs allowing the computing system <NUM> to receive signals from and send signals to other components to which the computing system <NUM> is connected (i.e., directly or indirectly connected).

The processor <NUM> comprises one or more processing devices for performing processing operations that implement functionality of the computing system <NUM>. A processing device of the processor <NUM> may be a general-purpose processor executing program code stored in the memory <NUM>. Alternatively, a processing device of the processor <NUM> may be a specific-purpose processor comprising one or more preprogrammed hardware or firmware elements (e.g., application-specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), etc.) or other related elements).

The memory <NUM> comprises one or more memory elements for storing program code executed by the processor <NUM> and/or data used during operation of the processor <NUM>. A memory element of the memory portion <NUM> may be a semiconductor medium (including, e.g., a solid state memory), a magnetic storage medium, an optical storage medium, and/or any other suitable type of memory element. A memory element of the memory portion <NUM> may be read-only memory (ROM) and/or random-access memory (RAM), for example.

In some embodiments, two or more elements of the computing system <NUM> may be implemented by devices that are physically distinct from one another (e.g., located in a common site or in remote sites) and may be connected to one another via a bus (e.g., one or more electrical conductors or any other suitable bus) or via a communication link which may be wired, wireless, or both and which may traverse one or more networks (e.g., the Internet or any other computer network such as a local-area network (LAN) or wide-area network (WAN), a cellular network, etc.). In other embodiments, two or more elements of the computing system <NUM> may be implemented by a single device.

While in embodiments considered above the off-road vehicle <NUM> is a construction or agricultural vehicle, in other embodiments, the vehicle <NUM> may be another type of work vehicle such as a knuckleboom loader, etc.) for performing forestry work, or a military vehicle (e.g., a combat engineering vehicle (CEV), etc.) for performing military work, a carrier (e.g. carrying a boom, a rig, and/or other equipment t), or may be any other type of vehicle operable off paved road. Although operable off paved roads, the vehicle <NUM> may also be operable on paved roads in some cases. Also, while in embodiments considered above the off-road vehicle <NUM> is driven by a human operator in the vehicle <NUM>, in other embodiments, the vehicle <NUM> may be an unmanned ground vehicle (e.g., a teleoperated or autonomous unmanned ground vehicle).

Any feature of any embodiment discussed herein may be combined with any feature of any other embodiment discussed herein in some examples of implementation.

Certain additional elements that may be needed for operation of certain embodiments have not been described or illustrated as they are assumed to be within the purview of those of ordinary skill in the art. Moreover, certain embodiments may be free of, may lack and/or may function without any element that is not specifically disclosed herein.

Claim 1:
A system (<NUM>) for monitoring a track (<NUM>) for traction of a vehicle (<NUM>) on a ground, the track being mounted around a plurality of wheels (<NUM>, <NUM><NUM>-<NUM><NUM>), the track comprising a ground-engaging outer surface (<NUM>) configured to engage the ground and an inner surface (<NUM>) opposite to the ground-engaging outer surface (<NUM>), the track (<NUM>) including elastomeric material (<NUM>) to flex around the wheels, the system comprising:
an interface (<NUM>, <NUM>, <NUM>) configured to receive data regarding at least one image of the track; and
a processor (<NUM>, <NUM>, <NUM>) configured to:
perform a two-dimensional (2D) image analysis based on the data regarding the at least one image of the track to obtain a result of the 2D image analysis, wherein the result of the 2D image analysis is an indication of a defect of the track that comprises a crack in the track;
create a three-dimensional (3D) model of the track based on the data regarding the at least one image of the track; and
generate information on a state of the track based on at least one of the result of the 2D image analysis and the 3D model of the track.