Patent Description:
There are a wide variety of different types of mobile work machines such as agricultural vehicles and construction vehicles. Some vehicles include harvesters, such as forage harvesters, sugar cane harvesters, combine harvesters, and other harvesters, that harvest grain or other crop. Such harvesters often unload into carts which may be pulled by tractors or semi-trailers as the harvesters are moving. Some construction vehicles include vehicles that remove asphalt or other similar materials. Such machines can include cold planers, asphalt mills, asphalt grinders, etc. Such construction vehicles often unload material into a receiving vehicle, such as a dump truck or other vehicle with a receiving vessel.

As one example, while harvesting in a field using a forage harvester, an operator attempts to control the forage harvester to maintain harvesting efficiency, during many different types of conditions. The soil conditions, crop conditions, and other things can all change. This may result in the operator changing control settings. This means that the operator needs to devote a relatively large amount of attention to controlling the forage harvester.

At the same time, a semi-truck or tractor-pulled cart is often in position relative to the forage harvester (e.g., behind the forage harvester or alongside the forage harvester) so that the forage harvester can fill the truck or cart while moving through the field. In some current systems, this requires the operator of the forage harvester to control the position of the unloading spout and flap so that the truck or cart is filled evenly, but not overfilled. Even a momentary misalignment between the spout and the truck or cart may result in hundreds of pounds of harvested material being dumped on the ground, or elsewhere, rather than in the truck or cart.

The receiving vehicle often has more freedom to move relative to the harvester than the harvester has to slow down or speed up due to crop unloading. Thus, some operators of the receiving vehicle currently attempt to adjust to the harvester so that the receiving vehicles are filled evenly, but not overfilled.

Other harvesters such as combine harvesters and sugar cane harvesters, can have similar difficulties. Also, construction vehicles can be difficult to operate while attempting to maintain alignment with a receiving vehicle.

<CIT> describes a counting system for counting the number of actuations of a dump truck loading container to record the number of payloads that have been transported with the dump truck.

Reference is made to the prior art described in <CIT> and <CIT> in both of which the fill state of a receiving vehicle is determined by sensing the amount of material loaded onto the vehicle with a throughput sensor on the loading vehicle.

The discussion proceeds with respect to a material loading vehicle being an agricultural harvester, but it will be appreciated that the present discussion is also applicable to material loading systems in which the material loading vehicle is a construction machines or other material loading vehicle as well, such as those discussed elsewhere herein. As discussed above, it can be very difficult for an operator to maintain high efficiency in controlling a harvester, and also to optimally monitor the position of the receiving vehicle. This difficulty can even be exacerbated when the receiving vehicle is located behind the forage harvester, so that the forage harvester is executing a rear unloading operation, but the difficulty also exists in side-by-side unloading scenarios.

It may also be desirable to count the number of times each receiving vehicle has been loaded during a harvesting operation over a load count window. The load count window may be a field, a day, a shift, etc. The number of loads for each receiving vehicle can be used, for example, to know the amount of material that was hauled. However, because both the operator of the receiving vehicle and the operator of the harvester are preoccupied with the harvesting operation, itself, and with performing the positioning of the vehicles and filling mechanisms, it can be difficult and cumbersome for the operators to maintain an accurate count of the number of times that each different receiving vehicle has been filled. Similarly, there may be multiple harvesters operating in a single field and a receiving vehicle may be filled by both of those harvesters during a given harvesting operation. This can make it even more difficult to the track the number of times that a receiving vehicle was filled.

In addition, the weight of the material in each load in a receiving vehicle may also be important. The various individuals involved in the harvesting operation may be compensated based upon the tonnage of material that is hauled by the receiving vehicles. Further, some of the receiving vehicles may have weight limits that are either placed on them by the manufacturer of the receiving vehicle, or by the owners of the receiving vehicle. By way of example, the owner of a receiving vehicle may not wish to overload the receiving vehicle in order to reduce wear on the receiving vehicle. Similarly, there may be weight restrictions on the roads over which the receiving vehicle travels from the harvester to a destination where the receiving vehicle is unloaded. For instance, in the United States, depending upon the particular state and federal laws, many receiving vehicles may not exceed <NUM>-<NUM> tons when traveling on highways. Exceeding this weight limit can result in large fines.

However, the operators of the harvester and the receiving vehicle may not always know the weight of the material that is in the receiving vehicle. This is because the harvesting operation may take place at a location that is a long distance from a scale. Thus, it is not uncommon for a receiving vehicle to be weighed once each day, and then have that weight be assumed for subsequent loads in the receiving vehicle, during the harvesting operation. This, of course, is inaccurate. Over the day, the crop conditions (e.g., moisture conditions) can change especially in hot or windy weather. Therefore, the weight of each load in a receiving vehicle, even though the volume of the material in the receiving vehicle is the same, may vary significantly.

Also, even if the crop conditions do not change during the day, the operator of the harvester must remember the fill level to which the receiving vehicle was filled, when it was weighed, in order to repeatably fill the receiving vehicle to that fill level, so that the weight is accurate. Again, this can be difficult because the operator of the harvester often fills multiple different receiving vehicles, different types of receiving vehicles, different sizes of receiving vehicles, etc. Because the operators of the harvester and receiving vehicle do not know the weight of material in the receiving vehicle, they can tend to underfill the receiving vehicle to ensure that the weight restrictions (either on the receiving vehicle or on the roads over which they travel, or other restrictions) are not exceeded. This can result in the receiving vehicles being underfilled and underweight, which reduces the efficiency of the harvesting operation.

In order to assist the operator of the harvester, some automatic cart filling control systems have been developed to automate portions of the filling process. One such automatic fill control system uses an image capture device, such as a stereo camera, on the spout of the harvester to capture an image (a static image or video image) of the receiving vehicle. An image processing system determines dimensions of the receiving vehicle and the distribution of the crop deposited inside the receiving vehicle. The system also detects crop height (or fill level) within the receiving vehicle, in order to automatically aim the spout toward empty spots and control the flap position to achieve a more even fill, while reducing spillage. Such systems can fill the receiving vehicle according to a fill strategy (such as front-to-back, back-to-front, etc.) that is set by the operator or that is set in other ways.

In addition, some current harvesters are provided with a machine synchronization control system. The harvester may be a combine harvester so that the spout is not movable relative to the frame of the harvester during normal unloading operations. Instead, the relative position of the receiving vehicle and the combine harvester is changed in order to fill the receiving vehicle as desired. Thus, in a front-to-back fill strategy, for instance, the position of the receiving vehicle, relative to the combine harvester, is changed so that the spout is first filling the receiving vehicle at the front end, and then gradually fills the receiving vehicle moving rearward. In such an example, the combine harvester and receiving vehicle may have machine synchronization systems which communicate with one another. When the relative position of the two vehicles is to change, the machine synchronization system on the combine harvester can send a message to the machine synchronization system on the towing vehicle to nudge the towing vehicle slightly forward or rearward relative to the combine harvester, as desired. By way of example, the machine synchronization system on the combine harvester may receive a signal from the fill control system on the combine harvester indicating that the position in the receiving vehicle that is currently being filled is approaching its desired fill level. In that case, the machine synchronization system on the combine harvester can send a "nudge" signal to the machine synchronization system on the towing vehicle. The "nudge", once received by the machine synchronization system on the towing vehicle, causes the towing vehicle to momentarily speed up or slow down, thus nudging the position of the receiving vehicle forward to rearward, respectively, relative to the combine harvester.

However, these types of systems do not assist the operator in counting the number of times a particular receiving vehicle was filled or in accurately estimating the weight of material in the receiving vehicle. Thus, these types of systems can still result in the receiving vehicles being underfilled or overfilled (so that they exceed the desired weight limits).

The present discussion thus proceeds with respect to a system which can use a camera or other sensor on the harvester, along with associated image processing functionality, to identify a receiving vehicle (or a type of receiving vehicle) that is being filled by the harvester. Once the identity of the receiving vehicle is known, then when it is full, a set of fill data can be generated for the receiving vehicle. The fill data can include a count of the number of times the receiving vehicle has been filled during the current load count window (e.g., during the current harvesting operation, during the current day, during the current shift, in the current field, etc.). The fill data also include the fill level of the receiving vehicle for each. The fill data include the estimated or measured weight in the receiving vehicle as well. The fill data for the receiving vehicle can then be transmitted to another system where it can be used in various ways.

In another example, the present description also proceeds with respect to a system that not only identifies the receiving vehicle and the fill level of the receiving vehicle, but also generates or uses a model that represents a correlation between the receiving vehicle and its fill level, and a weight of material in the receiving vehicle. For instance, in one example, the receiving vehicle can be identified and filled. The receiving vehicle can then be taken to a scale and weighed and a weight value indicative of the weight of material in the receiving vehicle can be sent to the harvester (or the other system) using a mobile device or in other ways. A model generator can then generate a correlation that can be used to estimate the weight of material, given the identity of the receiving vehicle and its fill level. Therefore, during subsequent operations when that same receiving vehicle is identified and its fill level is known, the system can access the correlation to also estimate the weight of material in the receiving vehicle. The system can also consider other parameters to increase the accuracy of the estimated weight, such as the sensed crop moisture or other parameters or crop attributes.

<FIG> is a pictorial illustration showing one example of a self-propelled forage harvester <NUM> (a material loading vehicle) filling a tractor-pulled grain cart (or receiving vehicle) <NUM>. Cart <NUM> thus defines an interior that forms a receiving vessel <NUM> for receiving harvested material through a receiving area <NUM>. In the example shown in <FIG>, a towing vehicle (e.g., a tractor) <NUM>, that is pulling grain cart <NUM>, is positioned directly behind forage harvester <NUM> and has a mobile device <NUM> which may be a smart phone, tablet computer, etc. either mounted in the operator compartment of tractor <NUM>, or carried by the operator of tractor <NUM>. Also, in the example illustrated in <FIG>, forage harvester <NUM> has a camera <NUM> mounted on the spout <NUM> through which the harvested material <NUM> is traveling. The spout <NUM> can be pivotally or rotationally mounted to a frame <NUM> of harvester <NUM>. Camera <NUM> can be a stereo-camera or a mono-camera that captures an image (e.g., a still image or video) of the receiving area <NUM> of cart <NUM>. In the example shown in <FIG>, the receiving area <NUM> is defined by an upper edge of the walls of cart <NUM>.

When harvester <NUM> has an automatic fill control system that includes image processing, as discussed above, the automatic fill control system can gauge the height of harvested material in cart <NUM>, and the location of that material. The system thus automatically controls the position of spout <NUM> and flap <NUM> to direct the trajectory of material <NUM> into the receiving area <NUM> of cart <NUM> to obtain an even fill throughout the entire length and width of cart <NUM>, while not overfilling cart <NUM>. By automatically, it is meant, for example, that the operation is performed without further human involvement except, perhaps, to initiate or authorize the operation.

For example, when executing a back-to-front automatic fill strategy the automatic fill control system may attempt to move the spout and flap so the material begins landing at a first landing point in the back of vessel <NUM>. Then, once a desired fill level is reached in the back of vessel <NUM>, the automatic fill control system moves the spout and flap so the material begins landing just forward of the first landing point in vessel <NUM>. This continues until the vessel <NUM> reaches a desired fill level.

It can be seen in the example of <FIG> that the camera <NUM> can capture an image of a portion of the cart <NUM>. For instance, it can capture an image of the forward portion <NUM> of cart <NUM>. Thus, in one example, optical or visual features of that forward portion <NUM> of cart <NUM> can be used by an image processor to uniquely identify cart <NUM>, or to identify the type of the cart <NUM>. A unique cart identifier, or type identifier, can be used to automatically identify a weight limit for cart <NUM> which may be set manually or downloaded from a manufacturer database or obtained in other ways. In addition, a correlation can be generated for cart <NUM> so that the weight of material in cart <NUM> can be estimated using the correlation and the current fill level of material in cart <NUM>. In this way, fill data can be automatically generated for cart <NUM> that identifies the number of times cart <NUM> is filled, as well as the fill level and weight of each fill. Additional sensor data can also be used in generating the correlation and/or estimating the weight, such as crop moisture, and/or other attributes or parameters. This fill data can be automatically generated without the operator needing to interact with the automatic cart filling control system to input settings corresponding to the cart <NUM>. Also, the operator can be alerted, or the filling operation can be automatically controlled, when the weight of material in the cart <NUM> approaches or meets the weight limit or restriction corresponding to cart <NUM>.

<FIG> is a pictorial illustration showing another example of a self-propelled forage harvester <NUM>, this time loading a semi-trailer (or receiving vessel on a receiving vehicle) <NUM> in a configuration in which a semi-tractor (that also has a mobile device <NUM>) is pulling semi-trailer <NUM> alongside forage harvester <NUM>. Therefore, the spout <NUM> and flap <NUM> are positioned to unload the harvested material <NUM> to fill trailer <NUM> according to a predefined side-by-side fill strategy. Again, <FIG> shows that camera <NUM> can capture an image (which can include a still image or video) of semi-trailer <NUM>. In the example illustrated in <FIG>, the field of view of camera <NUM> is directed toward the receiving area <NUM> of trailer <NUM> so that image processing can be performed to identify a landing point for the harvested material in trailer <NUM> and the height of material in trailer <NUM>. An automatic fill control system can thus control spout <NUM> and flap <NUM> to fill trailer <NUM> as desired.

Also, in the example shown in <FIG>, it can be seen that camera <NUM> can be positioned to have a field of view that captures an image of a side portion <NUM> of trailer <NUM>. Thus, the visual or optical features of the side portion <NUM> of trailer <NUM> can be used to uniquely identify trailer <NUM>, or at least to identify the type of the trailer <NUM>. Based on the unique trailer identifier or the type identifier, the settings values for the automatic cart filling control system can be obtained so that the cart is filled in a cart-specific way or in a cart type-specific way, depending upon whether the cart is uniquely identified or the cart type is identified. For example, once the cart or cart type is identified, the fill data can be generated by automatically counting the number of times the particular trailer <NUM> has been filled, the fill level of each fill and the actual or estimated weight of each fill. A correlation for this trailer or trailer type can be accessed so that once the trailer is identified and the fill level is detected the weight of the material in the trailer can be estimated. The correlation can account for other sensed attributes, such as crop moisture or other attributes.

In other examples, where machine <NUM> is a combine harvester, it may be that the spout <NUM> is not moved relative to the frame during normal unloading operations. Instead, the relative position of the receiving vehicle <NUM>, <NUM> and the combine harvester is changed in order to fill the receiving vehicle <NUM>, <NUM> as desired. Thus, if a front-to-back fill strategy is to be employed, then the relative position of the receiving vessel, relative to the combine harvester, is changed so that the spout is first filling the receiving vessel at the front end, and then gradually fills the receiving vessel moving rearward. This is just one example.

<FIG> is a pictorial illustration showing one example of an operator interface display <NUM> that can be displayed on a display mechanism <NUM>, for the operator in an operator compartment of forage harvester <NUM>. The display (or portion of it) can also be sent to the mobile device <NUM> for use by the operator of the receiving vehicle or towing vehicle (tractor <NUM> or the semi-tractor). The operator interface display <NUM> in <FIG> shows a view of images (static or video) captured by camera <NUM>. The image(s) show material <NUM> entering trailer <NUM>. An image processing system on harvester <NUM> illustratively identifies the perimeter of the opening <NUM> in trailer <NUM> and also processes the image of the material <NUM> in trailer <NUM> to determine the fill height relative to opening <NUM>. The perimeter-defining opening <NUM> can be visually enhanced by overlaying a visual overlay over the opening <NUM> so that the operator can easily identify the opening <NUM>, as it is being recognized by the image processing system.

It should also be noted that, in an example, in which forage harvester <NUM> has an automatic fill control system (or active fill control system) which fills trailer <NUM> according to a fill strategy (such as a back-to-front fill strategy, front-to-back fill strategy, etc.), a current location indicator (such as indicator <NUM>) may be displayed to show the current location where material <NUM> is being loaded into trailer <NUM> through spout <NUM> and the direction that spout <NUM> is, or should be, moving relative to trailer <NUM> as the filling operation continues. It can be seen in <FIG>, for instance, that indicator <NUM> is an arrow pointing in the front-to-back direction. The location of arrow <NUM> on the representation of trailer <NUM> indicates the current fill position, while the direction of the arrow <NUM> indicates the direction that spout <NUM> will be moved relative to trailer <NUM> in executing the selected front-to-back fill strategy.

<FIG> is a block diagram of one example of a material loading system <NUM>. Material loading system <NUM> includes (as a material loading vehicle) harvester <NUM> that can be operated by an operator <NUM>. <FIG> also shows that harvester <NUM> can be connected over network <NUM> to receiving/towing vehicle <NUM> (which may be a semi-tractor and trailer <NUM>, tractor <NUM> and cart <NUM>, or another receiving/towing vehicle). Receiving/towing vehicle <NUM> can include mobile device <NUM> or other items <NUM> and can be operated by an operator <NUM>. <FIG> also shows that harvester <NUM> can be connected over network <NUM> to other remote systems or vehicles <NUM> that are located remotely from harvester <NUM> (such as in the same field, in a different field, or at another location). In some examples, other remote systems or vehicles <NUM> can be operated by an operator or user <NUM>. For instance, where a remote system or vehicle <NUM> is a farm manager computing system, then the remote user <NUM> may be a farm manager. Where the remote system of vehicle <NUM> is another harvester, then operator <NUM> may be the operator of that harvester. These are examples only and other remote systems/vehicles <NUM> and operators/users <NUM> can be employed in system <NUM>.

Network <NUM> can be any of a wide variety of different types of networks, depending upon the type of communication that is desired. For instance, network <NUM> can be wide area network, a local area network, a near field communication network, a WIFI network, a cellular network, a Bluetooth network, or any of a wide variety of other networks or combinations of networks.

In the example shown in <FIG>, harvester <NUM> illustratively includes one or more processors or servers <NUM>, communication system <NUM>, data store <NUM>, sensors <NUM>, operator interface mechanisms <NUM>, receiving vehicle identification system <NUM>, fill control system <NUM>, model training system <NUM>, controllable subsystems <NUM>, fill data generation system <NUM>, and other harvester functionality <NUM>.

Data store <NUM>, itself, can include one or more receiving vehicle-to-weight limit mappings <NUM>. Mappings <NUM> map a unique cart or semi-trailer or other receiving vehicle, or a cart type to a corresponding weight limit. The weight limit can be downloaded from a remote system (such as a manufacturer's website), or the weight limit can be input by operator <NUM> or the operator <NUM> of the receiving/towing vehicle <NUM>, or it can be input in other ways.

Data store <NUM> can also include receiving vehicle weight estimation models <NUM>. Models <NUM>, in one example, receive a fill level corresponding to a receiving vehicle and generate an estimated weight value indicative of the weight of the material in that receiving vehicle, based on the identity of the receiving vehicle and based on the fill level. The estimated weight value may be the estimated combined weight of the receiving vehicle and the material in the receiving vehicle and/or the estimated weight of just the material in the receiving vehicle. Models <NUM> can also account for other crop characteristics or attributes, such as moisture level, or other attributes. Also, as described elsewhere, models <NUM> can instead be equations or mappings or other types of items that indicate a correlation between the fill level of a particular receiving vehicle or type of receiving vehicle and the weight of the material in that receiving vehicle.

Data store <NUM> can also include receiving vehicle fill data <NUM>. Fill data <NUM> is illustratively a set of fill data records where each data record corresponds to a particular receiving vehicle or type of receiving vehicle. Therefore, fill data <NUM> can include fill count <NUM> which indicates the number of times that the corresponding receiving vehicle or type of receiving vehicle has been filled for a particular load count window (e.g., for a harvesting operation, for a day, for a shift, for a field, etc.). Weights <NUM> identify the actual or estimated weights for each fill and time stamps <NUM> are generated to indicate the time when the receiving vehicle was filled. Data <NUM> can also include fill level per load data <NUM> which indicates how full the receiving vehicle was filled during each fill. Data <NUM> can include a wide variety of other data <NUM> as well. Data store <NUM> can also include other items <NUM>.

Sensors <NUM> can include camera <NUM>, moisture sensor <NUM>, position sensor <NUM>, receiving vehicle location sensor <NUM>, and other sensors <NUM>. Moisture sensor <NUM> illustratively senses the moisture level of the harvested crop. Position sensor <NUM> is illustratively a sensor that provides the geographic location of harvester <NUM> within a global or local coordinate system. Therefore, position sensor <NUM> can be a global positioning system (GPS) receiver, another type of global navigation satellite system (GNSS) receiver, a dead reckoning sensor, a cellular triangulation sensor, or any of a wide variety of other position sensors. Receiving vehicle location sensor <NUM> illustratively senses the location of receiving vehicle <NUM>. For instance, sensor <NUM> may be a RADAR sensor, a LIDAR sensor, an optical sensor, or another sensor that identifies the position of the receiving vehicle <NUM> relative to harvester <NUM>.

Operator interface mechanisms <NUM> can include a wide variety of different types of mechanisms. For instance, mechanisms <NUM> can include a steering wheel, joysticks, pedals, levers, linkages, buttons, switches, etc. In addition, mechanisms <NUM> can include mechanisms that provide outputs to operator <NUM> and receive inputs from operator <NUM>. Therefore, mechanisms <NUM> can include a display screen that displays actuators that can be actuated by operator <NUM> using a touch gesture, a point and click device, or other mechanisms. Similarly, mechanisms <NUM> can include a microphone and speaker where speech recognition and speech synthesis functionality (or other audio functionality) is provided. Mechanisms <NUM> can also include a wide variety of other audio, visual, and haptic mechanisms that can provide information to operator <NUM> and receive inputs from operator <NUM>.

Communication system <NUM> enables communication among the various items on harvester <NUM>, and over network <NUM>. Therefore, communication system <NUM> can include a controller area network - CAN bus control system, and other communication systems that enable communication over network <NUM>. Thus, the type of communication system <NUM> may depend on the type of networks <NUM> over which it is to communicate.

Receiving vehicle identification system <NUM> illustratively identifies the receiving vehicle (or the type or receiving vehicle) that harvester <NUM> is filling. Thus, system <NUM> includes unique receiving vehicle identifier <NUM>, receiving vehicle type identifier <NUM>, and other items <NUM>. Unique receiving vehicle identifier <NUM> uniquely identifies the receiving vehicle, whereas receiving vehicle type identifier <NUM> identifies the type of receiving vehicle, though not necessarily the unique receiving vehicle itself.

Identifiers <NUM> and <NUM> can be any of a wide variety of different types of identification systems that operate based on sensor inputs. For instance, where camera <NUM> captures one or more visual features or markers on the receiving vehicle <NUM> that is being filled, then identifiers <NUM> and <NUM> can include image processing systems that recognize the optical features or markers captured by the images from camera <NUM> and identify the receiving vehicle <NUM>, or the type of receiving vehicle, based upon those recognized optical features or markers. As one example, identifiers <NUM> and <NUM> may recognize the optical features or markers and access a library of visual features or markers (such as a library stored in data store <NUM> or elsewhere) to identify the particular receiving vehicle <NUM> or type of receiving vehicle based upon the recognized optical features or markers. Where a corresponding entry does not exist in the library, then receiving vehicle identification system <NUM> can recognize that the receiving vehicle <NUM> is one that has not been encountered before and for which no library entry exists. In that case, receiving vehicle identifications system <NUM> can create an entry corresponding to this set of recognized optical features or markers, so that this receiving vehicle <NUM> can be identified in the future.

Identifiers <NUM> and <NUM> can identify the receiving vehicle <NUM> in other ways as well. For instance, it may be that the receiving vehicle <NUM> has a transmitter that transmits its identity, during operation. In that case, a sensor <NUM> may sense the transmission and provide a signal indicative of the identity of the receiving vehicle <NUM> to receiving vehicle identification system <NUM>. These and other mechanisms for identifying the receiving vehicle <NUM> can be used as well.

Fill control system <NUM> can be used to illustratively control the position of spout <NUM> and/or flap <NUM> relative to the receiving vessel in the receiving vehicle <NUM> to control the filling operation. Fill control system <NUM> may be an automated fill control system (or active fill control system) which automatically controls the position of the spout <NUM> and flap <NUM> relative to the receiving vehicle <NUM> to fill the receiving vehicle <NUM> according to a predefined fill strategy (such as back-to-front, front-to-back, etc.). In another example, fill control system <NUM> may be a machine synchronization control system which sends control signals to the towing vehicle to change the relative position of the towing vehicle, relative to the harvester <NUM> in order to fill the receiving vessel in the receiving vehicle <NUM> as desired. Fill control system <NUM> may be a manually operated system in which operator <NUM> manually controls the position of the spout <NUM> and flap <NUM> relative to the receiving vehicle <NUM> in order to fill the receiving vehicle <NUM> according to a desired fill strategy.

For purposes of the present discussion, it will be assumed that fill control system <NUM> receives one or more images (static images or video) from camera <NUM> and automatically detects the fill level of material in the receiving vehicle <NUM> and may then estimate the weight of the material in the receiving vehicle <NUM> and can generate an output indicative of that weight. The output can be a control signal that automatically controls the fill operation when the weight approaches a weight limit for the receiving vehicle <NUM>, or the output can be a control signal to control and operator interface mechanism <NUM> to alert the operator. These and other features are contemplated herein.

For purposes of the present discussion, fill control system <NUM> includes fill level detection system <NUM>, model accessing system <NUM>, weight generation system <NUM>, weight limit comparison system <NUM>, control signal generator <NUM> and other fill control system functionality <NUM>. Fill level detection system <NUM> can be an image processor that detects the height of the material <NUM> in the receiving vehicle <NUM> to thus detect the fill level of material in the receiving vehicle <NUM>. System <NUM> provides an output indicative of the detected fill level. Model accessing system <NUM> receives an input from receiving vehicle identification system <NUM> identifying the receiving vehicle <NUM> that is being filled. Model accessing system <NUM> then accesses the receiving vehicle weight estimation model <NUM> (or other correlation) corresponding to the identified receiving vehicle <NUM>. Weight generation system <NUM> then uses the model <NUM> for the identified receiving vehicle <NUM>, along with the fill level output by fill level detection system <NUM> to generate an estimate of the weight of material in the receiving vehicle <NUM>. It will be noted that weight generation system <NUM> can also obtain the crop moisture from moisture sensor <NUM> and use that as model input when estimating the weight of the material.

Weight limit comparison system <NUM> also receives an output from receiving vehicle identification system <NUM> indicating the identity of the receiving vehicle <NUM>. Weight limit comparison system <NUM> then accesses the receiving vehicle-to-weight limit mappings <NUM> to obtain a weight limit corresponding to the identified receiving vehicle <NUM>. System <NUM> compares the current weight of the material in the receiving vehicle <NUM> against the weight limit and provides an output indicative of that comparison. Control signal generator <NUM> generates control signals based upon the output of weight limit comparison system <NUM>. For instance, control signal generator <NUM> can generate control signals to control a display in operator interface mechanisms <NUM> to display the current weight of the material in the receiving vehicle <NUM>. Control signal generator <NUM> can also generate control signals to generate an alert as the current weight of material in the receiving vehicle <NUM> approaches the weight limit corresponding to the receiving vehicle <NUM>. Control signal generator <NUM> may also generate control signals to control one or more of the controllable subsystems <NUM> as well.

Controllable subsystems <NUM> can include a material conveyance subsystem <NUM> which may include such things as a blower, spout <NUM>, flap <NUM>, etc. that are used to convey the harvested material from harvester <NUM> to the receiving vehicle <NUM>. Controllable subsystems <NUM> can also include propulsion subsystem <NUM>, steering subsystems <NUM> and other controllable subsystems <NUM>. Therefore, when the weight of the material in the receiving vehicle <NUM> reaches or exceeds the weight limit corresponding to that receiving vehicle <NUM>, control signal generator <NUM> may generate control signals to control propulsion subsystem <NUM> to stop harvester <NUM>, and also to control material conveyance subsystems <NUM> to stop conveying additional material to the receiving vehicle <NUM>.

When a receiving vehicle <NUM> has been filled, or during the fill operation, fill data generation system <NUM> can generate fill data corresponding to that receiving vehicle <NUM>. Thus, system <NUM> can generate records and store them as receiving vehicle fill data <NUM> in data store <NUM>. System <NUM> can also control communication system <NUM> to send the fill data to other systems/vehicles <NUM> or other places over network <NUM>.

Fill data generation system <NUM> illustratively includes receiving vehicle ID generator <NUM>, load count generator <NUM>, fill level generator <NUM>, load weight generator <NUM>, time stamp generator <NUM>, output generator <NUM>, and other items <NUM>. Receiving vehicle ID generator creates a receiving vehicle ID entry in a fill data record and assigns or obtains an identifier for the receiving vehicle <NUM>. Load count generator <NUM> adjusts the load count corresponding to this receiving vehicle <NUM>. For instance, each time this receiving vehicle <NUM> is filled, load count generator <NUM> increments the load count to indicate an additional fill for this particular receiving vehicle <NUM>. Fill level generator <NUM> enters the fill level corresponding to this fill operation, for this receiving vehicle <NUM>, in the fill data, and load weight generator <NUM> generates an entry indicating the estimated or actual load weight for this fill. For instance, it may be that the receiving vehicle <NUM> is intermittently taken to a scale and weighed. In that case, the mobile device <NUM> on the receiving vehicle <NUM> (or one used by a scale operator) may be used by the operator of the receiving vehicle <NUM> to transmit the weight back to harvester <NUM> so that the actual weight can be recorded by load weight generator <NUM>. In another example, the load weight generator <NUM> generates an entry indicating the estimated load weight that is estimated by weight generation system <NUM>. Time stamp generator <NUM> generates an entry in the fill data indicative of the time when the fill was completed, and output generator <NUM> generates an output indicative of the fill data record that was just created for this receiving vehicle <NUM>, for this particular fill operation. Output generator <NUM> can generate control signals to control data store <NUM> to store the new fill data record as receiving vehicle fill data <NUM>. Output generator <NUM> can also generate control signals to control communication system <NUM> to output the fill data record over network <NUM> as well.

Model training system <NUM> can generate and update or train a model <NUM> for each unique receiving vehicle <NUM> or type of receiving vehicle. For instance, where a model <NUM> does not exist for a particular receiving vehicle <NUM>, or type of receiving vehicle, then model training system <NUM> receives an identifier from receiving vehicle identification system <NUM> and determines that no model exists for this particular receiving vehicle <NUM>. Model training system <NUM> then automatically creates or instantiates a model <NUM> and obtains the fill level from fill level detection system <NUM>, once the receiving vehicle <NUM> has been filled. Model training system <NUM> may then prompt operator <NUM> or operator <NUM> to indicate that an actual weight is needed in order to complete the generation of the model <NUM> for this particular receiving vehicle <NUM>, or type of receiving vehicle. Model training system <NUM> thus waits for an input indicative of the measured weight. Again, the actual weight can be received from a mobile device <NUM> once the receiving vehicle is weighed at a scale. The weight can be received from a scale operator through another mobile device or another computing system, or the model training system <NUM> can receive the actual weight that may be input by operator <NUM>, once operator <NUM> becomes aware of the actual weight of material in the receiving vehicle <NUM> (e.g., operator <NUM> may receive a communication from operator <NUM> or the scale operator, or another device or person indicating the actual measured weight).

Once the identity of the receiving vehicle <NUM> (or receiving vehicle type is received and) the fill level for that receiving vehicle <NUM> and the weight of that receiving vehicle (once filled) are also received, then model training system <NUM> can generate a model <NUM> or other correlation that correlates the fill level for this particular receiving vehicle <NUM> to a weight. Then, in the future, when this particular receiving vehicle <NUM> is seen (or identified by system <NUM>), the fill level can be obtained and the model <NUM> for this receiving vehicle <NUM> can be used to estimate the weight of the material in the receiving vehicle <NUM>.

It will also be noted that, in some examples, model training system <NUM> can train the model based on other criteria, such as crop moisture, or other sensed crop attributes. In addition, it may be that a receiving vehicle is weighed on a scale more than once during a harvesting operation. In that case, once a model has been initially trained for this receiving vehicle <NUM>, if any additional actual weights are measured for the receiving vehicle <NUM>, those weights can be provided to model training system <NUM>, along with the identity of the receiving vehicle and the fill level for which the weight was taken. Model training system <NUM> can then retrain or modify the model or correlation corresponding to that receiving vehicle <NUM> to include the second or subsequent actual weight measure. In this way, model training system <NUM> can improve the accuracy of the models <NUM> or correlations corresponding to the receiving vehicles, based upon actual data.

<FIG> is a flow diagram illustrating one example of the operation of harvester <NUM> in automatically identifying a receiving vehicle that is being filled, and automatically updating a fill count for that receiving vehicle.

It is first assumed that harvester <NUM> is filling a receiving vehicle <NUM>. For purposes of the present discussion, assume that harvester <NUM> is filling trailer <NUM>, that is being towed by tractor <NUM>. Having harvester <NUM> filling receiving vehicle <NUM> is indicated by block <NUM> in the flow diagram of <FIG>.

Receiving vehicle identification system <NUM> then automatically detects the identity of the receiving vehicle <NUM>, as indicated by block <NUM>. As discussed above, receiving vehicle identification system <NUM> can be an image processing system that processes images from camera <NUM> that show optical features or markers on trailer <NUM>. Identifying the receiving vehicle <NUM> using image processing is indicated by block <NUM> in the flow diagram of <FIG>. Unique receiving vehicle identifier <NUM> may uniquely identify the receiving vehicle <NUM>, as indicated by block <NUM>. Having receiving vehicle type identifier <NUM> identify the receiving vehicle type is indicated by block <NUM>. The receiving vehicle type may be a make and model of receiving vehicle <NUM>, the size of receiving vehicle <NUM>, or other type information. The receiving vehicle <NUM> can be automatically identified in other ways as well, as indicated by block <NUM>.

Fill level detection system <NUM> then detects the fill level in receiving vehicle <NUM> and determines whether a desired fill level is reached, as indicated by block <NUM> in the flow diagram of <FIG>. The desired fill level may be a default level, it may be set by an operator, downloaded or otherwise obtained for this specific receiving vehicle <NUM>, etc. Filling continues, as indicated by block <NUM>, until receiving vehicle <NUM> is filled to its desired level.

Once receiving vehicle <NUM> is filled to its desired level, fill data generation system <NUM> generates or adjusts the fill data for this receiving vehicle <NUM>, as indicated by block <NUM>. In one example, fill level generator <NUM> receives an indication of the fill level from fill level detection system <NUM> and stores that fill level in the fill data record being generated or adjusted by system <NUM>. Detecting and storing the fill level is indicated by block <NUM> in the flow diagram of <FIG>. Load count generator <NUM> increments to the number of times (the load count) that this particular receiving vehicle <NUM> has been filled. The total number of counts can be aggregated over a load count window, such as per day, per field, per harvesting operation, etc. Increasing the load count is indicated by block <NUM> in the flow diagram of <FIG>. Time stamp generator <NUM> generates a time stamp corresponding to the fill data, as indicated by block <NUM>. Other fill data can be generated as discussed in greater detail elsewhere, and as indicated by block <NUM> in the flow diagram of <FIG>.

Output generator <NUM> then outputs the fill data to other systems, as indicated by block <NUM>. Output generator <NUM> can generate control signals to provide the output to operator <NUM> through operator interface mechanisms <NUM>, as indicated by block <NUM>. Output generator <NUM> can generate control signals to control data store <NUM> to store the record as vehicle fill data <NUM>, as indicated by block <NUM> in the flow diagram of <FIG>. Output generator <NUM> can generate control signals to control communication system <NUM> to output the fill data to other systems, such as a towing vehicle <NUM>, or other remote systems and vehicles <NUM>, as indicated by block <NUM>. The fill data can be output in other ways as well, as indicated by block <NUM>.

<FIG> is a flow diagram illustrating one example of the operation of model training system <NUM> in generating and/or training a model corresponding to a particular receiving vehicle <NUM> or type of receiving vehicle. It is first assumed that an identified receiving vehicle <NUM> (which has been identified by receiving vehicle identification system <NUM>) is filled to a desired fill level as indicated by block <NUM>. Model training system <NUM> can also obtain or detect the receiving vehicle dimensions. For instance, once the receiving vehicle <NUM> is identified, the dimensional specifications for that vehicle <NUM> can be obtained from a manufacturer's website, or from data store <NUM> (if they have been previously downloaded), or they can be obtained from a manual input by operator <NUM>, or in other ways. Similarly, model training system <NUM> may include an image processing system that can calculate the dimensions of the receiving vehicle <NUM> based on images received from camera <NUM>, or in other ways. Obtaining and detecting the receiving vehicle dimensions is indicated by block <NUM> in the flow diagram of <FIG>.

Once the receiving vehicle <NUM> is filled, the fill level detected for this receiving vehicle <NUM> can then be stored either locally in model training system <NUM> or data store <NUM>, or remotely in a remote system <NUM>. Storing the fill level for this receiving vehicle <NUM> is indicated by block <NUM> in the flow diagram of <FIG>. Detecting that the current fill operation is complete (e.g., that the identified receiving vehicle is filled to a desired fill level) can involve other operations and be done in other ways as well, as indicated by block <NUM>.

In one example, when the model being generated by system <NUM> accounts for crop moisture, then model training system <NUM> obtains the detected crop moisture level corresponding to the material that is loaded into the receiving vehicle <NUM>. For instance, system <NUM> can receive an input from moisture sensor <NUM>. Detecting the moisture level is indicated by block <NUM> in the flow diagram of <FIG>. The moisture level can be the average detected moisture level during the fill operation so that the moisture level value represents the average moisture value of the material in the receiving vehicle <NUM>. Detecting the average moisture value is indicated by block <NUM> in the flow diagram of <FIG>. The moisture level can be detected in other ways as well, as indicated by block <NUM>.

Once the fill level for the receiving vehicle <NUM> has been detected, model training system <NUM> detects a weight value for this receiving vehicle <NUM>, indicative of the weight of the material in the receiving vehicle <NUM>. Detecting a weight value is indicated by block <NUM> in the flow diagram of <FIG>. The weight value can be measured on a scale and provided through a mobile application (such as a mobile application on a mobile device used by the scale operator, a mobile application on mobile device <NUM> used by the towing vehicle driver, etc.) as indicated by block <NUM>. Also, instead of receiving the measured weight value from a scale, the weight value used to train a model <NUM> for receiving vehicle <NUM> can be estimated. For instance, where the dimensions of the receiving vehicle <NUM> are obtained, then the weight value can be estimated based on the moisture level of the crop, the fill level, and the receiving vehicle dimensions. By way of example, if the receiving vehicle <NUM> dimensions are obtained, then the volume of the receiving vehicle <NUM> can be calculated. Using that volume and the fill level, the volume of material in the receiving vehicle can be calculated as well. Given the moisture level of the material, and some correlation between moisture level, volume and weight (which may be a default correlation), then the weight of the material in the receiving vehicle <NUM> can be estimated as well. Estimating the weight of the material based on the moisture level, the fill level, and the receiving vehicle dimensions is indicated by block <NUM>. The weight value can be detected and obtained in other ways as well, as indicated by block <NUM>.

If a model <NUM> for this receiving vehicle <NUM> already exists, as determined at block <NUM>, then model training system <NUM> performs machine learning to update or revise the model for the receiving vehicle <NUM> based upon the weight and the fill level, as indicated by block <NUM>. However, if, at block <NUM>, a model for the current receiving vehicle <NUM> does not already exist, then model training system <NUM> generates a function or other correlation to indicate the estimated weight of the material based upon the fill level for the receiving vehicle <NUM>, as indicated by block <NUM>. The function or correlation can be a predictive model, as indicated by block <NUM>, a classifier, as indicated by block <NUM>, or another type of function or correlation as indicated by block <NUM>. It will be noted that the function or correlation can also account for other attributes, such as crop moisture, etc..

Fill data generation system <NUM> also generates fill data, even while the model training system <NUM> is training or generating a model. Generating an output indicative of the fill data is indicated by block <NUM> in the flow diagram of <FIG>. The output can be provided to remote systems <NUM>, as indicated by block <NUM>, or stored locally, as indicated by block <NUM>. The output can include the load count for this receiving vehicle <NUM>, as indicated by block <NUM> as well as the weight for this particular load, as indicated by block <NUM>. The output can be provided through operator interface mechanisms <NUM>, as indicated by block <NUM>, or in other ways, as indicated by block <NUM>.

Model training system <NUM> then stores the model that it has just generated or revised, for this particular receiving vehicle <NUM> or type of receiving vehicle, as indicated by block <NUM>. Again, the model can be stored locally as an estimation model <NUM>, and as indicated by block <NUM> in the flow diagram of <FIG>. The model can be stored at a remote system <NUM>, as indicated by block <NUM>, or the model can be stored in other ways, as indicated by block <NUM>. The model can then be retrieved and used to estimate weight the next time the receiving vehicle <NUM> (or the same type of receiving vehicle) is being filled.

<FIG> and <FIG> (collectively referred to herein as <FIG>) show a flow diagram illustrating one example of the operation of harvester <NUM>, once it has a receiving vehicle weight estimation model <NUM> in place for a receiving vehicle <NUM> that is receiving material from harvester <NUM>. It is thus assumed that harvester <NUM> is filling a receiving vehicle <NUM>, as indicated by block <NUM> in the flow diagram of <FIG>.

Receiving vehicle identification system <NUM> then automatically detects the identity of the receiving vehicle <NUM> that harvester <NUM> is filling. Automatically detecting the receiving vehicle identity is indicated by block <NUM> in the flow diagram of <FIG>.

Weight limit comparison system <NUM> then accesses the weight limit for the receiving vehicle <NUM> from receiving vehicle-to-weight limit mappings <NUM>, as indicated by block <NUM> in the flow diagram of <FIG>. Again, the weight limit mappings <NUM> can be downloaded or generated based upon the identity of the receiving vehicle <NUM>, as indicated by block <NUM>, or it can be previously input as indicated by block <NUM>, or the mappings <NUM> can be accessed in other ways as well, as indicated by block <NUM>.

Model accessing system <NUM> then accesses the receiving vehicle weight estimation model <NUM> for this receiving vehicle <NUM>, as indicated by block <NUM>. Fill level detection system <NUM> then detects the fill level of material inside the receiving vehicle <NUM> that is currently being filled by harvester <NUM>. Detecting the fill level is indicated by block <NUM> in the flow diagram of <FIG>.

Where the model <NUM> corresponding to the identified receiving vehicle <NUM> also considers moisture level, then fill control system <NUM> can also detect a representative moisture level (such as generating a rolling average of values from moisture sensor <NUM> while receiving vehicle <NUM> is being loaded) as indicated by block <NUM>.

Weight generation system <NUM> uses the fill level detected by fill level detection system <NUM> and the model <NUM> corresponding to this receiving vehicle <NUM> and estimates the weight of the material in the receiving vehicle <NUM>, as it is being filled. Estimating the weight of material in the receiving vehicle <NUM> is indicated by block <NUM> in the flow diagram of <FIG>.

Weight limit comparison system <NUM> then compares the estimated weight received from model <NUM> and weight generation system <NUM> to the weight limit for the receiving vehicle <NUM>. Comparing the two weights is indicated by block <NUM> in the flow diagram of <FIG>. In one example, as the weight of material in receiving vehicle <NUM> is being estimated by weight generation system <NUM> during the filling operation, it can be output on operator interface mechanisms <NUM>. Also, the weight comparison (which may indicate how close the current weight of material in receiving vehicle <NUM> is to the weight limit for receiving vehicle <NUM>) can also be output on operator interface mechanisms <NUM>. Controlling the operator interface mechanisms <NUM> to output the indication of the weight of material in receiving vehicle <NUM> and the result of comparison to the weight limit is indicated by block <NUM> in the flow diagram of <FIG>. The estimated weight of material in receiving vehicle <NUM> can be compared to the weight limit for receiving vehicle <NUM> in other ways as well, as indicated by block <NUM>.

In one example, weight limit comparison system <NUM> also determines whether the estimated weight of material in the receiving vehicle <NUM> is within a threshold level of the weight limit for that receiving vehicle <NUM>, as indicated by block <NUM>. If the estimated weight is not yet within a threshold level of the weight limit, then the fill control system <NUM> continues to fill the receiving vehicle <NUM>, as indicated by block <NUM>. However, if, at block <NUM> it is determined that the estimated weight of material in the receiving vehicle <NUM> is within a predetermined threshold of the receiving vehicle's weight limit, then control signal generator <NUM> generates control signals to control the operator interface mechanisms <NUM> to generate an output indicating that the receiving vehicle <NUM> has reached (or is about to reach) its weight limit. Generating an output indicating that the receiving vehicle <NUM> has reached (or is about to reach) its weight limit is indicated by block <NUM> in the flow diagram of <FIG>.

At some point, when receiving vehicle <NUM> is filled to a desired level (material weight or material height) either fill control system <NUM> automatically stops filling the receiving vehicle <NUM>, or operator <NUM> provides an input to control the controllable subsystems <NUM> to stop filling the receiving vehicle <NUM>. Fill data generation system <NUM> can detect that this receiving vehicle <NUM> has been filled, as indicated by block <NUM> in the flow diagram of <FIG>. Detecting that this receiving vehicle <NUM> has been filled can be performed by detecting that the material conveyance subsystem <NUM> has been stopped, as indicated by block <NUM>. Detecting that this receiving vehicle <NUM> has been filled can be detected when receiving vehicle identification system <NUM> detects that another receiving vehicle is in place adjacent harvester <NUM>, and being filled by harvester <NUM>, as indicated by block <NUM>. Detecting that the receiving vehicle <NUM> has been filled, and that the filling operation has stopped, can be done in other ways as well, as indicated by block <NUM>.

Fill data generation system <NUM> then generates the fill data and output generator <NUM> generates an output indicative of the fill data, as indicated by block <NUM>. As discussed elsewhere, the fill data can be provided to remote system/vehicles <NUM>, as indicated by block <NUM>. The fill data can be stored locally as indicated by block <NUM>. The fill data can include the load count for this receiving vehicle <NUM> as indicated by block <NUM>, the weight for this load, as indicated by block <NUM> and a wide variety of other information, as indicated by block <NUM>. As long as the harvesting operation continues, as indicated by block <NUM>, then processing reverts to block <NUM> where the harvester is filling another receiving vehicle, that vehicle is identified, etc..

It can thus be seen that the present description provides a description that automatically counts fill operations on a per-receiving vehicle-specific basis, or for different types of receiving vehicles. The present system can also estimate the weight of material in the receiving vehicle, compare it to a weight limit, and generate control signals based upon that comparison. These and other items can greatly increase the performance of the agricultural system. It will be noted that the present description can also just as easily be made with respect to construction equipment, such as a cold planar or another vehicle that is filling a receiving vehicle (such as a dump truck) with crushed concrete, asphalt, etc. The description provided with respect to an agricultural harvester is provided for the sake of example only.

The present discussion has mentioned processors and servers. In one example, the processors and servers include computer processors with associated memory and timing circuitry, not separately shown. They are functional parts of the systems or devices to which they belong and are activated by, and facilitate the functionality of the other components or items in those systems.

The user interfaces can take a wide variety of different forms and can have a wide variety of different user actuatable input mechanisms disposed thereon. For instance, the user actuatable input mechanisms can be text boxes, check boxes, icons, links, drop-down menus, search boxes, etc. The mechanisms can also be actuated in a wide variety of different ways. For instance, the mechanisms can be actuated using a point and click device (such as a track ball or mouse). The mechanisms can be actuated using hardware buttons, switches, a joystick or keyboard, thumb switches or thumb pads, etc. The mechanisms can also be actuated using a virtual keyboard or other virtual actuators. In addition, where the screen on which they are displayed is a touch sensitive screen, the mechanisms can be actuated using touch gestures. Also, where the device that displays the mechanisms has speech recognition components, the actuators can be actuated using speech commands.

It will be noted the data stores can each be broken into multiple data stores. All data stores can be local to the systems accessing them, all can be remote, or some can be local while others are remote.

It will also be noted that the information on map <NUM> can be output to the cloud.

<FIG> is a block diagram of the material loading system <NUM>, shown in <FIG>, except that it communicates with elements in a remote server architecture <NUM>. In one example, remote server architecture <NUM> can provide computation, software, data access, and storage services that do not require end-user knowledge of the physical location or configuration of the system that delivers the services. In various examples, remote servers can deliver the services over a wide area network, such as the internet, using appropriate protocols. For instance, remote servers can deliver applications over a wide area network and they can be accessed through a web browser or any other computing component. Software or components shown in <FIG> as well as the corresponding data, can be stored on servers at a remote location. The computing resources in a remote server environment can be consolidated at a remote data center location or they can be dispersed. Remote server infrastructures can deliver services through shared data centers, even though they appear as a single point of access for the user. Thus, the components and functions described herein can be provided from a remote server at a remote location using a remote server architecture. Alternatively, the components and functions can be provided from a conventional server, or they can be installed on client devices directly, or in other ways.

In the example shown in <FIG>, some items are similar to those shown in <FIG> and they are similarly numbered. <FIG> specifically shows that other systems <NUM>, systems <NUM> and <NUM>, and data store <NUM> can be located at a remote server location <NUM>. Therefore, harvester <NUM> accesses those systems through remote server location <NUM>.

<FIG> also depicts another example of a remote server architecture. <FIG> shows that it is also contemplated that some elements of <FIG> are disposed at remote server location <NUM> while others are not. By way of example, data store <NUM> or other systems <NUM> can be disposed at a location separate from location <NUM>, and accessed through the remote server at location <NUM>. Regardless of where the remote items are located, they can be accessed directly by harvester <NUM>, through a network (either a wide area network or a local area network), the remote items can be hosted at a remote site by a service, or they can be provided as a service, or accessed by a connection service that resides in a remote location. Also, the data can be stored in substantially any location and intermittently accessed by, or forwarded to, interested parties. For instance, physical carriers can be used instead of, or in addition to, electromagnetic wave carriers. In such an example, where cell coverage is poor or nonexistent, another mobile machine (such as a fuel truck) can have an automated information collection system. As the harvester comes close to the fuel truck for fueling, the system automatically collects the information from the harvester using any type of ad-hoc wireless connection. The collected information can then be forwarded to the main network as the fuel truck reaches a location where there is cellular coverage (or other wireless coverage). For instance, the fuel truck may enter a covered location when traveling to fuel other machines or when at a main fuel storage location. All of these architectures are contemplated herein. Further, the information can be stored on the harvester until the harvester enters a covered location. The harvester, itself, can then send the information to the main network.

Claim 1:
A material loading system (<NUM>), comprising:
a receiving vehicle identification system (<NUM>) configured to automatically identify a receiving vehicle (<NUM>, <NUM>, <NUM>) that receives material from a material loading vehicle (<NUM>);
a fill data generation system (<NUM>) configured to automatically generate a load count corresponding to the identified receiving vehicle (<NUM>, <NUM>, <NUM>), the load count being indicative of a number of times that the identified receiving vehicle (<NUM>, <NUM>, <NUM>) has been filled with material during a load count window; and
an output generator (<NUM>) configured to generate an output control signal to output the load count corresponding to the identified receiving vehicle (<NUM>, <NUM>, <NUM>);
characterized by comprising
a fill level detection system (<NUM>) configured to automatically detect a fill level of the material in the identified receiving vehicle (<NUM>, <NUM>, <NUM>); and
a weight generation system (<NUM>) configured to automatically generate an estimated weight value indicative of an estimated weight of the material in the identified receiving vehicle (<NUM>, <NUM>, <NUM>) based on the identified receiving vehicle (<NUM>, <NUM>, <NUM>) and the detected fill level.