DIY simulator (camera based)

[SwedishGuy]

Yes, made it myself. Used to be a standalone program where I experimented with having the recording voice activated but ended up with pressing space on keyboard..Would then give one beep to indicate that you should get prepared and then after a delay 2 beeps when it started to record, and finally another beep when the recording was done.
But now it uses the shot trigger detection of the simulator and saves a clip with recordings from just before shot (buffered) and a few seconds after.
I can send you the standalone version if you're interested. A bit crude but functional.
The voice activator is actually also standalone and simulates a keyboard press, but not working that great since I didn't spend much time on it.

[goatbarn]

If you don't mind, shoot me that program too. I have a GC2, but may be able to figure out how to replace shot trigger method to something that works with the GC2...link to PM, or I can provide email in PM. Let me know! Nice work.

[cj.smit03]

Hi, I am 13 years old and would like to build something like that, I want to know how many fps should a camera be, how do you actually calculate the distance of the ball for the golf simulator

[SwedishGuy]

Great to hear that young people are interested in developing stuff!
To calculate ball speed, launch angle and path, you only need "1 fps", but you need two cameras taking pictures of the ball from different angles. It's enough with one frame taken if the shutter time of the camera is long enough for the ball to leave a "blurred ball trace" in the image. Find the ends of the ball traces in both images and use stereo matching to calculate the 3D positions of them. See e.g. http://docs.opencv.org/3.1.0/dd/d53/..._depthmap.html to get an idea of what stereo matching is about. This will give you distance and angles. Shutter time gives you the time, and speed is just distance/time.
Have fun.

[SwedishGuy]

Hi,
some updates on my simulator. One big issue I had was that I used images of the ball on the tee + images of the ball in the air to calculate launch parameters. And this without knowing the exact time when the ball would leave the tee. The fault could be in the milliseconds range which just was too much. I have now improved my simulator by letting it take two shots of the ball in air instead but still trying to make sure there is about 1 meter of distance between the ball in the images (longer distance increases accuracy). Wasn't too hard to do since it is my club speed sensor which triggers the cameras and calculates what the delay should be. I actually first tried to let the cameras take 50 images each at full frame rate (150 fps) with the intention of only analyzing a few of them. But it turned out that I got issues with the usb buses and skipped frames (too many cameras on the buses).
This change did significantly improve the accuracy of my system. Especially since I now got timestamps on the images with resolution of around 10 microseconds.
I then decided to try to validate how well the system works, and especially making sure the stereo triangulation is valid and accurate.
I started by taking a black rod and attach a golf ball to each end of it, making sure there is 1 meter between the balls. I then triggered the system with that rod in different launch and path angle directions. Launch from 0 - 40 degrees and path from some -20 - 20 degrees.
Every time the distance between the balls was measured to be between 101.5 and 102.5 cm. So the calibration is a little bit off (1-3%) with might have to do with the precision of given size of calibration pattern, but then the accuracy seems to be around 1%.
I'm currently not chasing that 2% calibration error since I don't mind getting that extra ball speed
I also tried to measure the angles (while the rod was hanging from a fishing line), and the accuracy in my manual measurements weren't exactly what you would say totally reliable, but every time I came up with numbers matching my software within 1 degree or 2.
So I would say I'm pretty happy with what I got and find it playable. Putting down to around 1 meter also works well.

I also decided to try to use other simulator software apart from RedChain. I managed to connect to both E6 and TGC, but that depends heavily on utilizing the CP from Martin. A shame that there isn't a system with an open API to develop against...
I only tried a demo license of E6, but the impression is that it is much more forgiving than RedChain, producing straighter (and probably longer) shots. RedChain on the other hand exaggerates the side spins imo.
For the TGC I got the GSA/Steam license and the impression here is also that it's more forgiving than RedChain, giving straighter shots.
Biggest drawbacks with TGC is that you have to select sunny courses (otherwise too dark on projector) and that it's really only adapted to "mouse play". My wife wasn't happy when I could only add her as a "guest" and had to use same tee as me. Especially when one hole required a carry of some 180 meters over water... A driving range wouldn't be wrong either, with longest drive and closest pin competitions.

I still have a slight feeling that the simulator produces iron shots, like I6, which can be some 10 meters longer than in real life, while driver shots on the other hand are some 10 meters shorter than in real life. And it is even more so for slower swings speeds meaning that my wife's drives and irons are too close in distances. I can't find what should be wrong with my calculations so I start to wonder if not the simulators have flight calculations which are penalizing low swings speeds combined with low launch angles too much?

I've had thoughts about making the code open source, but since there still isn't any open api towards a simulator, I'm reluctant to dedicate the time for documenting everything for others.

[SwedishGuy]

Yes, I use opencv (c++) and Point Grey SDK for the cameras. Mostly pure opencv algorithms, but some custom built for spin detection of marked balls and also finding the ball in some cases with non uniform backgrounds. Most of the stuff is pretty basic, it's just a matter of combining it in the right way.
I suspect it's pretty adapted to the setup I have right now and could need some tweaking of parameters if it would be used in a different location with totally different lighting and backgrounds. Haven't spent a lot of time on making it a "finished product".

[codehead]

Have you looked into the KAZE / AKAZE algorithms for feature matching and tracking to do spin computation? My experience with machine vision and imaging is limited so if this is not relevant I apologize.

[SwedishGuy]

I've actually not looked at KAZE (might try it..) but used a "home brewed" algorithm for feature matching (and balls with special dot pattern all around). Unsure if KAZE would work with unmarked balls.
The problem as I see it is that for spin detection you want close up images of the ball, and that limits a bit where you can place the ball on the tee, and also decreases the accuracy you get for calculating speed and angles. The accuracy in finding the 3D position of the ball gets less important as the distance the ball has traveled between images increases. So I've focused on ball speed and angles to start with and then added club path. Adding my spin detection to the current setup means adding two more cameras (which I actually have in the LX), which might give me issues with too much on USB at the same time. Not sure. What I do know is that for me is both club path and club face more interesting than the actual ball spin. It tells me what I need to practice on. I'm not interested in finding the driver with the lowest spin number.

[cj.smit03]

Hi, thx for the reply, I am fimiliar with programming but i want to know if the code is hard to write because I'm not a pro programmer😂

[cj.smit03]

And also, how did you get all the calculations like launch angle synced up to e6/tgc

[SwedishGuy]

This is the part where things get complicated. There isn't any open API to use. You might be able to negotiate something with Martin at GSA, since he also sells "kits", utilizing his CP program for doing the launching?
Even if it would be possible to crack any of the ways to connect, it wouldn't be legal. Not even telling other people how to crack the systems themselves. http://csc.protee-united.com/hc/en-u...-Club-SDK-v1-1 describes what seems to be an open API towards TGC, but ProTee has switched to a version 2 where a secret launch code is needed as well. Maybe ProTee can be negotiated with as well?

[symo76]

Amazing. This is the kind of project I'm looking for!
Golfing enthusiast (nut) & Computer enthusiast (geek)
Where do i sign up? 😁

[codehead]

Would you consider just putting your code up on git or something? Wouldn't require a bunch of documentation

[SwedishGuy]

I actually half started to do that, but not sure there is any point when I can't put up the code for connecting to simulator programs.
And I think I would at least have to document the arduino circuits. A bit hard to build just from looking at the code.

[Caleb]

Hi I am really interested in learning to develop something like this I am pretty good at programming but I can’t really get my head around how you track the ball for example in your draw/fade video you show I’m guessing opencv lines follow the ball I was just wondering if you could maybe go into more detail about that or maybe share a little bit of the code that relates to that or maybe a link to where you have uploaded any code for it if that is ok

[htdumps]

Any Updates on this?

[ruant]

@SwedishGuy
Did you put something on GitHub or somewhere else?

[02bluesuperroo]

SwedishGuy Since you have concerns about posting the code that connects to the simulator APIs you could post some code and a few photos that just outputs the data of each swing to console and do not include any code for sending to the various game APIs. I'm sure many folks would love to play around with it or just learn from what you have done and would even pay to get a peak. I know I would, it is truly impressive!

[andygg1986]

He hasn't been on here since 2017, so I don't think you will be seeing a response from him.