Patent Description:
There are a wide variety of different types of mobile work machines such as agricultural 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.

As one example, while harvesting in a field using a forage harvester, an operator attempts to control the forage harvester to maintain harvesting efficiency. At the same time, a haulage unit (such as 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 haulage unit while moving through the field.

The present discussion proceeds with respect to an agricultural harvester. With these types of machines, logistical efficiency can be desirable. For instance, if a receiving vehicle that is receiving harvested material from a forage harvester reaches its full capacity at some point in the field, and there is no haulage unit nearby, then the forage harvester sits idle, waiting for a haulage unit to arrive. This increases the inefficiency of the forage harvester, and of the overall harvesting operation.

Similarly, in a given harvesting operation, there may be multiple different harvesters operating in a single field, along with multiple different haulage units. Thus, the haulage units may go to the wrong harvester. For instance, a haulage unit may go to a harvester which has a receiving vehicle which has not yet reached is full capacity, while a different harvester is sitting idle because it has no receiving vehicle into which to load material. This can also raise the inefficiency of the operation. Further, it may be that operators of the haulage units do not know when a particular receiving vehicle is reaching its capacity.

Other harvesters such as combine harvesters and sugar cane harvesters, can have similar difficulties.

It can thus be very difficult for an operator of an empty receiving vehicle to know where to go when approaching a field or after unloading material. The operator of the receiving vehicle does not know when or where the receiving vehicle(s) currently being filled by the harvester(s) will be full. Similarly, when there are multiple harvesters operating in a field, the operator of the empty receiving vehicle does not know which harvester will fill its current receiving vehicle first. This can result in inefficiencies.

In order to address issues encountered in filling a receiving vehicle, some automatic cart filling control systems have been developed to automate portions of the filling process. One such automatic fill control system uses a stereo camera on the spout of the harvester to capture an image of the receiving vehicle. An image processing system can determine dimensions of the receiving vehicle and the distribution of the crop deposited inside the receiving vehicle. The system also detects crop height 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.

<CIT> describes a harvester cooperating with transport vehicles. For position coordination, the harvester can control the speed and position of the transport vehicle. Once the container is full, the operator of the transport vehicle is informed such that he or she can drive away and allow another transport vehicle to drive to a position suitable for crop transferring. The driver of the new transport vehicle can control the vehicle to drive to the transfer position or this is done automatically. After all, this prior art has two options, i.e., the transport vehicle is controlled automatically, and the driver is informed only when the container is filled and thus the vehicle should leave the position, or all this is done automatically.

<CIT> describes a combine harvester with a system estimating the fill state of a grain tank based on yield data from a previous harvest and identifies a rendezvous point with a transport vehicle or indication that the grain tank is about full or indication that the grain tank is about full and communicates this to the driver of the transport vehicle. This prior art considers only the fill state of the grain tank of the harvester, not the fill state of the transport vehicle.

<CIT> describes a cold planer material transport management system in which a cold planer is milling asphalt from a road fills a transport vehicle. Based on throughput of the cold planer, a plant operator is informed when the transport vehicle will be filled, allowing the plant operator to generate dispatch signals for transport vehicles. Here, control of the transport vehicles is done by the transport management system or the plant operator, not by the drive of the transport vehicle.

A mobile harvester detects a fill level of material in a receiving vehicle and then generates an estimate of a fill parameter indicative of where or when the receiving vehicle will reach a target capacity. The fill parameter is then communicated to a mobile application (mobile app) on one or more mobile devices on one or more other receiving vehicles so the operator(s) of the one or more other receiving vehicles can efficiently determine where to go on the field so the harvester can continue harvesting without significant interruption.

<FIG> is a pictorial illustration showing one example of a self-propelled forage harvester <NUM> filling a tractor-pulled grain cart (a haulage unit 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 tractor <NUM>, that is pulling grain cart <NUM>, is positioned directly behind forage harvester <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 receive a target landing point for the material in cart <NUM> and gauge the height of harvested material in cart <NUM>. The automatic fill control system can control spout <NUM> and flap <NUM> to obtain an even fill throughout the entire length and width of cart <NUM>, while not overfilling cart <NUM>. An image processing system can identify how full cart <NUM> is. The automatic fill control system can then generate a fill parameter indicative of an estimate of when cart <NUM> will be full. For example, a flow rate sensor can sense a flow rate (e.g., volumetric flow rate) of material through harvester <NUM>. Based on the current fill level of cart <NUM> and the flow rate the automatic fill control system can generate an output indicative of when cart <NUM> will be full, or a location where cart <NUM> will be full. In another example, forward looking camera <NUM> can capture an image (sill or video) of an area ahead of harvester <NUM> so the image processor can generate an estimate of the volume of material that harvester <NUM> will encounter. This volume can be used to generate a fill parameter as well. In other examples, the fill parameter can be based on the current fill level of cart <NUM> and a historic yield in the field ahead of the harvester <NUM> as well as the location, heading, and speed of harvester <NUM>. These are only examples of how a fill parameter can be generated. The fill parameter can then be sent to a mobile app on a mobile device on other receiving vehicles. By automatically, it is meant, for example, that the operation is performed without further human involvement except, perhaps, to initiate or authorize the operation.

<FIG> is a pictorial illustration showing another example of a self-propelled forage harvester <NUM>, this time loading a semi-trailer (a haulage unit or a receiving vehicle) <NUM> in a configuration in which a semi-tractor is pulling semi-trailer <NUM> alongside forage harvester <NUM>. An automatic fill control system detects a target landing point in receiving vehicle <NUM>. The target landing point can be detected based on an operator input or an automated input or a default input. Therefore, the spout <NUM> and flap <NUM> are positioned to unload the harvested material <NUM> to fill trailer <NUM> at the target landing point according to a pre-defined 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 how full the trailer <NUM> is. The automatic fill control system can then generate the fill parameter indicative of when trailer <NUM> will be filled to a target capacity. For example, the fill parameter may be a time when trailer <NUM> will be filled to the target capacity, a location where trailer <NUM> will be filled to the target capacity, etc.). The fill parameter can then be sent to mobile apps on other receiving vehicles so the operators of the other receiving vehicles can best decide where to drive.

In some 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 vessel <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. In such an example, the combine harvester and towing vehicle may have machine synchronization systems which communicate with one another. When the relative position of the two vehicles is to change, then 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 vessel 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 vessel forward or rearward, respectively, relative to the combine harvester.

<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 operator interface display <NUM> in <FIG> shows a view of images (still or video) captured by camera <NUM> of material <NUM> entering trailer <NUM>. An image processing system on harvester <NUM> illustratively identifies the perimeter of the opening <NUM> in trailer <NUM> as generally lying in a plane and also processes the image of the material <NUM> in trailer <NUM> to determine where the trajectory of material <NUM> intersects with the plane that opening <NUM> lies in to identify the actual (or current) landing point of material <NUM> in trailer <NUM>. The image processor can also determine the fill height relative to opening <NUM> and the overall fill level of trailer <NUM> (such as the percentage of a target capacity to which trailer <NUM> is filled). 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. The target landing point may be identified on display <NUM> by an indicator <NUM>.

As mentioned, the target landing point may be input by the operator. For example, where the display screen on mechanism <NUM> is a touch sensitive display screen, then the operator may simply touch the screen in the area of the target landing point. The touch gesture is detected by the fill control system and the fill control system automatically generates control signals to move spout <NUM> so that it is depositing material <NUM> at the target landing point.

Generating the control signals to reposition spout <NUM> can be done in different ways. For instance, once the operator touches or otherwise selects (such as with a point and click device) an area of display <NUM>, the control system identifies the pixel or pixel sets that were selected (e.g., touched or otherwise selected) and, from those pixels, identifies a corresponding physical area or landing point within trailer <NUM>. The control system can then calculate the position that spout <NUM> needs to be in based on the density of the material <NUM> and the kinematics of the spout <NUM> and flap <NUM> and the velocity of the material <NUM> or estimated velocity of the material <NUM> as it exits the spout <NUM> in order to fill material <NUM> at that particular landing point in trailer <NUM>.

It should also be noted that, in one example, forage harvester <NUM> may have 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.). In that case, the indicator <NUM> may be displayed to show the current location where material <NUM> is being loaded (or is intended to be loaded) into trailer <NUM> through spout <NUM> and the direction that spout <NUM> will 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 target landing point, while the direction of the arrow indicates the direction that spout <NUM> will be moved relative to trailer <NUM> in executing the selected front-to-back fill strategy.

In one example, the automatic fill control system or a separate fill level processing system also determines a fill parameter indicative of when trailer <NUM> will be full. As discussed above, the automatic fill control system or separate system can receive an input indicative of the flow of material through harvester <NUM>, or indicative of the estimated flow of material through harvester <NUM>. The input may be based upon a view of the crop material ahead of harvester <NUM> generated by a forward looking camera <NUM>. The estimated flow of material can be based upon an estimated crop yield ahead of harvester <NUM>. The estimated yield can be based upon a current yield, or based upon historic yield from a same position in the field. The fill parameter may be an estimated time value indicative of when trailer <NUM> will reach its target capacity, or the fill parameter may be a distance value indicating a distance that harvester <NUM> will travel before trailer <NUM> reaches its target capacity. Similarly, the fill parameter can be generated based upon how long it took to fill trailer <NUM> to its current overall fill level. By way of example, if it took harvester <NUM> fifteen minutes to fill trailer <NUM> to a current overall fill level of <NUM>% of its target capacity, then the automatic fill control system can generate the fill parameter to indicate that trailer <NUM> will likely be full in <NUM> minutes. Similarly, if the automatic fill control system or separate system receives an input indicating that harvester <NUM> filled trailer <NUM> to <NUM>% of its target capacity after traveling <NUM> meters, then the automatic fill control system may generate the fill parameter to indicate that trailer <NUM> will be filled to its target capacity after harvester <NUM> travels an additional <NUM> meters. The fill parameter may be a location in a local or global coordinate system indicating a location where harvester <NUM> will be when trailer <NUM> reaches its capacity, or the fill parameter may be a different parameter.

Once the automatic fill control system or separate system generates the fill parameter, display <NUM> can display a fill parameter indicator <NUM>. In the example shown in <FIG>, the fill parameter indicator <NUM> is a distance value indicating how far harvester <NUM> will travel before trailer <NUM> reaches its target capacity. It will be appreciated that the fill parameter indicator <NUM> can be other values as well, such as a time value, a geographic location value, or any of a wide variety of other fill parameter values.

In one example, the automatic fill control system can also send the fill parameter to the receiving vehicle that is currently being loaded and to one or more other receiving vehicles that are not currently being loaded by harvester <NUM>. Therefore, if there are empty receiving vehicles that have been unloaded and are returning to the field or returning to harvester <NUM>, and that have mobile devices that are running the mobile app, the fill parameter can be sent to the mobile app which can display the fill parameter to the operator(s) of the empty receiving vehicles. The operator(s) can then determine where to drive to most efficiently meet harvester <NUM> (or another harvester) when trailer <NUM> (or another haulage unit) reaches its target capacity. Similarly, there may be multiple harvesters operating in the same field. There may also be multiple different receiving vehicles so that when an operator of an empty receiving vehicle is returning to the harvesters, that operator may find it difficult to know which harvester will need the empty receiving vehicle first, and where that harvester will be when it needs the empty receiving vehicle. Thus, the mobile app may receive fill parameters from each of the multiple different harvesters, and those fill parameters may be displayed by the mobile app so that the operator of the empty receiving vehicle can choose to drive to the harvester that results in a most efficient route.

These are just some examples of how the operator interface display <NUM> can be generated. Others are described in more detail below.

<FIG> is another example of an operator interface display <NUM> which can be generated for the operator of harvester <NUM>. Some items are similar to those shown in <FIG> and they are similarly numbered. <FIG> shows a view from camera <NUM> of cart <NUM> that is following behind harvester <NUM>. Material <NUM> is provided from spout <NUM> to cart <NUM>. In the example shown in <FIG>, the target landing point is represented by <NUM>.

The automatic fill control system or separate system can then sense the fill level of cart <NUM> and generate a fill parameter indicative of when or where the cart <NUM> will reach its target capacity and display a fill parameter indicator <NUM>. The fill parameter indicator <NUM> can be sent to a mobile app running on one or more mobile devices in one or more other receiving vehicles as well.

<FIG> is a block diagram showing one example of a mobile work machine which comprises agricultural harvester <NUM>, in more detail. Agricultural harvester <NUM>, in the example shown in <FIG>, includes one or more processors or servers <NUM>, communication system <NUM>, data store <NUM>, sensors <NUM>, fill control system <NUM>, fill level processing system <NUM>, operator interface mechanisms <NUM>, controllable subsystems <NUM>, and other harvester functionality <NUM>. Sensors <NUM> can include automatic fill control sensors <NUM> that are used by fill control system <NUM>. Sensors <NUM> can include camera <NUM> (which may be a mono-camera, stereo-camera or another type of camera), forward looking camera <NUM>, and other sensors <NUM>. The other sensors can include such things as Doppler sensors, RADAR sensors, other image sensors or any of a wide variety of other types of sensors. Sensors <NUM> can also include spout position sensor <NUM>, flap position sensor <NUM> and flow sensor <NUM>. Spout position sensor <NUM> illustratively senses the position of spout <NUM> relative to the frame of harvester <NUM>. Sensor <NUM> can do this by sensing the position of an actuator that drives movement of spout <NUM> relative to the frame of harvester <NUM>, or sensor <NUM> can be a rotary position sensor, a linear sensor, a potentiometer, a Hall Effect sensor, or any other of a wide variety of sensors that can sense the position of spout <NUM> relative to the frame of harvester <NUM>. Similarly, flap position sensor <NUM> can be a sensor that senses the position of the flap <NUM>. Thus, sensor <NUM> can be a rotary position sensor, a linear sensor, a potentiometer, a Hall Effect sensor, a sensor that senses a position of an actuator that drives movement of flap <NUM>, or any of a wide variety of other sensors. Flow sensor <NUM> can sense, for example, volumetric flow of material through harvester <NUM>. Flow sensor <NUM> can be an optical sensor disposed at different locations in harvester <NUM>, torque or pressure sensor(s) on mechanisms carrying the material through harvester <NUM>, mechanical sensors sensing the material as it is engaged by harvester <NUM>, or other sensors. Flow sensor <NUM> generates a signal indicative of the volumetric flow rate of material through harvester <NUM>.

Sensors <NUM> can also include machine synchronization sensors <NUM>. Sensors <NUM> can include relative position sensors <NUM> that sense the relative position of the harvester, relative to the receiving vehicle. Such sensors can include RADAR sensors, Doppler sensors, image or other optical sensors, or a wide variety of other relative position sensors. The relative position sensors <NUM> can also include position sensors (such as a GPS receiver, or another GNSS sensor, or another position sensor) that senses the position of harvester <NUM>. This can be used, in conjunction with another position sensor on the receiving vehicle, to determine the position of the two vehicles relative to one another. The machine synchronization sensors <NUM> can include other sensors <NUM>. The sensors <NUM> can include a crop moisture sensor <NUM>, and a ground speed sensor <NUM>, and a wide variety of other sensors <NUM> as well. Moisture sensor <NUM> can be a capacitive sensor or another sensor that generates an output indicative of a moisture level of the crop. Ground speed sensor <NUM> can sense the speed of travel of harvester <NUM> and generate an output indicative of the speed. Sensor <NUM> can sense the speed of rotation of an axle or a drive shaft or transmission on harvester <NUM>. Sensor <NUM> can sense other characteristics indicative of the speed of harvester <NUM>.

Fill control system <NUM> illustratively controls operations of various parts of harvester <NUM> (and possibly the towing vehicle <NUM>) to fill the receiving vehicle <NUM>, <NUM>, as desired. Fill control system <NUM> can include automatic fill control system <NUM> (which, itself, can include fill strategy selector <NUM>, fill strategy implementation processor <NUM>, and other items <NUM>), manual fill control system <NUM> (which, itself can include manual set point detector <NUM> and other items <NUM>), and/or machine synchronization fill control system <NUM>. Fill control system <NUM> can also include fill control signal generator <NUM>, fill level detector <NUM>, and other items <NUM>. Fill level processing system <NUM> is shown as being separate from fill control system <NUM> but could be part of fill control system <NUM> as well, Fill level processing system <NUM> can include fill processing trigger detector <NUM>, fill rate generator <NUM>, fill parameter generator <NUM>, other items <NUM>. Fill parameter generator <NUM> can include harvester identifier <NUM>, location identifier <NUM>, time identifier <NUM>, and other items <NUM>.

Operator interface mechanisms <NUM> can include interactive display mechanism <NUM> and a variety of other operator interface mechanisms <NUM>. Controllable subsystems <NUM> can include material conveyance subsystem <NUM>, propulsion subsystem <NUM>, steering subsystem <NUM>, one or more spout actuators <NUM>, one or more flap actuators <NUM> and other items <NUM>. <FIG> also shows that operator <NUM> can interact through operator interface mechanism <NUM> to control and manipulate agricultural harvester <NUM>. Further, <FIG> shows that harvester <NUM> is connected over network <NUM> to haulage units, such as receiving vehicle <NUM>, <NUM>, towing vehicle <NUM> and/or it can be connected to other systems <NUM>. The operators of the haulage units (e.g., receiving vehicles <NUM>, <NUM> or towing vehicles <NUM>) may have access to a mobile device <NUM> that may be mounted in the operator compartment or carried by the operator. The mobile device(s) may run a mobile app. Before describing the overall operation of agricultural harvester <NUM> in more detail, a brief description of some of the items in agricultural harvester <NUM>, and their operation, will first be provided.

Communication system <NUM> can facilitate communication among the items of harvester <NUM> and with other items over network <NUM>. Network <NUM> can be a wide area network, a local area network, a near field communication network, a cellular communication network, or any of a variety of other networks or combinations of networks. Therefore, communication system <NUM> can use a controller area network (CAN) bus or other controllers to facilitate communication of the items on harvester <NUM> with other items. Communication system <NUM> can also be different kinds of communication systems, depending on the particular network or networks <NUM> over which communication is to be made. In one example, communication system <NUM> can communicate with the mobile app on mobile device(s) <NUM> over network <NUM>.

Operator interface mechanisms <NUM> can be a wide variety of different types of mechanisms. Interactive display mechanism <NUM> can be a display mechanism, such as that shown in <FIG> and <FIG>, or mechanism <NUM> can be a display mechanism on a mobile device, such as a tablet computer, a smartphone, etc., that is carried by the operator <NUM> and/or mounted in the operator compartment of harvester <NUM>. Thus, interactive display mechanism <NUM> can be a touch sensitive display mechanism, a display mechanism that receives inputs through a point and click device, or other kinds of display mechanisms.

Other operator interface mechanisms <NUM> can include a steering wheel, levers, buttons, pedals, a microphone and speaker (where speech recognition and speech synthesis are provided), joysticks, or other mechanical, audio, visual, or haptic mechanisms that can be used to provide outputs to operator <NUM> or to receive inputs from operator <NUM>.

Controllable subsystems <NUM> can be controlled by various different items on harvester <NUM>. Material conveyance subsystem <NUM> can include any mechanisms used to convey material <NUM> through harvester <NUM> and to a haulage unit, such as conveyors, augers, fans, etc..

Propulsion subsystem <NUM> can be an engine that drives ground-engaging elements (such as wheels or tracks) through a transmission, hydraulic motors that are used to drive ground-engaging elements, electric motors, direct drive motors, or other propulsion systems that are used to drive ground-engaging elements to propel harvester <NUM> in the forward and rearward directions. Propulsion subsystem <NUM> can illustratively be controlled with a throttle to increase or decrease the speed of travel of harvester <NUM>.

Steering subsystem <NUM> can be used to control the heading of harvester <NUM>. One or more spout actuators <NUM> are illustratively configured to drive rotation or other movement of spout <NUM> relative to the frame <NUM> of harvester <NUM>. Actuators <NUM> can be hydraulic actuators, electric actuators, pneumatic actuators, or any of a wide variety of other actuators. Similarly, one or more flap actuators <NUM> are used to drive the position of flap <NUM> relative to spout <NUM>. The flap actuators <NUM> can also be hydraulic actuators, electric actuators, pneumatic actuators, or any of a wide variety of other actuators.

Fill control system <NUM> can use automatic fill control system <NUM> to perform automated fill control to automatically execute a fill strategy in filling one of the haulage units (e.g., one of receiving vehicles <NUM>, <NUM>). Therefore, fill strategy selector <NUM> can detect a user input selecting a fill strategy, or another input selecting a fill strategy and access data store <NUM> for a stored fill algorithm that can be executed to perform the selected fill strategy. For instance, where the selected fill strategy is a back-to-front strategy, the algorithm will direct filling of the receiving vehicle beginning with a target landing point at the back of the receiving vehicle and moving to a target landing point toward the front of the receiving vehicle. Other fill strategies can be selected as well. Fill level detector <NUM> receives an input from camera <NUM> and generates an output indicative of the height of material at the current landing point in the receiving vehicle and the overall fill level for the receiving vehicle (e.g., how close the receiving vehicle is to a target capacity. The target capacity may be an operator input value, a default value, an automatically generated value, or another value. Fill strategy implementation processor <NUM> receives inputs from the automatic fill control sensors <NUM>, spout position sensor <NUM>, and flap position sensor <NUM>, and can also access kinematic information for spout <NUM>, and receives an output from fill level detector <NUM>, and generates an output to fill control signal generator <NUM> based upon the inputs, to execute the desired automatic fill control strategy. Fill control signal generator <NUM> can generate control signals to control any of the controllable subsystems <NUM> (or other items) to execute the fill strategy being implemented by fill strategy implementation processor <NUM>.

Manual fill control system <NUM> can use manual set point detector <NUM> to detect a manual input from operator <NUM> (e.g., through interactive display mechanism <NUM>) to identify a target landing point in the haulage unit (e.g., receiving vehicle <NUM>, <NUM>) where the operator <NUM> desires the filling operation to be performed. Manual fill control system <NUM> can then generate outputs to fill control signal generator <NUM> which generates control signals to control the controllable subsystems <NUM> so that filling commences at the manually identified target landing point in the receiving vehicle <NUM>, <NUM>.

Machine synchronization fill control system <NUM> can receive operator inputs or other inputs, as well as sensor inputs from sensors <NUM> to generate outputs to fill control signal generator <NUM> in order to synchronize the positions of agricultural harvester <NUM> and the haulage unit (e.g., receiving vehicle <NUM>, <NUM>) so that a desired filling operation is performed. For instance, machine synchronization control system <NUM> can receive sensor inputs identifying that the current position that is being filled in receiving vehicle <NUM>, <NUM>, is at a desired fill level so that the receiving vehicle should move forward or rearward relative to agricultural harvester <NUM>. Machine synchronization fill control system <NUM> then generates an output to fill control signal generator <NUM> indicating this. Fill control signal generator <NUM> can generate an output either to controllable subsystems <NUM>, or communication system <NUM>, or both, based on the inputs from machine synchronization fill control system <NUM>. For instance, where the output from system <NUM> indicates that the receiving vehicle <NUM>, <NUM> should move forward relative to agricultural harvester <NUM>, then fill control signal generator <NUM> can control communication system <NUM> to communicate with a corresponding machine synchronization fill control system <NUM> on towing vehicle <NUM> indicating that towing vehicle <NUM> should "nudge" forward relative to the harvester <NUM> by momentarily increasing its ground speed and then returning to its current ground speed. Alternatively, or in addition, fill control signal generator <NUM> can generate control signals to control the propulsion subsystem <NUM> on agricultural harvester <NUM> to momentarily change the speed of agricultural harvester <NUM> so that the position of the receiving vehicle <NUM>, <NUM> relative to agricultural harvester <NUM> changes as desired.

Fill level processing system <NUM> receives the fill level of the receiving vehicle from fill level detector <NUM>. In one example, fill level processing system <NUM> receives the overall fill level (e.g., how close the receiving vehicle is to its target capacity). Fill processing trigger detector <NUM> detects when a new fill parameter is to be generated. Again, the fill parameter is illustratively a parameter indicative of when the receiving vehicle or haulage unit currently being filled by agricultural harvester <NUM> will be filled to its target capacity. Trigger detector <NUM> can trigger the generation of a new fill parameter on a periodic or otherwise intermittent basis. Similarly, trigger detector <NUM> can trigger the generation of a new fill parameter based on how close the receiving vehicle is to its target capacity, and/or based on how quickly the receiving vehicle is being filled. For instance, if the receiving vehicle is being filled at a first rate and is only half full, then trigger detector <NUM> may trigger the generation of a new value for the fill parameter at one rate. However, if the receiving vehicle is ninety percent full and is filling at a second rate that is quicker than the first rate, then trigger detector <NUM> may trigger the evaluation or generation of a fill parameter more often.

Fill rate generator <NUM> then receives information from sensors and other items on agricultural harvester <NUM> and generates an output indicative of the fill rate, (e.g., how quickly the receiving vehicle is being filled). For instance, fill rate generator <NUM> may monitor the rate at which the receiving vehicle is filled by monitoring the change in the overall fill level detected by fill level detector <NUM> over time. This historical fill rate for this receiving vehicle may be used to estimate the future fill rate as well. In another example, fill rate generator <NUM> may receive an input from forward looking camera <NUM> and perform image processing on that image to identify an estimate of a volume of material that the harvester <NUM> is about to encounter in the field. This volume can be used to estimate the volumetric flow rate of material through harvester <NUM>, and thus to estimate the rate at which the receiving vehicle is being filled.

In another example, flow sensor <NUM> may sense volumetric flow rate of material, as it is moving through agricultural harvester <NUM>. Sensor <NUM> may generate a flow rate signal indicative of the sensed volumetric flow rate and provide that to fill rate generator <NUM>. Based upon the size of the receiving vehicle and the volumetric flow rate sensed by flow sensor <NUM>, fill rate generator <NUM> can generate an output indicative of how quickly the receiving vehicle is being filled.

Fill parameter generator <NUM> then generates a fill parameter indicative of when the receiving vehicle will be filled to its target capacity. Fill parameter generator <NUM> may have access to the dimensions of the receiving vehicle that may be stored in datastore <NUM>, or those dimensions, when used by fill parameter generator <NUM>, can be sensed or otherwise obtained by fill parameter generator <NUM>. In one example, there may be multiple harvesters in a single field and therefore harvester identifier <NUM> generates a harvester identifier output that uniquely identifies agricultural harvester <NUM> among the various harvesters that are working in the field. Location identifier <NUM> can generate an output indicating a geographic location where harvester <NUM> will be when its current receiving vehicle is filled to its capacity. For instance, location identifier <NUM> may receive an input from ground speed sensor <NUM> indicating that ground speed of agricultural harvester <NUM>, and a fill rate signal output by fill rate generator <NUM> indicating the rate at which the receiving vehicle is being filled to its target capacity. Location identifier <NUM> may then access a route that agricultural harvester <NUM> is following or a geographic position of harvester <NUM> and a heading of harvester <NUM>. Given the direction that agricultural harvester <NUM> is traveling, and its ground speed, and given a rate at which the receiving vehicle is being filled and its current overall fill level, location identifier <NUM> can generate an output indicative of a geographic location (in a local or global coordinate system) where agricultural harvester <NUM> will be located when the receiving vehicle that it is currently filling reaches target capacity.

Time identifier <NUM> generates an output indicative of a time (either an absolute time in the future or a time period that will elapse) before agricultural harvester <NUM> fills its current receiving vehicle to target capacity. For instance, given the current fill level of the receiving vehicle detected by fill level detector <NUM> and the current fill rate generated by fill rate generator <NUM>, time identifier <NUM> can compute the time it will take to fill the receiving vehicle to its target capacity.

Fill parameter generator <NUM> outputs the fill parameter to fill control signal generator <NUM>. Fill control signal generator <NUM> can control communication system <NUM> to communicate the fill parameter to a mobile app on mobile device <NUM> on the receiving vehicles including one or more receiving vehicles that are not currently being filled by the harvester <NUM>. Fill level processing system <NUM> can output the fill parameter to operator interface mechanisms <NUM> for display to operator <NUM>. Control signals can be generated in other ways, based upon the fill parameter as well.

<FIG> is a flow diagram illustrating one example of the operation of agricultural harvester <NUM> in generating the fill parameter and communicating it to the mobile app on mobile devices <NUM> on other receiving vehicles. It is first assumed that the receiving vehicle has a mobile device <NUM> with a companion mobile app that may be a companion to an application or algorithm that is run by fill level processing system <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>. Mobile device <NUM> may be a smart phone carried by the operator of a receiving vehicle or haulage unit, as indicated by block <NUM>, or a tablet computer mounted in the operator compartment of a receiving vehicle or haulage unit as indicated by block <NUM>, or another mobile device <NUM>. Agricultural harvester <NUM> is loading material into a receiving vehicle (in the present example it is assumed that the receiving vehicle is a cart <NUM> towed by a tractor <NUM>) as indicated by block <NUM>. Fill level detector <NUM> then detects one or more inputs indicative of a fill level in the receiving vehicle, as indicated by block <NUM>. In one example, the input can be received from camera <NUM>, or other fill level sensors <NUM>.

Fill rate generator <NUM> then detects an input indicative of a fill rate of the receiving vehicle, as indicated by block <NUM>. The fill rate may be a portion of the receiving vehicle that is filled per unit of time, a portion of the receiving vehicle that is filled per unit of distance traveled by harvester <NUM>, or in other terms. The fill rate detector <NUM> can receive an input from a forward looking perception sensor, such as forward looking camera <NUM>, and/or from a flow rate sensor <NUM>. The fill rate generator <NUM> can receive yield data (e.g., historic yield data, estimated yield data, or sensed real time yield data) <NUM> as an input and generate an output indicative of the fill rate based upon the yield that the agricultural harvester <NUM> is about to encounter in the field. The fill rate generator <NUM> may also receive an input indicating the position, heading, and speed of harvester <NUM>, as indicated by block <NUM>. Fill rate generator <NUM> may receive a wide variety of other inputs <NUM> as well. Fill rate generator <NUM> then generates an output signal indicative of the rate at which the receiving vehicle is being filled, as indicated by block <NUM>.

Fill parameter generator <NUM> then generates an estimated cart fill parameter that is indicative of when or where the cart <NUM> will be filled. Generating the estimated cart fill parameter is indicated by block <NUM> in the flow diagram of <FIG>. Fill rate parameter generator <NUM> may detect or estimate the route of the harvester <NUM>, and the speed of harvester <NUM>, as indicated by block <NUM>. Location identifier identifies the location where harvester <NUM> will be when the cart that harvester <NUM> is currently filling will likely reach its target capacity, as indicated by block <NUM>. Again, the location may be a set of geographic coordinates in a local or global coordinate system, a route, etc..

Time identifier <NUM> may generate an output indicative of how long it will be until cart <NUM> reaches its target capacity, or an absolute time in the future when cart <NUM> is likely to reach its target capacity. Generating a time when the cart will reach its target capacity is indicated by block <NUM>. The cart fill parameter can be any of a wide variety of other or additional parameters <NUM> as well.

Fill level processing system <NUM> then outputs the cart fill parameter to the operator <NUM> of agricultural harvester <NUM> and controls communication system <NUM> to communicate the fill parameter to the mobile app on the mobile device <NUM> of the receiving vehicles that may be serving agricultural harvester <NUM>. Outputting the cart fill parameter to operator <NUM> is indicated by block <NUM> and communicating the cart fill parameter to the mobile app on mobile devices <NUM> on other receiving vehicles is indicated by block <NUM> in the flow diagram of <FIG>. The communication channel can be a Wi-Fi channel <NUM>, a Bluetooth channel <NUM>, a cellular channel <NUM>, or another type of communication channel <NUM>.

Fill processing trigger detector <NUM> then detects whether it is time to re-estimate or re-generate the cart fill parameter, as indicated by block <NUM>. If so, processing reverts to block <NUM>. If not, then the processing continues until the harvesting operation is complete, as indicated by block <NUM>.

<FIG> is a block diagram of one example of a mobile device <NUM> that can be used in the receiving vehicles. Mobile device <NUM> can include a processor <NUM>, a data store <NUM>, communication system <NUM>, a mapping system <NUM>, a user interface (UI) control system <NUM>, a mobile app <NUM>, user interface mechanisms <NUM>, and a wide variety of other mobile device functionality <NUM>. Mobile app <NUM> can include a harvester identifier <NUM>, a route generator <NUM>, fill parameter output system <NUM> and a wide variety of other items <NUM>.

Communication system <NUM> can include one or more different types of communication systems, such as a Wi-Fi communication system, a cellular communication system, a near field communication system, a Bluetooth communication system, a local area network or wide area network communication system, a web-based communication system, or any of a wide variety of other communication systems. Mapping system <NUM> can include a GNSS receiver or another position sensor that detects a current location of mobile device <NUM> and generates a map with map functionality, such as route planning, direction finding, etc. UI control system <NUM> controls user interface mechanisms <NUM> which may include a touch sensitive screen, buttons, keypads, microphone and speaker, and any of wide variety other user interface mechanisms.

Mobile app <NUM> can receive the fill parameter generated by fill parameter generator <NUM> on agricultural harvester <NUM> through communication system <NUM>. Harvester identifier <NUM> identifies, from the fill parameter, the particular harvester that generated the fill parameter. Fill parameter output system <NUM> can generate an output of an indication of the fill parameter to the operator through user interface mechanisms <NUM>. Route generator <NUM> may use mapping system <NUM> to generate a route to the position where the harvester <NUM> will be when the receiving vehicle that harvester <NUM> is currently loading reaches its target capacity. The fill parameter output system <NUM> may invoke mapping system <NUM> to output that route for the operator of the receiving vehicle on which mobile device <NUM> resides. Fill parameter output system <NUM> may generate an output simply indicating when the harvester <NUM> will fill its current receiving vehicle to the target capacity, where the harvester <NUM> will be when its current receiving vehicle is filled to the target capacity, how long it will be until the receiving vehicle is filled to the target capacity, or other things. Some examples are discussed in greater details below.

<FIG> is a flow diagram illustrating one example of the operation of mobile app <NUM> in an example in which the mobile device <NUM> running mobile app <NUM> is disposed in an empty receiving vehicle that is returning to be loaded by a harvester. Mobile app <NUM> first receives the cart fill parameter from the agricultural harvester <NUM> that generated it. This is indicated by block <NUM> in the flow diagram of <FIG>. It should be noted that mobile app <NUM> may receive multiple different fill parameters from multiple different harvesters <NUM>, such as when multiple different harvesters are harvesting in the same field. The cart fill parameter can be received by the mobile app <NUM> in a wide variety of different or other ways as indicated by block <NUM>.

Mobile app <NUM> then processes the cart fill parameter to identify a particular harvester <NUM> to which the empty receiving vehicle should proceed, as indicated by block <NUM>. In one example, mobile app <NUM> identifies the location closest to the empty receiving vehicle where a receiving vehicle being loaded by one of the harvesters will be filled to its target capacity, as indicated by block <NUM>. In another example, route generator <NUM> can generate a best route from the empty receiving vehicle to a location where the cart being filled by a harvester will reach its target capacity, as indicated by block <NUM>.

The fill parameter output system <NUM> may identify the particular harvester where the operator of the empty receiving vehicle is to drive to, as indicated by block <NUM>.

Route generator <NUM> may consider the location of the other receiving vehicles in the field. For instance, the mobile app <NUM> on each receiving vehicle may communicate the current position of the corresponding receiving vehicle on which it resides to other receiving vehicles in the area so that mobile apps on those other receiving vehicles can determine whether a different receiving vehicle is closer or further away from a specific harvester in the field. Considering the locations of other receiving vehicles is indicated by block <NUM> in the flow diagram of <FIG>. The cart fill parameter can be processed in other ways to identify where the operator of the receiving vehicles should drive as well, as indicated by block <NUM>.

Mobile app <NUM> then provides the information to user interface control system <NUM> which generates an output on user interface mechanisms <NUM> to the operator of the receiving vehicle (e.g., to the operator of a towing vehicle), as indicated by block <NUM>. The output may identify the time and/or location where the cart currently being filled by a particular harvester may reach its target capacity, as indicated by block <NUM>. The output may identify a harvester that the operator of the empty receiving vehicle is to drive to, as indicated by block <NUM>. The output may identify a specific or best route <NUM>, or the output may identify a wide variety of other information <NUM> as well.

Mobile app <NUM> may use communication system <NUM> to generate an output to other vehicles or systems as well, as indicated by block <NUM>. For instance, mobile app <NUM> may generate an output indicating that mobile app <NUM> is instructing the operator of the empty receiving vehicle to proceed to a particular harvester so that other mobile apps on other receiving vehicles can consider that in identifying how the operator of those other receiving vehicles should proceed.

<FIG> shows one example of a mobile device, in the form of a tablet computer <NUM>. Tablet computer <NUM> includes a screen <NUM> which can be a touch screen or a pen-enabled interface that receives inputs from a pen or stylus. Computer <NUM> can also use an on-screen virtual keyboard. Of course, computer <NUM> might also be attached to a keyboard or other user input device through a suitable attachment mechanism such as a wireless link or USB port, for instance. Computer <NUM> can also illustratively receive voice inputs as well.

In the example shown in <FIG>, computer <NUM> generates a display that displays a message <NUM> instructing the operator to proceed to a particular harvester ("Harvester <NUM>") and provides two actuators <NUM> and <NUM> that the operator can actuate. In one example, actuator <NUM> can be actuated so that the mobile app shows the location where Harvester <NUM> will be when its corresponding receiving vehicle is filled to its target capacity. Actuator <NUM> can be actuated to have route generator <NUM> generate a best route to the location of harvester <NUM> when the harvester's receiving vehicle is at its target capacity. In the example shown in <FIG>, the operator has actuated actuator <NUM> so that mobile app <NUM> uses mapping system <NUM> to generate a map display <NUM>. Map display <NUM> shows a current location <NUM> of Harvester <NUM> and a current location <NUM> of the receiving vehicle on which computer <NUM> resides. Map display <NUM> also displays a route <NUM> that can be taken by the empty receiving vehicle to reach a location <NUM> where the receiving vehicle currently being filled by harvester <NUM> will be at its target capacity.

<FIG> shows another example of a user interface display that can be generated by mobile app <NUM> on computer <NUM>. In the example shown in <FIG>, mobile app <NUM> generates a user interface display that has a first indicator <NUM> that indicates how much further a first harvester (Harvester <NUM>) needs to travel before its current receiving vehicle has reached its target capacity. Indicator <NUM> is a similar indicator, but showing how far another harvester (Harvester N) will travel before the receiving vehicle that it is currently filling with material will reach its target capacity. Mobile app <NUM> can also use mapping system <NUM> to generate a map display <NUM> that shows the current locations <NUM> of Harvester <NUM> and the location <NUM> where the receiving vehicle currently being filled by Harvester <NUM> will reach target capacity. Map display <NUM> also shows a current location <NUM> of Harvester N and a location <NUM> where Harvester N will be when its current receiving vehicle reaches target capacity. In the example shown in <FIG>, the map display <NUM> also shows a current location <NUM> of the receiving vehicle on which computer <NUM> resides. In addition, map display <NUM> can show a first route <NUM> that Harvester <NUM> will follow to reach the location <NUM> where its receiving vehicle will reach target capacity. Map display <NUM> can also show a second route <NUM> that Harvester N will follow to reach the location <NUM> where its current receiving vehicle will reach target capacity. The operator of the receiving vehicle on which computer <NUM> resides can use map display <NUM> and the information provided by indicators <NUM> and <NUM> to decide where to proceed in order to assist one of the harvesters illustrated on map display <NUM>.

The user interface displays shown in <FIG> and <FIG> are only examples and a wide variety of other user interface displays can be generated as well.

It can thus be seen that the present description describes a system in which a material loading vehicle generates a fill parameter indicative of at least one of when or where that material loading vehicle will be when the receiving vehicle that it is currently filling reaches a target capacity. That information can be output to a mobile app (which may be a companion app or a stand alone mobile app) on mobile devices carried by other receiving vehicles so that operators of those receiving vehicles can best plan their routes.

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 interface displays 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 them has speech recognition components, the mechanisms can be actuated using speech commands.

It will be noted the data stores can each be broken into multiple data stores.

<FIG> is a block diagram of harvester <NUM>, shown in previous FIGS. , except that it communicates with elements in a remote server architecture <NUM>. In an 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 previous FIGS. 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 the servers 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 previous FIGS. and they are similarly numbered. <FIG> specifically shows that data store <NUM>, other systems <NUM>, and other parts of the harvester <NUM> shown in previous FIGS. can be located at a remote server location <NUM>. Also, other receiving vehicle(s) <NUM>, with mobile device(s) <NUM> and operator(s) <NUM> can be disposed on architecture <NUM> as well. 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 previous FIGS. 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 items are located, the items can be accessed directly by harvester <NUM>, through a network (such as a wide area network or a local area network), the 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 <NUM> comes close to the fuel truck for fueling, the system automatically collects the information from the harvester <NUM> 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 <NUM> until the harvester <NUM> enters a covered location. The harvester <NUM>, itself, can then send the information to the main network.

It will also be noted that the elements of previous FIGS. or portions of them, can be disposed on a wide variety of different devices. Some of those devices include servers, desktop computers, laptop computers, tablet computers, or other mobile devices, such as palm top computers, cell phones, smart phones, multimedia players, personal digital assistants, etc..

<FIG> is a simplified block diagram of one illustrative example of a handheld or mobile computing device that can be used as a user's or client's hand held device <NUM>, in which the present system (or parts of it) can be deployed. For instance, a mobile device can be deployed in the operator compartment of harvester <NUM> for use in generating, processing, or displaying the spout and flap and turn data. <FIG>, <FIG>, and <FIG> are examples of handheld or mobile devices.

<FIG> provides a general block diagram of the components of a client device <NUM> that can run some components shown in previous FIGS. , that interacts with them, or both. In the device <NUM>, a communications link <NUM> is provided that allows the handheld device to communicate with other computing devices and under some embodiments provides a channel for receiving information automatically, such as by scanning. Examples of communications link <NUM> include allowing communication though one or more communication protocols, such as wireless services used to provide cellular access to a network, as well as protocols that provide local wireless connections to networks.

In other examples, applications can be received on a removable Secure Digital (SD) card that is connected to an interface <NUM>. Interface <NUM> and communication links <NUM> communicate with a processor <NUM> (which can also embody processors/servers from previous FIGS. ) along a bus <NUM> that is also connected to memory <NUM> and input/output (I/O) components <NUM>, as well as clock <NUM> and location system <NUM>.

I/O components <NUM>, in one example, are provided to facilitate input and output operations. I/O components <NUM> for various examples of the device <NUM> can include input components such as buttons, touch sensors, optical sensors, microphones, touch screens, proximity sensors, accelerometers, orientation sensors and output components such as a display device, a speaker, and or a printer port. Other I/O components <NUM> can be used as well.

Memory <NUM> stores operating system <NUM>, network settings <NUM>, applications <NUM>, application configuration settings <NUM>, data store <NUM>, communication drivers <NUM>, and communication configuration settings <NUM>. Memory <NUM> can include all types of tangible volatile and non-volatile computer-readable memory devices. Memory <NUM> can also include computer storage media (described below). Memory <NUM> stores computer readable instructions that, when executed by processor <NUM>, cause the processor to perform computer-implemented steps or functions according to the instructions. Processor <NUM> can be activated by other components to facilitate their functionality as well.

<FIG> is one example of a computing environment in which elements of previous FIGS. , or parts of it, (for example) can be deployed. With reference to <FIG>, an example system for implementing some embodiments includes a computing device in the form of a computer <NUM> programmed to operate as discussed above. Components of computer <NUM> may include, but are not limited to, a processing unit <NUM> (which can comprise processor or servers from pervious FIGS. ), a system memory <NUM>, and a system bus <NUM> that couples various system components including the system memory to the processing unit <NUM>. The system bus <NUM> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. Memory and programs described with respect to previous FIGS. can be deployed in corresponding portions of <FIG>.

Computer storage media includes hardware storage media including both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.

The computer <NUM> is operated in a networked environment using logical connections (such as a controller area network -CAN, local area network - LAN, or wide area network -WAN) to one or more remote computers, such as a remote computer <NUM>.

Claim 1:
A combination of a mobile harvester (<NUM>), a first receiving vehicle (<NUM>) and a second receiving vehicle (<NUM>),
wherein the mobile harvester (<NUM>) comprises:
a material conveyance subsystem (<NUM>) configured to convey material from the harvester (<NUM>) to a first receiving vehicle (<NUM>) through a spout;
a fill sensor (<NUM>) configured to generate a fill level sensor signal indicative of a fill level of material in the first receiving vehicle (<NUM>);
a fill level detector (<NUM>) configured to identify an overall fill level in the first receiving vehicle (<NUM>) based on the fill level sensor signal and to generate an overall fill level sensor signal indicative of the overall fill level; characterised in that it further comprises a fill parameter generator (<NUM>) configured to generate a fill parameter indicative of when or where the first receiving vehicle (<NUM>) will reach a given fill level based on the overall fill level sensor signal; and
a communication system (<NUM>) configured to communicate the fill parameter to a mobile application (<NUM>) running on a mobile device (<NUM>) in the second receiving vehicle (<NUM>);
and wherein the mobile application (<NUM>) on the mobile device (<NUM>) in the second receiving vehicle (<NUM>) comprises a fill parameter output system (<NUM>) configured to generate an output of an indication of the fill parameter to an operator of the second receiving vehicle (<NUM>) through a user interface mechanism (<NUM>).