ADAPTIVE GOLF RANGE ANALYZER WITH AUTOMATIC INTEGRATION OF ENVIRONMENTAL FACTORS

Abstract

An automated method for predicting a flight distance of a projectile is described. The method includes: retrieving a set of baseline values, each baseline value associated with a set of baseline parameter values; retrieving a set of current parameter values; and calculating a predicted distance based at least partly on the baseline value, the set of baseline parameter values, and the set of current parameter values. An automated method for translating a current distance to a home distance includes: receiving a current distance; receiving a set of current parameter values; retrieving a set of baseline distances and associated baseline parameter values; and calculating a home distance based at least partly on the current distance, the set of current parameter values, and the set of baseline distances and baseline parameter values.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application Ser. No. 61/870,189, filed on Aug. 26, 2013 and U.S. Provisional Patent Application Ser. No. 61/974,958, filed on Apr. 3, 2014.

BACKGROUND OF THE INVENTION

Many golfers may wish to accurately determine the proper club or relative distance to play on a given shot. Even when a golfer is aware of certain factors (e.g., distance to the pin, selected club, etc.), the golfer may be unaware of and/or otherwise unable to utilize various other factors (e.g., environmental conditions relative to the golfer's typical round) to improve the club or distance determination.

Many current solutions do not account for various factors that may affect distance (e.g., environmental conditions, course information, etc.). In addition, existing solutions do not adaptively update prediction algorithms based on information received from users under various conditions. Furthermore, existing solutions fail to consider conditions associated with measured distances (e.g., environmental conditions).

Thus there is a need for an adaptive range finder that is able to account for any number of changing factors that may affect a range of a golf ball while incorporating a baseline range associated with a set of baseline conditions.

BRIEF SUMMARY OF THE INVENTION

Some embodiments of the present invention generally provide a way to determine a predicted distance under current conditions given a known distance under a set of baseline conditions. Alternatively, a current distance may be translated to a distance associated with a set of baseline conditions. Such conditions may include various appropriate elements (e.g., environments elements such as temperature, elevation, humidity, etc.).

In some embodiments a user may provide information regarding a “home” or “baseline” distance (e.g., a distance associated with a particular course) for a set of golf clubs (e.g., the average distance achieved by the user for each club). Such home information may be associated with a set of home conditions (e.g., temperature, elevation, etc.). The user may then travel to a different course (a “current” course) and receive a predicted distance for each club based on conditions at the current course (e.g., temperature, elevation, etc.).

Conditions may be determined automatically (e.g., based on sensor data, based on data retrieved from a network-connected source, etc.) or manually (e.g., a user may enter conditions using an appropriate interface).

During “play” a user may receive predictions and may also provide feedback regarding the predictions, as appropriate. In this way, prediction models may be improved using heuristic learning.

For instance, using golf as an example, a user may enter a course being played. Some embodiments may be able to retrieve information related to the course (e.g., layout including elevations, features such as trees, traps, long grass, etc., grounds keeping data such as fairway grass height, fringe height, green height, etc.), environmental data (e.g., rainfall over a preceding period, soil type, grass type, etc.). Such data may be applied to predictions in various appropriate ways.

As one example, driving distance may include an estimation of ball flight and an estimation of rolling distance based on the landing area associated with the ball flight prediction. Thus, if a prediction resulted in a shot landing in long grass, a short “roll” distance may be appended to the flight projection. In contrast, if a prediction resulted in a shot landing on a dry, burned out area of a fairway, the roll distance appended to the flight projection may be significant. Other factors, such as the slope of a landing area, may also be applied to such calculations, as appropriate.

As another example, a tennis-based application may consider court surfaces when determining the appropriate equipment to match a player's expectations (including distance from the racquet to the playing surface and any resulting bounce trajectory and/or distance) based on a practice court or home court (e.g., hard, clay or grass surfaces). Thus, a player with a known arm speed on a serve may be able to choose a different racquet, adjust string tension, and/or make other adjustments such that the known arm speed will result in the expected ball placement when serving.

As still another example, artillery predictions may account for various obstacles and/or other physical features (e.g., buildings, hills, etc.) that may affect projectile flight and/or destination. Similar adjustments may be made in other applications. For instance, by recognizing water hazards, trees, and/or other obstacles or features of a golf course. As additional examples, some embodiments may account for net height in tennis, be aware of goalpost dimensions in football, and/or otherwise account for features associated with a particular application.

Different embodiments may use different specific variables and calculations based on the specific application(s). Such calculations may include various linear combinations of variables, coefficients, and/or operations, as appropriate. Such calculations may be systematically improved using heuristic learning in some embodiments.

A first exemplary embodiment provides an automated method for predicting a flight distance of a projectile. The method includes: retrieving a set of baseline values, each baseline value associated with a set of baseline parameter values; retrieving a set of current parameter values; and calculating a predicted distance based at least partly on the baseline value, the set of baseline parameter values, and the set of current parameter values.

A second exemplary embodiment provides an automated method for translating a current distance to a home distance. The method includes: receiving a current distance; receiving a set of current parameter values; retrieving a set of baseline distances and associated baseline parameter values; and calculating a home distance based at least partly on the current distance, the set of current parameter values, and the set of baseline distances and baseline parameter values.

A third exemplary embodiment provides a range projection device including: at least one user interface (UI) element; a storage able to store a set of baseline values, wherein each baseline value is associated with a set of baseline parameter values; a set of data sources, wherein each data source is able to provide at least one current parameter value; and a calculation module adapted to determine a predicted distance based at least partly on the set of baseline values, the associated sets of baseline parameter values, and current parameter values.

A fourth exemplary embodiment provides a computer-implemented method for predicting a distance of a projectile. The method includes: retrieving at least one baseline value associated with a set of baseline parameter values; retrieving a set of current parameter values; and calculating at least one predicted distance based at least partly on the baseline value, the set of baseline parameter values, and the set of current parameter values, wherein each baseline value and each predicted distance is associated with a particular player from among a plurality of players and the plurality of players is associated with a particular event.

The preceding Brief Summary is intended to serve as a brief introduction to various features of some exemplary embodiments of the invention. Other embodiments may be implemented in other specific forms without departing from the spirit of the invention.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The novel features of the invention are set forth in the appended claims. However, for purpose of explanation, several embodiments of the invention are illustrated in the following drawings.

FIG. 1 illustrates a schematic block diagram of a conceptual system according to an exemplary embodiment of the invention;

FIG. 2 illustrates a schematic block diagram of a conceptual distributed system of some embodiments;

FIG. 3 illustrates a schematic block diagram of a conceptual user device of some embodiments;

FIG. 4 illustrates a schematic block diagram of a conceptual client-side system of some embodiments;

FIG. 5 illustrates a schematic block diagram of a conceptual server-side system of some embodiments;

FIG. 6 illustrates a data structure diagram of various data elements used by some embodiments;

FIG. 7 illustrates a flow chart of a conceptual process used by some embodiments to generate a range projection;

FIG. 8 illustrates a flow chart of a conceptual process used by some embodiments to provide data to a client;

FIG. 9 illustrates a flow chart of a conceptual process used by some embodiments to perform heuristic learning;

FIG. 10 illustrates a flow chart of a conceptual process used by some embodiments to provide data related to an event or location;

FIGS. 11-27 illustrate various user interface (UI) features that may be provided by some embodiments; and

FIG. 28 illustrates a schematic block diagram of a conceptual computer system used to implement some embodiments of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The following detailed description is of the best currently contemplated modes of carrying out exemplary embodiments of the invention. The description is not to be taken in a limiting sense, but is made merely for the purpose of illustrating the general principles of the invention, as the scope of the invention is best defined by the appended claims.

Various inventive features are described below that can each be used independently of one another or in combination with other features. Broadly, some embodiments of the present invention generally provide a way to determine a predicted distance under current conditions given a known distance under a set of baseline conditions. Alternatively, a current distance may be translated to a distance associated with a set of baseline conditions.

Although many examples below may refer to golf, one of ordinary skill in the art will recognize that adaptive distance projection may be applied to various other fields including other “ball” sports (e.g., field goals in football, string tension for tennis racquets, etc.), shooting or artillery, etc.

In addition, although many examples may refer to ball or projectile “flight”, one of ordinary skill in the art will recognize that some embodiments may be applied to factors such as rolling distance, bounce distance and/or trajectory, and/or other relevant determinations. In addition, such application may involve other factors than those described below.

Several more detailed embodiments of the invention are described in the sections below. Section I provides a conceptual description of hardware elements implemented by some embodiments. Section II then describes software systems provided by some embodiments. Next, Section III describes methods of operation provided by some embodiments. Section IV then describes various user interface elements of some embodiments. Lastly, Section V describes a computer system which implements some of the embodiments of the invention.

I. Hardware System

Sub-section I.A provides a conceptual description of a local system provided by some embodiments. Sub-section I.B then describes a distributed system provided by some embodiments. Lastly, sub-section I.C describes a user device of some embodiments.

A. Local System

FIG. 1 illustrates a schematic block diagram of a conceptual local system 100 according to an exemplary embodiment of the invention. Specifically, this figure shows a system that may be used during play or participation. As shown, the system may include a user device 110, which may include a set of user interface (UI) elements 120, a calculation module 130, one or more storages 140, a set of internal data sources 150, and a heuristics module 160. In addition, the system may include external data sources 170 and/or a remote heuristics module 180.

The user device 110 may be any device capable of receiving input from a user (and/or other sources), performing a set of calculations based on the inputs (and/or other data sources), and providing an output to the user. A user device may be, for instance, a smartphone, a tablet device, a PC, a dedicated electronic device, etc. The user device may be capable of executing an application including various sets of software instructions (and/or data elements) to perform operations on sets of data.

The UI elements 120 may include various appropriate input and/or output elements (e.g., touchscreens, keyboards, keypads, buttons, display screens, etc.). Such elements may receive inputs from a user and/or provide outputs to the user.

The calculation module 130 may be able to perform calculations based on inputs received through the UI elements 120, storages 140, internal data sources 150, and/or heuristics module 160. In some embodiments, the calculation module 130 may be able to predict a distance associated with a current set of conditions based at least partly on a baseline distance associated with a baseline set of conditions. Alternatively, the calculation module may be able to translate a distance based at least partly on a current set of conditions to a distance associated with a baseline set of conditions.

The storages 140 may be any elements capable of storing data. In some embodiments, the storages may be integrated elements of the user device 110. Alternatively, in some embodiments, the storages 140 may be external elements that are access using one or more network connections and/or other connections.

The internal data sources 150 may be capable of providing data regarding current conditions. Such data sources may include physical sensors included in (or connected to) the device 110 (e.g., temperature sensors, humidity sensors, global positioning system (GPS) sensors, etc.) and/or other appropriate local sources. In some embodiments, the data sources 150 may include (and/or be associated with) various software components (e.g., a program used to calculate elevation based at least partly on data received from one or more GPS sensors).

The heuristics module 160 may interact with the calculation module 130 and a remote heuristics module 180 to update various prediction parameters (e.g., coefficients, variables, etc.) based on measured results and/or other feedback.

The external data sources 170 may include various data sources that may be utilized by the user device 110 (e.g., a website or service that provides weather, elevation or altitude information, a temperature sensor accessible via a wireless link such as a Bluetooth connection, etc.). Such external data sources 170 may also include various remote (and/or third-party) servers that are able to interact with the calculation module 130. The external data sources 170 may be accessible over one or more communication networks (e.g., a wireless network, a cellular network, etc.).

The remote heuristics module 180 may collect and/or analyze data from various user devices 110 and/or external data sources 170. The heuristics module 180 may compare predicted to measured results (e.g., a user may obtain a prediction and then provide feedback by entering the actual measure distance) in order to update calculations used to predict distance.

One of ordinary skill in the art will recognize that system 100 is conceptual in nature and may be implemented in various appropriate ways. For instance, in some embodiments various other components may be included, various components may be omitted, multiple components may be combined into a single component, or a single component may be divided into multiple components. In addition, various different embodiments may include different communications pathways than shown.

System 100 may be implemented using various combinations of hardware elements (e.g., processing devices, storage devices, etc.) and/or software elements (e.g., instructions, data, etc.). The system may be implemented using various web-based components (e.g., browsers, plug-ins, etc.) to provide various system functions. The system (or various components thereof) may be implemented using applications (or “apps”), widgets, and/or other such elements that run on various user devices (e.g., smartphones, tablet devices, etc.).

B. Distributed System

FIG. 2 illustrates a schematic block diagram of a conceptual distributed system 200 of some embodiments. As shown, the system may include one or more user devices 210, a set of networks 220, one or more remote servers 230 associated with a set of storages 240, and one or more third-party servers 250 associated with a set of storages 260.

Each user device 210 may be similar to user device 110 described above. Each user device 210 may be associated with a different user. Alternatively, multiple user devices may be associated with a single user or a single device may be associated with multiple users.

Networks 220 may include various communication pathways such as local-area networks (e.g., Wi-Fi networks, networks of Bluetooth-connected devices, etc.), cellular networks, the Internet, etc. Such networks may be accessed using various appropriate communication interfaces, protocols, etc.

Some embodiments may include remote servers 230 that may perform various functions. For instance, a remote server may provide software and/or data to each user device 210 in order to provide the functionality of some embodiments. The remote server 230 may also be able to serve as the external data source 170 and/or heuristics module 160 described above. Thus the remote sever 230 may implement functions such as heuristic learning by evaluating data from multiple users. The remote servers may be able to access various storages 240 that may include data related to various users, equipment, courses, and/or other appropriate elements.

Some embodiments may be able to access third-party servers 250. Such third-party servers may have access to storages 260. Alternatively, in some embodiments a user device 210 and/or remote server 230 may access storages 260 through an application programming interface (API). The third-party servers 250 may provide data associated with various third-party sources (e.g., weather data, data regarding a course or field, data regarding equipment such as clubs or balls, etc.) and thus may serve as an external data source 170 as described above.

One of ordinary skill in the art will recognize that system 200 is conceptual in nature and may be implemented in various appropriate ways. For instance, in some embodiments various other components may be included, various components may be removed, multiple components may be combined into a single component, or a single component may be divided into multiple components. In addition, various different embodiments may include different communications pathways than shown.

C. User Device

FIG. 3 illustrates a schematic block diagram of a conceptual user device 300 of some embodiments. The user device 300 may be similar to device 110 and/or device 210 described above. As shown, the user device may include one or more control elements 310, a set of UI elements 320, one or more storage elements 330, and, in some embodiments, a communications module 340.

The user device 300 may be a multi-purpose device (e.g., a smartphone) that executes an application of some embodiments. Alternatively, the device may be a dedicated range finder device (and/or other prediction device).

The control element 310 may include any set of components that is able to execute instructions and/or process data. The control element may provide functionality described above in reference to user device 110 (e.g., a calculation module, heuristics module, etc.). The control element 310 may be able to retrieve data from internal sources (e.g., data sources 150 described above).

The UI elements 320 may include various user-accessible input elements (e.g., a touchscreen, a microphone, sets of buttons and/or keys, switches, etc.) and/or output elements (e.g., a display screen, speakers, etc.).

The storages 330 may be any elements that are able to store data and provide the data to other system components.

The optional communication module(s) 340 may allow the user device 300 to communicate with various external devices, elements, systems, etc. over various appropriate connections (e.g., wired connections, wireless connections, network connections, web-based connections, cellular network connections, etc.). For instance, the communication module 340 may be able to connect to and communicate across network 220 described above. Some embodiments may operate with or without the communication module, as appropriate. For instance, when used at a remote location where network service is not available, data (e.g., temperature, elevation, etc.) that may otherwise have been retrieved from an external source may be acquired in other ways (e.g., entered by a user, default or average values may be used, etc.).

One of ordinary skill in the art will recognize that system 300 is conceptual in nature and may be implemented in various appropriate ways. For instance, in some embodiments various other components may be included, various components may be removed, multiple components may be combined into a single component, or a single component may be divided into multiple components. In addition, various different embodiments may include different communications pathways than shown.

II. Software System

Sub-section I.A provides a conceptual description of a client-side system of some embodiments. Sub-section I.B then describes a server-side system of some embodiments. Lastly, sub-section I.C describes conceptual data structures used by some embodiments.

A. Client-Side

FIG. 4 illustrates a schematic block diagram of a conceptual client-side system 400 of some embodiments. As shown, the system may include a control module 410, a set of UI interfaces 420, various data elements 430, a set of local interfaces 440, and a set of communication modules 450.

The client-side system 400 may be implemented by a multi-purpose user device such as a smartphone, a dedicated range finder device, and/or other appropriate client devices.

The control module 410 may communicate among the other system elements 420-450, perform calculations and/or other operations, and/or direct the operations of various other system elements 420-450.

The UI interfaces 420 may include interfaces to various user-accessible input elements (e.g., a touchscreen, a microphone, sets of buttons and/or keys, switches, etc.) and/or output elements (e.g., a display screen, speakers, etc.).

The data elements 430 may include data used by the client of some embodiments (e.g., user data, course data, baseline conditions and data, etc.).

The optional local interfaces 440 may allow the system 400 to interact with various device elements (e.g., a temperature sensor, GPS sensors, etc.). In this way, the system may be able to collect data regarding current playing conditions.

The optional communication modules 450 may allow the client-side system 400 to communicate with various external elements (e.g., a remote server, third-party data source, etc.). Such pathways may allow for collection of current condition data, updates to models or equations, updates to product or course data, and/or other data. In addition, the communication modules 450 may allow the client to send analytic data to a remote server such that the data may be used in heuristic learning.

One of ordinary skill in the art will recognize that system 400 is conceptual in nature and may be implemented in various appropriate ways. For instance, in some embodiments various other components may be included, various components may be removed, multiple components may be combined into a single component, or a single component may be divided into multiple components. In addition, various different embodiments may include different communications pathways than shown.

B. Server-Side

FIG. 5 illustrates a schematic block diagram of a conceptual server-side system 500 of some embodiments. As shown, the system may include a control module 510, a set of communication modules 520, various data elements 530, and a set of remote interfaces 540.

The server-side system 500 may be implemented by a set of server devices (e.g., devices 230 described above). Such devices may be distributed across multiple locations.

The control module 510 may communicate among the other system elements 520-540, perform calculations and/or other operations, and/or control the operations of various other system elements 520-540.

The communication modules 520 may allow the server-side system 500 to communicate with various external elements (e.g., client devices, third-party servers, etc.). Such pathways may allow for provision of updates, collection of analytic data, etc.

The data elements 530 may include data used by the client of some embodiments (e.g., user data, course data, baseline conditions and data, etc.).

The remote interfaces 540 may allow the system 500 to access (or be accessed by) various external systems. For instance, in some cases a golf course may wish to collect data regarding playing distances for users that have played the course using a range finder of some embodiments.

One of ordinary skill in the art will recognize that system 500 is conceptual in nature and may be implemented in various appropriate ways. For instance, in some embodiments various other components may be included, various components may be removed, multiple components may be combined into a single component, or a single component may be divided into multiple components. In addition, various different embodiments may include different communications pathways than shown.

C. Data Structures

FIG. 6 illustrates a data structure diagram of various data elements 600 used by some embodiments.

As shown, in the example of FIG. 6, the data elements may include an equation element that references a set of operands (e.g., addition, subtraction, multiplication, etc.). Each operand may reference a set of sub-elements that may include parameters, coefficients, operators, etc. that may be associated with each operand.

In addition, the data elements may include a structure such as a “club” set (or other appropriate group) of elements that may include a number club sub-elements, one or more equations (each of which may include various operands, not shown). For instance, a club set may include a set of clubs that may be defined in various appropriate ways (e.g., as a default list, by user selection, retrieved from a manufacturer database, etc.), where each club has associated attributes (e.g., average distance, club weight, shaft type, etc.). An equation associated with the club set may account for specific variations associated with the clubs (e.g., due to club design, materials used, etc.).

In this example, projectile data elements (and sub-elements) may be included in the club set, but different embodiments may include such elements separately. Projectile data elements may include data regarding, for example, a golf ball (e.g., elasticity, wind resistance, etc.).

The data elements may also include a “course” set, which may include sub-elements such as a set of holes, equations, etc. Each hole may include various attributes. For instance, hole sub-elements may include data regarding hole length (which may be defined for multiple tee locations and/or pin locations), distance from/to various hazards (e.g., fairway and greenside sand traps, water hazards, out of bounds areas, etc.) or other physical features of the course, elevations at locations along the course, etc. An equation associated with a course may account for various course-specific factors that may affect distance (e.g., height of fairway grass, firmness of the ground, etc.).

Finally, as shown, the data elements may include a heuristic set, which may refer to various elements and/or equations. Each element of the heuristic set may include one or more equations, parameter values, predicted results, actual results, etc.

The data elements may be used by various system hardware and/or software components to perform various functions associated with providing features of some embodiments. In some embodiments, the data elements may refer to various conditions associated with the data element (e.g., temperature, humidity and elevation associated with a set of club distances).

One of ordinary skill in the art will recognize that the data elements and relationships shown in FIG. 6 are for example purposes only. Different embodiments may include various different data elements, which may be organized and related in various different ways.

Some embodiments may allow a user to set the data values in various appropriate ways. For instance, a user may define a set of clubs by adding each club individually and then entering attributes associated with the club. Alternatively, some or all data may be provided automatically. For instance, a golf course may compile and upload data that may then be automatically retrieved by a player upon visiting the course. As another example, golf club manufacturers may compile data regarding clubs and then each user may enter player-specific information (e.g., actual hitting distance). Such data may be updated in various appropriate ways (e.g., information may be downloaded at regular intervals such that club or course data reflects the latest information made available by the manufacturers or courses).

III. Methods of Operation

Some embodiments may use equation (1), below, to calculate an equivalent distance. Such an equivalent distance may refer to, for example, a predicted distance for a particular club based on a set of current conditions and a home distance for the particular club associated with a set of baseline conditions.

D_E=D_H·(1+Δ_P1·A_P1+Δ_P2·A_P2+ . . . )+Δ_P1·B_P1+Δ_P2·B_P2+ . . .   (1)

Where D_H is home distance, Δ_P1 is a difference between a current parameter value and a baseline parameter value for a first parameter, A_P1 is a coefficient associated with the first parameter and the home distance, B_P1 is a coefficient associated with the first parameter, etc.

In some embodiments, the coefficients may include various sub-elements that may be combined in various appropriate ways. For instance, if temperature is used as a parameter, temperature might affect air resistance and ball elasticity, and thus each affect may be added to produce a cumulative effect due to the change in that particular parameter.

Some embodiments may use equation (2), below, to calculate a home equivalent distance (also referred to as a “plays as” or PlaysAs™ distance).

D_H=(D_C−Δ_P1·B_P1−Δ_P2·B_P2− . . . )/(1−(Δ_P1·A_P1−Δ_P2·A_P2− . . . ))  (2)

Where D_c is the current distance (e.g., the distance of a hole being played), Δ_P1 is a difference between a current parameter value and a baseline parameter value for a first parameter, A_P1 is a coefficient associated with the first parameter and the home distance, B_P1 is a coefficient associated with the first parameter, etc.

In some cases, the values of Δ_P1, A_P1, B_P1, etc. may be the same for equations (1) and (2). In other words, a single set of coefficients may be used to calculate either a predicted distance or an equivalent distance.

Different embodiments may use various different parameters (e.g., temperature, elevation, humidity, barometric pressure, wind speed and/or direction, season, etc.) and/or various different numbers of parameters. For instance, some embodiments may use additional parameters than those described, while other embodiments may use even a single parameter. Coefficients may be calculated in various ways (e.g., specified, determined using measured values, etc.). Equations (1) and (2) may be used to calculate distances related to various applications (e.g., golf, football, tennis, ballistics, artillery, etc.). Various other operators (e.g., 1n(x), exponential functions, etc.) may be applied in various ways (e.g., to single parameters, to linear combinations of parameters, etc.).

Some embodiments may include calculations based on “local” parameters (e.g., elevation from a particular point on a golf course to another point on the golf course, aiming direction, etc.). In addition, different embodiments may calculate different components of a distance. For instance, some embodiments may calculate total distance, while other embodiments may calculate distance of flight and/or rolling distance. Each type of distance calculation may include one or more sets of calculations using the form of equations (1) and/or (2).

Some embodiments may be optimized for use by golfers. Such embodiments may predict distances for each club under the current conditions, based on a set of baseline data or may determine a relative or PlaysAs™ distance based on the current conditions relative the golfer's home course baseline conditions.

An exemplary golf embodiment may include temperature, elevation, and humidity as variables. Thus, based on equations (1) and (2) above, for a golf-oriented solution: P1 is temperature, A_P1=T_DHAdj, B_P1=T_yfd/T_tfd; P2 is elevation, A_P2=E_PHAdj/E_FDDen, B_P2=0; P3 is humidity, A_P3=H_PHAdj/H_HDDen, B_P3=0. Where some embodiments may set the values as follows: T_yfd=0.4, T_tfd=10, T_DHAdj=0.00105, E_PHAdj=0.1, E_FDDen=5000, H_PHAdj=0.007, and H_HDDen=0.6.

In addition, some golf embodiments may include another coefficient related to temperature that is related to elasticity of the golf ball, such a coefficient may also be specified as a sub-element of A_P1 (e.g., a first component of A_P1 may be due to air resistance, and a second component may be due to ball elasticity). In some embodiments the effect of ball elasticity may be proportional to temperature. In some embodiments, the effect of ball elasticity (and/or other parameters) may be specified by a set of values that depend on a parameter range. For instance, a change in temperature at a lower temperature range may have a greater effect on distance than the same absolute change in temperature at a higher temperature range.

In addition, some embodiments may be expanded to include other variables (e.g., rolling distance, course conditions, etc.) which may have associated coefficients, operations, etc.

Other embodiments may be optimized for other applications (e.g., other sports, ballistics, artillery, etc.).

FIG. 7 illustrates a flow chart of a conceptual process 700 used by some embodiments to generate a range projection. Such a process may be executed by a user device such as that described above in reference to FIG. 3, which may be included as part of a system such as those described in FIGS. 1-2.

Process 700 may begin, for instance, when a user launches a smartphone app of some embodiments, when a user turns on a dedicated device of some embodiments, and/or at other appropriate times. In some embodiments, the process may be executed based at least partly on data associated with a particular user (e.g., a set of clubs and distances associated with the user) and/or a particular establishment (e.g., a golf course).

Next, the process may retrieve (at 710) a prediction equation. Such an equation may specify various operands, coefficients, parameters, etc. Next, the process may retrieve (at 720) device data. Such data may include locally stored data (e.g., club data, user data, etc.) and/or locally determined data (e.g., temperature measurements from a sensor included in the device, position data based on GPS components of the device, etc.).

The process may then retrieve (at 730) external data. Such data may include data provided by various external sources (e.g., weather data from a reporting service, club data from a manufacturer, course data from a media resource, etc.). Such data may be retrieved across various communication links (e.g., Wi-Fi, Bluetooth, etc.) using various available networks (e.g., cellular communication networks, wireless networks, the Internet, etc.). In some embodiments, external data may be retrieved by sending a request to a server which then responds with the requested data.

Next, the process may receive (at 740) user inputs (e.g., wind speed and/or direction, temperature, club selection, etc.). User inputs may also include relative location information (e.g., a user may be able to select the first tee as a location within a recognized golf course).

The process may then generate (at 750) a prediction based on the retrieved and/or received information. In some embodiments, the prediction may be a predicted flight distance associated with a particular club under the current conditions. Alternatively, the prediction may be a distance that indicates how the current distance would be perceived on the player's home course (i.e., a PlaysAs™ distance).

The process may then provide (at 760) the prediction to the user (e.g., by displaying the predicted value on a display screen of the user device).

In some embodiments, the process may then receive (at 770) user feedback (e.g., the user may indicate the actual distance achieved under the conditions), send data (e.g., condition data, course data, input data, feedback data, etc.) to the server and then end. Such feedback and collected data may be used by some embodiments to implement heuristic learning.

One of ordinary skill in the art will recognize that although process 700 has been described by reference to various details, different embodiments may implement the process in various different ways without departing from the spirit of the invention. For instance, different embodiments may perform the operations in different orders. As another example, various operations may be omitted and/or various other operations may be included. The process may be executed continuously, at regular intervals, based on some criteria, and/or at other appropriate times. The process may be divided into a set of sub-process and/or be included as a sub-process of a larger macro-process.

FIG. 8 illustrates a flow chart of a conceptual process 800 used by some embodiments to provide data to a client. Such a process may be executed by a remote server device such as that described above in reference to FIG. 2.

Process 800 may begin, for instance, when a user first sets up an application of some embodiments, when a client-side application of some embodiments requests information, and/or at other appropriate times. In some embodiments, the process may be executed based on data associated with a particular user (e.g., a set of clubs and distances associated with the user) and/or a particular establishment (e.g., a golf course) or manufacturer.

Next, the process may receive (at 810) a request from the client. Such a request may be received in various appropriate ways (e.g., through an API of some embodiments, through a communication interface provided by some combinations of client and server software, etc.).

The process may then retrieve (at 820) local data. Such local data may include data related to prediction equations, data related to similar users, and/or other appropriate data maintained or stored by the server of some embodiments.

Process 800 may then retrieve (at 830) third-party data. Such data may be retrieved in various appropriate ways (e.g., through one or more APIs, by sending a message to a third-party server, etc.).

Next, the process may generate (at 840) a response to the request. Such a response may include the requested data, updated data, and/or other appropriate elements. The process may then send (at 850) the response to the client and then end.

One of ordinary skill in the art will recognize that although process 800 has been described by reference to various details, different embodiments may implement the process in various different ways without departing from the spirit of the invention. For instance, different embodiments may perform the operations in different orders. As another example, various operations may be omitted and/or various other operations may be included. The process may be executed continuously, at regular intervals, based on some criteria, and/or at other appropriate times. The process may be divided into a set of sub-process and/or be included as a sub-process of a larger macro-process.

FIG. 9 illustrates a flow chart of a conceptual process 900 used by some embodiments to perform heuristic learning. Such a process may be executed by a remote server device such as that described above in reference to FIG. 2. The process may begin, for instance, when additional user feedback becomes available.

Next, the process may retrieve (at 910) an equation or other appropriate element to be evaluated. The process may then retrieve (at 920) equation data from multiple client sources. Such equation data may include data such as the local conditions, baseline conditions, selected club, course, hole, etc. The process may then retrieve (at 930) feedback data from users. Such data may include, for instance, actual distance.

The process may then update (at 940) the retrieved equation based on the retrieved data. Such an update may include analyzing sets of data to determine correlations among various parameters and the actual distance. Such correlations may be used to generate sets of operations, coefficients, etc., that may be used to update the retrieved equation to better fit the feedback data.

The process may then send (at 950) the updated equation to the clients and then end. Such updated equations may be sent individually, as part of a software update, and/or at other appropriate times.

Some embodiments may implement a similar heuristic learning process on the client-side. Such a client-side process may allow an individual user to automatically tailor various parameters to match the user's performance.

Such heuristic learning may be applied to existing applications (e.g., to improve prediction algorithms used for a golf application) or to new or different applications (e.g., as a set of baseline algorithms associated with a ballistics or artillery application, where the baseline algorithms may be refined using heuristics).

One of ordinary skill in the art will recognize that although process 900 has been described by reference to various details, different embodiments may implement the process in various different ways without departing from the spirit of the invention. For instance, different embodiments may perform the operations in different orders. As another example, various operations may be omitted and/or various other operations may be included. The process may be executed continuously, at regular intervals, based on some criteria, and/or at other appropriate times. The process may be divided into a set of sub-process and/or be included as a sub-process of a larger macro-process.

FIG. 10 illustrates a flow chart of a conceptual process 1000 used by some embodiments to provide data related to an event or location (e.g., a golf tournament). Such a process may be executed by a remote server device such as that described above in reference to FIG. 2. The process may begin, for instance, when a user launches a client application or when a widget is made available for broadcast (e.g., via a web portal, as a feed within a televised presentation, etc.).

Next, the process may identify (at 1010) players associated with the tournament. Such a roster may be retrieved from various appropriate sources (e.g., a professional golf association, a sports reporting outlet, a list of user-selected players, etc.).

The process may then retrieve (at 1020) information related to the event. Such information may include, for instance, location of the event (e.g., a town, a golf course, etc.), schedule of play, etc.

Next, the process may retrieve (at 1030) information associated with the players. Such information may include, for instance, home location or course, equipment used, past performance data, etc.

The process may then retrieve (at 1040) information associated with the course or location. Such information may include layout information, obstacle information, surface information, tee placement, hole placement, etc.

Next, the process may retrieve (at 1050) information related to current playing conditions. Such information may include, for instance, temperature, elevation, humidity, etc.

In addition, in some embodiments, various other information may be collected various appropriate sources. Such information may include other factors that may affect play (e.g., recent rainfall information, ground temperature, etc.) and/or feedback (e.g., information related to actual versus predicted distances in practice rounds).

The process may then generate (at 1060) predictions based at least partly on the retrieved information. Such predictions may be generated as described above.

Finally, the process may provide (at 1070) a multimedia output based at least partly on the generated predictions. One example output is described in reference to FIG. 27 below.

One of ordinary skill in the art will recognize that although process 1000 has been described by reference to various details, different embodiments may implement the process in various different ways without departing from the spirit of the invention. For instance, different embodiments may perform the operations in different orders. As another example, various operations may be omitted and/or various other operations may be included. The process may be executed continuously, at regular intervals, based on some criteria, and/or at other appropriate times. The process may be divided into a set of sub-process and/or be included as a sub-process of a larger macro-process.

IV. User Interaction

The various UI elements described below are presented for example purposes only. One of ordinary skill in the art will recognize that different embodiments may use various different UI features (e.g., different layouts, different components, etc.) without departing from the spirit of the invention. In addition, different specific UI elements may be activated or presented in various different ways depending on user selections and/or other relevant inputs.

FIG. 11 illustrates a UI 1100 of some embodiments. This UI may be provided as a start screen. As shown, the UI may include various selectable elements (e.g., “plays as”, “home course”, “my clubs”, “current distances”, information or help, etc.).

FIG. 12 illustrates a UI 1200 of some embodiments. This UI may be presented when a “home course” selection is received via UI 1100. As shown, the UI 1200 may include various buttons or other selectable elements (e.g., cancel, done, etc.) and/or various entry boxes that may be used to enter course information.

FIG. 13 illustrates a UI 1300 of some embodiments. This UI may be presented when a “my clubs” selection is received via UI 1100. As shown, the UI 1300 may include various instructions and/or buttons. In addition, some embodiments may provide “back” and/or “forward” buttons that may be used to navigate through various UIs.

FIG. 14 illustrates a UI 1400 of some embodiments. This UI may be presented when an “add club” selection is received via UI 1300. As shown, the UI 1400 may include various club attributes that may allow a user to either select an existing club from a database (e.g., a database comprising manufacturer specifications) or provide information regarding a club that is not included in the database.

FIG. 15 illustrates a UI 1500 of some embodiments. This UI may be presented when a “Club Name” selection is received via UI 1400. As shown, the UI 1500 may include a list of possible clubs to select from. Different embodiments may present such lists in various different ways (e.g., as a table, as a set of radio buttons, etc.).

FIG. 16 illustrates a UI 1600 of some embodiments. This UI may be presented when a “7W” selection is received via UI 1500. As shown, the UI 1600 may include information associated with the selected club. In this example, the information includes a custom name, “Mid Mashie” used to identify the selected club.

FIG. 17 illustrates a UI 1700 of some embodiments. This UI may be presented when a “Distance” selection is received via UI 1400 or UI 1600. As shown, the UI 1700 may allow a user to enter a distance associated with the selected club.

FIG. 18 illustrates a UI 1800 of some embodiments. This UI may be presented when a “Loft” selection is received via UI 1400 or UI 1600. As shown, the UI 1800 may allow a user to enter a loft associated with the selected club.

FIG. 19 illustrates a UI 1900 of some embodiments. This UI may be presented when a “Display” selection is received via UI 1400 or UI 1600. As shown, the UI 1900 may provide various selectable display options, which may include custom options associated with specific clubs.

FIG. 20 illustrates a UI 2000 of some embodiments. This UI may be presented when a user has finalized all selections (e.g., after pressing “Done” on UI 1900). As shown, the UI 2000 may provide a summary of the selected club.

FIG. 21 illustrates a UI 2100 of some embodiments. This UI may be presented when a user has finalized all selections (e.g., after pressing “Done” on UI 1900, after pressing a toggle feature on UI 2000, etc.). As shown, the UI 2000 may provide an alternative summary of the selected club and/or allow a user to make edits including deleting the club.

FIG. 22 illustrates a UI 2200 of some embodiments. This UI may be presented when a user has finalized all selections (e.g., after pressing “Done” on UI 1900) and multiple clubs are available for selection. As shown, the UI 2200 may provide a summary of the current club and include buttons or other features (e.g., a swipe motion) that may allow a user to view and/or select other clubs.

FIG. 23 illustrates a UI 2300 of some embodiments. This UI may be presented when a “Current Distances” selection is received via UI 1100. As shown, the UI 2300 may include various fields associated with the variables to be used in a prediction. In this example, the fields are unpopulated.

FIG. 24 illustrates a UI 2400 of some embodiments. This UI may be presented when the various fields of UI 2300 are populated (and/or at other appropriate times, such as when a user presses a “calculate” or similar button, when updated condition or equation data is received, etc. The fields may be populated in various appropriate ways (e.g., one or more fields may be automatically populated based on measured data, received data, etc.). In addition, a user may enter values into the fields.

In the example of UI 2400, the current club result shows a total increase of sixteen yards over the baseline distance for the selected club. Some embodiments may separate out effects on distance attributed to various parameters. For instance, some embodiments may include separate indications for change in distance associated with temperature, humidity, and elevation. Some embodiments may also include a separate indication for a total change in distance. In some embodiments, each separate effect indication may be presented as a positive value (i.e., causing an increase in distance relative to a baseline) or a negative value (i.e., causing a decrease in distance relative to a baseline). Some embodiments may include a visual indication of positive effects (e.g., by highlighting such effects in green) and negative effects (e.g., by highlighting such effects in red). In the example of UI 2400, a forward slash fill pattern represents a positive effect while a backward slash fill pattern represents a negative effect.

FIG. 25 illustrates a UI 2500 of some embodiments. This UI is another example of a UI that may be presented when the various fields of UI 2300 are populated. In addition, UI 2500 shows a “PlaysAs™” button that may be provided in some embodiments.

FIG. 26 illustrates a UI 2600 of some embodiments. This UI may be presented when a “PlaysAs™” selection is received via UI 2500. The home equivalent distance UI 2600 may allow a user to enter a current distance (e.g., distance to pin) and an associated home distance may be displayed. Some embodiments may also include a recommended club selection based on the expected distance.

Some embodiments may allow a user to calculate a current distance automatically. For instance, a smartphone user may be able to use the smartphone camera to take a picture of a flagstick or other appropriate feature. Such a picture may be evaluated to determine a relative size of the feature, and thus, an approximate distance. Alternatively, a position sensor associated with a smartphone may be able to determine a position of the device relative to a feature of the course. As another alternative, a user may be able to enter an estimated distance or a distance obtained from another source (e.g., a yardage marker).

One of ordinary skill in the art will recognize that the UIs described above in reference to FIGS. 11-26 may be implemented in various different ways without departing from the spirit of the invention. For instance, the UIs may be optimized for different types of devices having different types of inputs or outputs (and/or different size outputs, such as display screens). As another example, various different UIs may include different buttons, fields, arrangements, etc. than those shown.

FIG. 27 illustrates a UI 2700 of some embodiments. Such a UI may be provided by a widget or event application of some embodiments.

Some embodiments may provide a UI such as UI 2700 for use during an event such as a televised tournament. Such a UI may allow announcers and/or fans, for instance, to access a database including information related to the course, the players, the conditions and/or other relevant factors. In this way, each user may be able to access data related to specific players (and/or groups of players), their home course(s), a club (or set of clubs), current course, playing conditions and/or other relevant information.

As one example, an announcer or fan may be able to use such an interface to predict the club a player will select at a particular distance, to predict distance based on club selection, and/or to recognize situational possibilities (e.g., a scenario where a golfer should be able to carry over an obstacle versus a scenario where the golfer would not be able to clear an obstacle and may have to employ a different strategy).

As another example, such information may be used by other personnel (e.g., camera operators) such that they may better predict ball flight or otherwise provide an improved presentation.

Different embodiments may present information based on various different criteria. For example, a spectator may be able to select from among players that are currently active in the tournament. As another example, an announcer may automatically receive information associated with a player on a “live” monitor. Alternatively and/or conjunctively, an announcer may be able to select information regarding other players (e.g., to compare an earlier shot under different conditions to a live situation). As still another example, a specific cameraman may automatically receive information associated with a particular location (e.g., information associated with the current player standing in a tee box).

Some embodiments may provide a “widget” or other appropriate feed that shows a relationship between two locations. The widget may include sets of graphics, data and/or instructions that may be provided as an interface or portal on a web site (and/or other appropriate ways, such as a smartphone widget, an element within a multimedia display such as a monitor or television, etc.).

Such a widget may include references to a home location (e.g., a city) and a current location (e.g., a different city). The widget may retrieve current conditions for each location (e.g., temperature, elevation, and humidity) and determine (and display) a percentage delta between the two locations (e.g., “location 2 is playing 10% longer than location 1”). Such a determination may be made based on a particular club (e.g., a 7-iron) or other relevant criteria and may be based on coefficients associated with average or typical equipment (and/or player distance).

Such a widget may be associated with various locations in various ways. For instance, the widget may be displayed on a golf course's website (and associated with the location of the golf course) and may allow a user to merely enter his home location in order to determine the current distance difference between the locations.

As another example, the widget may include various “pairs” of locations to compare (or lists of multiple pairs). For instance, some embodiments may include a widget that provides a feed of comparisons related to well-known courses, or courses within a certain geographical distance, and/or other appropriate sets of locations.

As still another example, some embodiments may compare current conditions at a particular location to past conditions at the same location (e.g., a comparison of relative playing distances between a current tournament site and the same site one year earlier).

One of ordinary skill in the art will recognize that the UI 2700 described above may be implemented in various different ways without departing from the spirit of the invention. For instance, the UI may be optimized for different types of devices having different types of inputs or outputs (and/or different size outputs, such as display screens). As another example, various different UIs may include different buttons, fields, arrangements, etc. than those shown.

V. Computer System

Many of the processes and modules described above may be implemented as software processes that are specified as one or more sets of instructions recorded on a non-transitory storage medium. When these instructions are executed by one or more computational element(s) (e.g., microprocessors, microcontrollers, Digital Signal Processors (DSPs), Application-Specific ICs (ASICs), Field Programmable Gate Arrays (FPGAs), etc.) the instructions cause the computational element(s) to perform actions specified in the instructions.

In some embodiments, various processes and modules described above may be implemented completely using electronic circuitry that may include various sets of devices or elements (e.g., sensors, logic gates, analog to digital converters, digital to analog converters, comparators, etc.). Such circuitry may be adapted to perform functions and/or features that may be associated with various software elements described throughout.

FIG. 28 illustrates a schematic block diagram of a conceptual computer system 2800 used to implement some embodiments of the invention. For example, the systems described above in reference to FIGS. 1-5 may be at least partially implemented using computer system 2800. As another example, the processes described in reference to FIGS. 7-10 may be at least partially implemented using sets of instructions that are executed using computer system 2800. As still another example, the UI elements described in reference to FIGS. 11-27 may be presented using computer system 2800.

Computer system 2800 may be implemented using various appropriate devices. For instance, the computer system may be implemented using one or more personal computers (“PC”), servers, mobile devices (e.g., a smartphone), tablet devices, and/or any other appropriate devices. The various devices may work alone (e.g., the computer system may be implemented as a single PC) or in conjunction (e.g., some components of the computer system may be provided by a mobile device while other components are provided by a tablet device).

As shown, computer system 2800 may include at least one communication bus 2805, one or more processors 2810, a system memory 2815, a read-only memory (ROM) 2820, permanent storage devices 2825, input devices 2830, output devices 2835, various other components 2840 (e.g., a graphics processing unit), and one or more network interfaces 2845.

Bus 2805 represents all communication pathways among the elements of computer system 2800. Such pathways may include wired, wireless, optical, and/or other appropriate communication pathways. For example, input devices 2830 and/or output devices 2835 may be coupled to the system 2800 using a wireless connection protocol or system.

The processor 2810 may, in order to execute the processes of some embodiments, retrieve instructions to execute and/or data to process from components such as system memory 2815, ROM 2820, and permanent storage device 2825. Such instructions and data may be passed over bus 2805.

System memory 2815 may be a volatile read-and-write memory, such as a random access memory (RAM). The system memory may store some of the instructions and data that the processor uses at runtime. The sets of instructions and/or data used to implement some embodiments may be stored in the system memory 2815, the permanent storage device 2825, and/or the read-only memory 2820. ROM 2820 may store static data and instructions that may be used by processor 2810 and/or other elements of the computer system.

Permanent storage device 2825 may be a read-and-write memory device. The permanent storage device may be a non-volatile memory unit that stores instructions and data even when computer system 2800 is off or unpowered. Computer system 2800 may use a removable storage device and/or a remote storage device 2860 as the permanent storage device.

Input devices 2830 may enable a user to communicate information to the computer system and/or manipulate various operations of the system. The input devices may include keyboards, cursor control devices, audio input devices and/or video input devices. Output devices 2835 may include printers, displays, and/or audio devices. Some or all of the input and/or output devices may be wirelessly or optically connected to the computer system.

Other components 2840 may perform various other functions. These functions may include performing specific functions (e.g., graphics processing, sound processing, etc.), providing storage, interfacing with external systems or components, etc.

Finally, as shown in FIG. 28, computer system 2800 may be coupled to one or more networks 2850 through one or more network interfaces 2845. For example, computer system 2800 may be coupled to a web server on the Internet such that a web browser executing on computer system 2800 may interact with the web server as a user interacts with an interface that operates in the web browser. Computer system 2800 may be able to access one or more remote storages 2860 and one or more external components 2865 through the network interface 2845 and network 2850. The network interface(s) 2845 may include one or more application programming interfaces (APIs) that may allow the computer system 2800 to access remote systems and/or storages and also may allow remote systems and/or storages to access computer system 2800 (or elements thereof).

As used in this specification and any claims of this application, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic devices. These terms exclude people or groups of people. As used in this specification and any claims of this application, the term “non-transitory storage medium” is entirely restricted to tangible, physical objects that store information in a form that is readable by electronic devices. These terms exclude any wireless or other ephemeral signals.

It should be recognized by one of ordinary skill in the art that any or all of the components of computer system 2800 may be used in conjunction with the invention. Moreover, one of ordinary skill in the art will appreciate that many other system configurations may also be used in conjunction with the invention or components of the invention.

In addition, while the examples shown may illustrate many individual modules as separate elements, one of ordinary skill in the art would recognize that these modules may be combined into a single functional block or element. One of ordinary skill in the art would also recognize that a single module may be divided into multiple modules.

The foregoing relates to illustrative details of exemplary embodiments of the invention and modifications may be made without departing from the spirit and scope of the invention as defined by the following claims.

Claims

1. An automated method for predicting a flight distance of a projectile, the method comprising:

retrieving a set of baseline values, each baseline value associated with a set of baseline parameter values;

retrieving a set of current parameter values; and

calculating a predicted distance based at least partly on the baseline value, the set of baseline parameter values, and the set of current parameter values.

2. The automated method of claim 1, wherein the set of baseline parameter values comprises a first temperature value, a first humidity value, and a first elevation value.

3. The automated method of claim 2, wherein the set of current parameter values comprises a second temperature value, a second humidity value, and a second elevation value.

4. The automated method of claim 3 further comprising retrieving a set of club parameters associated with a particular club.

5. The automated method of claim 4, wherein the set of baseline parameter values includes a first distance associated with the particular club and the first temperature value, the first humidity value, and the first elevation value.

6. The automated method of claim 5, wherein calculating the predicted distance comprises:

retrieving a set of coefficients associated with at least one equation used to predict distance;

determining a first difference between the second temperature value and the first temperature value;

determining a second difference between the second humidity value and the first humidity value;

determining a third difference between the second elevation value and the first elevation value; and

determining the predicted distance by: multiplying the first distance by a sum of: one, a product of a first coefficient from the set of coefficients and the first difference, a product of a second coefficient from the set of coefficients and the second difference, and a product of a third coefficient from the set of coefficients and the third difference; and adding a sum of a product of a fourth coefficient from the set of coefficients and the first difference, a product of a fifth coefficient from the set of coefficients and the second difference, and a product of a sixth coefficient from the set of coefficients and the third difference.

7. The automated method of claim further comprising calculating a home distance based at least partly on a current distance, the baseline value, the set of baseline parameter values, and the set of current parameter values.

8. An automated method for translating a current distance to a home distance, the method comprising:

receiving a current distance;

receiving a set of current parameter values;

retrieving a set of baseline distances and associated baseline parameter values; and

calculating a home distance based at least partly on the current distance, the set of current parameter values, and the set of baseline distances and baseline parameter values.

9. The automated method of claim 8, wherein the set of current parameter values and the set of baseline parameter values each comprises at least one temperature value, at least one elevation value, and at least one humidity value.

10. The automated method of claim 9, wherein the set of baseline distances includes an average distance associated with each club from among a set of golf clubs.

11. The automated method of claim 10 further comprising calculating a predicted distance based at least partly on a selection of a particular club from among the set of clubs, the set of current parameter values and the set of baseline distances and baseline parameter values.

12. The automated method of claim 11, wherein calculating the predicted distance comprises retrieving a set of equation coefficients and determining a set of differences among the set of current parameter values and the baseline parameter values.

13. The automated method of claim 8, wherein calculating the home distance comprises receiving a set of equation coefficients and determining a set of differences among the set of current parameter values and the baseline parameter values.

14. The automated method of claim 8, wherein each distance in the set of baseline distances is associated with a particular ordnance.

15. A range projection device comprising:

at least one user interface (UI) element;

a storage able to store a set of baseline values, wherein each baseline value is associated with a set of baseline parameter values;

a set of data sources, wherein each data source is able to provide at least one current parameter value; and

a calculation module adapted to determine a predicted distance based at least partly on the set of baseline values, the associated sets of baseline parameter values, and the current parameter values.

16. The range projection device of claim 15, wherein the calculation module is further adapted to determine a home distance based at least partly on a current distance, the set of baseline values, the sets of baseline parameter values, and the current parameter values.

17. The range projection device of claim 15, wherein each set of baseline parameter values comprises at least one of a baseline temperature value, a baseline humidity value, and a baseline elevation value.

18. The range projection device of claim 17, wherein the current parameter values include at least one of a current temperature value, a current humidity value, and a current elevation value.

19. The range projection device of claim 15, wherein each baseline value is a distance associated with a particular golf club from among a set of clubs.

20. The range projection device of claim 15, wherein the set of data sources includes at least one of an internal data source and a network accessible data source.