Wind speed estimation

Abstract

A method and apparatus are provided that implement or use a technique for estimating wind speed and include a computer program product. Measurements are obtained that indicate two or more trajectories through which a flying ball passes. A wind speed estimate for each of the two or more trajectories is determined, the determination including comparing a modeled acceleration of the ball to an observed acceleration of the ball derived from the measurements. An aggregated wind speed estimate is calculated as a weighted average of the determined wind speed estimates for the two or more. The aggregated wind speed estimate is used to generate ball trajectory information presented to an output device.

Description

[Technical Field]

[0001] The present invention relates to estimating wind speed and direction, and more particularly to estimating wind speed and direction as a sports ball travels through the air. [Background technology]

[0002] For various reasons, it is commonly desirable to know the trajectory of a sports ball (e.g., a golf ball, hereafter simply referred to as the "ball") as it moves through the air. Typically, various types of hardware equipment, such as radar or cameras, can be used to measure the multiple instantaneous positions of the ball during a shot. The measurement data can then be combined using software to create a trajectory for the ball.

[0003] In order to calculate the most accurate trajectory possible, it is useful to know the wind conditions because having this information reduces the number of free parameters used by the physics model used in the software to calculate the ball's trajectory. Furthermore, a player may want to obtain information about a "normalized" version of their shot (i.e., a version compensated for weather conditions and the type of ball used) so that, for example, they can better compare two shots to determine how the player's adjustments to their posture or equipment affect those shots. Having accurate information about wind speed and direction is important in making such decisions.

[0004] In some physical 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 portion of the trajectory observed by radar and / or optical sensors. Summary of the Invention [Means for solving the problem]

[0005] Wind speed estimation using the systems and techniques described herein can provide one or more advantages, including avoiding the variability in wind speed estimation associated with performing physical modeling using only data from a single trajectory at a time. It should be noted that small deviations in data measured by radar(s) and / or camera(s) in a single shot can result in highly inaccurate wind speed estimates using conventional techniques. By using the systems and techniques described herein, wind speed and / or direction estimation can be improved, thereby allowing for more accurate calculations when wind is a factor, such as in ball trajectory determination.

[0006] In some aspects, the technology described herein relates to a method for estimating wind speed, comprising obtaining measurements indicative of two or more trajectories traversed by a flying ball, determining a wind speed estimate for each of the two or more trajectories including comparing a model acceleration of the ball to an observed acceleration of the ball derived from the measurements, and calculating the aggregated wind speed estimate as a weighted average of the determined two or more respective wind speed estimates. The aggregated wind speed estimate is used to generate ball trajectory information presented on an output device.

[0007] In some embodiments, the trajectory measurements are performed at least in part by radar and / or cameras.

[0008] In some embodiments, determining each wind speed estimate includes solving an optimization problem that involves minimizing a loss function that compares a model acceleration of the ball to the observed acceleration of the ball.

[0009] In some embodiments, the model acceleration is calculated as the sum of a gravity acceleration component, a drag acceleration component, and a lift acceleration component.

[0010] In some embodiments, the optimization problem optimizes for the initial spin rate of the ball, the spin decay coefficient of the ball, and / or the spin angle of the ball in addition to optimizing for wind speed.

[0011] In some embodiments, each of the two or more trajectories meets minimum criteria for a minimum observed fraction of flight distance and / or trajectory length.

[0012] In some embodiments, the two or more trajectories include trajectories in which measurements were collected during a predefined time window.

[0013] In some embodiments, the predefined time window is about 2-4 minutes.

[0014] In some embodiments, the aggregated wind speed estimate is calculated in response to a new trajectory generated by the flying ball.

[0015] In some embodiments, calculating the aggregated wind speed estimates occurs at regular time intervals.

[0016] In some embodiments, the method further includes using the aggregated wind speed estimate as a starting wind speed estimate for subsequent trajectory estimations.

[0017] In some embodiments, the method further includes using the aggregated wind speed estimates to model a normalized trajectory that is not affected by any wind.

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

[0019] In some embodiments, separate aggregated wind speed estimates are determined for different portions of the play area.

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

[0021] In some aspects, the technology described herein relates to a system for estimating wind speed, including an acquiring means, a determining means, and a calculating means. The acquiring means acquires measurements indicative of two or more trajectories traversed by a flying ball. The determining means determines a wind speed estimate for each of the two or more trajectories. The determining includes comparing a model acceleration of the ball derived from the measurements to an observed acceleration of the ball. The calculating means calculates an aggregate wind speed estimate as a weighted average of each of the two or more determined wind speed estimates.

[0022] In some aspects, the technology described herein relates to a system for estimating wind speed, the system including: means for generating an aggregated wind speed estimate based on a ball acceleration model and an observed acceleration of the ball obtained by two or more respective wind speed estimates for two or more measured ball trajectories; and means for providing prepared ball trajectory information based on the aggregated wind speed estimate.

[0023] The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims. [Brief explanation of the drawings]

[0024] [Figure 1] FIG. 1 is a schematic diagram of a wind estimation system according to some embodiments. [Figure 2] FIG. 1 is a schematic diagram of a wind aggregator data processing system according to some embodiments. [Figure 3] 10 is a flowchart illustrating the operation of a wind aggregator in determining an aggregated wind speed estimate, according to some embodiments. [Figure 4A]1 illustrates a portion of a user interface displaying the measured trajectory of the ball, as well as information about lift, drag, and wind, according to some embodiments. [Figure 4B] 1 illustrates a portion of a user interface displaying the measured trajectory of the ball, as well as information about lift, drag, and wind, according to some embodiments. [Figure 5A] 10A-10C illustrate portions of a user interface displaying a measured trajectory and a normalized trajectory, respectively, according to some embodiments. [Figure 5B] 10A-10C illustrate portions of a user interface displaying a measured trajectory and a normalized trajectory, respectively, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0025] Like reference symbols in the various drawings refer to like elements.

[0026] Various embodiments of the present invention relate to a technique for estimating wind speed based on recorded trajectory data of a ball (e.g., a golf ball). Generally, as a ball flies through the air, data captured by sensors such as cameras and / or radar is processed by software to generate a trajectory of the ball. Wind speed (i.e., a wind vector describing the wind direction and magnitude) is estimated from data about each collected trajectory. The estimated wind speeds from several trajectories are then used to calculate an aggregated wind speed estimate. Thus, a more robust and accurate wind speed estimate can be obtained compared to wind speeds that can be derived from each trajectory alone. The aggregated wind speed estimate can be updated over time using data from the most recent set of trajectories to consistently provide accurate wind speeds for various purposes. The estimated wind speed can be used for various purposes, such as an initial wind speed estimate when estimating subsequent trajectories or a “normalized” trajectory that approximately describes a trajectory in calm conditions.

[0027] Figure 1 is a block diagram illustrating the general architecture of a wind estimation system 100 according to some embodiments. As shown in Figure 1, the wind estimation system 100 includes a wind database 102 and a wind aggregator 104 communicating over a network 114. Optionally, the wind estimation system 100 may include one or more sensors 106, shot normalizers 110, and / or clients 112, depending on the particular embodiment at hand. It should be noted that while Figure 1 only shows the wind databases 102, wind aggregators 104, etc., this is for illustrative purposes only, and in various implementations, the wind estimation system 100 may be much larger and include several of these (and possibly other types of) components.

[0028] In the embodiment shown in FIG. 1 , the wind database 102 includes current and historical data for each trajectory, as well as a calculated average wind speed for multiple trajectories calculated by the wind aggregator 104. However, it should be appreciated that other embodiments may store additional weather-related data, such as the calculated wind speed for each trajectory, as well as temperature, humidity, and / or timestamps for each trajectory. Accordingly, the embodiment shown in FIG. 1 should not be considered limiting. The wind aggregator 104 obtains data about each ball trajectory collected by one or more sensors 106 and applies a physics model 108 to the data to determine an estimated wind speed for each trajectory. The wind aggregator 104 then calculates a weighted average of each estimated wind speed as an aggregated wind speed estimate, which can then be used for various purposes. Some embodiments of the wind aggregator 104 are described in more detail below with reference to the flowchart of FIG. 3 .

[0029] The wind database 102 and the wind aggregator 104 communicate over a network 114, which may be any combination of wired and / or wireless networks, including a local network such as an intranet, or a global network such as the Internet. The network 114 may also include any combination of public and / or private networks. These various types of network configurations are well known to those skilled in the art.

[0030] The wind estimation system 100 may optionally include a physical or virtual client 112 for displaying data related to single shots, individual or aggregated wind speeds, statistical data, player data, etc. on a user interface. Various software applications may be executed on the client 112 to display the data in a manner preferred by a user of the wind estimation system 100. Figures 4A-4B and 5A-5B show examples of windows that may be displayed to a user on a user interface in response to a selection made by the user. In Figures 4A-4B, the user has selected to view data for a single shot.

[0031] More specifically, FIG. 4A shows the measured position of the ball along its 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). Additionally, the user may select additional information to display, such as lift, drag, and wind, which are indicated by arrows along the trajectory. FIG. 4B shows a view similar to FIG. 4A, except that the user has selected to view how the ball moves laterally (i.e., in the horizontal plane) during the shot, which is indicated by the X-axis in FIG. 4A. Conceptually, this can be thought of as having a bird's-eye view, looking straight at the ball during the shot. In some implementations, FIGS. 4A-4B may be combined into a 3D representation of the trajectory, with all three axes shown at once, allowing the user to select different vantage points to view the ball's trajectory. Display of the trajectory and any additional information may be performed using a virtual or augmented reality system provided by client 112.

[0032] Some embodiments of the wind estimation system 100 include a shot normalizer 110 for determining a “normalized” trajectory that “subtracts” an aggregated wind speed estimate from the recorded trajectory to determine what the trajectory would have been if there had been no wind. The client 112 can be used to visualize such information to a user of the wind estimation system 100. FIGS. 5A-5B show user interfaces corresponding to FIGS. 4A-4B, respectively. However, in this case, the user has chosen to show a comparison between two trajectories of the ball: one measured trajectory 502 (shown in FIGS. 4A-4B) and one “normalized” trajectory 504. The normalized trajectory 504 displays what the shot would have looked like if there had been no wind. That is, the calculated wind speed is “subtracted” before displaying the shot to the user on the user interface. The user can choose whether to view the original shot 502, the normalized shot 504, or a comparison of the two, and obtain useful information that may inform the user on how to adjust, for example, their technique or club selection, as shown in Figures 5A-5B on the user interface.

[0033] As described above, wind estimation system 100 receives input data from a set of sensors 106 that capture data about a ball traveling through a three-dimensional (3D) space. The ball may be, for example, a golf ball or another type of object that is hit, kicked, or thrown to travel through the air (e.g., a baseball, soccer ball, or football / rugby). In some implementations, the 3D space is a golf driving range, such as a golf driving range, a grass field, or another open area from which objects can be launched. For example, the 3D space may be a playing area of ​​a sport such as a golf course, where holes are hit from a launch area, such as a golf tee or an intermediate landing point for the ball in play, on a particular hole on a golf course to a target, such as a cup at the end of the particular hole being played on the golf course or an intermediate landing point for the ball in play. Other implementations are possible, for example, the launch area is one of multiple designated teeing areas along a tee line where golfers can hit balls into an open field, or the launch area is one of multiple designated teeing areas on a stadium stand where golfers can hit balls onto a playing field in a sports arena.

[0034] Typically, two or more sensors, such as cameras (e.g., a stereo camera pair), radar devices (e.g., a Doppler radar device), or a combination thereof (e.g., a camera to sense the ball angle combined with radar to sense the ball distance), are connected to the wind estimation system 100 as shown in FIG. 1 or via one or more computing devices that can perform various levels of processing on the data collected by the sensors 106 before transmitting the processed data to a wind aggregate 104 of the wind estimation system 100.

[0035] Typically, the sensors 106 are located near the ball launch area. However, in some implementations, one or more sensors 106 may 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, in a golf tournament, a camera may be located behind the green, facing the golfer, assuming the shot is being hit toward the green. Thus, in various implementations, the sensor may observe and track objects moving away from, toward, and / or through the field of view of the sensor.

[0036] The sensors 106 may have different sensitivities (e.g., different image sensor resolutions) and may be of various types (e.g., radar, camera, or a combination thereof), which may affect the quality of the data transmitted to the wind estimation system 100. However, the sensitivity of the sensors 106 does not affect the way the wind aggregator 104 operates, as will be described in more detail below with reference to FIG. 3. Thus, many variations in sensor setup and configuration will be apparent to those skilled in the art, based on the situation at hand.

[0037] Different types of computers can be used in the system. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. As used herein, a "computer" can include a server computer, a client computer, a personal computer, an embedded programmable circuit, or a special-purpose logic circuit. Figure 2 is a schematic diagram of a data processing system including a data processing device 200, representing an embodiment of the wind aggregator 104. The data processing device 200 may be connected to one or more computers 290 via a network 280.

[0038] Data processing device 200 may include various software modules that may be distributed between the application layer and the operating system. These may include executable and / or interpretable software programs or libraries, including, for example, program 230 that operates as a single-trajectory wind speed estimation program or an aggregated wind speed estimator. The number of software modules used may vary depending on the implementation. Also, in some cases, program 230 may be implemented in embedded firmware, while in other cases, program 230 may be implemented as software modules distributed across one or more data processing devices connected by one or more computer networks or other suitable networks.

[0039] Data processing apparatus 200 may include hardware or firmware devices including one or more hardware processors 212, one or more additional devices 214, a non-transitory computer-readable medium 216, a communication interface 218, and one or more user interface devices 220. Processor 212 is capable of processing instructions for execution within data processing apparatus 200, such as instructions stored on non-transitory computer-readable medium 216 (e.g., instructions of program 230), which may include a storage device such as one of additional devices 214.

[0040] In some implementations, processor 212 is a single processor or a multi-core processor, or two or more central processing units (CPUs). Data processing device 200 uses its communication interface 218 to communicate with one or more computers 290, for example, via network 280. Thus, in various implementations, the processes described may be executed in parallel or serially on single-core or multi-core computing machines, and / or computer clusters / clouds, etc.

[0041] Examples of user interface devices 220 include displays, touchscreen displays, speakers, microphones, haptic feedback devices, keyboards, mice, and headsets or heads-up displays for virtual reality or augmented reality environment systems. Furthermore, the user interface device(s) need not be local device(s) 220 but may be remote from the data processing apparatus 200, such as, for example, user interface device(s) 290 accessible via one or more communication network(s) 280. For example, the user interface device(s) 220 / 290 may be, for example, a user's smartphone or tablet computer for an augmented reality implementation. The data processing apparatus 200 may, for example, store instructions for performing the operations described herein on a non-transitory computer-readable medium 216, including, for example, one or more additional devices 214, such as, for example, a hard disk device, an optical disk device, a tape device, and a solid-state memory device (e.g., a RAM drive).

[0042] Additionally, instructions for performing the operations described herein may be downloaded from one or more computers 290 (e.g., from the cloud) over a network 280 to the non-transitory computer-readable medium 216. In some implementations, the data processing device 200 is a smartphone or tablet computer. In some implementations, the RAM drive is a volatile memory device, and the instructions are downloaded each time the computer is powered on.

[0043] 3 is a flowchart illustrating a method 300 performed by the wind aggregator 104 in determining an aggregated wind speed estimate, according to some embodiments. As shown in FIG. 3, method 300 begins with acquiring 302 sensor data for two or more ball trajectories collected by sensors 106 as described above. Acquiring 302 may acquire data from another computer / system or from local memory to which the data has been actively pushed, or acquiring 302 may passively receive data on an ongoing basis. Depending on the embodiment at hand, the sensor data may undergo different degrees of pre-processing by other computing devices before being acquired by the wind aggregator 104, or it may be acquired as raw data, and the wind aggregator 104 may directly operate on the raw data from the sensors 106.

[0044] In some embodiments, such pre-processing may include, for example, noise reduction, since the parameters measured by the sensors are noisy due to many factors, such as the camera hardware (e.g., the type of image sensor affects the resolution, i.e., the accuracy of the location of the ball center in the image), the mathematical model of the camera used to convert the camera image to distance (i.e., a pinhole camera is assumed), determining the accuracy of the direction / vector, etc. Therefore, it is beneficial to perform noise reduction pre-processing on the sensor data before it is sent to the wind aggregator 104, which in some sense enhances the observation data from the sensors 106 compared to the original data.

[0045] Such noise reduction may involve, for example, selecting multiple points along the measurement trajectory, fitting a polynomial to those points, and determining the difference between a number of measurement points along the trajectory and corresponding points along the fitted polynomial, e.g., using least-squares difference or other general-purpose statistical methods. This method can be repeated many times, fitting different polynomials to different measurement points, until a satisfactory fitting polynomial is found, and the resulting "polynomial trajectory" values ​​can be used as input values ​​for the wind aggregator 104. What is considered "satisfactory" in this case may depend on many factors, such as available time and processing resources, but typically involves iterating either up to a predetermined quality threshold to find a polynomial track that is deemed to provide better input values ​​for the wind aggregator 104 than the original data measured by the sensors 106. This noise filtering reduces the potentially adverse effects of "outliers" due to imperfections in the measurement data from the sensors 106 and provides better input parameters for the wind aggregator 104, as explained below.

[0046] The wind aggregator 104 determines (304) a wind speed estimate for each shot (i.e., each trajectory). In this process, the wind aggregator 104 uses a physics model 108 in which the wind speed estimate is determined as a solution to an optimization problem, as described below. However, it should be noted that there may be other methods for determining wind speed, and variations of the method presented herein that can consider additional physical parameters. Therefore, the physics model 108 and optimization problem presented herein should not be construed as limiting the scope of the present invention. Furthermore, for clarity, it should be reiterated that the meaning of speed as used herein refers to a vector, i.e., direction and amplitude, rather than one or another as is often colloquially used.

[0047] As mentioned above, when calculating the wind speed estimate for a single shot, the wind speed estimation model uses a calculation model of the golf ball acceleration and trajectory.

number

number

number

number

number

number

number

number

number

number

number

number

number

[0048] In some embodiments, the wind speed vector v w is assumed to have its y component always set to zero. However, in other embodiments, the wind speed vector v w can have a non-zero y-component, i.e., a 3D vector, or a vector that varies with height above ground. As those skilled in the art know, there are different normalized wind models that describe how wind varies with height above ground. For example, the World Meteorological Organization (Geneva, Switzerland, 2008) describes such models in its "Guidelines for Meteorological Instruments and Observation Methods" WMO-No. 8.

[0049] The unknown variables to be optimized are θ1, θ2, and α d , v w This means that the optimization finds the initial spin rate, spin damping coefficient, spin angle, and wind speed for a specified trajectory.

[0050] The loss function L can be minimized using, for example, a descent-based optimization method such as Newton's method, quasi-Newton's method, or gradient methods, well known to those skilled in the art.

[0051] In some embodiments, rather than directly using the second-order loss, the inventors have found that using the Huber loss function can improve numerical stability and convergence because it is less sensitive to anomalous data compared to the second-order loss function.

[0052] In some embodiments, the direction vector u D and u L is made a unit vector after each optimization step to prevent the norm of the direction vector from becoming larger or smaller than 1. This normalization has been proven to increase the numerical stability of the optimization model. In an alternative implementation, the direction vector u D and u L can instead be expressed in terms of angles, which eliminates the need to normalize the vector. A full 3D vector can be expressed in terms of two angles, or a single angle if we assume that the ball has no gyroscopic spin (i.e., rotation along the direction of travel).

[0053] In some embodiments, the limited-memory Broyden-Fletcher-Goldfarb-Shanno (BFGS) optimization algorithm with line search (using the strong Wolfe criterion) is used, which is a quasi-Newton type optimization algorithm that uses iterative methods for solving unconstrained nonlinear optimization problems and is well known to those skilled in the art.

[0054] Some implementations use the L-BFGS algorithm, an algorithm that approximates the BFGS algorithm using a limited amount of computer memory. The BFGS / L-BFGS algorithm is a standard algorithm for solving unconstrained numerical optimization problems and is well known to those skilled in the art. It should be noted that the various embodiments of the invention described herein are not limited to one or the other with respect to both the formulation of the optimization problem (e.g., loss function) and the selection of the particular optimization algorithm used in solving this problem.

[0055] There are several standard algorithms that can be used in this context, including gradient descent, Newton's method, BFGS, and L-BFGS. It should be noted that this is not an exhaustive list of possible algorithms, but rather a suggestion of suitable algorithms. When choosing which algorithm to use, several considerations exist, including the number of iterations the algorithm takes to converge, the time each iteration takes, and the stability of the algorithm.

[0056] For example, gradient descent tends to be relatively stable but typically requires many iterations to converge. However, each iteration is typically computationally fast. Overall, however, the time to converge is typically the longest of the above algorithms. Newton's method converges quickly but can be unstable. Each iteration is also computationally expensive compared to the other methods. BFGS converges at roughly the same speed as Newton's method and is more stable. Each iteration is much cheaper than Newton's method, but slightly more expensive than gradient descent. In terms of time, BFGS typically converges the fastest. As mentioned above, L-BFGS is a slight modification of BFGS that speeds up the algorithm and uses less memory. Such efficiency considerations are often important for use cases, and therefore the L-BFGS algorithm can be a better choice than the traditional BFGS algorithm.

[0057] Two key challenges concern how to manage the amount of noise and how to manage outliers in the data, which are addressed by smoothing the data and using the Huber loss function as described above to normalize the spin vectors to prevent them from deviating from unit vectors, as explained in more detail below, and by using only those shots that provide accurate wind speed estimates.

[0058] Furthermore, the spin rate of the ball α m It should be noted that although (t) is represented above as a linear function in the above embodiment, in other alternative embodiments it may be any decreasing function of t, such as exponential decay, quadratic decay, etc.

[0059] Because the acceleration observed by the sensor 106 is subject to noise, some embodiments use a polynomial moving window approach to reduce noise. Specifically, a Savitzky-Golay filter can be applied to the data points collected by the sensor 106 to smooth the data. This is achieved by convolution, fitting successive subsets of adjacent data points with a low-order polynomial via linear least-squares fitting. If the data points are evenly spaced, an analytical solution to the least-squares equation can be found in the form of a single set of "convolution coefficients" that can be applied to all data subsets to give an estimate of the smoothed signal (or the derivative of the smoothed signal) at the center point of each subset, providing an estimate of the smoothed t_miN. In other embodiments, noise reduction can be achieved, for example, by using Gaussian core convolution or by using a moving average window. The selection of the window size and polynomial order typically depends on the time resolution and noise level of the sensor 106 and therefore varies based on the particular setup at hand. However, it is believed that such selection of parameters can be made by one of ordinary skill in the art without undue experimentation.

[0060] Returning now to FIG. 3 , once several wind speed estimates have been determined, the wind aggregator 104 calculates an aggregated wind speed estimate. In some embodiments, the aggregated wind speed estimate is calculated in a two-step process. First, all wind speeds calculated during a time window representing the last N minutes are used to calculate an average wind speed. This average wind speed is the “raw wind speed” value for the time window. The length of the time window depends on the number of shots required to make an accurate wind estimate. The longer the time window, the more likely it is that a sufficient number of shots will occur during that time window. In general, more shots tend to produce a better estimate. In this case, the degree to which a sufficient number of shots is considered depends primarily on the accuracy of the tracking sensors. However, it should be noted that increasing the time window can lead to inaccurate wind estimates because the wind may change during the time window, and the assumption that the wind is constant during the time window no longer holds. Therefore, it is important to find a good balance between these competing factors. Some embodiments use a fixed time window, while other embodiments use a dynamic time window. For example, the time window may depend on the number of available shots, with N being shorter as more shots are available. In some embodiments, N is about 2-4 minutes.

[0061] An exponentially weighted moving average (EWMA) is then applied to this time series to obtain an aggregated wind speed estimate. The EWMA is chosen because it is easy to implement and places more weight and importance on the most recent data points rather than applying the same weight to all observations in a time period. However, the EWMA is only one of many models that can be used, and many other models will be apparent to those skilled 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, e.g., when averaging three data points, the weights are 0.2, 0.3, and 0.5.

[0062] In some implementations, the aggregated wind speed estimate is calculated using only the wind speed estimates for each shot with a minimum length. This is because shorter shots have lower ball speeds, which increases the impact of estimated spin on wind speed and increases the uncertainty in the estimated wind speed. As a result, shots that are too short may actually negatively affect the estimated wind speed of the shot and should not be included in the calculation. While what constitutes "sufficiently long" in this context is a parameter that can be determined by one skilled in the art using experimentation, one exemplary criterion is a flight distance of at least 100 meters, within which at least 70% of the trajectory is observed (not estimated / estimated) by the sensor 106. Of course, this also depends on the sensitivity and noise level of the sensor 106. While 70% may be appropriate for some types of sensors, other sensors may exist that can use smaller or larger flight distances and / or percentages.

[0063] Once the weighted average wind speed is calculated, it is stored 308 in the wind database 102 and may be displayed to the user at the client 112 (or apparatus 200 or device 220) and / or used by the shot normalizer 110. The process then concludes as described above with reference to FIGS. 4A-4B and 5A-5B, respectively. Typically, the wind database 102 also stores the time at which the weighted average wind speed was calculated. Typically, process 300 is run according to a schedule, for example, when N seconds have elapsed since the most recent average wind speed was calculated. Alternatively, the process could be run each time a new shot is recorded. Of course, these are just two examples, and there may be many other trigger mechanisms that one skilled in the art can envision for when process 300 should be run.

[0064] In some embodiments, each time process 300 is run, it uses data collected about any shots that have occurred since the last time process 300 was run, thereby ensuring that all shots that meet the qualification criteria (e.g., at least 100 meters with at least 70% of the trajectory observed, as described above) are considered.

[0065] As noted above, aggregated wind speed estimates use only the most recent shots. Thus, in some implementations, any aggregated wind speed estimate has an expiration time (e.g., 20 minutes) if no new shots have occurred (and no new aggregated wind speed estimates have been calculated). However, of course, this expiration time parameter is configurable.

[0066] In some implementations, each time the wind aggregator 104 processes a new shot using the physics model 108, the most recent aggregated wind speed estimate is used as the initial wind speed in the first iteration of a convergent computational model, such as the one described above. Thus, the aggregated methods described herein can be used with any physics model that takes current wind estimates as input.

[0067] Furthermore, as described above, one use of the aggregated wind speed estimate can be used as input to the shot normalizer 110 to calculate a normalized shot. When determining a normalized shot by the shot normalizer 110, the aggregated wind speed used as the initial wind speed in the physical model of the shot can be used. This aggregated wind speed estimate is selected for normalization rather than a more recent one because it is the best wind speed estimate available at the time of the shot. The more recent aggregated wind speed estimate may be affected by subsequent shots, and the wind may have changed when the cut was made, so it may not accurately reflect the wind conditions at the time of the cut. Shot normalization is just one use for the aggregated wind speed estimate; various other uses of the aggregated wind speed estimate may be made. In any case, the resulting normalized shot (or other shot data resulting from other uses of the aggregated wind speed estimate) can be displayed to a user on the client 112 (or apparatus 200 or device 220) and / or further processed to provide useful information to the user.

[0068] Typically, the aggregated wind speed estimate is calculated as a single value for the entire play area. However, because the play area (e.g., the area) may be quite large, wind may vary between different portions of the play area, such as the outer edges and the center. Thus, in some implementations, the aggregated wind speed estimate may be calculated as separate estimates for different subsections of the play area, and using only shot data from each subsection, the wind database may include data regarding which portion of the play area the aggregated wind speed estimate applies to. The number of subsections may vary depending, for example, on the size of the play area or the specific layout and configuration of the play area. For example, as described herein, the play area may be divided into different regions based on shot locations, and each region may have its own wind estimate. In some cases, the regions may overlap. It should be noted that such region division schemes assume that the wind is constant or altitude-dependent (but constant at a given altitude). In reality, golf shots are long and have different wind conditions at the beginning and end of the ball trajectory (i.e., at the hitting area and where the ball lands, respectively), which may depend, for example, on the surrounding terrain (trees, buildings, etc.) The general principles described herein also apply in these situations, although more sophisticated modeling is required to account for the effects of wind variations along the trajectory.

[0069] The present invention also relates to computer software functionality for estimating wind speed in accordance with the above. Such computer software functionality is then configured, when executed, to execute the acquisition trajectories described above, determine individual wind speed estimates, and calculate an aggregated wind speed estimate. The computer software functionality is configured to run on the physical or virtual hardware of the wind aggregator 104 and / or data processing device 200 of the system 100, as described above.

[0070] The embodiments and functional operations of the subject matter described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or a combination of one or more of them. The embodiments of the subject matter described herein can be implemented using one or more computer program instruction modules encoded on a non-transitory computer-readable medium for a data processing device to perform or control the operation of the data processing device. The computer-readable medium can be a computer system hard drive, an optical disk sold through retail channels, or a manufactured product such as an embedded system. The computer-readable medium can be obtained separately and later encoded with one or more modules of computer program instructions, such as delivery of 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 one or more combinations thereof.

[0071] The term "data processing device" includes all means, devices, and machines for processing data, such as a programmable processor, a computer, or multiple processors or computers. In addition to hardware, a device may also include code that creates an execution environment for associated computer programs, such as code comprising processor firmware, a protocol stack, a database management system, an operating system, a runtime environment, or one or more combinations of these. Furthermore, the device may employ the infrastructures of various computing models, such as web services, distributed computing, grid computing, etc.

[0072] A computer program (also referred to as a program, software, software application, script, or code) can be written in any suitable programming language, including compiled, interpreted, declarative, or process languages, and can be arranged in any suitable form, including as an independent program or as modules, components, subroutines, or other units suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that stores other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the related program, or in multiple associated files (e.g., files storing one or more modules, subprograms, or portions of code). A computer program can be arranged to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communications network.

[0073] One or more programmable processors can execute the processes and logic flows described herein to perform functions by executing one or more computer programs and operating on input data to generate output. The processes and logic flows may also be performed by, and an apparatus may be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (special purpose integrated circuit).

[0074] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, as well as one or more processors of any suitable digital computer. Generally, a processor may receive instructions and / or data from a read-only memory (ROM), a random access memory (RAM), or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also receive data from, or be operatively coupled to, one or more mass storage devices used to store data, such as disks, magneto-optical disks, or optical disks, or both. However, a computer need not have such devices. Additionally, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices such as EPROM (erasable programmable read-only memory), EEPROM (electrically erasable read-only memory), and flash memory devices; magnetic disks such as internal hard disks or removable disks; magneto-optical disks; CD-ROM and DVD-ROM disks; network-attached storage; and various forms of cloud storage. Processors and memory can be supplemented and embedded by dedicated logic circuitry.

[0075] To interact with a user, embodiments of the subject matter described herein can be implemented on a computer that includes a display device for displaying information to a user, such as an LCD (liquid crystal display), OLED (organic light-emitting diode), or other display, and a keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices can also be used to interact with a user; for example, feedback provided to the user can be sensory feedback, such as visual feedback, auditory feedback, or haptic feedback, and input from the user can be received in various forms, including acoustic, speech, or tactile input.

[0076] A computing system may include clients and servers. Clients and servers are generally remote from each other and often interact through a communications network. The relationship of client and server arises by virtue of computer programs running on the respective computers and by virtue of the client-server relationship they have to each other. Embodiments of the subject matter described herein may be implemented in a computer with back-end components such as data servers (e.g., middleware components such as application servers), or front-end components such as client computers having a graphical user interface or web browser through which users can interact with implementations of the systems and techniques described herein, or a combination of one or more such back-end, middleware, or front-end components. The components of a system may be interconnected by any form or medium of digital data communication (e.g., a communications network). Examples of communications networks include local area networks (“LANs”) and wide area networks (“WANs”), internetworks (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer-to-peer networks).

[0077] While this specification contains many details of embodiments, these details should not be construed as limitations on the scope of the invention or the content that may require protection, but rather as descriptions of specific features of embodiments of the invention. Some features described herein in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented alone or in any suitable subcombination in multiple embodiments. Furthermore, even if protection is initially claimed, in some cases one or more features of the claimed combination may be deleted from the combination, and the claimed combination may refer to a subcombination or a variation of the subcombination. Thus, unless expressly stated otherwise or unless clearly indicated by the knowledge of one skilled in the art, any feature of the described embodiments may be combined with any other feature of the described embodiments.

[0078] Similarly, although the figures depict acts in a particular order, this should not be understood as requiring those acts to be performed in the order or sequence depicted, or to require that all of the depicted acts be performed to achieve a desired result. In certain situations, multitasking and / or parallel processing may be advantageous. Furthermore, the separation of various system components in the above-described embodiments should not be understood as requiring such separation in all embodiments; the described program components and systems may be integrated together in a single software product or packaged in multiple software products.

[0079] Thus, embodiments of the present invention have been described. Other embodiments are within the scope of the following claims. For example, while the above description focuses on wind speed estimation in the context of golfing, the described systems and techniques are applicable to other types of objects that move through the air and are affected by wind, such as baseball or skeet shooting, as well as non-sports applications. Furthermore, while the embodiments described herein use two sensors to measure the trajectory of the ball, it should be noted that other embodiments may measure angle and distance using a single sensor (e.g., Doppler radar), and no additional sensors are required. [Explanation of symbols]

[0080] 100 Wind Estimation System 102 Wind Database 104 Wind Aggregator 106 Sensors 108 Physical Model 110 Shot Normalizer 112 clients 114 Network 200 Data processing device 212 One or more hardware processors 214 one or more additional devices 216 Non-transitory computer-readable medium 218 Communication Interface 220 one or more user interface devices 230 Programs 280 Network 290 one or more computers

Claims

1. 1. A method for estimating wind speed, comprising: obtaining measurements indicative of two or more trajectories traversed by a flying ball; determining a wind speed estimate for each of the two or more trajectories, said determining including comparing a model acceleration of the ball with an observed acceleration of the ball derived from the measurements; calculating an aggregated wind speed estimate as a weighted average of each wind speed estimate of the two or more determined trajectories; and using the aggregated wind speed estimates to generate ball trajectory information that is presented on an output device.

2. The method of claim 1 , wherein the trajectory measurements are performed at least in part by one or more of radar, camera, or both.

3. Determining each wind speed estimate includes: The method of claim 1 , comprising solving an optimization problem involving minimizing a loss function that compares the model acceleration of the ball to the observed acceleration of the ball.

4. The method of claim 3 , wherein the model acceleration is calculated as the sum of a gravity acceleration component, a drag acceleration component, and a lift acceleration component.

5. 5. The method of claim 4, wherein the optimization problem, in addition to optimizing for wind speed, optimizes for one or more of the initial spin rate of the ball, the spin damping coefficient of the ball, the spin angle of the ball, and combinations thereof.

6. 6. The method of claim 1, wherein each of the two or more trajectories meets at least one minimum criterion of distance traveled and a minimum observed percentage of trajectory length.

7. The method of claim 1 , wherein the two or more trajectories include trajectories in which measurements were collected during a predefined time window.

8. The method of claim 7 , wherein the predefined time window is between 2 and 4 minutes.

9. The method of claim 1 , wherein calculating the aggregated wind speed estimate is performed in response to a new trajectory generated by a flying ball.

10. The method of claim 1 , wherein calculating the aggregated wind speed estimates is performed at fixed time intervals.

11. The method of claim 1 , further comprising using the aggregated wind speed estimate as a starting wind speed estimate for subsequent trajectory estimations.

12. The method of claim 1 , further comprising using the aggregated wind speed estimates to model a normalized trajectory that is not affected by any wind.

13. The method of claim 1 , wherein the weighted average is determined using an exponential moving average.

14. 6. A method according to any one of claims 1 to 5, wherein separate aggregated wind speed estimates are determined for different parts of the play area.

15. Computer software configured, when executed, to carry out the steps of the method of any one of claims 1 to 5.

16. 1. A system for estimating wind speed, comprising: receiving means for receiving measurements indicative of two or more trajectories traversed by a flying ball; determining means for determining a wind speed estimate for each of the two or more trajectories, said determining comprising comparing a model acceleration of the ball with an observed acceleration of the ball derived from the measurements; a calculation means for calculating an aggregated wind speed estimate as a weighted average of each wind speed estimate of the two or more determined trajectories; generating means for using the aggregated wind speed estimates to generate ball trajectory information for presentation on an output device.

Images