Random header image... Refresh for more!

Posts from — September 2009

Well Now, That Didn’t Work.

ThatDidntWork

I am really starting to hate those robotic motors.  Sometimes they won’t move at all, and other times they’ll overcompensate for all the times they don’t move and end up flying across the screen when the ball is two pixels away.  They just do not want to be controlled.  The battery change has given them new life.  Actions that were once just right are now wildly off the mark.

Stupid real devices.  Does anyone know how to attach a debugger to the laws of physics so I can see what’s going wrong?

September 8, 2009   No Comments

The Next Problem To Solve…

LowBattery

Now I just need to make the robot recharge its own batteries, perhaps even make it run off solar power…

September 8, 2009   No Comments

Why Can’t It Win All The Time?

I’ve watched the robot play a bit more and I’ve noticed a few tendencies that are preventing it from winning more often.

  • Predictions are sometimes skewed by initial guesses.  The farther away the ball is, the worse the predictions tend to be.  Sometimes there will be a batch of outliers that will pull the prediction just far enough up or down so the paddle just barely misses the ball.
    • Possible solution:  Use a rolling window of the last N predictions for the average.
    • Downside:  Prediction will be more susceptible to outliers within the window.
  • The paddle can’t get across the screen fast enough.  When the paddle misses the ball at the bottom of the screen, the serve will usually occur toward the top of the screen, and even at its fastest, the paddle doesn’t get there in time.
    • Possible solution:  Make it move faster.  Possibly even take into account the ball’s distance from the target point when determining the paddle speed.
    • Downside:  The faster it moves, the less control it has.  It might be overshooting the target more often than it hits it.
  • Prediction history will sometimes carry over after a point is scored.  When this happens, you have all the points where the ball was going, which are heavily weighing down the points of where the ball is going.  It usually ends up with the prediction point somewhere in the middle of the screen and nowhere near where the ball actually is.  And, of course, the robot tracks the predicted point and misses the ball entirely.  There’s already logic to throw out the history after a point is scored, but it’s based on the number of “unrecognized frames”, and it’s not always accurate.
    • Possible solution:  The history window will help this problem immensely, but won’t make it go away.  The history should also be thrown out if the position of the ball jumps more than 25% of the screen width in a short period of time.
    • Downside:  This kind of calculation can run into a number of false positives.  The recognition is occasionally flaky, and the ball might become the paddle briefly and trigger this solution based on that.

Additionally, I’ve noticed that when the robot misses the ball once, it usually misses the ball several more times.  These second and third misses are usually the direct result of one of the problems listed above.  If I can correct those issues, then missing one ball won’t turn into missing three balls, which means that the robot stands a much better chance of winning.  A score of 21-20 that was decided on the last ball will turn into a score of 21-10, which is a much nicer victory to see.

September 8, 2009   No Comments

A Bridge Too Far…

Sadly, I don’t think the whole TV thing is going to work out.  I got nowhere on the calibration.  cvFindChessboardCorners will find the corners on a real chessboard, but didn’t accept the Atari screen at all.

Checkerboard Pattern

So, at this point, that’s a dead end and it’s not worth chasing.  I’m sure there’s a way to make it work out, but I don’t really feel like spending time trying to sort it out.

I think I’ll go back and try to tweak the projection logic and the robot a bit more.  It’s only won a single game so far, and that was far too close.  If I can’t make it play on a real TV, at least I can make it play better on the direct video feed.

September 8, 2009   No Comments

The Moon Is Falling…

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

September 8, 2009   No Comments

Yeah, About The TV Thing…

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?

Video Chess

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

September 8, 2009   No Comments

That Doesn’t Help…

CvCapture

September 7, 2009   No Comments

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:

CameraCalibration

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