In another thread, Mike Page suggested a definition of "exact" that involved programming a robot to find correct pivot points using CTE/ProOne. I started a new thread for this because I don't consider CTE/ProOne a pivot system in the sense intended by the "Proofs of the EXACTNESS of Pivot Systems" thread. Among other things, neither the pivot nor the cue are necessary to apply the system successfully.
This is a brief general outline of how I think a robot could be programmed to use CTE/ProOne. Many details depend on how the robot knows the locations (and orientations where appropriate) of itself, the balls, and the pockets. Fortunately, those details don't matter to the algorithm. It'd be easiest in a VP3-like system where everything is calculated, but almost any visual data acquisition system system would work. Binocular vision might be helpful but isn't necessary and might introduce more difficulties than it'd be worth. The following assumes that a monocular vision system is used to acquire all external data the robot needs. I've attempted to not use any raw data not available to the player, at least in some form; I think that effort was successful, but it should be checked.
The robot starts with a practice phase. An arbitrary (but not straight-in) shot is set up. The robot computes and records the cut angle. The cut angle is used to select the correct secondary alignment point on the object ball (left-1/8, A, B, C, or right-1/8) and cue ball (left edge, left-1/8, right-1/8 or right edge). The robot then aligns itself by iteratively calculating CTE and secondary alignment lines and adjusting its position and orientation until the criteria specified for correct alignment are met. The robot then iteratively makes test shots from candidate bridge positions until it finds two different ones that drive the object ball across the center of the pocket. From the two bridge positions, it calculates the CB-GB line for that shot. The robot then selects some point along that CB-GB line that is fairly close to the CTE line and that gives a fairly normal bridge length; this is the initial bridge position for future shots. The robot considers this point to be the apex of the 90-degree angle of a right triangle that has the CB-GB line as its long side and the CTE line as its hypotenuse (there are other ways of handling this but as a right triangle is probably simplest).
For each subsequent shot, the robot determines the new cut angle and uses that to select the appropriate new secondary alignment points. It iteratively finds new CTE and secondary alignment lines and adjusts its alignment until the halting criteria are met. The change in cut angle plus the angular difference between the old and new CTE lines determines the change in angle between the old and new CTE-to-GB angles; from that last angle change, the robot calculates a new CTE-line-to-bridge-point distance (and/or bridge length if that seems desirable). Once the new bridge point is found, the robot aligns the cue from the bridge point to the CB center, completing the "aiming" portion of the shot.
Assuming all of that actually works (no, I'm not going to write the code to test it), then I think it shows there's at least one reasonably sound theoretical basis for CTE/ProOne, though I expect Stan Shuffett doesn't think about it like this at all. It also meets Mike Page's definition of "exact".
Of course, it doesn't say anything at all about it being "exact" as used by humans. I know of no aiming system that is "exact" when used by humans, perhaps excepting short straight-in shots. It's certainly possible that with practice a human can be come so proficient with CTE/ProOne that they rarely need to "adjust" while moving into bridge position.
Oh... and note that the robot didn't pivot or use its cue at all in this
.
NOTES:
It would be interesting to know the bridge point's range of distances from the CTE line over a range of normal bridge lengths. By inspection (of a number of 3D drawings), I think the range is fairly small - in the plus/minus 1/4-inch range and centered around 1/2-inch - over a six to twelve inch bridge length range. Of course, that could be very wrong - I couldn't get SketchUp to measure those distances (admittedly, I didn't try very hard).
It could be argued that the practice phase constitutes "feel" rather than "exactness", especially the use of successive approximations to find the initial CB-GB line. With respect to that I see two points. First, all systems require the user to practice with them to become proficient; people don't seem to complain that practicing visualizing the ghost ball is "feel". Second, a whole lot of people, especially A-to-D builders, would argue that determining a value by successive approximations gives VERY exact results.
It could be argued that explicitly using the cut angle and the old-to-new CTE line angle changes quantitatively constitutes using information in a way that a human player cannot (avoiding that was one of the goals of this exercise). First, I would say that doing so does not invalidate CTE/ProOne as a system that can produce precise results; at worst, it may indicate that using CTE/ProOne to locate a precise bridge point is beyond human capabilities; that an approximation within some limits is the best a human can do. Second, humans are very good at working in 3D perspective space (they get a lot of practice), and I think they use the same information the robot does, but once their vision system "understands" the desired result, it applies the data automatically and simultaneously (rather like an analog computer might, but I really know zip about those).
It would be simpler to use the cut angle change to directly calculate the new CB-GB line, but that doesen't seem to me to be what the CTE/ProOne procedure is designed to do; rather, it finds a bridge point on that line without knowing where the GB is located (sort of).
While the robot "sees" the CTE and secondary alignment lines in 3D space and makes its adjustments accordingly, I think it's safe to do angle and distance calculations in the table's perspective plane. I do think it's necessary to use the perspective plane for calculations, however. For one thing, that's what the player's vision-brain system does (in its analogish way). Also, all of the robot's activity and feedback occurs in perspective space (albeit monocular). Also keep in mind that this perspective space has vanishing points along all three axes, and the robot uses the z-axis for the secondary alignment points, which lie on the equator or top of the ball as seen by the robot in perspective and will therefore be slightly "tilted" with respect to the plane of the table).
If we were going to build a real pool playing robot, then during the practice phase it could also acquire information such as cloth speed, how subject this set of balls is to throw and transferred english (i.e., how "sticky" they are) on a per-ball basis, how the cushions respond on bank shots, etc. If it wanted to be really picky, it could also determine each ball's exact diameter and use that information to adjust the shot (since balls larger or smaller than the cue ball won't behave the same as ones that are exactly the cue ball's size). It could also gather information on squirt and swerve at various shot speeds, and test the results of masse and jump shots. In the shot making process, once the cue was aligned along the bridge to CB center line, the robot would adjust the cue's alignment as needed for throw, squirt, etc. It could do all of that very accurately.
For those still worried about getting infinite cut angles from a finite set of alignment points: If the cut angle for the new shot differs any at all from that for the previous shot, then the angle between the CTE line and the CB-GB line also changes. This is true even if the new shot uses the same secondary alignment points on the cue ball and object ball as did the previous shot. The robot/player has moved during the alignment process and the new CTE and secondary alignment lines are not at the old angle to the OB-Pocket line, even though the alignment lines are pointing at the same points on the OB as seen relative to the cue ball. This is trivial to test.
This is a brief general outline of how I think a robot could be programmed to use CTE/ProOne. Many details depend on how the robot knows the locations (and orientations where appropriate) of itself, the balls, and the pockets. Fortunately, those details don't matter to the algorithm. It'd be easiest in a VP3-like system where everything is calculated, but almost any visual data acquisition system system would work. Binocular vision might be helpful but isn't necessary and might introduce more difficulties than it'd be worth. The following assumes that a monocular vision system is used to acquire all external data the robot needs. I've attempted to not use any raw data not available to the player, at least in some form; I think that effort was successful, but it should be checked.
The robot starts with a practice phase. An arbitrary (but not straight-in) shot is set up. The robot computes and records the cut angle. The cut angle is used to select the correct secondary alignment point on the object ball (left-1/8, A, B, C, or right-1/8) and cue ball (left edge, left-1/8, right-1/8 or right edge). The robot then aligns itself by iteratively calculating CTE and secondary alignment lines and adjusting its position and orientation until the criteria specified for correct alignment are met. The robot then iteratively makes test shots from candidate bridge positions until it finds two different ones that drive the object ball across the center of the pocket. From the two bridge positions, it calculates the CB-GB line for that shot. The robot then selects some point along that CB-GB line that is fairly close to the CTE line and that gives a fairly normal bridge length; this is the initial bridge position for future shots. The robot considers this point to be the apex of the 90-degree angle of a right triangle that has the CB-GB line as its long side and the CTE line as its hypotenuse (there are other ways of handling this but as a right triangle is probably simplest).
For each subsequent shot, the robot determines the new cut angle and uses that to select the appropriate new secondary alignment points. It iteratively finds new CTE and secondary alignment lines and adjusts its alignment until the halting criteria are met. The change in cut angle plus the angular difference between the old and new CTE lines determines the change in angle between the old and new CTE-to-GB angles; from that last angle change, the robot calculates a new CTE-line-to-bridge-point distance (and/or bridge length if that seems desirable). Once the new bridge point is found, the robot aligns the cue from the bridge point to the CB center, completing the "aiming" portion of the shot.
Assuming all of that actually works (no, I'm not going to write the code to test it), then I think it shows there's at least one reasonably sound theoretical basis for CTE/ProOne, though I expect Stan Shuffett doesn't think about it like this at all. It also meets Mike Page's definition of "exact".
Of course, it doesn't say anything at all about it being "exact" as used by humans. I know of no aiming system that is "exact" when used by humans, perhaps excepting short straight-in shots. It's certainly possible that with practice a human can be come so proficient with CTE/ProOne that they rarely need to "adjust" while moving into bridge position.
Oh... and note that the robot didn't pivot or use its cue at all in this
.NOTES:
It would be interesting to know the bridge point's range of distances from the CTE line over a range of normal bridge lengths. By inspection (of a number of 3D drawings), I think the range is fairly small - in the plus/minus 1/4-inch range and centered around 1/2-inch - over a six to twelve inch bridge length range. Of course, that could be very wrong - I couldn't get SketchUp to measure those distances (admittedly, I didn't try very hard).
It could be argued that the practice phase constitutes "feel" rather than "exactness", especially the use of successive approximations to find the initial CB-GB line. With respect to that I see two points. First, all systems require the user to practice with them to become proficient; people don't seem to complain that practicing visualizing the ghost ball is "feel". Second, a whole lot of people, especially A-to-D builders, would argue that determining a value by successive approximations gives VERY exact results.
It could be argued that explicitly using the cut angle and the old-to-new CTE line angle changes quantitatively constitutes using information in a way that a human player cannot (avoiding that was one of the goals of this exercise). First, I would say that doing so does not invalidate CTE/ProOne as a system that can produce precise results; at worst, it may indicate that using CTE/ProOne to locate a precise bridge point is beyond human capabilities; that an approximation within some limits is the best a human can do. Second, humans are very good at working in 3D perspective space (they get a lot of practice), and I think they use the same information the robot does, but once their vision system "understands" the desired result, it applies the data automatically and simultaneously (rather like an analog computer might, but I really know zip about those).
It would be simpler to use the cut angle change to directly calculate the new CB-GB line, but that doesen't seem to me to be what the CTE/ProOne procedure is designed to do; rather, it finds a bridge point on that line without knowing where the GB is located (sort of).
While the robot "sees" the CTE and secondary alignment lines in 3D space and makes its adjustments accordingly, I think it's safe to do angle and distance calculations in the table's perspective plane. I do think it's necessary to use the perspective plane for calculations, however. For one thing, that's what the player's vision-brain system does (in its analogish way). Also, all of the robot's activity and feedback occurs in perspective space (albeit monocular). Also keep in mind that this perspective space has vanishing points along all three axes, and the robot uses the z-axis for the secondary alignment points, which lie on the equator or top of the ball as seen by the robot in perspective and will therefore be slightly "tilted" with respect to the plane of the table).
If we were going to build a real pool playing robot, then during the practice phase it could also acquire information such as cloth speed, how subject this set of balls is to throw and transferred english (i.e., how "sticky" they are) on a per-ball basis, how the cushions respond on bank shots, etc. If it wanted to be really picky, it could also determine each ball's exact diameter and use that information to adjust the shot (since balls larger or smaller than the cue ball won't behave the same as ones that are exactly the cue ball's size). It could also gather information on squirt and swerve at various shot speeds, and test the results of masse and jump shots. In the shot making process, once the cue was aligned along the bridge to CB center line, the robot would adjust the cue's alignment as needed for throw, squirt, etc. It could do all of that very accurately.
For those still worried about getting infinite cut angles from a finite set of alignment points: If the cut angle for the new shot differs any at all from that for the previous shot, then the angle between the CTE line and the CB-GB line also changes. This is true even if the new shot uses the same secondary alignment points on the cue ball and object ball as did the previous shot. The robot/player has moved during the alignment process and the new CTE and secondary alignment lines are not at the old angle to the OB-Pocket line, even though the alignment lines are pointing at the same points on the OB as seen relative to the cue ball. This is trivial to test.
