Patent Description:
It is often desirable to know the trajectory of a sports ball (e.g., a golf ball, hereinafter simply referred to as a "ball") as it moves through the air for several reasons. In general, various types of hardware equipment, such as radar or cameras, can be used to measure a large number of instant locations of the ball as during a shot. The measured data can then be combined through using software to create a trajectory for the ball.

To calculate a trajectory that is as accurate as possible, it is helpful to know the wind conditions, as having that information reduces the number of free parameters used by the physics model in the software uses to calculate the trajectory of the ball. Furthermore, there may be situations in which a player may want to obtain information about a "normalized" version of their shot (i.e., a version that is compensated for the weather conditions and the type of ball being used), for example, to be able to better compare two individual shots to determine how certain types of adjustments the player makes to their posture or equipment affect their shots. Having accurate information about the wind speed and direction is important in such a determination.

In some physics models, the wind speed is a free parameter, i.e., the wind vector is unknown and is estimated based on the wind speed and direction that best fits the parts of the trajectory observed by the radar and/or optical sensors. <CIT> describes systems, methods, and devices for providing an adjusted yardage recommendation (AYR) to a golfer prior to a golf shot. AYRs are determined based on predicted golf ball trajectories that are modeled from a golfer's golf ball launch data, using non-classical mathematical approximation methods. Each of the modeled trajectories are unique, and result in personalized AYR values that are personalized to each individual golfer, even where two golfers hit a ball with the same club the same distance while having two different ball flights. Devices that can perform the methods of the present invention include rangefinder devices and/or portable computing devices, such as a smartphone. Systems can include a rangefinder device and a portable computing device, in which the rangefinder device determines the line-of-sight distance and angle of elevation to a target and communicates the same to the portable computing device, which calculates the AYR. <CIT> describes a system and method for using weather applied metrics for determining the impact of weather conditions on the flight of a ball at an outdoor sports venue. Historical and current data for weather parameters, including wind, air pressure, humidity, temperature, and precipitation, are obtained to calculate the influence of each parameter on the flight of a ball. The influences of each of the parameters are summed to model the flight of the ball based on the current weather conditions. Weather instruments, such as weather sensors, anemometers, LiDAR and SODAR devices, weather consoles, data routing devices, and processors can be included in a system for using weather applied metrics to predict the flight of a ball based on current weather conditions. <CIT> describes sensors in a golf teeing booth that are used to: detect that a ball has be driven and estimate a predicted ball landing point on a golf practice range. A mobile unmanned golf ball retrieval vehicle, sometimes referred to as a gofer, determines a precise ball location on the field and reports the results to a control system. The control system updates the golfer's score based on the determined precise ball location.

Wind velocity estimation using the systems and techniques described in this document can provide one or more advantages, including avoiding volatility in wind estimates associated with performing physics modeling using data from only a single trajectory at a time. Note that a small deviation in the data measured by the radar(s) and/or camera(s) for a single shot might result in a wildly inaccurate wind estimate using traditional techniques. Using the systems and techniques described in this document can improve the estimation of wind speeds and/or directions, which enables more accurate calculations in which wind forms a factor, such as for ball trajectory determination.

In some aspects, the techniques described herein relate to a method for estimating wind velocity, including: obtaining measurements indicating two or more trajectories traversed by flying balls; determining individual wind velocity estimates for the two or more trajectories, wherein the determination includes comparing a model acceleration of the ball with an observed acceleration of the ball, derived from the measurements; and calculating the aggregated wind velocity estimate as a weighted average of the determined two or more individual wind velocity estimates. The aggregated wind velocity estimate is used for generating ball trajectory information to be presented on an output device.

In some embodiments, the trajectory measurements are made at least in part by a radar and/or a camera.

In some embodiments, determining an individual wind velocity estimate comprises solving an optimization problem that involves minimizing a loss function that compares the model acceleration of the ball with the observed acceleration of the ball.

In some embodiments, the model acceleration is calculated as a sum of an acceleration component due to gravity, an acceleration component due to drag, and an acceleration component due to lift.

In some embodiments, the optimization problem, in addition to optimizing for wind velocity, optimizes for an initial spin rate of the ball, a spin decay factor of the ball, and/or a spin angle of the ball.

In some embodiments, each of the two or more trajectories fulfill a minimum criterion with respect to a carry distance and/or a minimum observed fraction of the trajectory length.

In some embodiments, the two or more trajectories include trajectories for which measurements have been collected during a pre-defined time window.

In some embodiments, the pre-defined time window has a size of approximately <NUM>-<NUM> minutes.

In some embodiments, the aggregated wind velocity estimate is calculated in response to a new trajectory being generated by a flying ball.

In some embodiments, calculating the aggregated wind velocity estimate occurs at regular time intervals.

In some embodiments, the method further comprises using the aggregated wind velocity estimate as a starting wind velocity estimate for a subsequent trajectory estimation.

In some embodiments, the method further comprises using the aggregated wind velocity estimate to model a normalized trajectory that is not being affected by any wind.

In some embodiments, the weighted average is determined using an exponential moving average.

In some embodiments, separate aggregated wind velocity estimates are determined for different parts of a playing area.

In some aspects, the techniques described herein relate to a computer software product that when executed causes a data processing apparatus associated with a wind aggregator to perform one or more of the methods described above.

In some aspects, the techniques described herein relate to a system for estimating wind velocity, including: obtaining means, determination means, and calculating means. The obtaining means obtain measurements indicating two or more trajectories traversed by flying balls. The determination means determine individual wind velocity estimates for the two or more trajectories. The determination comprises comparing a model acceleration of the ball with an observed acceleration of the ball, derived from the measurements. The calculating means calculate an aggregated wind velocity estimate as a weighted average of the determined two or more individual wind velocity estimates.

In some aspects, the techniques described herein relate to a system for estimating wind velocity, comprising: means for generating an aggregated wind velocity estimate for two or more individual wind velocity estimates, produced for two or more measured trajectories of balls, in accordance with a model of ball acceleration and an observed ball acceleration; and means for providing ball trajectory information prepared in accordance with the aggregated wind velocity estimate.

Other features and advantages of the invention will be apparent from the description and drawings, and from the claims.

The various embodiments of the invention pertain to techniques for estimating wind velocity, based on recorded data about trajectories traversed by a ball, such as a golf ball. In general, data captured by sensors, such as cameras and/or radars, as a ball flies through the air, is processed by software to generate a trajectory for the ball. A wind velocity (that is, a wind vector describing both a wind direction and wind speed magnitude) is estimated from the data collected about each trajectory. Estimated wind velocities from several trajectories are then used to calculate an aggregated wind velocity estimate. As a result, a more robust and accurate wind velocity estimate can be obtained, compared to what can be derived from a single trajectory only. The aggregated wind velocity estimate can be updated over time, using data from the most recent set of traj ectories, such that an accurate wind velocity is always available for various purposes. The estimated wind velocity can be used for a variety of purposes, such as an initial wind velocity estimate when estimating subsequent trajectories, or to approximate a "normalized" trajectory that describes what the trajectory would have looked like, were there no wind.

<FIG> is a block diagram showing the general architecture of a wind estimation system <NUM>, in accordance with some embodiments. As can be seen in <FIG>, the wind estimation system <NUM> comprises a wind database <NUM> and a wind aggregator <NUM>, which communicate over a network <NUM>. Optionally, the wind estimation system <NUM> can include one or more sensors <NUM>, a shot normalizer <NUM>, and/or a client <NUM>, depending on the particular embodiment at hand. It should be noted that while only a single wind database <NUM>, a single wind aggregator <NUM>, etc., are illustrated in <FIG>, this is only done for purposes of explanation and in various implementations, the wind estimation system <NUM> can be much larger and include several of each of these (and sometimes additional types of) components.

In the embodiment shown in <FIG>, the wind database <NUM> contains current and historical data about individual trajectories, and calculated average wind velocities for multiple trajectories, as calculated by the wind aggregator <NUM>. However, it should be realized that in other embodiments, further data may be saved, such as the calculated wind velocities for individual trajectories, etc., and further weather-related data, such as temperature, humidity, and/or time stamps for individual trajectories, etc. Thus, the embodiment shown in <FIG> should not be considered limiting. The wind aggregator <NUM> obtains data collected by the one or more sensors <NUM> about individual trajectories for balls and applies a physics model <NUM> to the data, to determine an estimated wind velocity for the individual trajectories. The wind aggregator <NUM> then calculates a weighted average of the individual estimated wind velocities as an aggregated wind velocity estimate, which can subsequently be used for various purposes. A more detailed description of the wind aggregator <NUM> in accordance with some implementations will be described below with respect to the flowchart of <FIG>.

The wind database <NUM> and the wind aggregator <NUM> communicate over the network <NUM>, which can be any combination of wired and/or wireless networks, including local networks, such as intranets, or global networks, such as the Internet. The network <NUM> can also include any combination of public and/or private networks. These various types of network configurations are familiar to those having ordinary skill in the art.

The wind estimation system <NUM> can optionally include a physical or virtual client <NUM>, which can be used to display data relating to, for example, single shots, individual or aggregated wind velocities, statistics, player data, etc. on a user interface. Various software applications can run on the client <NUM> to display the data in a preferred way to a user of the wind estimation system <NUM>. <FIG> and <FIG> show examples of windows that can be displayed to a user on the user interface, in response to a selection being made by the user. In <FIG>, the user has selected to view data for an individual shot.

More specifically, <FIG> shows measured positions of a ball along a trajectory. The length of the shot is shown on the horizontal axis (i.e., the Z-axis) and the height of the shot is shown on the vertical axis (i.e., the Y-axis). In addition, the user has an option of selecting further information to be displayed, such as lift, drag, and wind, which are illustrated by the arrows along the trajectory. <FIG> shows a similar view to that of <FIG>, but in this case, the user has selected to view how the ball moves sideways (i.e., in the horizontal plane) during a shot, which is illustrated by the X-axis of <FIG>. Conceptually, this can be thought of as having a bird's eye view, looking straight down at the ball during the shot. In some implementations, the views of <FIG> can be combined into a 3D representation of the trajectory, where all three axes are shown at once, and the user can select different vantage points from which the ball trajectory can be viewed. The display of the trajectory and any optional additional information can be done in a virtual reality or an augmented reality system provided by using the client <NUM>.

Some embodiments of the wind estimation system <NUM> include a shot normalizer <NUM>, which can be used to determine a "normalized" trajectory, in which the aggregated wind velocity estimate has been "subtracted" from a recorded trajectory to determine what the trajectory would have looked like, were there no wind. The client <NUM> can be used to visualize such information to a user of the wind estimation system <NUM>. <FIG> show corresponding user interface views to those of <FIG>, respectively. However, in this case, the user has selected to show a comparison between two trajectories for the ball; one measured trajectory <NUM> (as shown in <FIG>) and one "normalized" trajectory <NUM>. The normalized trajectory <NUM> displays what the shot would have looked like, were there no wind. That is, the calculated wind velocity is "subtracted" before displaying the shot to the user on the user interface. The user can select whether to view the original shot <NUM>, the normalized shot <NUM>, or a comparison between the two, as shown in <FIG> on the user interface, to gain valuable information that will inform the user about how to adjust their technique or choice of clubs, for example.

As was mentioned above, the wind estimation system <NUM> obtains input data from a set of sensors <NUM> that capture data about a ball in flight through a three-dimensional (3D) space. The ball can be, for example, a golf ball or another type of object that is struck, kicked, or thrown (e.g., a baseball, a soccer ball, or a football/rugby ball) to travel through the air. In some implementations, the 3D space is a golf practice area, such as a golf driving range; a grass field; or another open area into which objects can be launched. For example, the 3D space can be a playing area for a sport, such as a golf course, where the ball is struck from a launch area, such as a golf tee for a particular hole on the golf course, or an intermediate landing point for a golf ball in play on the course, to a target, such as the cup at the end of the particular hole on the golf course or an intermediate landing point for a golf ball in play on the course. Other implementations are also possible, such as the launch area being one of multiple designated tee areas along a tee line where golfers can hit golf balls into an open field, or the launch area being one of multiple designated tee areas in the stands at a sports stadium where golfers can hit golf balls over and onto the playing field of the sports stadium.

Typically, two or more sensors, such as cameras (e.g., stereo camera pairs), radar devices (e.g., Doppler radar devices), or combinations thereof (e.g., a camera used to sense an angle to the ball in combination with a radar used to sense a distance to the ball), are connected to the wind estimation system <NUM>, either directly as shown in <FIG>, or through one or more computing devices, which may perform various levels of processing on the data collected by the sensors <NUM> prior to sending the processed data to the wind aggregator <NUM> of the wind estimation system <NUM>.

Generally, the sensors <NUM> are located close to the launch area for the ball. However, in some implementations, one or more of the sensors <NUM> can be located along one or both sides of the 3D space, and/or on the other side of the 3D space opposite the launch area. For example, at a golf tournament, the camera can be located behind the green, looking back at the golfer, assuming that shots will be hit towards the green. Thus, in various implementations, the sensors can observe and track objects that move away from a sensor, toward a sensor, and/or through the field of view of a sensor.

The sensors <NUM> may have different sensitivity (e.g., different image sensor resolutions), and be of varying types (e.g., radars, cameras, or combinations thereof) which may affect the quality of the data that gets transmitted to the wind estimation system <NUM>. However, the sensitivity of the sensors <NUM> does not affect the how the wind aggregator <NUM> operates, which will be described in further detail below with reference to <FIG>. Thus, many variations of sensor setups and configurations will be apparent to those having ordinary skill in the art, based on the situation at hand.

Distinct types of computers can be used in the system. As used herein, a "computer" can include a server computer, a client computer, a personal computer, embedded programmable circuitry, or a special purpose logic circuitry. <FIG> is a schematic diagram of a data processing system including a data processing apparatus <NUM>, which represents an implementation of the wind aggregator <NUM>. The data processing apparatus <NUM> can be connected with one or more computers <NUM> through a network <NUM>.

The data processing apparatus <NUM> can include various software modules, which can be distributed between an applications layer and an operating system. These can include executable and/or interpretable software programs or libraries, including a program <NUM> that operates as a wind velocity estimation program for a single trajectory, or an aggregated wind velocity estimator, for example. The number of software modules used can vary from one implementation to another. Also, in some cases, the program <NUM> can be implemented in embedded firmware, and in other cases, the program <NUM> can be implemented as software modules that are distributed on one or more data processing apparatus connected by one or more computer networks or other suitable communication networks.

The data processing apparatus <NUM> can include hardware or firmware devices including one or more hardware processors <NUM>, one or more additional devices <NUM>, a non-transitory computer readable medium <NUM>, a communication interface <NUM>, and one or more user interface devices <NUM>. The processor <NUM> is capable of processing instructions for execution within the data processing apparatus <NUM>, such as instructions (e.g., of the program <NUM>) stored on the non-transitory computer readable medium <NUM>, which can include a storage device such as one of the additional devices <NUM>.

In some implementations, the processor <NUM> is a single or multicore processor, or two or more central processing units (CPUs). The data processing apparatus <NUM> uses its communication interface <NUM> to communicate with one or more computers <NUM>, for example, over the network <NUM>. Thus, in various implementations, the processes described can be run in parallel or serially, on a single or multi-core computing machine, and/or on a computer cluster/cloud, etc..

Examples of user interface devices <NUM> include a display, a touchscreen display, a speaker, a microphone, a tactile feedback device, a keyboard, a mouse, and a headset or heads-up display of a virtual reality or augmented reality environment system. Moreover, the user interface device(s) need not be local device(s) <NUM> but can be remote from the data processing apparatus <NUM>, e.g., user interface device(s) <NUM> accessible via one or more communication network(s) <NUM>. For example, the user interface device(s) <NUM>/<NUM> can be a smartphone or a tablet computer of the user, e.g., for an augmented reality implementation. The data processing apparatus <NUM> can store instructions that implement operations as described in this document, for example, on the non-transitory computer readable medium <NUM>, which can include one or more additional devices <NUM>, for example, one or more of a floppy disk device, a hard disk device, an optical disk device, a tape device, and a solid-state memory device (e.g., a RAM drive).

Moreover, the instructions that implement the operations described in this document can be downloaded to the non-transitory computer readable medium <NUM> over the network <NUM> from one or more computers <NUM> (e.g., from the cloud). In some implementations, the data processing apparatus <NUM> is a smartphone or a tablet computer. In some implementations, the RAM drive is a volatile memory device to which the instructions are downloaded each time the computer is turned on.

<FIG> is a flowchart illustrating a method <NUM> performed by the wind aggregator <NUM> when determining an aggregated wind velocity estimate, in accordance with some embodiments. As can be seen in <FIG>, the method <NUM> starts by obtaining <NUM> sensor data for two or more ball trajectories, collected by the sensors <NUM>, as described above. The obtaining <NUM> can involve retrieving the data from another computer/system or from local memory where that data has been actively pushed, or the obtaining <NUM> can involve passively receiving the data on an ongoing basis. Depending on the embodiment at hand, the sensor data may be pre-processed to various degrees by other computing devices prior to being obtained by the wind aggregator <NUM>, or it may be obtained as raw data and the wind aggregator <NUM> can operate directly on that raw data from the sensors <NUM>.

In some embodiments, this pre-processing can include, for example, noise reduction, as the parameters measured by the sensors can often be noisy due to a number of factors, such as the hardware of the cameras (e.g., the type of image sensor affects the resolution, i.e., the accuracy of where the center of the ball is in the images), the mathematical model of the camera (i.e., a pinhole camera is assumed) used when converting camera images to distances, the accuracy by which directions/vectors can be determined, etc. Therefore, pre-processing of the sensor data in terms of noise reduction may be beneficial before the sensor data is sent to the wind aggregator <NUM>, so that the observed data from the sensors <NUM> is in some sense enhanced compared to the raw data recorded by the sensors <NUM>.

Such noise reduction may involve, for example, selecting a number of points along a measured trajectory, fitting a polynomial to those points, and then determining a difference value between a large number of measured points along the trajectory and the corresponding points along the fitted polynomial, for example, using a least squares difference method or another statistical method serving that same general purpose. This method can be repeated a number of times and with different polynomials being fitted to different measured points, until a satisfactory fitted polynomial has been found, and then the values from this resulting "polynomial trajectory" can be used as the input values to the wind aggregator <NUM>. What is considered as "satisfactory" in this context may depend on a number of factors, such as the available time and processing resources, but typically either a set number of iterations are performed, or the iterations continue until a certain predetermined quality threshold of the polynomial trajectory has been found, where the polynomial trajectory is considered to provide better input values to the wind aggregator <NUM> than the raw data measured by the sensors <NUM>. This noise filtering reduces the potential adverse effects of "outliers" resulting from poor measurement data from the sensors <NUM>, and provides better input parameters for the wind aggregator <NUM> to be used as described below.

A wind velocity estimate is determined <NUM> for each shot (i.e., for each trajectory) by the wind aggregator <NUM>. In doing so, the wind aggregator <NUM> uses a physics model <NUM>, in which the wind estimation is determined as a solution to an optimization problem, as will now be described. However, it should be noted that there may be other methods that can also be used to determine wind speed, as well as variants of the method that is presented herein, which can consider further physical parameters. Thus, the physics model <NUM> and optimization problem presented herein should not be construed as limiting the scope of the invention. Furthermore, for the sake of clarity, it should be noted again that the concept of velocity as used in this description refers to a vector quantity, i.e., a direction and a magnitude, and just not one or the other as may often be done in colloquial language use.

As was noted above, when calculating a wind velocity estimate for an individual shot, the wind estimation model uses an optimization problem, which compares a calculated model acceleration â of the golf ball to the actual observations of the acceleration from the trajectory a, and where it is desirable to minimize the squared difference loss function L: <MAT>.

The model acceleration, â(t)comes from <MAT> where.

The drag and lift accelerations are in turn defined as:
<MAT>
<MAT>
where.

In some implementations the wind velocity vector vw is assumed to have a y-component that is always set to zero. However, in other implementations, the wind velocity vector vw can have a non-zero y-component, that is, be a 3D vector, or be a vector that varies with the height above ground. As the skilled person knows, there are different standardized wind models that describe how the wind varies with the height above ground. For example, one such model is described in the "<NPL>.

The unknown variables to be optimized over are θ<NUM>, θ<NUM>, αd, vw. This means that the optimization will find the initial spin rate, the spin decay factor, the spin angle, and the wind velocity for a given trajectory.

The loss function L can be minimized, for example using a descent-based optimization method, such as a Newton, quasi-Newton, or gradient method, as are familiar to those having ordinary skill in the art.

In some implementations, a Huber loss function is used instead of using the quadratic loss directly, as the inventors have found the Huber loss function to improve.

numerical stability and convergence, due to being less sensitive to outlier data compared to the quadratic loss function.

In some implementations, directional vectors uD and uL are normalized into unit vectors after each optimization step in order to prevent the norm of the directional vector from becoming larger or smaller than <NUM>. This normalization has been proven to enhance numerical stability of the optimization model. In an alternative implementation, the directional vectors uD and uL can instead be represented by angles, which obviates the need to normalize the vectors. A full 3D vector can be represented by either two angles, or by a single angle if one assumes that the ball does not have any gyro spin (i.e., rotation along the direction of travel).

In some implementations, a limited-memory Broyden-Fletcher-Goldfarb-Shanno (BFGS) optimization algorithm with line-search (using strong Wolfe criteria) is used. This is an optimization algorithm of the quasi-Newton type, which uses an iterative method for solving unconstrained nonlinear optimization problems, and is familiar to those having ordinary skill in the art.

Some implementations use an L-BFGS algorithm, which is an algorithm that approximates the BFGS algorithm, using a limited amount of computer memory. The BFGS / L-BFGS algorithms are standard algorithms for solving unconstrained numerical optimization problems, and are familiar to those having ordinary skill in the art. It should be noted that the various embodiments of the invention described herein relate both to formulating the optimization problem (e.g., the loss function), and to selecting the particular optimization algorithm to use when solving the problem, and not exclusively to one or the other.

There are several standard algorithms that could be used in this context, which include: Gradient descent, Newtons method, BFGS, L-BFGS. It should be noted that this is not an exhaustive list of possible algorithms, but rather suggestions of suitable algorithms. When selecting what algorithm to use, there are a number of considerations that need to be made, such as how many iterations it takes for the algorithm to converge, how much time each iteration takes, how stable is the algorithm, etc..

For example, gradient descent tends to be relatively stable but typically takes many iterations to converge. However, each iteration is usually fast to compute. But overall, the time for it converge is the usually the longest among the algorithms listed above. Newtons method converges fast but can sometimes be unstable. Each iteration is also expensive to compute to compared to the other methods. BFGS converges almost as fast as Newtons method and is more stable. Each iteration is much less expensive than Newtons method, but a bit more expensive than Gradient descent. In time, BFGS usually converges the fastest. As was mentioned above, L-BFGS is a slight modification of BFGS to make algorithm faster and use less memory. Such efficiency considerations are often important for use cases, and the L-BFGS algorithm can therefore often be a better choice than the conventional BFGS algorithm.

Two significant challenges involve how to manage the amount of noise and how to manage outliers in the data. These challenges are addressed by smoothing the data and using a Huber loss function, as described above, normalizing the spin vector to prevent it from diverging from a unit vector, and using only those shots that can provide accurate wind estimates, as will be described in further detail below.

Further, it should be noted that while the spin magnitude, αm(t), of the ball is expressed above as a linear function in the described embodiment, it can be any decreasing function of t, such as exponential decay, quadratic decay, etc., in other, alternative embodiments.

Since the observed acceleration by the sensors <NUM> is subject to noise, some implementations use a polynomial moving-window approach to reduce the noise. In particular, a Savitzky-Golay filter can be applied to data points collected by the sensors <NUM> for the purpose of smoothing the data. This is achieved through convolution, by fitting successive sub-sets of adjacent data points with a low-degree polynomial by the method of linear least squares. When the data points are equally spaced, an analytical solution to the least-squares equations can be found, in the form of a single set of "convolution coefficients" that can be applied to all data sub-sets, to give estimates of the smoothed signal (or derivatives of the smoothed signal) at the central point of each sub-set. In other implementations, noise reduction can be achieved, for example, by using convolution with a Gaussian kernel, or by using a moving average window. The selection of a size of the window and the degree of the polynomial typically depends on the time resolution and noise level of the sensors <NUM>, and will thus vary based on the particular setup at hand. However, it is considered that such a selection of parameters can be done by the skilled artisan without undue experimentation.

Returning now to <FIG>, once several wind velocity estimates have been determined, the wind aggregator <NUM> calculates <NUM> an aggregated wind velocity estimate. In some implementations the aggregated wind velocity estimate is calculated in a two-step process. First, an average wind velocity is calculated, using all the wind velocities computed during a time window representing the N last minutes. This average wind velocity is a "raw wind velocity" value for the time window. The length of the time window depends on the number of shots needed to make accurate wind estimates. The longer the time window, the more likely it is that a sufficient number of shots occur during that time window. In general, more shots tend to lead to better estimates. What is considered a sufficient number of shots in this context depends largely on the accuracy of the tracking sensor. However, it should be noted that as the time window increases, the wind might change during the time window, which can lead to an incorrect wind estimate because the assumption that the wind is constant during the time window no longer holds true. Thus, it is important to find a good balance between these competing factors. Some implementations use a fixed time window, while other implementations use a dynamic time window can be dynamic. For example, the time window can be made dependent on the number of shots available, such that it becomes shorter when more shots are available. In some implementations, N is approximately <NUM>-<NUM> minutes.

Next, an Exponential Weighted Moving Average (EWMA) is applied to this time series to obtain the aggregated wind velocity estimate. The EWMA is chosen as it is simple to implement and makes it possible to place a greater weight and significance on the most recent data points, rather than applying an equal weight to all observations in the period. However, the EWMA is merely one of many models that can be used and that many others are apparent to those having ordinary skill in the art. For example, in some implementations, a moving average can be used, with weights such that more recent data points have a higher weight, for example, [<NUM>, <NUM>, <NUM>] when averaging three data points.

In some implementations, only wind velocity estimations for individual shots that have a minimum length are used in calculating the aggregated wind velocity estimate. The reason being that for shorter shots, the ball has a lower velocity, and thus the influence on the wind velocity of the estimated spin will increase, leading to an increase in the uncertainty for the estimated wind velocity. As a result, a shot that is too short, may actually have a negative impact on the estimated wind velocity for the shot, and it is therefore better not to include that shot in the calculations. Exactly what is considered as "long enough" in this context is a parameter that can be determined by the skilled artisan using experimentation, but one example criterion is a carry distance of at least <NUM> meters with at least <NUM> % of the trajectory being observed (as opposed to being estimated/extrapolated) by the sensors <NUM>. However, this of course also depends on the sensitivity and noise levels of the sensors <NUM>. While <NUM>% may be suitable for one type of sensor, there may be other sensors where smaller or larger carry distances and/or percentages can be used.

Once the weighted average wind velocity has been computed, it can be stored <NUM> in the wind database <NUM>, displayed to a user on the client <NUM> (or apparatus <NUM> or device <NUM>), and/or be used by the shot normalizer <NUM>, as discussed above with reference to <FIG> and <FIG>, respectively, which ends the process. Typically, the wind database <NUM> also stores the time when the weighted average wind velocity was calculated. Typically, the process <NUM> runs on a schedule, for example, when N seconds have elapsed since the most recent average wind velocity was computed. Alternatively, the process can run whenever a new shot is recorded. Of course, these are merely two examples, and there may be many other triggering mechanisms that can be envisioned by those having ordinary skill in the art for when the process <NUM> should be run.

In some implementations, each time the process <NUM> is run, it uses the data collected for any shots that have occurred since the previous time the process <NUM> was run, which ensures that all shots that fulfill the eligibility criteria (such as a carry distance of at least <NUM> meters with at least <NUM>% of the trajectory observed, as discussed above) will be taken into consideration.

As was mentioned above, the aggregated wind velocity estimate uses recent shots only. Therefore, in some implementations, any aggregated wind velocity estimate value has an expiration time (for example, <NUM> minutes) if no new shots have occurred (and no new aggregate wind velocity estimate has been computed). But of course, this expiration parameter is configurable.

In some implementations, every time the wind aggregator <NUM> processes a new shot using the physics model <NUM>, the most recent aggregated wind velocity estimate is used as an initial wind velocity in a first iteration of a converging computational model, such as the one described above. Therefore, the aggregation method described herein can be used with any physics model for which a current wind estimate is an input.

Further, as was mentioned above, one use of the aggregated wind velocity estimate is to use it as an input in a shot normalizer <NUM> to calculate a normalized shot. When determining the normalized shot by the shot normalizer <NUM>, the aggregated wind velocity that was used as the initial wind velocity in the physics model for that shot can be used. The reason for choosing this aggregated wind velocity estimate for normalization purposes, rather than a more recent one, is because this aggregated wind velocity estimate was the best possible wind velocity estimate at the time of the shot. A more recent aggregated wind velocity estimate might be affected by subsequent shots, and the wind may have changed since the shot was made, and not accurately reflect the wind conditions at the time of the shot. Shot normalization is merely one application in which the aggregated wind velocity estimate can be used, and various other uses of the aggregated wind velocity estimate can be made. In any case, the resulting normalized shot (or other shot data resulting from other uses of the aggregated wind velocity estimate) can be displayed to the user on the client <NUM> (or apparatus <NUM> or device <NUM>), and/or be further processed to yield useful information to the user.

Typically, the aggregated wind velocity estimate is calculated as a single value for an entire, playing area. However, as a playing area (e.g., a range) may be fairly large, the wind may vary between different parts of the playing area, such as the outer edges and the middle, for example. Therefore, in some implementations, the aggregated wind velocity estimate can be calculated as separate estimations for different subsections of a playing area, using shot data from each respective subsection only and the wind database may contain data about what part of the playing area the aggregated wind velocity estimate applies to. The number of subsections can vary, for example, depending on the size of the playing area, or the specific layout and configuration of the playing area. For example, the playing area can be divided into different regions based on where the shots are being hit from, and each region can have its own wind estimate, as described herein. In some cases, regions may overlap. It should be noted that this type of division into regions assumes that the wind either is constant or depends on the altitude (but it is still constant at a predetermined altitude). In practice, golf shots are long and there may be different wind conditions at the start and end of a ball trajectory (i.e., the hitting area, and where the ball lands, respectively) which, for example, may depend on the surrounding terrain (trees, buildings, etc.). The general principles described herein apply also in these situations, but more sophisticated modeling may be needed to account for the effect of wind variations along the trajectory.

The present invention also relates to a computer software function for estimating wind velocity according to what has been described above. Such a computer software function is then arranged to, when executing, perform the above-described obtaining trajectories, determining individual wind velocity estimates, and calculating an aggregated wind velocity estimate. The computer software function is arranged to execute on physical or virtual hardware of the wind aggregator <NUM> of system <NUM> and/or the data processing apparatus <NUM>, as described above.

Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented using one or more modules of computer program instructions encoded on a non-transitory computer-readable medium for execution by, or to control the operation of, data processing apparatus. The computer-readable medium can be a manufactured product, such as hard drive in a computer system or an optical disc sold through retail channels, or an embedded system. The computer-readable medium can be acquired separately and later encoded with the one or more modules of computer program instructions, such as by delivery of the one or more modules of computer program instructions over a wired or wireless network. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, or a combination of one or more of them.

The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a runtime environment, or a combination of one or more of them. In addition, the apparatus can employ various computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

A computer program (also known as a program, software, software application, script, or code) can be written in any suitable form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any suitable form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, subprograms, or portions of code).

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and one or more processors of any suitable digital computer. Generally, a processor will receive instructions and data from a read-only memory (ROM) or a random-access memory (RAM) or both. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; CD-ROM and DVDROM disks; network attached storage; and various forms of cloud storage.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., LCD (liquid crystal display), OLED (organic light emitting diode) or other monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in various forms, including acoustic, speech, or tactile input.

Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described is this specification, or any suitable combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any suitable form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network ("LAN") and a wide area network ("WAN"), an internetwork (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

While this specification contains many implementation details, these should not be construed as limitations on the scope of the invention or of what may be claimed, but as descriptions of features specific to implementations of the invention. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub combination or variation of a sub combination. Thus, unless explicitly stated otherwise, or unless the knowledge of one of ordinary skill in the art clearly indicates otherwise, any of the features of the embodiment described above can be combined with any of the other features of the embodiment described above.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and/or parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and the described program components and systems can be integrated together in a single software product or packaged into multiple software products.

Claim 1:
A method for estimating wind velocity, comprising:
obtaining (<NUM>) measurements indicating two or more trajectories traversed by flying balls;
determining (<NUM>) individual wind velocity estimates for the two or more trajectories, wherein the determining comprises comparing a model acceleration of the ball with an observed acceleration of the ball, derived from the measurements;
calculating (<NUM>) an aggregated wind velocity estimate as a weighted average of the determined two or more individual wind velocity estimates; and
using (<NUM>) the aggregated wind velocity estimate for generating ball trajectory information to be presented on an output device.