Maybe I shouldn’t have played Berzerk with the Mindstorms unit still attached to the Atari…

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.

Changing to basic angles seems to have helped considerably.  The movements are now more controlled.  The problem is, now they’re completely overshooting the mark.  I think the problem is that I’m sending rotate requests with every frame, and they’re getting queued up on the robot.  So, I say LEFT LEFT LEFT LEFT LEFT LEFT LEFT STOP, but it’s hit the mark after just two LEFTs. yet it still runs through the remaining five LEFTs before it sees my STOP.

Looks like I need to go async here and have the robot tell me when it’s done moving before I send it another command.

So.  There’s obviously a bit of a problem with the movement.  It’s either moving too fast and coming apart or too slow and not getting to the mark in time.  I see two potential solutions to this issue.  I could try gearing the motor, so that it can spin like crazy, but not move the paddle quite so wildly.  Or, I can try using the more precise controls and tell it exactly how many degrees to rotate, rather than telling it to move left or right until I tell it to stop.

I don’t know which one of those has a higher probability of working…

The gears would be easier, since it’s mostly a reconfiguration of the existing robot.  The rotation angle method would require calibrating the paddle to determine what angle represents a sweep from top to bottom of the screen.

Maybe I should try to solve the disappearing paddle problem first and see if that makes things better.

Here is the panel where I’ve been spending most of my time lately.

When I first did it, the power was way too high, so I made it lower.  The power is still way too high, so I made it lower.  Then it was too low to move.  That’s when I discovered what the “Motor Power” control does.  It’s like traction control in your car, it will adjust power to make the motor move at the same speed, even if there’s resistance.  That got things moving.

Unfortunately, the only movement that happened was the paddle moving off the bottom of the screen and getting lost.  When a paddle gets lost, weird things begin to happen.  The logic ends up royally confused, sometimes thinking that the ball is the paddle.  At any rate, it continues to tell the paddle to move down, so it ends up continually telling the robot to rotate left.  Eventually, the paddle hits the left endpoint of its range, and BLAM!  The spinner assembly kicks a gear and the whole thing keeps on spinning.

 

ktktktktktktktktktktktktktktktktktkt

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…

It looks like videos from my video camera will work in a Silverlight player after all. The screen capture videos don’t work, but I think they’re using some crazy codec. Hopefully these will work for people and you won’t have to download the videos to watch them.

Robot Demonstration

Things Going Wrong

A robot must obey any orders given to it by human beings, except where such orders would conflict with the First Law.

Done.  It’s now responding to my commands and is no longer clicking.

[Click for Video]

It is also very obvious that this is going to be way too fast for the Atari Paddle.  I think I’m going to have to have slow, medium, and fast commands, too.