Random header image... Refresh for more!

Category — Crazy Weekend Project 1: Pong Robot

It’s Not About Doing It Right, It’s About Doing It Right Away.

Dirty hacks are permissible on Crazy Project Weekend.

Dirty Hacks Are Permissible

If you can’t get the lines drawn as an overlay on top of the window, then draw them directly on top of the images.

September 7, 2009   No Comments

Drawing Lines

I don’t remember Windows.Forms being this stupid.  All I’m trying to do is draw an overlay of lines between two images.  Why are you making that so hard?

September 7, 2009   No Comments

About the TV Screen

Trying to use a real TV screen will pose a couple of problems.  First, I have to find the TV screen in the image.   Then, once I have the TV screen, I’ll have to do something about the distortion.  There will be two types of distortion.  First is perspective distortion, since I can’t assume that the camera is facing the TV screen head on.  Then, of course, since this is a typical CRT TV, there’s the curve of the screen to take into account.

I’m going to rely heavily on user input to calibrate the display.  My idea is that the user will have to click several points on the video image that correspond to points on the playfield.  Then, hopefully, I’ll be able to fix the distortion in the image and have a playfield image that’s nice and square to use.

It will look something like this:


There.  Wasn’t that simple?

Of course, it would be totally awesome if I could simply feed it an image of what I expect to see, then have it find that image in the video and undistort everything for me.  However, I haven’t quite read that chapter yet…

September 7, 2009   No Comments

Okay, Now Get Back To Work

I hooked up the webcam and noticed the edge detector and contour recognition displays going wild.  So, I got a little side-tracked…

Star Trek

I am definitely going to have to play around with OpenCV some more when I’m done with this robot project.

September 7, 2009   No Comments

But first…

It’s time for a bit of refactoring.  My main() is something like 200 lines of code that doesn’t belong all in one place.  I had been trying to keep everything in the PongLogic class, but that fell apart after a while.  Gotta take care of that.

September 7, 2009   No Comments

So Now What?

So, the robot won a game. It won largely on luck, though, it was making plenty of mistakes along the way.  But, it’s now time to move on.

See, it’s all well and nice that it can play based on the video signal from a  TV input card fed directly from the Atari into the computer.  But that’s not terribly practical, is it?  Who has a TV input card to hook an Atari up to?  What do people usually play Atari on?


They play on Channel 3.

This is going to complicate things…

September 7, 2009   No Comments

Now I have to implement the “Smack Talk” feature…


Booyah!  Chew on that, Stella!

September 7, 2009   No Comments

One Down…

if (uncalculatedFrameCount > 20 && uncalculatedFrameCount < 60)
    robot.SendMotorCommand(0, (sbyte)30);

That seems to be fixing the lost paddle problem. This code will spin the paddle to the right after the gameboard gets confused. I had tried a variant of this before, but it turns out that the gameboard gets confused after every goal, so the paddle would wildly move out of place after every goal, which is not good.

So, I tried it again, with a lower bound of lost frames. This way the game has to be really confused before it tries to recover the paddle. The upper bound is there to prevent it from going wild if the playfield can’t be recovered. Otherwise, when the game ends, the robot will spin right until something breaks, which is not good.

I just ran another game with this logic and watched the robot correctly recover from a lost paddle in the middle of the game.

September 7, 2009   No Comments

Thinking Outside The Box

I set up the improved motor control and while it seemed to be working a little better, there were times that I noticed that the motor seemed to get stuck.  The command had been given to turn left, the motor was making a sound like it was trying to do something, but there was no movement.  It seemed like it couldn’t overcome the initial friction to get going.  So, I tried something a bit different.

I removed the spinner assembly from the cage structure and held it in one hand, then stuck it on the paddle, which I held in the other hand.  When I tried it out, it seemed to be running better.  So, I attached the motor to the cage backwards, and had the spinner sit on top of the paddle.  The paddle was now outside the box, sitting loose on the desk.  It let it go and the robot began to play the best game yet.  It was even up 4-0 at one point.

Unfortunately, at one point, it overcorrected and shot the paddle off the bottom of the screen.  Once it loses the paddle, it’s game over.  I’ve got to fix that.

So the major problem areas as they stand:

  • Motor doesn’t want to engage properly when paddle is in cage.
  • Prediction is sometimes flaky.
  • Paddle gets lost == game over.

I’m giving myself an hour to fix those problems, then I have to move on.  I can’t get stuck tweaking things forever.  It’s playing at the level of a crappy human player as it is, so that should be good enough to continue.

September 7, 2009   No Comments

This Is Why I’m Not In UX


Let’s Ship It!

September 7, 2009   No Comments