Well, okay, not quite 24 hours, but whatever.

So, I’ve made no progress on the camera calibration.  (Unless you want to consider failure progress because I now know more about what doesn’t work, in which case I’ve made tons and tons of progress…)  The cvCalibrateCamera2 function seems to have requirements that aren’t fully explained anywhere, except perhaps in error codes that are occasionally in Japanese.  I’m know I’m calling it wrong, but I have no idea how to call it right…   I think I’ll keep trying for a little bit longer and see if I can figure out what I’m missing.

If that doesn’t work out, then there is a slight change in strategy I’ve been considering.  You see, OpenCV has a function called “cvFindChessboardCorners”, and it is used to find the corners of a chessboard.  The corners of a chessboard are then used for calibration.  How is that going to help me, when I’m trying to find the edges of a TV and not the corners of a chessboard pattern?

Well, it’s not like Pong is the only Atari game I own or anything…

Booyah!  Chew on that, Stella!

So, all this talk about it, and all these videos of the thing going wrong, and yet I haven’t actually posted a video of what the thing does when it’s actually working right?  Well, here you go.

And the YouTube version:

It’s a lot more subdued than when I started this morning.  The robot I had in the morning could have torn your hand off.  Now it’s much more mellow.  (Of course, I’m afraid that it’ll kill me in my sleep, but whatever…)

Two days remain, and there is still much to be done.

21-13, the best score yet.  I tweaked the motion yet again.  I went back to continuous motion, for starters, since the angular was constantly starting and stopping over and over and over and over, slowing it down.  I think part of the main problem before was the message buffering.  The same thing that was happening with the LEFT LEFT LEFT stuff I talked about earlier was happening in continuous motion mode, too.  The solution here doesn’t have to be async, though, which is nice.  Instead, all I have to do is not send the same message more than once in a row.  You can tell me LEFT LEFT LEFT LEFT LEFT all you want, and I only tell the robot a single LEFT and I leave it at that.  It’s now hardly ever overshooting the mark, and when it does, it can usually recover with a quick nudge back in the right direction.

Also, with this game, the robot was briefly in the lead!

So, now, why isn’t it winning?  It’s supposed to be a perfect robot, why is it still losing to a 30 year old processor?  Two big apparent reasons:

1. It’s not moving fast enough.  I need to alter it so that it will race from one side to the other when the projected point is far away.
2. It’s not going to the right place.  The trajectory projection isn’t perfect.  It’ll sometimes miss the mark.  I’ll need to go back and work on that a bit to improve the prediction.

Still, I’m very pleased with what’s come together in the last hour or so.  The day wasn’t going so well until then.  Right now, I’m at the point where I’d hoped to be by about 2 PM…  The problems today have all been little stupid ones that can only be fixed by experimentation.  There hasn’t been much problem solving, it’s all been iterative failure toward a higher goal.

Computer Vision Processing Game Screen? Check.
Game Play Logic Predicting Ball Trajectory? Check.
Mindstorm Robot Attached To Paddle? Check.
Bluetooth Communication To Robot? Check.
Linking Trajectory Prediction to Robot Communication? Check.

Okay! Let’s go!

Maiden Voyage

Complex Systems Interacting To Produce Failure? Check.

That high pitched noise at the end after it jams is coming from the motor. Motors are not supposed to give off high pitched noises. Additionally, prior to jamming, it forced the potentiometer inside the paddle to skip past the end of its range a couple of times (The loud clicks that you heard). That can’t be a good thing to have it doing…

Here’s the prototype for the robot.  What do you think?

I set up the application to overlay all of its information over the real game screen, then started recording.  Then I stumbled across this:

[Click to Play Video]

I think there’s something philosophical and deep to be had here.  I’m working on all this technology and complicated calculations and processing in order to beat the game, and none of it turns out to be as effective as sitting still and doing nothing.  Awesome.

BTW, final score, 21-Zip.

 

Edit:  Here’s a YouTube video of an entire perfect game from that spot.

One thing that I haven’t mentioned regarding the “physics” of Pong is that the paddle causes a total change in the motion of the ball.  The walls reflect the ball like a real-world wall would, giving the ball a negative slope of the same value.  The paddles, however, assign a new slope, based on where the ball hits.

If the ball hits high on the paddle, the ball gets a steep upward slope.  If the ball hits toward the middle of the bottom half, the ball takes a 45 degree downward trajectory, and when it hits the middle, it will go straight across.

The diagram above is for illustrative purposes only, as I’m pretty sure there are 7 possible angles, not the five shown:  Three up, three down, and straight.  Seven makes the most sense when considering the game programming, as well.  There are seven possible angles for each side, which makes 14 possible angles in normal play.  Add in straight up and straight down, which are possible on some of the other variations of Pong on the cartridge, and you get 16 total angles, which can be stored neatly in a four-bit nibble.

Another point to note is the X on the upper half of the paddle.  That represents the location of the follow point on the CPU paddle.  The Atari will try to always seek that point to the ball, which means that most of the time, when the CPU paddle hits the ball, it’ll bounce it in an upper trajectory.  However, in order to make it possible for the player to actually beat the computer, the CPU paddle can’t move fast enough to perfectly track the ball.  The paddle is always too slow for the highest angles and will only be able to hit them if the ball reflects off a boundary wall close enough to the CPU side so it doesn’t have to chase it that far.  At higher speeds, it can be too slow for any angle, potentially even straight across.

Anyway, the relevance of this to my project is that I’m not going to attempt to calculate the trajectory after hitting the paddle.  It would be too much work to determine the location of the different reflection zones, and wouldn’t be of any real benefit.

Another good reason to build this robot:

I suck at Pong.

And that’s with a non-jittery paddle.