Maybe it does work.  It’s just that whoever wrote this .Net wrapper around OpenCV failed to make the CvCapture.Dispose(); call, you know, dispose of the object.  So, of course it was open, I’d just called it in the previous iteration through the loop.

Looks like it will work, but…

I can’t set the input source from the program.  If it’s not set to the Coax Input by something else, I’m getting blue from the S-Video input.

The FPS from the tuner seems to be 0.0, which leads to everything going grey, just like it all was when I started yesterday.

Anyway, at least it’s something.  Also, I now know that my web camera will work with OpenCV, so that’s good.  I hadn’t checked it before.

Right about now, I should be making a post about how awesome it was to play Pong using this program, and uploading a video of it in action in a real game.  Unfortunately, technology does not seem to want to let me do that.

I have an ATI TV Tuner in my PC that I used for capturing the sample videos that I’ve been programming against.  I had thought that I’d be able to use that tuner for when I wanted to play it live for the first time.  Apparently not.  OpenCV tells me that the card is in use, even though nothing should be using it.  I get an error, then I get the input source selection dialog.  Then my program crashes.

Fun.

So much for that milestone.

This centerpoint issue is more trouble than I originally anticipated.  It’s deeper than just an integer problem.  The ball contour is not a consistent size or shape, which is really throwing off the calculations.  Even with a five point weighted average, the projection error is huge, not to mention the fact that now any jitter will cause the next five frames to be worthless. 

I think I’m going to have to try to turn the tables and use the error to my advantage.  I’m going to continue with the projection and implement the boundary reflections and paddle plane intersection calculations.  (So far, I’ve only done the boundary plane intersection, and I’m projecting forward and backward, which I don’t need to do.)  Once I get that, I’ll be able to keep a history of the paddle plane intersection points.  I should be able to average those and throw out any outliers, and use that to determine where the real point will be.

Damn!  My statistics textbook is at work!

I’m trying to recognize the elements on the screen.  The upper and lower boundaries were easy, but the ball and paddles aren’t behaving quite so nice.

[Click for video]

As you see, it’s consistently saying the ball is a paddle and that the left paddle isn’t even there.  Something tells me that there’s a bug here…

Yep.  Noise is going to be a problem.

(Left: Raw Video.  Right: Canny Edge Detection)

So, apparently OpenCV doesn’t like MPEG files.  The samples I recorded were MPEG.  That means I have to convert the videos to AVI.  Here’s the result of that exercise:

I wouldn’t exactly call that correct…

Another good reason to build this robot:

I suck at Pong.

And that’s with a non-jittery paddle.