Ball throwing machine

Abstract

A ball thrower (100) is disclosed that includes one or more launch wheels configured to impart motion to one or more balls, a frame attached to the one or more launch wheels (127), and a control circuit configured to control the one or more launch wheels. The control circuit includes a processor (310), a non-transitory computer-readable medium having logic stored thereon, and one or more motion sensors configured to acquire data regarding operation of the ball thrower, including the launch of a first of the one or more balls (90). In some cases, imparting motion to the one or more balls includes rotating the one or more launch wheels to effect delivery of the one or more balls to a player, the one or more balls being one or more soccer balls.

Description

[Technical Field]

[0001] This application is a continuation of U.S. patent application Ser. No. 18 / 500,943, filed November 2, 2023, entitled "System and Method for a Ball-Throwing Machine," U.S. patent application Ser. No. 18 / 500,995, filed November 2, 2023, entitled "Systems and Methods for Determining Ball-Throwing Machine Operability," U.S. patent application Ser. No. 18 / 501,000, filed November 2, 2023, entitled "Systems and Methods for Determining Operability Status of a Ball-Throwing Machine Through Signature Analysis," U.S. patent application Ser. No. 18 / 501,005, filed November 2, 2023, entitled "Systems and Methods for Determining Operability Status of a Ball-Throwing Machine Through Machine Learning Techniques," U.S. patent application Ser. No. 18 / 501,005, filed November 2, 2023, entitled "Systems and Methods for Determining Whether a Ball is This application claims priority to U.S. patent application Ser. No. 18 / 501,506, entitled "Systems and Methods for a Ball-Throwing Machine Present in a Staging Area of ​​a Ball-Throwing Machine," filed on November 2, 2023, and U.S. patent application Ser. No. 18 / 501,009, entitled "Systems and Methods for a Ball-Throwing Machine Providing Launch Wheel Motor Feedback," filed on November 2, 2023, each of which claims priority to U.S. provisional patent application Ser. No. 63 / 422,370, entitled "Model 2100 Touch Trainer," filed on November 3, 2022, each of which is incorporated herein by reference in its entirety. [Background technology]

[0002] In soccer, ball control is important for players at all levels. The ability to quickly and effectively control a tricky bouncing ball gives the player with the ball an immediate advantage. The first touch of the ball often makes the difference between success and failure in most game situations. Furthermore, accuracy when passing and shooting the ball is crucial in creating a balanced game. Ball throwers can increase the speed and efficiency of training programs, thus improving a player's ability to perform at a higher level and at a faster rate. Disruptions to training programs, including the loss of ball thrower operation, can negatively impact a player's training. Therefore, improvements in the reliability and consistency of the ball throwing process can benefit players and training programs.

[0003] In some cases, such ball throwers may operate for hours, days, or even months at a time without being checked for operational problems. For example, multiple ball throwers may be deployed in a training or social environment, with dozens of people using a single machine on a daily basis. At the end of the environment's operating hours, a person (e.g., a trainer or other staff member) may simply plug each ball thrower into an electrical outlet to charge the ball thrower's batteries. At the start of the next day, the trainer or other staff member may unplug the ball throwers and start each one for use with a player. This cycle may be repeated for weeks or months.

[0004] However, over time, a ball thrower may wear out in certain areas or develop minor operability issues that are not easily observed with the naked eye. For example, a trainer or staff member may not be able to observe slight wear over time on the wheels that operate to launch the balls. Over time, that wear on one or both of the ball launch wheels affects the launch of the balls and, as a result, the training experience. In such cases, the balls may not be launched at the correct speed and / or direction due to wear or uneven wear. In another example, the motor of a ball thrower is critical to its operability; however, a trainer or staff member may not be able to observe variations in the motor's operability with the naked eye. For example, the amount of current utilized by the motor varies based on whether the ball thrower is actively launching balls or is in "standby" mode (i.e., between ball launches).

[0005] As a result, ball throwers often operate for days, weeks, or months without a trainer or other staff member realizing that the ball thrower is not operating properly. While a ball thrower may operate sufficiently to launch a series of balls according to a selected training program, it may experience performance issues that result in degradation of the ball thrower and / or the player's experience over time. Due to the complexity of today's ball throwers, particularly those disclosed herein, they may deteriorate, but there are many complex aspects of the ball thrower that are easily correctable (e.g., replacing a worn ball launching wheel and / or ensuring that balls are in the hopper to avoid attempting to launch a ball when none is present).

[0006] Disclosed herein are systems and methods for improving the reliability and consistency of the ball throwing process of a ball throwing machine. Additionally, disclosed herein are systems and methods for determining the operability of a ball throwing machine. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] U.S. Patent No. 9,010,309 [Patent Document 2] U.S. Patent No. 9,555,306 [Patent Document 3] U.S. Patent No. 10,252,128 [Patent Document 4] U.S. Patent No. 10,118,078 Summary of the Invention [Means for solving the problem]

[0008] Disclosed herein is an object-throwing device that, according to some embodiments, includes one or more launch wheels configured to impart motion to one or more objects, a frame attached to the one or more launch wheels, and a control circuit configured to control the one or more launch wheels. The control circuit further includes a processor, a non-transitory computer-readable medium having logic stored thereon, and one or more operational sensors. The processor is configured to execute logic that, when executed, results in operations including (i) launching a series of objects and (ii) acquiring data regarding operation of the object-throwing device, including the launch of a first object in the series of objects.

[0009] In some embodiments, firing includes spinning one or more firing wheels to cause the delivery of one or more objects to the player, where the one or more objects may be one or more balls.

[0010] In some embodiments, the one or more motion sensors include at least one of an accelerometer or a microphone.

[0011] In some embodiments, the operation further includes (i) acquiring data from one or more operational sensors while the ball thrower launches the series of balls in accordance with the received instructions, and (ii) detecting one or more operational actions based on the data acquired from one or more of the operational sensors.

[0012] In some embodiments, the operations further include (i) analyzing data related to the operation of the object throwing device and (ii) detecting that the launch of the first object was anomalous by comparing the data related to the operation of the object throwing device to a data signature representing an expected set of data corresponding to the launch of the first object.

[0013] In some embodiments, the operations further include (i) analyzing data related to the operation of the object-throwing device, where the data related to the operation of the object-throwing device includes at least one of vibration data or sound data; and (ii) detecting that the object-throwing device is operating anomalously by comparing the data related to the operation of the object-throwing device to a data signature representative of expected vibration data or sound data.

[0014] In some embodiments, the operations further include (i) acquiring vibration data from one or more motion sensors while the ball thrower launches the series of objects in accordance with the received commands; and (ii) performing an analysis on the vibration data acquired from the one or more motion sensors, wherein performing the analysis includes comparing a subset of the vibration data corresponding to a known point in time during the launch of the series of objects to expected vibration data, the known point in time corresponding to the expected launch of a first object by the ball thrower.

[0015] In some embodiments, the operations further include (i) acquiring sound data from a microphone while the ball thrower launches a series of objects in accordance with the received commands, the microphone being included in the one or more motion sensors, and (ii) performing an analysis on the sound data. Performing the analysis includes comparing (i) a subset of the sound data corresponding to a known time point at which the first object was launched against (ii) expected sound data for the object launch. Performing the analysis further includes determining that the launch of the first ball was anomalous and generating an alert indicating that the launch of the first ball was anomalous. In some embodiments, the alert is recorded in a data log.

[0016] In some embodiments, the control circuitry is configured to receive instructions to launch a series of objects, the instructions indicating a number of objects to be launched and at least a velocity and trajectory for each of the launched objects.

[0017] A computerized method is also disclosed herein, which, according to some embodiments, includes: (i) receiving instructions to launch a series of objects from a ball thrower including a set of launch wheels configured to launch the series of objects, a motor driving the launch wheels, and one or more motion sensors; (ii) acquiring data from the one or more motion sensors while the ball thrower launches the series of objects in accordance with the received instructions; and (iii) detecting one or more motion actions based on the data acquired from one or more of the motion sensors.

[0018] In some embodiments of the computerized method, launching the series of objects includes rotating one or more launch wheels to result in the delivery of one or more objects to the player, where the one or more objects may include one or more balls.

[0019] In some embodiments of the computerized method, the one or more motion sensors include at least one of an accelerometer or a microphone.

[0020] In some embodiments, the computerized method further includes (i) acquiring data from one or more motion sensors while the ball thrower launches the series of objects in accordance with the received commands, and (ii) detecting one or more motion actions based on the data acquired from one or more of the motion sensors.

[0021] In some embodiments, the computerized method further includes (i) analyzing data relating to the operation of the object throwing device; and (ii) detecting that the launch of the first object was anomalous by comparing the data relating to the operation of the object throwing device to a data signature, the data signature representing an expected set of data corresponding to the launch of the first object.

[0022] In some embodiments, the computerized method further includes (i) analyzing data related to the operation of the object-throwing device, where the data related to the operation of the object-throwing device includes at least one of vibration data or sound data; and (ii) detecting that the object-throwing device is operating anomalously by comparing the data related to the operation of the object-throwing device to a data signature representative of expected vibration data or sound data.

[0023] In some embodiments, the computerized method further includes (i) acquiring vibration data from one or more motion sensors while the ball thrower launches the series of objects in accordance with the received commands, and (ii) performing an analysis on the vibration data acquired from the one or more motion sensors. Performing the analysis may include comparing a subset of the vibration data corresponding to a known point in time during the launch of the series of objects to expected vibration data, the known point in time corresponding to the expected launch of a first object by the ball thrower.

[0024] In some embodiments, the computerized method further includes (i) acquiring sound data from a microphone while the ball thrower launches a series of objects in accordance with the received commands, the microphone being included in one or more motion sensors, and (ii) performing an analysis on the sound data, the analysis including comparing (i) a subset of the sound data corresponding to a known time point at which the first object was launched to (ii) expected sound data for the object launch. In such embodiments, the computerized method may further include determining that the launch of the first ball was anomalous and generating an alert indicating that the launch of the first ball was anomalous. In some embodiments of the computerized method, the alert is recorded in a data log.

[0025] In some embodiments of the computerized method, the control circuitry of the ball throwing machine is configured to receive instructions to launch a series of objects, the instructions indicating a number of objects to be launched and at least a velocity and trajectory for each of the launched objects.

[0026] These and other features of the concepts provided herein will become apparent to those skilled in the art in view of the following description and accompanying drawings, which set forth in more detail certain embodiments of such concepts.

[0027] Embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like references indicate similar elements and in which: [Brief explanation of the drawings]

[0028] [Figure 1] FIG. 1 is a perspective front view of a ball thrower according to some embodiments. [Figure 2] FIG. 2 is a cross-sectional side view of the ball thrower of FIG. 1 according to some embodiments. [Figure 3] FIG. 2 is a top view of a control unit of the ball thrower of FIG. 1 according to some embodiments. [Figure 4]2 is a block diagram of a first computerized method of the ball throwing machine of FIG. 1 according to some embodiments. [Figure 5A] 10 is a block diagram of a second computerized method of the ball throwing machine of FIG. 1 according to some embodiments. [Figure 5B] 10 is a block diagram of a third computerized method of the ball throwing machine of FIG. 1 according to some embodiments. [Figure 6A] FIG. 2 is a front view of the ball thrower of FIG. 1 with the ball hopper removed, according to some embodiments. [Figure 6B] 2 is a detailed view of a portion of the ball thrower of FIG. 1 showing a ball sensor and a ball stop, according to some embodiments. [Figure 7] 4 is a schematic diagram of an emergency shutdown circuit of the control unit of FIG. 3 according to some embodiments. [Figure 8] 10 is a block diagram of a fourth computerized method of the ball throwing machine of FIG. 1 according to some embodiments. [Figure 9] 10 is a block diagram of a fifth computerized method for the ball thrower of FIG. 1 according to some embodiments. [Figure 10] FIG. 2 is a perspective rear view of the ball thrower of FIG. 1 with the ball hopper removed, according to some embodiments. [Figure 11] 1 is a block diagram illustrating a first system architecture of a ball throwing machine coupled to a data processing system operating in a networked environment, according to some embodiments. [Figure 12] 12 is a logic diagram illustrating logic modules of the data processing system ("system") of FIG. 11 stored on non-transitory storage and configured to be executed by one or more processors, according to some embodiments. [Figure 13A] 1 is a flow diagram illustrating the operation of a method for identifying normal or anomalous behavior of a ball thrower through signature analysis, according to some embodiments. [Figure 13B]13B is an illustrative flow of operations of the method 1300 of FIG. 13A, including analyzing sensor data and generating a sensor data signature, according to some embodiments. [Figure 14] 1 is a flow diagram illustrating operations of an exemplary method for generating a signature for sensor data from a first sensor (a vibration sensor) during operation of a ball throwing machine, according to some embodiments. [Figure 15] 1 is a flow diagram illustrating operations of an example method for generating a trained machine learning model configured to determine a prediction about the operability status of a ball thrower, according to some embodiments. [Figure 16-1] 1 is a flow diagram illustrating operation of a method for deploying a ball thrower, identifying normal or anomalous behavior of the ball thrower, and taking corrective action, if necessary, according to some embodiments. [Figure 16-2] 1 is a flow diagram illustrating operation of a method for deploying a ball thrower, identifying normal or anomalous behavior of the ball thrower, and taking corrective action, if necessary, according to some embodiments. [Figure 17] 1 is a flow diagram illustrating operation of a method for monitoring wheel motor data to detect ball launches during deployment of a ball thrower, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0029] Before some specific embodiments are disclosed in more detail, it should be understood that the specific embodiments disclosed herein do not limit the scope of the concepts provided herein. It should also be understood that the specific embodiments disclosed herein can have features that can be easily separated from the specific embodiment and that can be optionally combined with or substituted for features of any of the other embodiments disclosed herein.

[0030] Regarding the terms used herein, it should also be understood that the terms are intended to describe certain specific embodiments and do not limit the scope of the concepts provided herein. Ordinal numbers (e.g., first, second, third, etc.) are generally used to distinguish or identify different features or steps in a group of features or steps and do not provide serial or numerical limitations. For example, "first," "second," and "third" features or steps do not necessarily have to appear in that order, and a particular embodiment including such features or steps is not necessarily limited to three features or steps. Labels such as "left," "right," "top," "bottom," "front," "back," and the like are used for convenience and are not intended to suggest, for example, any particular fixed location, orientation, or direction. Instead, such labels are used to reflect, for example, relative location, orientation, or direction. The singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise.

[0031] The phrases "connected to," "coupled with," and "in communication with" refer to any form of interaction between two or more entities, including, but not limited to, mechanical, electrical, magnetic, electromagnetic, fluid, and thermal interaction. Two components may be coupled to one another without being in direct contact with one another. For example, two components may be coupled to one another through an intermediate component.

[0032] The term "logic" may refer to hardware, firmware, or software configured to perform one or more functions. As hardware, the term logic may refer to or include circuitry having data processing and / or storage capabilities. Examples of such circuitry may include, but are not limited to, or restricted to, a hardware processor (e.g., a microprocessor, one or more processor cores, a digital signal processor, a programmable gate array, a microcontroller, an application specific integrated circuit (ASIC), etc.), semiconductor memory, or a combination of elements.

[0033] Additionally or alternatively, the term logic may refer to or include software such as one or more processes, one or more instances, application programming interface(s) (APIs), subroutine(s), function(s), applet(s), servlet(s), routine(s), source code, object code, shared library / dynamic link library (dll), or even one or more instructions. This software may be stored on any type of suitable non-transitory or transitory storage medium (e.g., electrical, optical, acoustic, or other form of propagated signal, such as a carrier wave, infrared signal, or digital signal). Examples of non-transitory storage media may include, but are not limited to, programmable circuitry, non-persistent storage such as volatile memory (e.g., any type of random access memory "RAM"), non-volatile memory (e.g., read-only memory "ROM", power-backed RAM, flash memory, phase-change memory, etc.), persistent storage such as a solid-state drive, hard disk drive, optical disk drive, or portable memory device. Logic may be stored in persistent storage as firmware.

[0034] Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. As used herein, the term "trajectory" includes the initial path of an object through a launch, which includes the launch angle and lateral or side-by-side direction relative to the ground.

[0035] Any method disclosed herein includes one or more steps or actions that perform the described method. Method steps and / or actions may be interchanged with one another. In other words, unless a specific order of steps or actions is required for proper operation of an embodiment, the order and / or use of specific steps and / or actions may be modified. Furthermore, only subroutines or portions of methods described herein may be separate methods within the scope of the present disclosure. In other words, some methods may include only a portion of the steps described in a more detailed method. Furthermore, all embodiments disclosed herein are combinable and / or interchangeable unless otherwise stated; otherwise, such combination or substitution would contradict the stated operability of any embodiment.

[0036] A soccer player's first touch with the ball is an important core skill to develop. Touch can be as simple as receiving a loose pass on the ground or as difficult as snatching a top-speed knuckling ball out of the air and directly under one's feet. First touch development is a continuous process; youth and professional players alike train constantly to constantly improve their first touch and ball-handling skills. Touch skills are typically trained by players forming pairs and passing the ball to each other. While this training method can produce results, it tends to fall short in providing a disciplined approach to training that allows for progress measurement and goal-directed improvement. Furthermore, this technique requires players to find another individual to practice with, which is not always practical, especially for professional athletes who devote significant time to their training.

[0037] This disclosure describes a dedicated ball thrower that can be used to improve a player's first touch and ball control, among other benefits. The ball thrower can be designed to throw, lob, pitch, or otherwise eject a soccer ball toward a player, who can trap the ball or practice other ball control skills. The ball thrower may be controlled using a controller in the form of a handheld computing device or the like. The game of soccer is commonly known in some countries as "football" or "association football." For convenience, this specification will refer only to the term "soccer," but such use should be considered synonymous with "football" and "association football." Furthermore, embodiments of the ball thrower, controller, and soccer network application described herein can be used or adapted for sports other than soccer, some examples of which are described below.

[0038] While this specification primarily refers to using a ball thrower to train ball trapping skills, it should also be noted that the ball thrower can be used to train other skills. For example, the ball thrower can be used to train passing, shooting, and stopping a soccer ball, among other ball skills. Further details regarding ball throwers can be found in U.S. Patent Nos. 9,010,309, 9,555,306, 10,252,128, and 10,118,078, each of which is incorporated by reference in its entirety into this application.

[0039] I. Ball throwing machine FIG. 1 shows a perspective view of a ball thrower 100 (sometimes referred to as an object throwing device) according to some embodiments, and FIG. 2 is a cross-sectional side view of the ball thrower 100 showing various internal components, with the ball thrower 100 positioned on a ground 50. The ball thrower 100 can be used to pitch a ball, such as to deliver a ball to a user. For example, the ball thrower 100 can be used to deliver a soccer ball or a specialized soccer-type ball to a user. The ball thrower 100 can likewise be used with a variety of other balls or objects for a variety of other sports.

[0040] The remote controller 80 is shown in wireless communication with the ball thrower 100. The remote controller 80 can be a player / user's computing device, such as a smartphone, tablet, laptop, personal digital assistant (PDA), or other wireless handheld device, or even a desktop, in some embodiments. The remote controller 80 can wirelessly communicate with a wireless module within the ball thrower 100. The remote controller 80 can include functionality to control training programs executed on the ball thrower 100. For example, the remote controller 80 can include functionality for a user to select training programs to be communicated to the ball thrower 100. Each training program can include a set of drills, commands, or instructions to be executed by the ball thrower 100, such as how many balls to throw in a given period of time, how fast to throw them, and what trajectory to use for throwing. Training programs can be selected and customized by the user.

[0041] The illustrated ball thrower 100 includes a housing 102. The ball thrower 100 can be easily transportable. For example, the ball thrower can include one or more transport wheels 118, which may be motorized in some embodiments. The ball thrower 100 can also include one or more handles 124 for grasping and manipulating the ball thrower 100 while moving the ball thrower 100. In some embodiments, the one or more handles 124 can be extendable and / or positionable.

[0042] 1 and 2, the ball thrower 100 includes a hopper 126. The hopper 126 may be used to receive and / or store balls 90 for later dispensing or throwing by the ball thrower 100. The embodiment shown includes a large volume or large storage type hopper 126. In some embodiments, the hopper 126 is capable of storing as many as 25 balls 90. Of course, it will be understood that the hopper 126 may hold more or fewer balls 90 as needed or desired.

[0043] Many different styles and types of hoppers can be used. As shown, the hopper 126 is a gravity-type hopper having a spiral ramp 128 positioned around a hopper column 130. The hopper column 130 can be used to provide structural strength to the hopper 126 and can also provide proper spacing so that the balls 90 within the hopper 126 can properly rotate and move downward within the hopper 126. Alternatively, the hopper column 130 is not included in some embodiments. Rather, the hopper 126 simply includes the spiral ramp 128. In another embodiment, the spiral ramp 128 is omitted and the hopper 126 includes a column that holds a plurality of balls 90.

[0044] In some embodiments, the hopper 126 may be transparent. For example, the outer material of the hopper may be clear plexiglass or plastic or a thin mesh-like fabric. This transparency may allow a user to observe the balls 90 in the hopper 126 and identify when the hopper 126 needs to be reloaded. The hopper 126 may have an upper hopper portion 126A and a lower hopper portion 126B. The upper hopper portion 126A may be configured to accept one or more balls 90 within the hopper 126 and, in some embodiments, may hold additional balls 90. The lower hopper portion 126B may be configured to transition the balls 90 from the hopper 126 into a ball staging area 212, sometimes referred to as the base of the hopper 126.

[0045] The hopper 126 can be used to store the balls 90 when the ball thrower 100 is in use and / or when the ball thrower 100 is not in use. In some embodiments, the hopper 126 can be foldable or removable to reduce the size of the ball thrower 100, such as when the ball thrower is not in use. In some embodiments, the hopper column 130 can be a telescoping tube, and the outer material of the hopper 126 can be fabric so that the hopper 126 can increase or decrease in size. In some embodiments having a foldable hopper 126, the upper hopper portion 126A can be folded to rest on top of the lower hopper portion 126B. Alternatively, the hopper column 130 can be configured to be removable to remove structural supports separating the upper hopper portion 126A from the lower hopper portion 126B.

[0046] Advantageously, in certain embodiments, the ball thrower 100 is designed to deliver soccer balls smaller than adult regulation-size soccer balls, thereby enabling more effective training of ball-trapping skills. The smaller surface area of ​​such balls can make smaller balls more difficult to trap compared to regulation-size balls (e.g., size "5" soccer balls). Thus, training with smaller balls can benefit players who use larger regulation-size balls in their games because the players will have acquired skills that carry over to larger balls that are easier to trap. In some embodiments, the balls used with the ball thrower 100 are about half the size of a regulation-size 5 ball, about one-third the size of a regulation-size 5 ball, about one-quarter the size of a regulation-size 5 ball, or some other size. For youth players who may already be using smaller balls in their games, the ball thrower 100 can use even smaller balls than the youth players use in their games. For example, if a youth player typically uses a size 4 soccer ball, the ball thrower 100 can throw a size 3 soccer ball or smaller, etc. However, in other embodiments, a regulation size ball is used instead of a smaller ball.

[0047] The size of the ball 90 used by the ball throwing machine 100 can be smaller than a regulation size 3 ball, even for older youth and adult players. For example, in one embodiment, the ball is preferably about 152 mm in diameter. However, in other embodiments, the ball can range in size from about 132 mm to about 172 mm in diameter while still providing some or all of the benefits of the balls described herein. In yet other embodiments, the ball can range in size from about 115 mm to 215 mm in diameter while still providing at least some of the benefits described herein.

[0048] The ball 90 that may be used herein may have any of the following characteristics: rubber construction, butyl bladder, one or more nylon plies (1, 2, 3, or 4 or more nylon plies), spiral wound nylon plies, and the like. These and other characteristics of the ball, among others (size, texture, weight, cover type, etc.), may be selected to achieve a desired liveliness or resilience of the ball. Different balls may be provided with different liveliness for different levels of difficulty. For example, a ball with greater resilience may be more difficult to trap and therefore suitable for a higher level of difficulty, while a ball with less resilience may be easier to trap and therefore suitable for a lower level of difficulty. Additionally, the color of the ball may be selected to target foot-eye coordination. For example, the ball may be blue, green, or red, or a combination thereof, because these colors may be easier to see than other colors. Alternatively, a color may be selected that is less easy to see and increases the difficulty of training. Different colors may be provided for players / users who may perceive colors slightly differently.

[0049] In one embodiment, ball 90 is not an actual soccer ball. For example, a ball having a size smaller than a regulation size ball may be considered a ball other than a soccer ball. Counterintuitively, it may be beneficial to train soccer skills (such as trapping) using a non-soccer ball, such as any of the balls described herein. Balls used in other sports may similarly be thrown by ball thrower 100 to train soccer skills. For example, tennis balls, racquetballs, and squash balls may be beneficially used to train trapping skills.

[0050] The body 110 of the ball thrower 100 includes a rear portion 113 and a front portion 114. The rear portion 113 includes a ball staging area 212, and the front portion 114 includes the ball delivery device 120. As can be seen in FIG. 2 , the ball staging area 212 is located adjacent to the top of the ball delivery ramp 122, i.e., between the hopper 126 and the ball delivery ramp 122, and can hold one or more balls 90. Shown disposed within the opening 205 of the housing 102 is a ball sensor (or ball presence sensor) 211 configured to detect when a ball 90 is present within the staging area 212. The ball thrower 100 can also include one or more ball stops configured to selectively prevent and allow individual balls 90 from (i) traveling down the ball delivery ramp 122 to the ball delivery device 120 or (ii) traveling along various stages of the hopper ramp 128. 2, the ball thrower 100 includes a control unit 220 and a power source 222 (e.g., a rechargeable battery) mounted to a base frame member (or frame) 216. In the embodiment shown, the ball thrower 100 includes a single ball stop 210, shown with an opening 205. In other embodiments, the ball thrower 100 may include two or more ball stops 210.

[0051] As shown, the front portion 114 also includes at least one opening 116. The opening 116 can provide a space for the ball 90 to be thrown to the player. The opening 116 can be one of many different shapes, such as oval, elliptical, rectangular, triangular, or any other desired shape. In some embodiments, the outer housing of the front portion 114 includes a minimal amount of material so that most, or at least a substantial portion, of the ball delivery device 120 is exposed and unenclosed. In such embodiments, there may be little or no portion of the outer housing between the ball delivery device 120 and the player.

[0052] With further reference to FIG. 2 , an embodiment of ball delivery device 120 is shown. Ball delivery device 120 can include any number of various components. Ball delivery device 120 can be used to impart motion to ball 90. In some embodiments, ball delivery device 120 can be used to control (i) the launch angle 121 of ball 90 relative to ground 50 and (ii) the velocity of ball 90 as it leaves ball thrower 100. Ball delivery device 120 can perform these functions in a variety of different ways, including those described below. It will be understood that ball delivery device 120 also encompasses various other systems and methods that perform the above functions, as well as other additional and / or alternative functions.

[0053] As shown, ball delivery device 120 includes one or more launch wheels or balls (e.g., two launch wheels 1271-1272, which may be collectively or individually referred to as "launch wheels 127") used to impart velocity, spin, and / or lateral direction to ball 90. Ball delivery device 120 may also include one or more launch wheel motors 1281-1282 (which may be collectively or individually referred to as "launch wheels 127") connected to launch wheels 127 to rotate launch wheels 127, which rotation imparts velocity, spin, and / or lateral direction to ball 90. In some cases, two launch wheels 127 may rotate at the same rate, and in other cases, two launch wheels 127 may rotate at different rates to impart spin to ball 90, causing it to curve when launched. 1, the ball delivery device 120 includes two firing wheel motors 1281-1282, where the first firing wheel motor 1281 is configured to control the first firing wheel 1271 and the second firing wheel motor 1282 is configured to control the second firing wheel 1272. Additionally, each of the two firing wheel motors 1281-1282 may include an encoder attached thereto. FIG. 2 shows an encoder 1291 attached to the firing wheel motor 1281. A similar configuration may exist for the encoder coupled to the firing wheel motor 1282. Further details regarding the encoder(s) are described below with respect to at least FIG. 17.

[0054] 1 and 2 together, ball delivery device 120 is rotatably coupled to base frame member 216 at rotatable coupling point 115. Rotation of ball delivery device 120 relative to base frame member 216 defines a launch angle 121 of ball 90. Ball thrower 100 also includes a launch angle actuator 225 coupled between ball delivery device 120 and base frame member 216, which is configured to control or adjust the angle of ball delivery device 120 relative to base frame member 216 to define the launch angle 121 of ball 90 relative to ground 50. Launch angle actuator 225 may include any suitable type of motor, such as, for example, a brushed DC motor, a servo motor, or a stepper motor.

[0055] The ball thrower 100 includes a base plate 112 rotatably coupled to a base frame member 216 via an axle 231 extending between the base plate 112 and the base frame member 216. The base plate 112 includes a number of legs 232 configured to provide stable placement of the ball thrower 100 on the ground 50. A lateral actuator 235 is coupled between the base plate 112 and the base frame member 216 such that operation of the lateral actuator 235 rotates the base frame member 216 relative to the base plate 112 during use. Rotation of the base frame member 216 relative to the base plate 112 defines a lateral (adjacent) direction of the trajectory. The lateral actuator 235 may include any suitable type of motor, such as, for example, a brushed DC motor, a servo motor, or a stepper motor.

[0056] 3 shows a top view of the control unit 220. The control unit 220 with control circuitry can include various features that can be used to control the ball thrower 100, including the ball delivery device 120. The control unit 220 includes a circuit card assembly (CCA) 300 with electronic circuitry, including, among other things, a power connector 302, an interface module connector 303, a daughter board connector 304, a launch motor driver 306, a wireless module (e.g., BLUETOOTH™) 308, and a processor 310. The CCA 300 may also be referred to as a printed circuit board assembly (PCBA), printed circuit assembly (PCA), or circuit board. The memory 312 (e.g., a non-transitory computer-readable medium) includes program instructions stored thereon for controlling various electrical features of the ball thrower 100, such as the launch motor 128 of the ball delivery device 120 and the other actuators described above. The power connector 302 provides a wired connection to the power source 222, the interface module connector 303 provides a wired connection to the interface module 1000 (see FIG. 10 ), and the daughterboard connector 304 provides a wired connection to a daughterboard (not shown). The inclusion of a daughterboard within the circuit board architecture enables many possible types of additional functionality for the ball thrower 100 that may not currently be foreseen, may be required for only a few units, or may otherwise be an optional item. As an example, a daughterboard may be utilized to enable wired communication over a serial port to the controller via a 9-pin connector 1008 on the back of the user interface module 1000 ( FIG. 10 ). The firing motor driver 306 provides power to the firing motor 128 as dictated by an electrical signal from the processor 310.The CCA 300 further includes an audio notification device 314 (eg, a buzzer or speaker) configured to provide various audible notifications or alerts to the user as defined by the logic.

[0057] The wireless module 308 is configured to enable communication between the ball thrower 100 and at least the remote controller 80. For example, the wireless module 308 enables the ball thrower 100 to receive operational commands from the remote controller 80 and transmit operational data to the remote controller 80.

[0058] In the illustrated embodiment, the control unit 220 includes one or more operational sensors configured to monitor the operation of the ball thrower 100, such as to detect anomalous operating conditions. The control unit 220 may also include a microphone 320 electrically coupled to the CCA 300 such that logic, when executed by the processor 310, can analyze the sound data and determine from the sound data whether the ball thrower 100 is operating normally, i.e., the logic can determine from the sound data that the ball thrower 100 is operating abnormally or anomalously in any number of ways. The microphone 320 is attached directly to the CCA 300, increasing reliability and reducing the cost of the ball thrower 100 by eliminating wires, connectors, and certain microphone-mounted components. During operation, the ball thrower 100 generates various noises, i.e., sound data, associated with normal operation, and the ball thrower 100 may also generate different sound data associated with abnormal operation.

[0059] As an example, during normal operation, the motors 128 may define expected sound data (e.g., a hum) when rotating the firing wheel 127 at a particular defined speed (RPM). If one of the motors 128 has a defect, such as a worn motor bearing, the motor 128 may generate anomalous sound data, i.e., sound data that differs from the expected sound data. In such a case, the microphone 320 may pick up (i.e., listen to) the anomalous sound data and determine from the sound data that one of the motors 128 is not operating properly.

[0060] As another example, ball stop 210 may generate noise when transitioning from (i) a first state that prevents ball 90 from traveling down ball-delivery ramp 122 to ball-delivery device 120 to (ii) a second state that allows ball 90 to travel down ball-delivery ramp 122 to ball-delivery device 120. Synchronized with a logic command that transitions ball stop 210 from the first state to the second state, the logic may look for an expected sound signature (which may be stored in memory) associated with a successful transition from the first state to the second state. If the expected sound signature is not detected, the logic may determine that ball stop 210 did not transition from the first state to the second state. In the illustrated embodiment, microphone 320 may be located in close proximity to ball stop 210, such as directly below ball stop 210, so as to be able to acquire accurate sound data from ball stop 210. Additionally, ball stop 210 may be mounted to housing 102 such that housing 102 acts as a sound board to generate the sound signature.

[0061] In a similar manner, in synchronization with the logic command that transitions ball stop 210 from a first state to a second state, thereby allowing ball 90 to travel down launch ramp 122 to ball delivery device 120, the logic may look for an expected sound signature associated with the launch of ball 90. If the expected sound signature is not detected, the logic may determine that ball 90 was not launched and that the launch was anomalous.

[0062] As an alternative to or in addition to the microphone 320, the control unit 220 may include an accelerometer 330 electrically coupled to the CCA 300 such that logic, when executed by the processor 310, can analyze vibration data (or more broadly, motion data) of the base frame member 216 and determine from the vibration data whether the ball thrower 100 is operating normally, i.e., whether the logic can determine from the vibration data whether the ball thrower 100 is operating abnormally in any number of ways. Like the microphone 320, the accelerometer 330 is mounted directly to the CCA 300, increasing reliability and reducing cost of the ball thrower 100 by eliminating wires, connectors, and certain accelerometer-mounted components. Additionally, the CCA 300 is mounted directly to the base frame member 216 such that the accelerometer 330 can obtain accurate readings of the movement / vibration of the base frame member 216. During normal operation, operation of the ball thrower 100 may cause the base frame member 216 to move in various expected ways, resulting in vibration data associated with normal operation, which the accelerometer 330 may detect or determine. In the event of abnormal operation, the ball thrower 100 may move the base frame member 216 in a manner associated with abnormal operation that is different from normal operation. Thus, the accelerometer 330 may be configured to detect differences in the vibration or movement of the base frame member 216 produced by the ball thrower 100 between normal and abnormal operation.

[0063] As an example, during normal operation, the firing wheels 127 may define expected vibration data, particularly when the firing wheels 127 rotate at a specified speed (RPM). In some cases, the firing wheels 127 may wear, resulting in an imbalance of the firing wheels 127. The imbalance may therefore result in a difference (e.g., an increase) in the vibration of the base frame member 216 as the firing wheels 127 rotate. Thus, the accelerometer 330 may detect vibration data that differs from the expected vibration signature. In response, the logic may determine that at least one of the firing wheels 127 is out of balance.

[0064] As another example, the base frame member 216 may move or vibrate in response to the launch of the ball 90; i.e., the base frame member 216, together with the ball thrower 100 as a whole, may kick or lurch backward as the launch wheel 127 imparts velocity to the ball 90. Thus, synchronized with each launch of the ball 90, logic may look for expected vibration data associated with normal launch characteristics. If the detected vibration data differs from the expected vibration data (e.g., a vibration signature stored in memory), the logic may determine that the ball 90 was not launched as intended, e.g., was not launched or was launched erroneously. There are several possible causes for an erroneous ball launch, such as, for example, an incorrect ball size, a deflated ball, a worn ball, a ball with a slippery or wet surface, or a worn launch wheel. In some embodiments, the accelerometer 330 may include a sensing orientation, indicated by arrow 331. In such an embodiment, the accelerometer 330 may be oriented so that the sensing orientation 331 is aligned with the fore / aft direction of the ball thrower 100 as shown in FIG.

[0065] In a similar manner as described above, microphone 320 and / or accelerometer 330 may be used to monitor the operation of launch angle actuator 225 and / or lateral actuator 235. In other words, microphone 320 and / or accelerometer 330 may be deployed to determine whether an activation command causes one or both of launch angle actuator 225 or lateral actuator 235 to operate normally, operate abnormally, or fail to operate.

[0066] It will be understood that ball delivery device 120 can function in many different ways, including different ways than described herein. For example, rather than including a launch angle actuator 225 or a lateral angle actuator 235, ball delivery device 120 can be moved or positioned manually. Additionally, although described as being primarily used for pitching soccer balls, ball delivery device 120 can be similarly adapted to pitch other types of balls, such as baseballs, softballs, tennis balls, racquetballs, squash balls, cricket balls, lacrosse balls, volleyballs, and the like.

[0067] The CCA 300 may also include a current sensor 316 and / or a temperature sensor 318. In some embodiments, the current sensor 316 may be included in the CCA 300 and configured to measure the current through one or more of the wheel motors 128. In some embodiments, the CCA 300 may include two current sensors 316, whereby a first current sensor 316 measures the current through the first wheel motor 1281 and a second current sensor 316 measures the current through the second wheel motor 1282. In some embodiments, the current sensor 316 may be a Hall-effect current sensor. The current sensor 316 may be an integrated circuit (IC) or surface-mount device (SMD) component disposed on the CCA 300. As the ball delivery device 120 operates during the process of implementing the training programs discussed herein, the current sensor 316 may continuously monitor the current drawn by the wheel motors 128.

[0068] In some cases, the current value measured by the current sensor 316 may be provided to logic (shown in FIGS. 11-12) of the system 1104. In some particular examples, the sensor data evaluation logic 1214 obtains the measured current value and compares it to one or more thresholds, where the one or more thresholds indicate whether the wheel motors 128 are drawing too much current. As a result, an alert or flag may be generated for an administrator or other user. In some cases, based on the threshold comparison, the CCA 300 may be instructed to take action, including pausing execution of code responsible for implementing a training program. Thus, pausing execution of the code may include instructing the wheels to stop spinning, allowing the current draw to decrease. For example, if the measured current value exceeds a first threshold, the alert generation logic 1220 may generate an alert for an administrator or other user, and if a second threshold (the second threshold indicating a current value greater than the first threshold) is exceeded, instructions to pause execution of the code described above may be provided to the CCA 300.

[0069] In some embodiments, a temperature sensor 318 may be included in the CCA 300 and may be configured to measure the ambient temperature of the CCA 300, which is indicative of the current drawn by one or more of the wheel motors 128. As discussed above, the amount of current drawn by one or more of the wheel motors 128 indicates how fast the wheels 127 are spinning. In some cases, the temperature values ​​measured by the temperature sensor 318 may be provided to logic (shown in FIGS. 11-12 ) of the system 1104. In some specific examples, the sensor data evaluation logic 1214 obtains the measured temperature values ​​in the same manner as the measured current values, as described above, and compares the measured temperature values ​​to one or more thresholds. Furthermore, similar actions may be taken in response to the threshold comparisons.

[0070] FIG. 4 is a block diagram of a computerized method 400 that, according to some embodiments, includes all or any subset of the following actions, operations, or processes. Each block shown in FIG. 4 represents an operation of method 400 performed by a ball thrower disclosed herein and typically as a result of execution of logic in the ball thrower. Method 400 may include receiving instructions to launch a series of objects from a ball thrower (block 402), the ball thrower including a set of launch wheels configured to launch the series of objects, a motor coupled to each launch wheel, and one or more motion sensors. In some embodiments of method 400, launching the series of objects includes rotating the set of launch wheels to result in the delivery of the series of objects to the player, where the series of objects may include one or more balls. In some embodiments of method 400, the one or more motion sensors include at least one of an accelerometer or a microphone. Method 400 may further include acquiring data from the motion sensors (block 404) while the ball thrower launches the series of objects in accordance with the received instructions. Method 400 may further include detecting one or more operational actions of the ball thrower based on data obtained from one or more of the operational sensors (block 406). In some embodiments, computerized method 400 further includes (i) analyzing data related to the operation of the ball thrower; and (ii) detecting that the launch of a first object was anomalous by comparing the data related to the operation of the object throwing device to data signatures stored in a memory of the ball thrower, the data signatures representing an expected set of data corresponding to the launch of a series of objects. In some embodiments, method 400 further includes (i) analyzing data related to the operation of the ball thrower, the data related to the operation of the ball thrower including at least one of vibration data or sound data; and (ii) detecting that the ball thrower is operating anomalously by comparing the data related to the operation of the ball thrower to data signatures representing expected vibration data or sound data.

[0071] FIG. 5A is a block diagram of a computerized method 500 that, according to some embodiments, includes all or any subset of the following actions, operations, or processes. Each block shown in FIG. 5 represents an operation of method 500 performed by the ball thrower disclosed herein and typically as a result of execution of one or more disclosed logic modules of the ball thrower. Method 500 may include acquiring data from an accelerometer of the ball thrower that captures vibration data of the ball thrower during operation (block 502). Method 500 may further include performing one or more analyses on the data acquired from the accelerometer, a first of the one or more analyses including comparing vibration data corresponding to known points in time during operation of the ball thrower, the known points in time corresponding to an expected launch of an object by the ball thrower (block 504). Method 500 may further include determining whether the expected launch of the object has occurred based on the comparison (block 506). The method 500 may further include classifying the firing as normal or anomalous upon determining that an expected firing of the object has occurred (block 508).

[0072] FIG. 5B is a block diagram of a computerized method 550, which, according to some embodiments, includes all or any subset of the following actions, operations, or processes. Each block shown in FIG. 5 represents an operation of method 550 performed by the ball thrower disclosed herein and typically as a result of execution of one or more disclosed logic modules of the ball thrower. Method 550 may include acquiring sound data from a microphone of the ball thrower while the ball thrower launches a first object of a series of objects in accordance with received instructions (block 552). Method 550 may further include performing an analysis on the sound data, which may include comparing (i) a subset of sound data corresponding to a known time point at which the first object was launched against (ii) expected sound data for the object launch, the expected sound data being stored in a memory of the ball thrower (block 554). Method 550 may further include determining that the launch of the first ball was anomalous based on the comparison (block 556) and generating an alert indicating that the launch of the first ball was anomalous (block 558). In some embodiments of method 550, the alert is recorded in a data log. In some embodiments of computerized method 550, the control circuitry of the ball throwing machine is configured to receive instructions to launch a series of objects, the instructions indicating a number of objects to be launched and at least a velocity or trajectory for each of the launched objects.

[0073] 6A is a front view of the ball thrower 100 with the hopper 126 removed. The ball delivery ramp 122 is shown positioned between the launch wheels 127 of the ball delivery device 120. A ball 90 located in the ball staging area 212 (see FIG. 2) is also shown in phantom. As discussed above, the ball thrower 100 includes a ball stop 210 that prevents the ball 90 from leaving the ball staging area 212 and a ball sensor 211 that detects the presence of the ball 90 within the staging area 212. The ball stop 210 includes a solenoid 610, which is shown hidden beneath the housing 102. The solenoid 610 is attached to the underside of the housing 102 via a solenoid mount 611.

[0074] 6B is a detailed view of a portion of the ball thrower 100 showing the ball stop 210 and ball sensor 211 disposed within the opening 205. The ball stop 210 further includes a protrusion 612 operably coupled to a solenoid 610 such that the protrusion 612 can extend through the opening 205. Activation of the solenoid 610 selectively positions the protrusion 612 between an extended position and a retracted position. In the extended position, the protrusion 612 protrudes from the opening 205 and engages the ball 90 to retain the ball 90 within the staging area 212. In the retracted position, the protrusion 612 disengages from the ball 90, allowing the ball 90 to exit the staging area 212 and travel down the ball delivery ramp 122 to the ball delivery device 120 for launch. In the embodiment shown, the protrusion 612 is biased toward the extended position so that when the solenoid 610 is deactivated (i.e., demagnetized), the ball 90 is retained within the staging area 212 and prevented from being launched. An advantage of biasing the protrusion 612 toward the extended position is that the ball 90 can be stored within the staging area 212 and hopper 126 when the ball thrower 100 is not in use.

[0075] As discussed above, ball sensor 211 detects the presence and / or absence of ball 90 within staging area 212. In the illustrated embodiment, ball sensor 211 is coupled to the underside of housing 102. In some embodiments, ball sensor 211 may be attached directly to solenoid 610, which is attached to the underside of housing 102. Ball sensor 211 may be any type of sensor capable of detecting the presence of ball 90, such as, for example, a ball activated switch, a proximity sensor, a capacitance sensor, an inductive sensor, or an optical sensor. In the illustrated embodiment, ball sensor 211 is an optical sensor configured to project emitted light signal 606 through opening 205 and into staging area 212. Ball sensor 211 is further configured to detect reflected light signal 604, i.e., a reflection of emitted light signal 606 from surface 91 of ball 90, when ball 90 is disposed within staging area 212. Because ball 90 may include different colors, e.g., black and white, and because the surface of ball 90 may include seams that may affect reflectivity, emitted light signal 606 may include a defined wavelength spectrum for optimal operation and / or reliability of ball detection. In the illustrated embodiment, ball sensor 211 includes a laser configured to project emitted light signal 606 having wavelengths within the red light spectrum to optimize operation and / or reliability of ball detection. As known in the art, the red light spectrum range is often considered to be light waves having wavelengths within the range of 620 nanometers (nm) to 700 nm.

[0076] 7 is a schematic diagram of an optional emergency stop circuit 752 of the control unit 220, according to some embodiments. The emergency stop circuit 752 is a hardwired fail-safe circuit that, when deployed, will disconnect power from the motor 128. In some embodiments, the emergency stop circuit 752 may be connected to an external instrument or device by a wired connection, such as by two dedicated pins on a 9-pin serial connector 1008 (see FIG. 10 ). The emergency stop circuit 752 is configured to allow the motor 128 to move when the two pins are connected together. If the two pins are not connected together, the emergency stop circuit will cut power to the launch motor 128.

[0077] 7, one example implementation of emergency shutdown circuit 752 may include a daughter CCA 750 coupled to CCA 300. In the embodiment shown, a first portion of emergency shutdown circuit 752 is located on daughter CCA 750 and a second portion of emergency shutdown circuit 752 is located on CCA 300. In other implementations, daughter CCA 750 may be omitted such that both the first and second portions of emergency shutdown circuit 752 are located on CCA 300.

[0078] The daughter CCA 750 includes, among other things, an e-stop relay 754, the output of which is serially connected in-line with the launch motor 128. Thus, when the e-stop relay 754 is de-energized, the e-stop relay 754 interrupts the power connection to the launch motor 128. More specifically, the e-stop relay 754 is a normally open relay.

[0079] In some embodiments, the watchdog component will enable the e-stop function if the microprocessor 310 fails to properly create an AB toggle function. The AB toggle function involves the microprocessor 310 setting the A pin to "high" and the B pin to "low." Then, within a specified amount of time, the microprocessor 310 sets the A pin to "low" and the B pin to "high," then back again within the same specified amount of time. The AB toggle function occurs continuously. The watchdog component monitors this toggle, and if the watchdog component determines that the AB pin values ​​are not toggling properly, the e-stop relay 754 is enabled.

[0080] The input of the emergency stop relay 754 is coupled to the emergency stop switch according to alternative configurations. In a first configuration, a local emergency stop switch 756A is operably coupled to the input of the emergency stop relay 754 such that when the local emergency stop switch 756A is closed, the emergency stop relay 754 is energized and when the local emergency stop switch 756A is opened, the emergency stop relay 754 is de-energized, thereby cutting power to the launch motor 128. In some embodiments, the local emergency stop switch 756A may be located on the motor head as shown in FIG. 10 . However, in other embodiments, the local emergency stop switch 756A may be located on the interface module 1000.

[0081] In a second alternative configuration, the remote emergency stop switch 756B is operably coupled to the input of the emergency stop relay 754 by a wired connection including, for example, two dedicated pins on the 9-pin serial connector 1008. The remote emergency stop switch 756B therefore operates similarly to the local emergency stop switch 756A, i.e., when the remote emergency stop switch 756B is closed, it allows operation of the firing motor 128, and when the remote emergency stop switch 756B is open, it prevents operation of the firing motor 128.

[0082] FIG. 8 is a block diagram of a computerized method 800 that, according to some embodiments, includes all or any subset of the following actions, operations, or processes. Each block shown in FIG. 8 represents an operation of method 800 performed by a ball thrower disclosed herein and typically as a result of execution of logic in the ball thrower. Method 800 may include receiving (block 802) a command to launch a series of objects from a ball thrower that includes a set of launch wheels configured to launch the series of objects, a motor coupled to each launch wheel, and a ball presence sensor. Method 800 may further include obtaining (block 804) a reading from the ball presence sensor prior to launching the objects in accordance with the received command. In some embodiments of method 800, the ball presence sensor is an optical sensor configured to detect light reflected from an exterior surface of one of the series of objects. Method 800 may further include determining (block 806) whether an object is present at a base of a hopper of the ball thrower based on the reading from the ball presence sensor. The method 800 may further include allowing or preventing initiation of an object launch sequence based on a determination as to whether an object is present at the base of the hopper (block 808).

[0083] In some embodiments, method 800, following block 808, may allow the object launch to begin and / or may include performing any of the following actions: repeating method 800 beginning at block 804 (e.g., obtaining a second subsequent reading from the ball presence sensor and re-evaluating whether a ball is present); pausing execution of software code corresponding to the training program for a predetermined amount of time (e.g., 5, 10, 15 seconds, etc.) to allow time for the ball to fall down the hopper or to give the trainer or user an opportunity to place the ball in the hopper; pausing execution of software code corresponding to the training program and activating a stepper motor or solenoid of ball throwing device 100, which is intended to shake or vibrate ball thrower 100 and cause the ball to fall from its location in the hopper downward to the base of the hopper.

[0084] In some cases, in response to determining that an object is not present at the base of the hopper, method 800 may ignore such determination and assume that the ball presence sensor is broken, defective, or otherwise not working properly. In such cases, method 800 may allow ball thrower 100 to continue operating and implementing the training program while monitoring whether one or more balls have been fired in accordance with the training program by other methods, such as by monitoring current usage as discussed above with respect to current sensor 316 and temperature sensor 318, or by detecting ball firing through analysis of captured video of the training session (e.g., using image detection to detect balls fired at expected times based on the training program).

[0085] FIG. 9 is a block diagram of a computerized method 900 that, according to some embodiments, includes all or any subset of the following actions, operations, or processes. Each block shown in FIG. 9 represents an operation of method 900 performed by a ball thrower disclosed herein and typically as a result of execution of logic in the ball thrower. Method 900 may include obtaining a reading from a ball presence sensor of the ball thrower (block 902) following receipt of an instruction to launch a series of objects from the ball thrower. In some embodiments of method 900, the ball presence sensor is an optical sensor configured to detect light reflected from an exterior surface of one of the objects. Method 900 may further include initiating an object launch sequence in an attempt to launch a first object according to the received instruction (block 904). Method 900 may further include analyzing a reading obtained from the ball presence sensor at a time corresponding to the anticipated launch of the object (block 906) following an unsuccessful object launch sequence. The method 900 may further include determining whether a first object was present at the base of the hopper of the ball thrower at the expected launch time based on an analysis of the readings obtained from the ball presence sensor (block 908).

[0086] FIG. 10 shows a perspective rear view of the ball thrower 100 with the hopper 126 removed. The ball thrower 100 includes an interface module 1000 having various components to enable the ball thrower 100 to be operated by a user and / or an external device. The operator interface portion of the interface module 1000 may include an on / off switch 1002, such as, for example, a push button switch. The operator interface portion may further include several status indicators 1014, including, for example, visual status indicators such as LEDs. The status indicators 1014 may provide notifications to the user according to normal and / or abnormal operation, such as those discussed above in connection with one or more sensors. The status indicators 1014 may also provide other notifications or alerts, such as, for example, a low battery condition.

[0087] The interface module 1000 may further include various connectors to enable the ball thrower 100 to interact with external devices. The connectors or ports may include, for example, a 9-pin serial port 1008, a USB-C connector 1006, a charging port 1004 (e.g., configured to receive an M12 4-pin connector), and / or an RJ45 port (Ethernet) connector 1010.

[0088] The 9-pin serial port connector 1008 allows the ball thrower 100 to be hardwired to the remote controller 80 and / or other devices, such as a sensor configured to detect the ball 90 in the hopper 126, an emergency stop system, or a ball return system. The RJ45 port (Ethernet) connector 1010 connects directly to a port on the CCA 300, allowing the ball thrower 100 to communicate over a wired network if and when wired communication is desired. The USB-C connector 1006 allows the ball thrower 100 to charge the remote controller 80, a phone, a tablet, or any other device. In the embodiment shown, the charging circuitry of the CCA 300 may be configured to provide charging power including 3 amps at 5 volts.

[0089] II. Ball throwing motion analysis Some deployments of ball throwers may include sports training facilities or social settings. In the former, multiple ball throwers may be deployed within portions, which may be called bays, of a larger space, and sets of bays may be separated from each other and from other aspects of the larger space by netting. In the latter (social settings), ball throwers may similarly be deployed within bays of a larger space that are separated from other bays or aspects of the larger space by netting or walls. Trainers or staff members may be trained upon commencing a training program within a sports training facility or a gamification program within a social setting, and training programs and gamification programs may collectively be referred to herein as "training programs."

[0090] As mentioned above, in some cases, a ball thrower may operate for hours, days, or even months at a time without being evaluated for performance issues. For example, a trainer may initiate a series of training programs, and the ball thrower is deployed to launch a series of balls. At the end of the facility's business hours, the trainer may plug the ball thrower into an electrical outlet (or otherwise charge the batteries). This procedure may be repeated day after day until the ball thrower "suddenly" develops a performance issue. Exemplary performance issues may include worn launch wheels, over-inflated balls, deflated balls, motor issues, or loose components of the ball thrower (e.g., loose screws). These performance issues may not be easily observable with a trainer's naked eye. For example, an extremely deflated ball may be easily noticed, but a slightly deflated ball will not be visually detectable with the naked eye. "Slightly deflated" may refer to, for example, 10-20% deflation compared to desired inflation; pressure is measured in pounds per square inch (PSI), with the International Federation of Association Football (FIFA) requiring a PSI of 8.5-16.5. A slightly deflated ball can affect the operability of a ball thrower by affecting launch accuracy by not launching with the proper speed, direction, spin, etc., and can affect the operation of the motor by drawing a higher amount of current than would otherwise be necessary to spin the launch wheel at the required speed. As another example, a loose component within a ball thrower may not be visually detectable by a trainer but may still cause operational problems. For example, a loose component may become dislodged and fall into an airspace within the ball thrower, interfering with ball launch and damaging the ball or the ball thrower.In some embodiments, as components become loose, the ball thrower may begin to rattle during operation, a rattle that is undetectable by the human ear, especially in large spaces with many ball throwers operating simultaneously and players training. However, such rattle may be detectable by a microphone recording the sounds of the ball thrower during operation. Similarly, the progression of motion performed for each ball launch may produce a similar noise pattern (signature) from launch to launch and / or may follow scripted timing.

[0091] Through the methods described herein, a trainer or other staff member may be alerted to anomalous behavior or otherwise confirm normal behavior by monitoring and analyzing sensor data collected during operation of the ball thrower. Additionally, the methods described herein may initiate automated corrective or remedial action in response to automated determinations regarding the operability of the ball thrower, which may be based on automated analysis of signatures generated from acquired sensor data and / or the deployment of machine learning / artificial intelligence techniques. Accordingly, some practical applications of the inventive concepts will be further detailed below, including identifying improper mechanical operation of a ball thrower, identifying a lack of available balls immediately prior to a firing sequence, identifying one or more deflated or over-inflated balls, identifying improper timing of operations including a firing sequence, identifying loose components of the ball thrower, instructing a trainer or staff member to take specific remedial action, and / or automatically initiating specific remedial action. Other practical applications will be discussed throughout and / or will become apparent to those skilled in the art.

[0092] Currently, there is no automated monitoring of the operability status of a ball thrower and determining whether the status is normal or anomalous. Therefore, there is a need in the art for a ball thrower, method, and system that determines when these complex, technical machines are operating anomalously. As described herein, a ball thrower includes specific, specialized data sensors configured to acquire specific data regarding the operability of the ball thrower. Furthermore, detailed methods are disclosed for generating signatures from the sensor data that can be compared with known normal and / or anomalous behavior signatures in light of general operability and in specific situations, such as firing sequences. Further disclosed embodiments relate to the generation (training) and deployment of machine learning models configured to predict the operability status of a ball thrower from sensor data acquired during operation of the ball thrower.

[0093] As such, the embodiments disclosed herein specifically improve the technical operation of current ball throwing machines by ensuring that the machines operate as expected, identifying performance issues not discernible by the human eye (or ear), identifying trends in performance status that may indicate impending performance issues, providing alerts of performance status, issues, or trends to trainers or staff members, and finally, at their option, providing instructions regarding or automatically initiating corrective action. As such, the present disclosure enables more accurate operation of ball throwing machines and reduces the likelihood that the machines will suffer permanent or serious malfunctions.

[0094] As described in detail below, the methods provided herein improve the field of ball throwers, particularly “smart” ball throwers that are coupled to a network and exchange data with logic running on a networking device (e.g., a remote server or other cloud computing resource). In some embodiments, the ball thrower may include one or more sensors integrated therein, such as a microphone or vibration sensor disposed on the ball thrower's circuit board. The sensors may acquire data during operation of the ball thrower and logic (e.g., executed by one or more processors) running on the ball thrower's circuit board and / or communicatively coupled to the ball thrower. In some cases, the logic generates one or more signatures from the sensor data and compares the signatures to known operational statuses, e.g., signatures of normal or anomalous operational behavior. In other cases, the logic deploys a machine learning (ML) model that provides the sensor data as input to obtain a prediction or classification of the ball thrower's operational status. In some cases, both modalities may be utilized. For example, one modality (signature comparison or ML analysis) may carry more weight in the decision, or one modality may be used to confirm the other, such that when the modalities match, the status has a high confidence indication, and when the modalities do not match, the status has a low confidence indication.

[0095] 1. System Architecture 11, a block diagram illustrating a first system architecture of a ball thrower coupled to a data processing system operating in a networked environment is shown, according to some embodiments. Shown is a networked environment 110 including a ball thrower 100, a remote 80, and a network 1102. Additionally, two instances 1104 of the data processing system are shown. 1-2(Either instance may be referred to as "data processing system 1104") is shown operating on network 1102 and remote 80, respectively. In some embodiments, an instance of a data processing system may operate on ball thrower 100, although not shown for simplicity.

[0096] As discussed above, the ball thrower 102 is configured to deliver balls, such as soccer balls or specialized soccer-type balls, to a user, with the delivery of the balls typically occurring according to a training program. As further discussed above, the training program is selected by a user, trainer, or other staff member and transmitted to the ball thrower 100, with execution of the training program resulting in the initiation of actions performed by the ball thrower 100 to launch a series of balls. As shown in FIG. 11 , the selection of the training program may occur remotely 80 and transmitted to the ball thrower 11, for example, via a wired or wireless connection. In other embodiments, the selection of the training program may occur at a network device communicatively coupled to the ball thrower via network 1102, whereby the selection is transmitted over the network.

[0097] As soon as operation resulting in the launch of a ball according to the training program begins, a set of sensors may begin collecting data indicative of the operability of the ball thrower. The set of sensors may include sensors disposed on the ball thrower 100, such as the ball sensor 211, microphone 320, accelerometer 330, etc. As discussed in detail below, a data processing system ("system") 1104 is configured to acquire the sensor data, generate one or more signatures from the sensor data, and / or analyze the sensor data to determine the operability status of the ball thrower and / or particular components of the ball thrower. Analysis of the sensor data may include comparison with predetermined signatures generated following deployment of the ball thrower during known operating conditions (e.g., known to be suitable or unsuitable for normal operation and for abnormal operation, including known abnormal conditions such as a worn launch wheel, an over-inflated or under-inflated ball, no ball in the solenoid, etc.). Additionally or alternatively, the analysis may involve machine learning techniques such as processing the sensor data with a trained machine learning model or neural network.

[0098] As will be discussed below, the system 1104 is configured to determine the operability status of the ball thrower or its components and / or predict the future operability status of the ball thrower. Based on the determination or prediction, the system 1104 may generate an alert to a user, trainer, or other staff member, may generate a log entry that is recorded for later observation, may automatically stop the ball thrower, may automatically adjust the training program (e.g., reducing the speed of the ball, pausing the training program to allow the ball to be placed in the hopper, etc.), and / or may provide remediation recommendations or instructions to remedy errors associated with the abnormal operation.

[0099] 12, a logic diagram illustrating logic modules of the data processing system ("system") of FIG. 11 stored on non-transitory storage and configured to be executed by one or more processors is shown, according to some embodiments. The illustrated computing environment 1200, including processor 1202, communications 1204, and non-transitory computer-readable medium (storage) 1206, may represent a portion of a network device, such as a server device, a mobile phone, a tablet, or other computing device. In other embodiments, computing environment 1200 may represent a cloud computing environment, which may be understood to include hosted services delivered over a network such as the Internet. In some cases, computing environment 1200 may refer to a cloud computing service including servers, storage, and virtualized computing resources hosted by a third party, such as Amazon Web Services, Inc. (AWS), where computing environment 1200 is configured for processing within a virtualized computing environment, e.g., a virtual machine (VM).

[0100] System 1104 is shown as stored on storage 1206 and includes logic modules for sensor collection logic 1208, signature generation logic 1210, model training logic 1212, sensor data evaluation logic 1214, alert generation logic 1220, and improvement logic 1222. Sensor data evaluation logic 1214 includes sub-logic modules for signature evaluation logic 1216 and model evaluation logic 1217. System 1104 is shown to include signature / model storage (e.g., database) 1218. Additionally, storage 1206 may have communication interface logic 1224 stored thereon.

[0101] The sensor collection logic 1208, when executed by the processor 1202, is configured to operate to receive acquired sensor data from each of one or more sensors disposed in a ball thrower, such as ball thrower 100. The sensor collection logic 1208 may acquire the sensor data in any of several formats, as individual sensors acquire data in various formats (e.g., audio data via a microphone and numerical data representing vibration levels). Additionally, the sensor collection logic 1208 is configured to acquire current / power usage readings from the ball thrower's motor. The current / power usage data will be included as part of the sensor data discussed herein.

[0102] The signature generation logic 1210, when executed by the processor 1202, is configured to perform operations to generate a signature from the sensor data. Details regarding the signature generation process are provided below, for example, with respect to Figures 13A-13B. Following signature generation, the signature may be stored in the signature / model storage 1218.

[0103] The model training logic 1212, when executed by the processor 1202, is configured to perform operations to train machine learning models or neural networks, each configured to analyze the sensor data and / or signatures to predict or classify the operational status of the ball thrower. More details on training machine learning models and neural networks are included below. Following training or generation of the machine learning models or neural networks, each may be stored in the signature / model storage 1218.

[0104] The sensor data evaluation logic 1214, when executed by the processor 1202, is configured to evaluate the sensor data and perform operations involving signature analysis and / or machine learning techniques to classify a current operational status of the ball thrower, predict a current or future operational status of the ball thrower, classify or predict the operational status of particular components of the ball thrower, etc. The sensor data evaluation logic 1214 may include sub-modules signature evaluation logic 1216 and model evaluation logic 1217. The signature evaluation logic 1216 may be configured to obtain acquired sensor data from the sensor collection logic 1208 and one or more signatures from the signature / model storage 1218, and perform a comparison between the acquired sensor data and the one or more signatures. As described herein, the comparison may, in some embodiments, attempt to find an exact match. However, in other embodiments, the comparison may attempt to identify a percentage of match, whereby the percentage may be compared to a threshold, with meeting the threshold comparison indicating a match (e.g., the threshold may be 75%, 80%, 90%, etc.). The threshold may vary according to the particular signature, whereby a first signature (e.g., derived from audio data and compared to the audio data) may be paired with a first threshold (e.g., 70%), and a second signature (e.g., derived from vibration data and compared to the vibration data) may be paired with a second threshold (e.g., 80%). It should be understood that these examples are not limiting and are merely illustrative. The comparison may indicate that a particular action did or did not occur when the sensor data was collected (in other words, the signature comparison, and optionally the threshold comparison, may indicate that the sensor data represents a particular action, such as a ball firing sequence or the activation of a solenoid in a ball thrower). Thus, signature comparison may be used to determine the sequence of actions that occurred during deployment of the ball thrower.By comparing (i) the sequence or series of actions detected according to the signature comparison with (ii) the training program, the sensor data evaluation logic 1214 may determine whether the ball thrower is operating normally or abnormally. For example, when the actions of the training program match the actions detected according to the signature comparison for the same actions, the sensor data evaluation logic 1214 determines that the ball thrower is operating normally (e.g., the training program commands that 10 balls be fired, and the sensor data indicates that 10 balls were fired according to the signature comparison). However, if the signature comparison results are inconsistent with the training program, the sensor data evaluation logic 1214 determines that the ball thrower is operating abnormally. Depending on the percentage of the signature comparison results that match the training program, the sensor data evaluation logic 1214 may indicate the percentage of the ball thrower that is operating normally or abnormally. Further, in some embodiments, the sensor data evaluation logic 1214 may indicate that certain components are operating normally, while other components are operating abnormally. For example, if two out of ten actions are identified by the signature evaluation logic 1214 as not occurring or occurring outside of a threshold time window (e.g., occurring later), the component(s) responsible for such actions may be indicated as behaving abnormally, while the other components may be indicated as behaving normally.

[0105] Additionally, the model evaluation logic 1217 may be specifically configured to obtain the acquired sensor data and one or more models (collectively, machine learning models and / or neural networks) from the sensor collection logic 1208 and the signature / model storage 1218, respectively, and apply the models to the acquired sensor data (e.g., the sensor data is provided as input to the models). The application of the models to the sensor data results in a classification or prediction of a future operating status. In some embodiments, the trained machine learning models may be configured to classify components of the ball thrower as operating normally or abnormally. Alternatively or additionally, the trained machine learning models may be configured to extrapolate the current operating status of various components to generally predict the future operating status of one or more components of the ball thrower.

[0106] Details of some embodiments of the training and deployment of some machine learning techniques are discussed below. Various machine learning models may be trained using historical data (e.g., sensor data during deployment of the ball thrower under known operating conditions and / or labeled previously collected sensor data), where the machine learning models are configured to classify or predict the operational status of the ball thrower or its components. Exemplary machine learning algorithms that may be used in generating the trained machine learning models include, but are not limited to, classification algorithms such as logistic regression, decision trees, random forests or gradient boosting-based classifiers, kNN (k-nearest neighborhood), and the like. In other embodiments, the machine learning techniques may include the training and deployment of one or more neural networks, the training and deployment of which are also discussed below. Additionally, in some embodiments, the sensor evaluation logic 1214 may provide the results discussed above to the improvement logic 1222, discussed below.

[0107] The alert generation logic 1220, when executed by the processor 1202, is configured to perform operations that generate an alert, a notification, a graphical user interface (e.g., a dashboard), etc. The alert or notification may be provided to one or more users in various ways, such as an email, a text message, a visual alert displayed on a graphical user interface, a change in the status of a light (e.g., a light emitting diode (LED)) on a ball thrower, etc. In some embodiments, the alert generation logic 1220 may be configured to compare the results of the evaluation performed by the sensor data evaluation logic 1214 against one or more thresholds, and an alert may be generated based on the threshold comparison. The threshold comparison may be as discussed above. It should be understood that regardless of whether the threshold comparison is performed by the sensor data evaluation logic 1214 or the alert generation logic 1220, when the results of the evaluation by the sensor data evaluation logic 1214 do not meet a threshold, no action need be taken, e.g., no indication of normal operating behavior need occur. However, in some cases, when the threshold comparison indicates normal operating behavior, a status indicator may be provided to one or more users (e.g., an indication within a dedicated application may maintain a "normal operating behavior" indicator, such as a green check mark or other symbol, adjacent to the ball thrower within a listing for the ball thrower). Alternatively or additionally, a status indicator (e.g., an illuminated LED on the ball thrower) may maintain an indication of normal operating behavior (e.g., illuminated as green or another predetermined color).

[0108] The remediation logic 1222, when executed by the processor 1202, is configured to perform operations that determine remediation actions to be taken in response to the evaluations made by the sensor data evaluation logic 1214. For example, once the sensor data evaluation logic 1214 determines that the sensor data indicates that the launch wheels are worn, the remediation logic 1222 may provide the alert generation logic 1220 with a specific action to be taken, which is then included in an alert or notification. For example, the indication of the remediation action may include a text instruction such as "change the launch wheels," or may provide a code that a trainer or staff member can correlate to the remediation instruction. In other cases, the remediation logic 1222 may automatically initiate a specific action. For example, if the sensor data evaluation logic 1214 determines that the current / power usage exceeds a certain threshold indicating that the motor is overworked, the remediation logic 1222 may automatically initiate a shutdown of the ball thrower to allow the motor to cool. The remediation logic 1222 may obtain remediation actions through a lookup or query to a database (which may be included as part of the remediation logic 1222 or stored in a separate data store, not shown) using as a key the results of the sensor data evaluation logic 1214 or the threshold comparison made by the alert generation logic 1220. Other examples of remediation actions will be described below, and other examples will be apparent to those skilled in the art based on the disclosure provided herein.

[0109] 2. Systems Methodology Referring to Figure 13, a flow diagram illustrating the operations of a method for identifying normal or anomalous behavior of a ball thrower through signature analysis, according to some embodiments, is shown. Figure 13 illustrates a method 1300 for identifying normal or anomalous behavior of a ball thrower, such as the ball thrower 100 disclosed herein. Each block in Figure 13 represents an operation within method 1300, and it should be understood that one or more of the operations illustrated in method 1300 are optional.

[0110] Method 1300 begins when a ball thrower is deployed under known operating conditions in accordance with a selected training program (block 1302). The known operating conditions may be any known operating condition, such as a normal operating condition in which all components of the ball thrower are operating properly. Other known operating conditions may include operation in which one or more components are known to be operating improperly (e.g., a known worn launch wheel, operation with no balls in the hopper, operation with an over-inflated or deflated (under-inflated) ball, etc.). Before, during, and / or after deployment of the ball thrower in accordance with the training program, sensor data is collected from one or more sensors operating as components of the ball thrower (block 1304). Thus, sensor data may be collected at various stages of operation / deployment. It should be understood that the operations of blocks 1302-1304 may be repeated multiple times if the ball thrower is deployed under various wide operating ranges of sensor data corresponding to known operating conditions.

[0111] Following collection of the sensor data, the sensor data may be analyzed in light of a selected training program to determine variability in the sensor data (block 1306). Deployment of the ball thrower may generate training program data, which may associate timestamps with the training program and aspects of the training program. For example, a timestamp may be associated with the start / end of the training program, such that the duration of the training program is associated with the timestamp, e.g., measured in seconds or milliseconds. Furthermore, each action within the training program may be associated with a timestamp that is noted, such as each ball firing sequence and each aspect of the ball firing sequence. A ball firing sequence may refer to the determination of the presence of a ball at the base of the hopper and the opening of a ball stop by activating a solenoid, as discussed above.

[0112] Analysis of the sensor data in light of the selected training program may include comparing timestamps of known actions (e.g., solenoid activation) with timestamps of the sensor data, which results in generating pairings of known activities and one or more sensor data values ​​(e.g., labeling a particular time frame of sensor data as a known activity). As an example, solenoid activation produces a unique and identifiable noise. Thus, analysis of the sensor data may generate pairings of audio data (e.g., 1-2 seconds) with a label of solenoid activation. The pairing of a known activity and a particular duration of sensor data represents a first signature (block 1308). As discussed above, a signature may represent the pairing of a single source of sensor data with a single known activity. Other signatures may represent the pairing of a single source of sensor data over a duration covering multiple known activities (e.g., a firing sequence or an entire training program). Other signatures may represent the pairing of multiple sources of sensor data with a single known activity. Still other signatures may represent pairings of multiple sources of sensor data over durations covering multiple known activities. As noted above, the generated signatures may be stored in a signature / model storage for comparison with signatures generated from subsequently collected sensor data of the ball thrower operating under unknown conditions. The operations of blocks 1306-1308 are shown in FIG. 13B and discussed below.

[0113] The ball thrower may then be deployed under unknown operating conditions, e.g., standard operating conditions, in which a trainer or staff member powers on the machine during its normal course of deployment, and the ball thrower executes instructions corresponding to the training program, resulting in the firing of multiple balls at specified speeds, directions, angles, timing, etc. Sensor data is collected during deployment of the ball thrower operating under unknown operating conditions, and one or more signatures are generated for the sensor data in light of the training program. The recently generated signatures are then compared to signatures generated under known operating conditions to identify normal or anomalous behavior of the ball thrower (block 1310). The signature comparison may result in an indication that the recently generated signature is an exact match or an indication of the level of similarity (e.g., percentage match) of a particular signature. When the results of the signature comparison indicate a threshold match to one or more stored signatures, a threshold comparison may be performed, with the result of the threshold comparison indicating whether there is a sufficient match between the recently generated signature and the stored signature. If a perfect match or a sufficient match is determined to exist based on the threshold comparison, a record may be created indicating the match and, therefore, the activity or operational status of the ball thrower determined by the system 1104 to have occurred. In some cases, a match (perfect or sufficient) with one or more signatures may indicate anomalous behavior (e.g., detection of a particular extraneous noise or lack of solenoid activation).

[0114] Further, each training program is associated with a set of actions, which may be predetermined and known prior to initiation, or may be dynamically determined during the training program as the training program progresses based on factors such as trainer input (to increase or decrease difficulty) or user accuracy (returning a fired ball to the commanded target or location with at least a threshold amount of accuracy). In either case, as the training program progresses, training program data (e.g., records) of commanded actions and their corresponding timestamps are generated. Thus, in some embodiments, an analysis may be performed that compares signatures generated from sensor data acquired during the training program, the commanded actions, and their corresponding timestamps. Such an analysis may provide an indication of whether the ball thrower is operating to generate sensor data indicative of and consistent with the commanded (expected) actions. Such an analysis may include determining how well the timestamps of the expected actions matched the timestamps of the sensor data signatures (e.g., whether the ball firing sequence began within a predetermined time frame of its expected onset, such as 5 milliseconds). Further, the analysis may include determining how many actions actually occurred as expected within a threshold time frame. Alerts may be generated at any level of inconsistency (and may be set by a trainer or staff member). For example, an alert may be generated only when an expected action did not occur within a predetermined time frame (e.g., an action occurred but too late, such as more than 5 milliseconds), or when an expected action did not occur at all. Alternatively or additionally, an alert may be generated when a threshold number of actions occurred later or did not occur.Additionally, determinations may be made regarding the operational status of the ball thrower, such as operating normally or abnormally (e.g., anomalous or abnormal behavior detected), based on the percentage of actions that did not occur or the percentage of actions that occurred outside of a predetermined time frame from the expected time. Other metrics, such as the duration of a particular action, may also be analyzed.

[0115] 13B, an exemplary flow of operations of the method 1300 of FIG. 13A, including analyzing sensor data and generating a sensor data signature, according to some embodiments, is shown. In particular, the operations of blocks 1304-1308 are primarily shown. To summarize the above discussion, block 1304 includes collecting sensor data from one or more sensors operating as components of the ball throwing machine, block 1306 includes analyzing the sensor data in light of a selected training program to determine variability in the sensor data, and block 1308 includes creating a sensor data signature for one or more of the events and a standby status based on the known timing of the events from the training program.

[0116] FIG. 13B illustrates the operation of blocks 1304-1308 along with a diagram of a sensor component, e.g., microphone 320, collecting audio data 1320. Consistent with FIG. 3, microphone 320 is shown disposed on control unit 300, which functions to operate the ball thrower. As discussed above, microphone 320 may begin collecting audio data as soon as operation begins to implement a training program. For example, to power on the ball thrower and receive a training program selection, power is provided to the ball thrower's motor, causing the ball thrower's launch wheel to spin. Noise made by the spinning of the motor and launch wheel may be at least a portion of the audio data collected by microphone 320.

[0117] The audio data 1320 is then analyzed in light of the selected training program. For example, the audio data 1320 may be parsed into segments, “(Audio Data-1),” “(Audio Data-2),” etc., and converted into signatures paired with timestamps of the audio data segments. In some embodiments, the conversion may only involve creating pairings of audio data segments with timestamps (e.g., indicating the beginning of a segment or a range, such as a start time and end time of a segment). In other embodiments, the conversion may involve reformatting the audio data from a first format (e.g., waveform audio file (WAV)) to a second format (e.g., MPEG-1 Audio Layer III (“MP3”)). The conversion may result in a table 1330, which may be compiled into a table 1335 containing pairings of signatures and timestamps. Table 1335 may be correlated with entries in table 1340, which contains pairings of labels of training program actions and the expected timing of those actions. For example, the timing of the actions may include a start time for each action relative to the beginning of the training program, or a time segment (duration) relative to the beginning of the training program.

[0118] The pairings in table 1340 are predetermined and known in advance based on the selected training program. More specifically, the selected training program includes a known set of actions and timing for each action, e.g., 20 ball launches, with each ball launch sequence taking 3 seconds and a 15-second standby period between each ball launch sequence. Correlation 1350 of tables 1335, 1340 may include determining which label in table 1340 corresponds to each signature in table 1335 by comparing the timestamps in table 1335 with the time indicators (timestamps or time durations) in table 1340 to align the time indicators. Thus, because the ball thrower is operating under known conditions when generating the signatures, table 1360 provides an indication of the signatures and signature patterns for the training program when the ball thrower is operating properly and, in some cases, when the ball thrower is operating improperly. Regarding the latter, a signature may be generated that indicates how the training program would perform under certain improper operating conditions, such as having a worn wheel or missing one or more balls. To do so, the correlation pairs the signature with a label and a time duration (or other time indicator, such as a timestamp relative to the beginning of the selected training program). The pairings in table 1360 may then be recorded on a non-transitory computer-readable medium for future access and comparison with future sensor data collected when the ball thrower is operating under unknown conditions to identify actions (or inactions) taken by the ball thrower, enabling system 1104 to identify normal or anomalous behavior.

[0119] a. Exemplary Use Cases As an example of an exemplary use case, the system 1104 may perform a computerized method for determining the operability status of a ball thrower. The operations of the computerized method may include acquiring data from one or more motion sensors collected during operation of the ball thrower and determining the operability status of the ball thrower from the data collected by the one or more motion sensors. In such an example, the one or more motion sensors may be disposed on the ball thrower, and operation of the ball thrower includes performing a series of ball firing sequences that result in firing a series of balls according to a training program. The ball thrower may comprise one or more launch wheels configured to launch one or more balls by imparting motion to the balls, a frame to which the one or more launch wheels are coupled, and control circuitry configured to control the one or more launch wheels.

[0120] In some implementations of the use case, executing the launch sequence for the first ball includes a motor of the ball thrower spinning one or more launch wheels at a spin rate configured to impart movement to the first ball at a specified speed. Further, the one or more operational sensors may include at least one of an accelerometer configured to detect vibration data, a microphone configured to detect audio data, a temperature sensor configured to detect an ambient temperature of the control circuitry, or a current sensor configured to detect current drawn by at least the first launch wheel. In some implementations, determining the operability status of the ball thrower includes analyzing the collected data, resulting in detecting variability in the collected data, and detecting whether the variability in the collected data is consistent with expected variability based on the training program.

[0121] In some cases, determining the operational status of the ball thrower includes parsing the collected data into segments based on variability in the collected data. In still further cases, determining the operational status of the ball thrower further includes comparing the segments of collected data to signatures of known actions, including a training program, and detecting whether a time-based ordering of the segments is consistent with an expected set of actions based on the training program. In some implementations, the operation further includes generating an alert indicating that the ball thrower is operating abnormally and causing the alert to be displayed on a display of the network device.

[0122] b. Signature Generation Referring now to FIG. 14 , a flow diagram illustrating operations of an exemplary method for generating a signature for sensor data from a first sensor (vibration sensor) during operation of a ball thrower, according to some embodiments, is shown. Each block illustrated in FIG. 14 represents an operation of method 1400 performed by system 1100. While method 1400 specifies the collection of vibration data, it should be understood that the principles underlying signature generation apply to other sensor data as well. Additionally, some operations of method 1400 may be optional. Method 1400 begins when a ball thrower is deployed under known operating conditions according to a selected training program (block 1402). Vibration data is collected from a vibration sensor operating as a component of the ball thrower (block 1404). As discussed above, sensor collection logic 1208 may acquire the vibration data. For example, a vibration sensor may be communicatively coupled to a processor of the ball thrower and provide the vibration data to sensor collection logic 1208. In some embodiments, the sensor collection logic 1208 operates on the ball thrower (e.g., on its circuit board) or in a cloud computing or other networked service. In either case, the vibration data is provided to the signature generation logic 1210, which parses the vibration data according to time blocks of standby operation and identified ball launch sequences (block 1406). The term standby operation may refer to a period of deployment of the ball thrower between ball launch sequences (or prior to the initial ball launch sequence). A ball launch sequence may be comprised of a series of actions performed by multiple components.

[0123] A vibration data signature is then created for the standby operation and ball launch sequence, the vibration data signature including the vibration data over the identified time period and a label corresponding to the standby operation of the ball launch sequence (block 1408). The ball launch sequence may be composed of multiple actions, such that a signature is generated for the entire ball launch sequence and / or for one or more of the actions individually. Thus, multiple vibration signatures may be generated from the vibration data collected over a period spanning the entire ball launch sequence. The vibration data signature may then be recorded in a non-transitory computer-readable medium (e.g., signature / model storage 1218 of FIG. 12 ) for use in identifying normal or abnormal operation or behavior of a ball throwing machine deployed under unknown operating conditions (block 1410).

[0124] b. Machine Learning / Artificial Intelligence Deployment The model evaluation logic 1217 is configured to perform various analyses on the received sensor data. As shown in further detail in Figures 15-16, the model evaluation logic 1217 may perform operations categorized as one or more artificial intelligence techniques. For example, the model training logic 1213 may perform operations to generate or train a machine learning model or neural network, and the model evaluation logic 1217 may perform operations to implement the trained machine learning (ML) model or neural network.

[0125] (i) Machine learning model More specifically, the model training logic 1212 may operate to generate a trained machine learning (ML) model, which is typically done through processing historical data using an ML algorithm. The trained ML model is specifically configured to receive as input any of the sensor data discussed herein. As understood, machine learning is a subset of artificial intelligence (AI) that involves the development of algorithms and models that enable computers to learn and make predictions or decisions based on data without being explicitly programmed. Essentially, the goal of machine learning is to enable computers to gradually improve their performance on tasks by automatically learning from examples.

[0126] The implementation of machine learning by the model training logic 1212 and the model evaluation logic 1217 may include operations such as data collection, data preprocessing, feature engineering, model training, loss function, optimization, validation / testing, hyperparameter tuning, and deployment / inference. More specifically, data collection involves acquiring a dataset containing examples relevant to the task to be learned by the machine learning model. The dataset includes input features (also known as attributes) and corresponding target labels (desired outputs or outcomes). Examples of such may include the current value drawn by one or more of the motor wheels, the speed of wheel rotation (e.g., revolutions per minute), the ambient temperature of a circuit board, the number of ball launches, the detection of a ball present at the base of a hopper, stepper motor motion, the number of balls thrown, the timing of the balls thrown, the angle and direction of the balls thrown, vibration data, noise data, etc.

[0127] Because raw data (including datasets) are often chaotic and may contain noise, missing values, or inconsistencies, data preprocessing operations may involve automated cleaning of the raw data and conversion of the raw data into a usable format, which may include removing outliers, filling missing values, and scaling features.

[0128] Feature engineering involves determining input features in a dataset that are specific to the task being learned in order to efficiently represent underlying patterns in the data. Feature engineering involves the selection of relevant features, and in some cases the creation of new features, to improve the performance of a trained ML model.

[0129] Model training involves providing a prepared dataset (e.g., following preprocessing and including selected features) to a selected ML algorithm, whereby processing of the prepared dataset by the ML algorithm results in a trained model through adjustment of the model's internal parameters that result in a mapping of input features to target labels. The ML algorithm utilized for training may depend on the task being solved. The model training logic 1212 may generate one or more trained ML models configured to determine one or more of the following: a classification of the operational status of the ball thrower, a classification of the operational status of one or more components of the ball thrower, or any prediction. Exemplary ML algorithms may include classification algorithms such as logistic regression, decision trees, random forests or gradient boosting-based classifiers, kNN (k-nearest neighbors), etc.

[0130] During the model training process, an effort is made to minimize a loss function (also known as a cost function), which quantifies the error between the model's predictions and the actual target labels. The loss function depends on the ML algorithm utilized in training; for example, mean squared error for regression tasks and cross entropy for classification tasks. Further details of minimizing the loss function are explained below, but as a general summary, the internal parameters of the model are iteratively updated using techniques such as gradient descent, which is a first-order iterative optimization algorithm for finding a local minimum of a differentiable function, such that the model's parameters are adjusted in a direction that reduces the loss function.

[0131] Following training, the model's performance is evaluated on data not utilized in training (e.g., data not previously presented to the model). The dataset is typically divided into a training set (used for training) and a validation / test set (used for evaluation). The model is provided with the validation / test set as input (without labeling), and the resulting predictions / decisions are evaluated against the labeling of the validation / test set. Depending on the machine learning algorithm utilized, the model's hyperparameters may be adjusted following training. Hyperparameters may refer to model configurations that are not learned during training but that affect the model's behavior.

[0132] Following model validation and testing, the model can be deployed to make predictions regarding new real-world data (e.g., newly acquired sensor data). During inference, the model processes new input data and generates predictions or decisions based on what the model learned during training.

[0133] The following subsections provide details on training and deploying linear regression models and neural networks, but the disclosure is not limited to these examples. The following are intended to be merely illustrative of possible artificial intelligence techniques. Furthermore, it should be understood that either linear regression models or neural networks may be used to classify or predict operational status and / or determine remedial actions to be provided to trainers or other staff members.

[0134] More specifically, classification machine learning algorithms that may be utilized when processing the training data to generate a machine learning model configured to classify a current performance status may include logistic regression, K-nearest neighbors (KNN), support vector machine (SVM), decision trees, naive Bayes, K-means clustering, random forest, Gaussian process classification, etc. Additionally, predictive machine learning algorithms that may be utilized when processing the training data to generate a machine learning model configured to predict a future performance status may include linear regression, ridge and lasso regression, decision trees, random forest, gradient boosting algorithm, time series forecasting, support vector regression (SVR), K-nearest neighbors (KNN), K-means, etc.

[0135] (ii) Linear regression As an example, the implementation of machine learning by the model training logic 1212 and the model evaluation logic 1217 may include training and deploying a linear regression machine learning model. Training a linear regression machine learning model involves finding a best-fit linear relationship between a set of input features and a target variable. This relationship may be

number

[0136] where y is the target variable to predict, β0 is the intercept (the y-axis value when all x values ​​are 0), and β1, β2, . . . , β n are the coefficients for each input feature. Training a linear regression model involves minimizing the error between the predicted value (y) and the actual target value, β0, β1, β2, . . . , β n This results in determining the value of . This is typically done using a mathematical optimization technique known as least squares regression. In some embodiments, the operations involved in training a linear regression model include data collection, data preprocessing, model initialization, coefficient minimization, and model evaluation.

[0137] More specifically, the input features (x1, x2, . . . , x n ) and a target variable (y). The training data may undergo preprocessing steps, including handling missing values, scaling values, or normalizing values. The coefficients (β0, β1, β2, . . . , β n ) is initialized, such as with 0 or a small value, a random value, etc. Next, the values ​​of the coefficients that minimize the loss function, e.g., the mean squared error (MSE), are determined, which is typically done by using a gradient descent algorithm. This is done by using the initial (current) coefficient values ​​and the input features to find y(y predict y predict and the error (or loss) between the target value of y. The coefficient values ​​are then adjusted using an optimization algorithm (e.g., gradient descent). The process iterates until the error or loss no longer improves or no longer improves by more than a threshold amount, or until a predetermined number of iterations have occurred. Following model validation and testing, the model may be deployed to make predictions on new real-world data (e.g., sensor data).

[0138] b. Neural Networks Additionally or alternatively, the model training logic 1212 and the model evaluation logic 1217 may operate to train and implement neural networks configured to determine the classifications and / or predictions discussed above. As will be appreciated, neural networks consist of layers of interconnected nodes or "neurons" organized into three main types of layers: input layers, hidden layers, and output layers. Each neuron in a layer is connected to neurons in adjacent layers through weighted connections.

[0139] More specifically, the input layer receives raw data or features (input data) related to the task assigned to the neural network, and each neuron in the input layer corresponds to a specific feature in the input data. The hidden layer(s) are intermediate layers between the input layer and the output layer and perform complex transformations and feature extraction. Each neuron in the hidden layer takes input from neurons in the previous layer, applies weights to those inputs, and passes the results through an activation function. Each connection between neurons has an associated weight that determines the strength of the connection, affecting how information is propagated through the layers of the neural network. Neurons in the hidden layer apply an activation function to the weighted sum of their inputs. The activation function introduces nonlinearity into the network, resulting in the detection of complex relationships in the input data. Examples of activation functions include ReLU (Rectified Linear Unit), sigmoid, and tanh. The output layer produces the neural network's final prediction or decision. The number of neurons in this layer depends on the task the neural network is assigned to solve. For example, a binary classification problem may involve a single neuron with a sigmoid activation function, while a multi-class classification problem may involve multiple neurons with softmax activation.

[0140] Training a neural network involves multiple steps, including a feedforward pass, computing a loss function, backpropagation, and optimization (updating weights). More specifically, the process of feeding data through the network, computing the loss, backpropagation, and updating the weights is repeated iteratively (through the entire training dataset) for multiple epochs until the neural network's performance converges to a satisfactory level, in a manner similar to that discussed above with respect to training a machine learning model.

[0141] Describing the training process in more detail, during the feedforward pass, input (training) data is fed into the neural network. The data passes through the layers, and each neuron's weighted input is transformed using an activation function. The output of the output layer represents the neural network's prediction. The neural network's prediction is then compared to the actual target values ​​(known as part of the training data) using a loss function. The loss function quantifies how well the neural network's prediction matches the desired outcome. Examples of loss functions include mean squared error for regression and cross entropy for classification. Once the loss is calculated, the neural network's parameters (weights and biases) are adjusted to minimize the loss. Backpropagation is the process of calculating the gradient of the loss with respect to the weights and biases; the gradient indicates the direction and magnitude of the change needed to minimize the loss. The gradient is calculated layer by layer, starting at the output layer and working backward toward the input layer using an optimization algorithm (e.g., gradient descent). For example, gradient descent involves making adjustments to each parameter of a neural network in the opposite direction of the gradient, effectively moving the parameter toward a value that reduces the loss. The weights and biases are then updated according to the computed gradient.

[0142] As noted above, the training process is repeated iteratively (through the entire training dataset) for multiple epochs until the neural network's performance converges to a satisfactory level, in a manner similar to that discussed above with respect to training a machine learning model. Deployment of the trained neural network involves a feedforward pass, where input data is fed into the trained neural network. The data passes through layers, where the weighted input of each neuron is transformed using an activation function. The output of the output layer represents the network's prediction.

[0143] Various activation functions and output layer functions are designed with different functions that determine whether the neural network is configured to classify current behavioral status or predict future behavioral status. Activation functions are used in the hidden layer of a neural network to introduce nonlinearity into the neural network, enabling it to learn complex patterns and representations from input data. Activation functions are applied to the weighted sum of inputs within each neuron in the hidden layer and transform the neuron's output before passing the output to the next layer. Output layer functions are applied to the output layer of a neural network and are responsible for producing the final network output (e.g., classification or prediction) and also determine the format and characteristics of the output.

[0144] Examples of classification activation functions that may be utilized to generate a neural network configured to classify the current operational status may include sigmoid activation (logistic), softmax activation, rectified linear unit (ReLU), Tanh (hyperbolic tangent), swish activation, gated activation functions (e.g., long-short term memory (LSTM) or gated recurrent unit (GRU) cells), etc.

[0145] Examples of classification output functions that may be utilized to generate a neural network configured to classify the current operational status may include sigmoid activation and binary cross-entropy loss for binary classification, softmax activation, and categorical cross-entropy loss (for multi-class classification), etc.

[0146] Examples of predictive activation functions that may be utilized to generate neural networks configured to predict future behavioral status may include linear activation (identity function), rectified linear unit (ReLU), leaky ReLU (a variant of ReLU that allows for small non-zero gradients for negative inputs, mitigating the "dying ReLU" problem), parametric ReLU (PReLU, which is similar to leaky ReLU but allows the gradient to be learned during training), exponential linear unit (EPU), sigmoid activation, Tanh (hyperbolic tangent), etc.

[0147] Examples of predictive output functions that may be utilized to generate a neural network configured to predict future performance status may include linear activation (identity function), Gaussian output function, logistic sigmoid activation, hyperbolic tangent (Tanh) activation, softmax activation, exponential activation, etc. Additionally, in some embodiments, no output function may be used for prediction.

[0148] Referring now to FIG. 15 , a flow diagram illustrating operations of an exemplary method for generating a trained machine learning model configured to determine a prediction about the operability status of a ball thrower is shown, according to some embodiments. Each block shown in FIG. 15 represents an operation of method 1500 performed by system 1100. Additionally, some operations of method 1500 may be optional. While method 1500 specifies the collection of audio data, it should be understood that the principles underlying generating a trained machine learning model apply to other sensor data as well. Method 1500 begins when a ball thrower is deployed under known operating conditions according to a selected training program (block 1502).

[0149] Audio data is collected from a microphone operating as a component of the ball thrower (block 1504). For example, the audio data may be collected by microphone 320 of FIG. 3 disposed on control unit 220 of FIG. 3, which is a component of the ball thrower. As such, the microphone, like other sensors, should be understood as a specific hardware component of the ball thrower and configured to operate during deployment of the ball thrower. Following collection of the audio data, a trained machine learning model is generated by processing the audio data with a machine learning algorithm, resulting in adjustment of internal parameters of the model that result in mapping input features in the audio data to target labels provided by the audio data (block 1506). As such, as part of the operation of block 1506, audio data collected during deployment under known conditions is labeled, which may include associating a timestamp or time duration and an action title (e.g., “solenoid activation”) with the audio data. As such, the machine learning algorithm may process a set of ordered vectors of {audio data segment, action title, timestamp / time duration}, where the ordering is based on time. As a result of the sequencing, the machine learning model may learn sequencing of ball firing sequences and audio data that includes ball firing sequences. The operations of block 1506, which discuss training a machine learning algorithm, may be replaced with training a neural network as discussed herein.

[0150] The trained machine learning model is then recorded to a non-transitory computer-readable medium, and the trained machine learning model is configured to identify normal or abnormal behavior (operation) of the ball thrower deployed under unknown conditions by processing audio data subsequently collected by microphones of the ball thrower and / or other ball throwers (block 1508).

[0151] c. Actions in response to operability decisions Referring now to FIG. 16 , a flow diagram illustrating method operations for deploying a ball thrower, identifying normal or anomalous behavior of the ball thrower, and taking corrective action as needed, according to some embodiments, is shown. Each block illustrated in FIG. 16 represents an operation of method 1600 performed by system 1100. Additionally, some operations of method 1600 may be optional. Method 1600 begins when a ball thrower is deployed under unknown operating conditions according to a selected training program (block 1602). As mentioned above, unknown operating conditions may refer to standard use without extensive inspection of the ball thrower's components. For example, a standard visual inspection may be performed when a trainer turns on the ball thrower, but such inspection would be insufficient to determine whether the launch wheel is worn beyond noticeable wear. Sensor data is collected from one or more sensors operating as components of the ball thrower (block 1604). The sensor data is evaluated in any of the ways described above (e.g., by signature analysis or machine learning techniques) to provide a determination as to whether the ball thrower (or one or more particular components thereof) is operating properly (block 1606). As noted above, the determination may be the result of one or more signature comparisons and / or classifications / predictions generated by a machine learning model or neural network. If the determination indicates that the ball thrower is operating properly (Yes at block 1608), the deployment of the ball thrower continues without adjustment (block 1610). In some embodiments, a recording of the determination, including a timestamp, may be made to a data log or data store. In some embodiments, an indication of proper operation is provided to a trainer or staff member, such as a status indicator (e.g., a light-emitting diode (LED)) illuminating a particular color, or a message or icon being provided via text message or within a dedicated software application configured to communicate with or control the ball thrower.

[0152] However, when the ball thrower is not operating properly (no at block 1608), the logic of the system 1100 may stop or adjust the deployment of the ball thrower (1612) and / or an alert or log entry may be generated and provided to the trainer or staff member (1614). In some cases, when it is determined that the ball thrower or a particular component of the ball thrower is not operating properly, the ball thrower may be prevented from operating through software stored on the control unit. In other cases, the trainer may be alerted and manually select to proceed, or the default may be to proceed with standard operation until the trainer or staff member manually stops or adjusts the training program. In some embodiments, a particular component may be determined to be operating improperly or abnormally by a certain percentage (e.g., a wheel that is 50% worn), thereby generating an alert and / or preventing the training program from proceeding or automatically adjusting when the component is operating abnormally by at least a certain threshold. For example, a wheel may be determined to be only 30% worn, which does not affect the safety or accuracy of the ball thrower, and therefore may result in the generation of an alert or log entry to the trainer, but will not prevent the ball thrower from proceeding.

[0153] In addition to the optional operations explicitly stated in blocks 1612-1614, further remedial actions may be taken (block 1616). Exemplary remedial actions may vary based on the detected anomaly or abnormality. In some cases, such as when a ball is not detected at the base of the hopper (discussed above), the logic of system 1100 may automatically obtain a second subsequent reading from the ball presence sensor and re-evaluate whether a ball is present. Additionally or alternatively, the logic of system 1100 may pause execution of software code corresponding to the training program for a predetermined amount of time (e.g., 5, 10, 15 seconds, etc.) to allow time for the ball to fall into the hopper or to provide the trainer or user with an opportunity to place the ball in the hopper. In some cases, the logic of the system 1100 may pause execution of the software code corresponding to the training program and activate a stepper motor or solenoid of the ball throwing device 100, which is intended to shake or vibrate the ball thrower 100 and cause the ball to fall from its location within the hopper downward to the base of the hopper.

[0154] In other cases, in response to a determination that an object is not present at the base of the hopper, the logic of the system 1100 may ignore such determination and assume that the ball presence sensor is broken, defective, or otherwise not working properly. In such cases, the logic of the system 1100 may execute software code corresponding to an ongoing training program while monitoring whether one or more balls are launched according to the training program by other methodologies (e.g., using current via the current sensor 316 and / or the temperature sensor 318, or detecting the launch of a ball by image detection of video of the user receiving the ball). In other embodiments, when an abnormality or irregularity (other than the absence of a ball present at the base of the hopper) is detected, any of the remedial actions described above may be taken. As such, the present disclosure includes several automated actions that may be taken by the ball thrower 100 or its logic in response to detecting an abnormality in the operation of the ball thrower 100 or its constituent component(s).

[0155] d. Wheel Motor Feedback As noted above, FIG. 2 shows that an implementation of the ball thrower 100 includes an encoder 1291 attached to the firing wheel motor 1281, and the discussion above indicates that a similar configuration may exist for an encoder coupled to the firing wheel motor 1282 (such encoders may be referred to collectively or individually as “encoder 129” or “encoders 129”). The encoder 129 may include a Hall Effect sensor and a magnet, whereby the Hall Effect sensor is configured to detect changes in the magnetic field as the magnet is rotated by the firing wheel motor 128. The encoder 129 is one component utilized in controlling the rotation of the firing wheel 127. In some embodiments, the CCA 300 provides power to the motor windings via a motor driver for the firing wheel motor 128, which rotates the motor. The rotation speed can be inferred from how much voltage and current are applied; however, this may not be precisely regulated due to many variables, such as inertia, load, and friction. The encoder 129 produces discrete signals or "blips" at specific degrees of rotation of the motor shaft, providing information to the CCA 300 indicating where each firing wheel motor 128 is in its rotation and how fast each firing wheel motor 128 is rotating by providing time between blips. Based on this information, the CCA 300 can intentionally modify (e.g., add / subtract) the voltage and / or current to control the position, velocity, and acceleration of the firing wheel motors 128.

[0156] Referring now to FIG. 17 , a flow diagram illustrating the operation of a method for monitoring wheel motor data to detect ball launch during deployment of the ball thrower 100 is shown, according to some embodiments. Each block shown in FIG. 17 represents an operation of the method 1700 performed by the system 1100. Additionally, some operations of the method 1700 may be optional. The method 1700 begins when the ball thrower is deployed according to a selected training program (block 1702). During deployment, wheel motor data is acquired by an encoder on the wheel motor (block 1704). In some embodiments, the wheel motor data is also acquired by the “control effort” required to spin the wheel in a desired manner. Control effort is the variation in voltage or current over a certain amount of time. The encoder indicates the position of the launch wheel motor 128 at a particular time, which may be used to vary the control effort. The control effort indicates how much energy or force is / was needed to spin the wheel in a desired manner.

[0157] In many implementations, a ball throwing machine includes two wheel motors, each with an encoder coupled to the wheel motor. As a result, wheel motor data may be acquired for both wheel motors. In some cases, the wheel motor data may refer to the measured revolutions per minute (RPM) of the wheel and a timestamp. Thus, the wheel motor data provides a record of the speed at which a particular wheel spins, for example, in revolutions per minute (RPM), and the corresponding timing.

[0158] The logic of system 1100 monitors the wheel motor data, which may include maintaining a log of the wheel motor data and / or comparing the wheel motor data to one or more thresholds. As discussed below, monitoring the wheel motor data may include detecting changes in the wheel motor data and comparing the timing of the detected changes to events (e.g., ball launches) in the selected training program. Additionally, monitoring the wheel motor data may include analyzing the detected changes to determine the level of inflation of the launched ball.

[0159] A ball launch sequence is initiated by the ball thrower in accordance with the selected training program (block 1706). As discussed above, the ball launch sequence may be comprised of a series of actions performed by multiple components. Exemplary actions may include adjusting the positioning of the ball thrower to adjust the direction or angle of the launch, increasing or decreasing the rotational speed of one or more wheels, and pulling a solenoid to release a ball disposed at the base of the ball thrower's hopper.

[0160] Following the ball launch sequence, the logic of the system 1100 may determine whether the wheel motor data indicates that the ball was actually launched (block 1708). In some implementations, the logic of the system 1100 may compare the monitored wheel motor data to stored signatures of ball launch sequences in which the ball was properly launched. When the similarity between the monitored wheel motor data and the stored signature(s) meets a threshold comparison (e.g., meets or exceeds a predetermined threshold level of similarity), the logic of the system 1100 determines that the ball was launched (Yes at block 1708). In some cases, the logic of the system 1100 considers a timing component in such a determination. For example, the logic of the system 1100 may acquire the monitored wheel data for a specific time block based on a selected training program. For example, if execution of software code corresponding to a selected training program includes the initiation of a ball launch sequence at a timestamp of October 1, 2023, 17:01:00, logic of system 1100 may obtain monitored wheel motor data within a time block of + / - 10 seconds from such timestamp. As such, determining whether a ball launch has occurred may include determining that a level of similarity between the monitored wheel motor data and a stored signature satisfies a threshold comparison and that such an occurrence occurred within an expected time frame based on execution of software code corresponding to the selected training program. In other implementations, logic of system 1100 may analyze monitored wheel data to determine whether a change in wheel spin rate occurs within a time period corresponding to an expected ball launch sequence.

[0161] If it is determined that the ball has been launched (Yes at block 1708), the logic of system 1100 may determine the inflation level of the launched ball (block 1710). In some embodiments, the inflation level of the ball is detected based on changes in monitored wheel motor data during the ball launch sequence. For example, the logic of system 1100 may analyze the wheel motor data to determine whether a sharp drop in RPM occurs, followed by a quick recovery back to the expected RPM level (which may indicate that the launched ball was over-inflated), or whether a delayed drop in RPM occurs, followed by a prolonged recovery (which may indicate that the launched ball was under-inflated). The terms steep drop and delayed drop are used in conjunction with each other, such that an over-inflated ball will cause the wheel RPM to drop more quickly than an under-inflated ball. Similarly, the terms rapid recovery and prolonged recovery are used in conjunction with one another, whereby an over-inflated ball will cause the wheel RPM to recover to the expected RPM level more quickly than an under-inflated ball.

[0162] However, when a ball launch is not detected (No at block 1708), the logic of the system 1100 may take one or more remedial actions (block 1712). Exemplary remedial actions are discussed throughout above.

[0163] Specific embodiments of the inventive concepts discussed herein may include the following examples. Some embodiments include a ball thrower comprising: one or more launch wheels configured to impart motion to one or more balls; a frame attached to the one or more launch wheels; and a control circuit configured to control the one or more launch wheels, the control circuit comprising a processor; a non-transitory computer-readable medium having logic stored thereon; and one or more motion sensors configured to acquire data regarding operation of the ball thrower, including the launch of a first of the one or more balls. Imparting motion to the one or more balls may include rotating the one or more launch wheels to result in the delivery of the one or more balls to the player, the one or more balls being one or more soccer balls. The one or more motion sensors may include an accelerometer disposed on the control unit. The accelerometer may be configured to acquire vibration data of the ball thrower while the ball thrower executes a training program, the training program including a ball firing sequence, during which a ball is fired, and a standby status, during which the ball firing sequence is not performed. The vibration data may indicate a difference in vibration of the ball thrower during the ball firing sequence and the standby status. The one or more motion sensors may include a microphone disposed on the control unit. The microphone may be configured to acquire audio data of the ball thrower while the ball thrower executes a training program, the training program including a ball firing sequence, during which a ball is fired, and a standby status, during which the ball firing sequence is not performed. The audio data may indicate a difference in noise generated by the ball thrower during the ball firing sequence and the standby status.The ball thrower may further include one or more communication ports communicatively coupled to the control unit. The one or more communication ports may be located on an interface module disposed on a rear surface of the ball thrower opposite the one or more launch wheels. The interface module may include one or more status indicators, and the control unit is configured to cause illumination of a first status indicator based on an operational status of the ball thrower. The ball thrower may further include a handle attached to the frame, the handle extending outward from a location adjacent to the one or more communication ports. The one or more operational sensors may include at least one of a temperature sensor configured to detect an ambient temperature of the control circuitry or a current sensor configured to detect a current drawn by at least the first launch wheel. The ball thrower may further include a hopper coupled to the frame, the base of the hopper combining with the frame to form a staging area. The hopper may be removably coupled to the frame. The control circuit may be configured to communicatively couple to a network device. The control circuit may be configured to receive instructions from the network device, the instructions corresponding to a training program including instructions to launch a series of balls. The operation of the ball thrower may include a ball firing sequence, during which a ball is fired, and a standby state, during which no ball firing sequence occurs. One or more operational sensors may be configured to collect data regarding the operation of the ball thrower indicative of a difference between the operability of the ball thrower during the ball firing sequence and the standby state. The ball thrower may further include a ball sensor coupled to the frame and communicatively coupled to the control circuit, the ball sensor configured to detect the presence of the first ball prior to firing the first ball.

[0164] In another embodiment, a computerized method for determining the operability status of a ball thrower includes acquiring data from one or more motion sensors collected during operation of the ball thrower, the one or more motion sensors being disposed on the ball thrower, the operation of the ball thrower including: performing a series of ball launch sequences that result in the launch of a series of balls according to a training program, the ball thrower including: one or more launch wheels configured to launch one or more balls by imparting motion to the balls, a frame to which the one or more launch wheels are coupled, and a control circuit configured to control the one or more launch wheels; and determining the operability status of the ball thrower from the data collected by the one or more motion sensors. Performing the launch sequence for a first ball may include a motor of the ball thrower spinning the one or more launch wheels at a spin rate configured to impart motion to the first ball at a specified speed. The one or more motion sensors may include at least one of an accelerometer configured to detect vibration data, a microphone configured to detect audio data, a temperature sensor configured to detect an ambient temperature of the control circuit, or a current sensor configured to detect current drawn by at least the first launch wheel. Determining the operability status of the ball thrower may include analyzing the collected data, resulting in detection of variability in the collected data, and detecting whether the variability in the collected data is consistent with expected variability based on a training program. Determining the operability status of the ball thrower may include parsing the collected data into segments based on the variability in the collected data. Determining the operability status of the ball thrower may further include comparing the segments of the collected data to signatures of known actions, including the training program, and detecting whether a time-based ordering of the segments is consistent with an expected set of actions based on the training program.The operations may further include generating an alert indicating that the ball thrower is operating abnormally and causing the alert to be displayed on a display of the network device. Additionally, similar embodiments may include a computing device having a processor and a non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by the processor, causing the processor to perform the operations discussed above.

[0165] In another embodiment, a computerized method for determining the operability status of a ball thrower includes acquiring sensor data collected by a sensor disposed on the ball thrower during deployment of the ball thrower to perform operations according to a training program including firing a series of balls; parsing the sensor data into segments; comparing the segments to a sequence of predetermined signatures ordered according to actions specified by the training program, the predetermined signatures representing known sensor data values ​​for operations performed according to the training program; and determining that the ball thrower is performing abnormally when at least a first threshold percentage of the segments are indicated as being inconsistent with the sequence of predetermined signatures. The computerized method may further include determining that the ball thrower is operating properly when less than a first threshold percentage of the segments are indicated as being inconsistent with the sequence of predetermined signatures. The sensor data may include at least one of audio data collected by a microphone, vibration data collected by an accelerometer, ball presence data collected by a ball sensor, temperature data collected by a temperature sensor, or current data collected by a current sensor. A first segment may be indicated as consistent with a first predetermined signature when at least a percentage of the sensor data comprising the first segment matches sensor data comprising the first predetermined signature. A first segment may be indicated as consistent with a first predetermined signature when the duration of the first segment is within a threshold time range for the first predetermined signature. The sensor data may be parsed into segments based on variability in the sensor data or an expected duration for an action of a training program. The computerized method may further include, upon determining that the ball thrower is operating improperly, generating an alert indicating that the ball thrower is operating improperly and causing the alert to be displayed on a display of the network device.Additionally, similar embodiments may include a computing device having a processor and a non-transitory computer-readable medium having instructions stored thereon that, when executed by the processor, cause the processor to perform the operations discussed above.

[0166] In another embodiment, a computerized method for determining the operability status of a ball thrower includes acquiring sensor data collected by sensors during deployment of the ball thrower to perform operations according to a training program, the sensors being disposed on the ball thrower; deploying a trained machine learning model on the sensor data, the trained machine learning model resulting in a classification of the current operability status of the ball thrower or a prediction of the future operability status of the ball thrower; and generating an alert when the classification indicates that the ball thrower is performing abnormally or the prediction indicates that the ball thrower is predicted to perform abnormally. The computerized method may further include acquiring training sensor data from the sensors collected during deployment of the ball thrower under known conditions to perform operations according to the training program; acquiring labels for the training sensor data; and processing the labeled training sensor data with a machine learning algorithm, the trained machine learning model being produced through adjustment of internal parameters of the trained machine learning model that result in a mapping of the training sensor data to labels. The machine learning algorithm may be a classification algorithm, such that a trained machine learning model resulting from processing the labeled training sensor data with the machine learning algorithm is configured to classify a current operational status of the ball thrower. The machine learning algorithm may be a prediction algorithm, such that a trained machine learning model resulting from processing the labeled training sensor data with the machine learning algorithm is configured to predict a future operational status of the ball thrower. The machine learning algorithm may be linear regression. The sensor data may include at least one of audio data collected by a microphone, vibration data collected by an accelerometer, ball presence data collected by a ball sensor, temperature data collected by a temperature sensor, or current data collected by a current sensor. The microphone and accelerometer may be disposed on a control unit of the ball thrower.Additionally, similar embodiments may include a computing device having a processor and a non-transitory computer-readable medium having instructions stored thereon that, when executed by the processor, cause the processor to perform the operations discussed above.

[0167] In yet another embodiment, a ball throwing machine includes one or more launch wheels configured to impart motion to one or more balls; a frame to which the one or more launch wheels are coupled, wherein a staging area is formed within the frame adjacent to the one or more launch wheels; a ball sensor; and control circuitry configured to control the one or more launch wheels, the control circuitry including a processor and a non-transitory computer-readable medium having logic stored thereon, the logic, when executed by the processor, resulting in performance of operations including: receiving ball sensor data from the ball sensor; and determining, based on the ball sensor data, whether a ball is present within the staging area. Imparting motion to the one or more balls may include rotating the one or more launch wheels to result in the delivery of one or more balls to a player, the one or more balls being one or more soccer balls. The ball sensor may be disposed behind an opening in the frame adjacent to the staging area. The ball sensor may be an optical sensor configured to project a light signal onto the staging area and detect a reflected light signal when a ball is present within the staging area. Determining whether a ball is present within the staging area based on the ball sensor data may include determining whether a reflected light signal is detected. The ball sensor may include a laser configured to project a light signal having a wavelength within the red light spectral range of 620 nanometers (nm) to 700 nm. The ball sensor may be one of a ball activation switch, a proximity sensor, a capacitive sensor, or an inductive sensor. Furthermore, similar embodiments may include a computing device having a processor and a non-transitory computer-readable medium having instructions stored thereon that, when executed by the processor, cause the processor to perform the operations discussed above.

[0168] In some embodiments, a ball throwing machine includes one or more launch wheels configured to impart motion to one or more balls; a wheel motor coupled to each of the one or more launch wheels; a first encoder coupled to a first wheel motor coupled to a first of the one or more launch wheels; a frame attached to the one or more launch wheels; and a control circuit configured to control the one or more launch wheels, the control circuit including a processor and a non-transitory computer-readable medium having logic stored thereon, the logic configured, when executed by the processor, to cause performance of operations including: receiving wheel motor data from the first encoder, the wheel motor data including a log of revolutions per minute of the first wheel motor; and detecting whether a first ball has been launched based on fluctuations in the wheel motor data. Imparting motion to the one or more balls may include rotating the one or more launch wheels to cause the delivery of one or more balls to a player, the one or more balls being one or more soccer balls. The ball throwing machine may further include a second encoder coupled to a second wheel motor coupled to a second launch wheel of the one or more launch wheels, and the operations further include receiving wheel motor data from the second encoder and detecting whether the first ball has been launched based on variations in the wheel motor data received from the first encoder and the second encoder. Detecting whether the first ball has been launched based on variations in the wheel motor data may include comparing the variations in the wheel motor data to a predetermined signature of wheel motor data representative of known ball launches. Detecting whether the first ball has been launched based on the variations in the wheel motor data may include processing the wheel motor data with a trained machine learning model configured to provide a classification prediction indicating whether a ball launch has occurred.The operations may further include acquiring training wheel motor data from a first encoder collected during deployment of the ball throwing machine under known conditions and performing operations according to a training program; acquiring labels for the training wheel motor data; and processing the labeled training wheel motor data with a machine learning algorithm, resulting in a trained machine learning model through adjustment of internal parameters of the trained machine learning model that results in a mapping of the training wheel motor data to the labels. The operations may further include initiating remedial action in response to detecting that the first ball was not launched as expected. Furthermore, similar embodiments may include a computing device having a processor and a non-transitory computer-readable medium having instructions stored thereon, which, when executed by the processor, cause the processor to perform the operations discussed above.

[0169] Although some specific embodiments have been disclosed herein, and although specific embodiments have been disclosed in a certain degree of detail, the specific embodiments are not intended to limit the scope of the concepts provided herein. Further adaptations and / or modifications may be apparent to those skilled in the art, and the broader aspects encompass these adaptations and / or modifications as well. Thus, departures may be made from the specific embodiments disclosed herein without departing from the scope of the concepts provided herein.

Claims

1. A ball throwing machine, one or more launch wheels configured to impart motion to one or more balls; a frame attached to one or more launch wheels; and a control circuit configured to control the one or more launch wheels, the control circuit including a processor, a non-transitory computer-readable medium having logic stored thereon, and one or more motion sensors configured to acquire data regarding operation of the ball thrower, including the launch of a first of the one or more balls.

2. 2. The ball throwing machine of claim 1, wherein imparting motion to the one or more balls includes rotating one or more launch wheels to effect the delivery of the one or more balls to the player, the one or more balls being one or more soccer balls.

3. The ball thrower of claim 1 , wherein the one or more motion sensors include an accelerometer disposed on the control unit.

4. 4. The ball thrower of claim 3, wherein the accelerometer is configured to acquire vibration data of the ball thrower while the ball thrower executes training programming, the training programming including a ball firing sequence during which a ball is fired, and a standby status during which the ball firing sequence is not executed.

5. 5. The ball thrower of claim 4, wherein the vibration data indicates a difference in vibration of the ball thrower during a ball firing sequence and a standby status.

6. The ball thrower of claim 1 , wherein the one or more motion sensors include a microphone disposed on the control unit.

7. 7. The ball thrower of claim 6, wherein a microphone is configured to capture audio data of the ball thrower while the ball thrower executes training programming, the training programming including a ball firing sequence during which a ball is fired, and a standby status during which the ball firing sequence is not executed.

8. 8. The ball thrower of claim 7, wherein the audio data represents a difference between noises generated by the ball thrower during a ball firing sequence and a standby status.

9. The ball thrower of claim 1 , further comprising one or more communication ports communicatively coupled to the control unit.

10. 10. The ball thrower of claim 9, wherein the one or more communication ports are located on an interface module disposed on a back side of the ball thrower opposite the one or more launch wheels.

11. 11. The ball thrower of claim 10, wherein the interface module includes one or more status indicators, and the control unit is configured to cause illumination of a first status indicator based on an operability status of the ball thrower.

12. 12. The ball thrower of claim 11, further comprising a handle attached to the frame, the handle extending outwardly from a location adjacent the one or more communication ports.

13. 10. The ball thrower of claim 1, wherein the one or more operational sensors include at least one of a temperature sensor configured to detect an ambient temperature of the control circuit or a current sensor configured to detect a current drawn by at least the first launch wheel.

14. 10. The ball thrower of claim 1, further comprising a hopper coupled to the frame, the base of the hopper combining with the frame forming a staging area.

15. 15. The ball thrower of claim 14, wherein the hopper is removably coupled to the frame.

16. The ball thrower of claim 1 , wherein the control circuitry is configured to communicatively couple to a network device.

17. 17. The ball thrower of claim 16, wherein the control circuitry is configured to receive instructions from a network device, the instructions corresponding to a training program including instructions to launch a series of balls.

18. 2. The ball thrower of claim 1, wherein the operation of the ball thrower includes a ball firing sequence during which the ball is fired, and a standby state during which the ball firing sequence is not performed.

19. 20. The ball thrower of claim 18, wherein one or more operational sensors are configured to collect data regarding the operation of the ball thrower indicative of a difference between the operability of the ball thrower during a ball launch sequence and a standby status.

20. 10. The ball thrower of claim 1, further comprising a ball sensor coupled to the frame and communicatively coupled to the control circuit, the ball sensor configured to detect the presence of the first ball prior to the launch of the first ball.

Images