The gripper piece of the spinner assembly is a bit stronger than I’d anticipated.

That wasn’t supposed to happen…

So, I finally got a new paddle cage put together.  While the old one was all stylish and minimalist, this one looks like it’s built out of Legos.  Real Legos, too, not those lame Technic beams.

Features include gearing to hopefully reduce the impact of the motor overrun, a button pressing motor (Not yet active), and flexible support arm for the angled knob.

I wrote a test program that will repeatedly rotate it like crazy and hopefully shake out the bugs.  Here’s video of it in action.

Of course, what kind of test would it be if it didn’t end in catastrophic structural failure?  Unfortunately, the camera was not rolling for the chaos, but I assure you it was about as spectacular as it could be given what it is.  Anyway, I did record the aftermath.

The flaw is fairly obvious in the first video, there’s some tall connector blocks on the spinner that kept knocking against the gear bar.  Eventually one of them caught and didn’t knock loose, but the motor spun the 360 anyway.  It kinda popped loose for a bit, then shuddered, before eventually collapsing.  I’ve since fixed the problem¹ and had it run for upwards of ten minutes without issue.

It feels good to have some forward progress.

For those curious, the paddle in the cage is one of the Indy 500 Driving Paddles with a free 360 degree range of motion.  That’s how it was able to spin all it wanted without running into the range limitation that’s in a normal paddle.

1. I was going to fix it before even running it the first time, but I wanted to see if it would cause a catastrophic structural failure… [↩]

My paddle gripper isn’t centered on the paddle knob.  I hadn’t noticed that before.  That would be why the paddle worked better when it wasn’t constrained in the cage:  It could move where it needed to be to counteract the off-balance.

I’m going to have to try to fix that…

Now, where is my Atari USB adaptor?  I think it might support the paddle as an analog joystick axis.  If it does, then I can tweak control outside of the problematic Pong situation.  I’ll have direct feedback about where the paddle is and what it does when I move it.

Of course, I’ll have to learn how to read the value of an analog joystick access…  But at least it’ll be doing something useful.

So, I hacked the new movement logic into the old Pong processing code.

After an initial lack of movement due to a flipped bit in the Busy property, the robot started turning when it was told to turn.

When it needed to move the paddle down, it rotated counter clockwise.

When it needed to move the paddle up, it rotated counter clockwise.

I think you can get a sense of the problem.

It was a bit frightening to experience, actually.  It would turn the paddle a little to the left.  Then a little more.  Eventually, it would turn so far that the paddle dropped off the bottom of the screen, causing it to launch into recovery mode.  Recovery mode is where it does a fast clockwise turn to get the paddle back into the visible playfield.  Unfortunately, when the command “Fast Clockwise Turn” gets translated into “Fast Counter-Clockwise Turn”, things can go very bad, very fast.  After the first command did not recover the paddle, it issued another command.  Then another.  Then another.  It quickly hit the counterclockwise extreme of the paddle’s rotational range, where it was again told to continue in the same direction.  Then again.  Then again.

Immovable Object (Paddle Potentiometer) + Irresistable Force (Insane Mindstorms Motor) == Flying Lego Parts.

Even when it wasn’t attempting to self destruct, the force it exerted and the noise it made while spinning seems a bit excessive.

I think it might be perfect…

At any rate, I think it tried to calibrate the movement, based on the segment calibration technique I described earlier, but I can’t tell if it worked because of its slight homicidal streak.  Gotta get working on that.

Last time, the paddle was a bunch of errors and trials, approached from the point of view of the Bluetooth interface of the Mindstorms NXT.  It didn’t work out so well.  Many of the problems I had were the result of telling the NXT to do conflicting things, often queueing up many actions faster than it could process them.  It ended up having about as much control as a fully loaded freight train.  I’d tell it to rotate left and it would rotate left.  While it was rotating, every frame processed would tell it to rotate left again.  And again.

And again.

Then, the paddle would reach the point where I wanted it to stop, so I’d send a stop request.  Of course, I’d already sent a ton of “RotateLeft”s that it hadn’t processed yet, so it would run through them until it had used them all up.  Then it would stop.

By then, though, since the paddle had gone too far, I’d tell it to rotate right to get back where I wanted it.  In the next frame, it was still too far, so I’d tell it to rotate right again.  And again.

And again.

Eventually it would catch up and start rotating right, back toward the target point.  Now the queue was full of “RotateRight”s, so it would spin wildly back across the target.  Then again in the other direction.  Then back.

The ball, of course, wouldn’t wait around for the paddle to make up it’s mind and would sail steadily right past the confused rectangle.

Obviously, that’s bad.

I hacked around the problem by adding limited protection against command queuing.  I also lowered the power of the rotation motor so that the paddle would be less likely to swing past the target point, so it would be less likely to need to swing back.  Unfortunately, the lowered power also meant that it was no longer fast enough to reach from one side of the play field to the other.  If the paddle was at the bottom and the ball went for the top, it couldn’t make it.

In the end, this lack of control limited how well it could play.  It ended up playing just slightly better than the computer paddle.  Despite all of the technology and computing power involved, it was still no match for a reasonably skilled human player.

What I really needed was to be able to tell the paddle to go to a specific point as fast as it could. ROTATE 10 DEGREES LEFT.  And off it would go, just like that, resulting in a point that’s 10 degrees left of where it was.

Actually, I could tell it to do that.  Sort of.  I could tell it to rotate a certain number of degrees, but there were two problems with that.  First, the motor seemed to think that rotating somewhere in the same magnitude as 10 degrees was the same as rotating exactly 10 degrees.  I’d tell it to move 10 degrees and it would go full speed for 10 degrees, then coast for another 15, stopping at 25.  Then after that, if you told it to rotate another 10 degrees in the same direction, it wouldn’t go anywhere.  Since it went a total of 25 degrees with the first movement, it wasn’t going to go anywhere until the cummulative total of future movement requests was greater than 15 degrees.  Great, so now it was moving totally randomly and sometimes refusing to respond to movement requests.  That’s really useful right there.

The second problem is that it didn’t really matter if I could tell it how to rotate exactly 10 degrees, because I had no concept of what in the hell 10 degrees meant in the game world.  All of the calculations and projections were in pixels.  Degrees would be meaningless without some sort of conversion, and a conversion would require crazy calibration code.

I think I eventually may have solved the first problem, outside of the Crazy Weekend Project timeframe.  I think there was a mode for the Mindstorm motor that would force it to rotate the desired amount exactly, but that it was a hidden mode or was not accessible the way I was trying to use it or something like that.  I haven’t tried it out on a game, but I have a reasonable expectation of success there.

I think I’ve also solved the second problem, as well.  All of my initial thoughts on paddle calibration involved some crazy scheme where I’d rotate the paddle to the clockwise extreme of the screen, then take a reading, rotate it to the counter-clockwise extreme, take another reading, and use the numbers to come up with a conversion between pixels and degrees.  A little something like this:

It’s all fine on paper, but in practice, it all falls apart.  First, you have to find the extremes.  You can’t just rotate the paddle all the way to the left, then all the way to the right, because Atari paddles have a useful range somewhere in the middle.  They have a roughly 270 degree arc, but for most games, there’s only about 100 degrees of usefulness.  Also, even if that did work, how will you detect when you’ve hit the end point of the paddle?  The motor will just keep going and going until something breaks.  You might be able to turn left or right until the on screen paddle quits moving, but in some games, like Pong, the paddle will happily sail off the screen.  If the paddle behaved and stayed on the screen, you still have to correlate the rotation angle of the paddle to the movement on screen, and stop moving and make your calculation at the instant the extreme is reached.  There’s a good chance that you’d have to move so cautiously and deliberately that you will have lost the game before you’ve calibrated your paddle.

However, the idea is sound.  The math is a simple transformation that works. So what if you take away the walls and try again?  Why bother with two variables, when you can do it with only one?  Like this:

The extremes don’t matter at all.  What matters is that you have a distance and an angle.  So why not start with specifying the angle?  Rotate 10 degrees clockwise or 25 degrees counter-clockwise.  Then, when the motion is done, see how far the paddle on the screen has moved.  This will be much easier to do, not to mention, much faster.  One movement and you’re done.

This is what I’m going to try to do.  I already have the Pong recognition set up and running from last time, so I’m going to use that as a base to implement and tune the new movement engine.

The general Paddle class interface will be something like this, although it will likely be modified and tuned as I go.

I seem to have been neglecting this lately.  I’m a week overdue on a programming/testing post, and it’s almost getting to the point where I’m late on a video game history lesson.  So, to prove I’m not dead, here’s a few bits of here and there.

First, if you’re in Washington, you have less than a week left to Approve Refererendum 71.  I already have.  Have you?

Now, back to games and things.  Here’s a few of my latest acquisitions.

This one should require no introduction or explanation.  Tengen Tetris.  I spoke about this game several times in previous entries, alluding to the legal fight between Atari and Nintendo, but always in passing.  Now that I actually have a copy, I’ll have to devote an entire article about it.  That’ll be in the future, but for now, to illustrate its awesomeness:  Two-Player Cooperative Mode.

The second notable acquisition is a Japanese Famicom game called Metafight.  Well, it’s actually “Something-Something Metafight”, but I don’t know Japanese.  The cover has some generic anime characters, one of which looks angry.  None of that really matters.  I’m not really into Japanese things and I’m not really into anime or stuff like that.  And I don’t have a Famicom system.  So, then, you ask, why would I go out of my way to buy a Japanese anime game for the Famicom?

This screenshot might help you figure it out.  It at least might look a bit familiar to you.  Maybe.  Can’t quite place it?  This’ll do it:

Metafight is the Japanese version of Blaster Master.¹  There is no opening story sequence in Metafight, which automatically means that the plot for Metafight makes far, far more sense than the “My pet frog jumped on a box of radioactive waste in my backyard and went down a hole and I followed it and found this bad-ass hyper-agile tank in the underworld and I proceeded to fight lots of nasty creatures in my bad-ass hyper-agile tank in order to rescue my radioactive mutant pet frog and save the world from the radioactive mutants that live under the Earth’s crust” plot that Blaster Master tried to have.  Of course, since Blaster Master changed the story from whatever angry anime guy was doing to something stupid about a mutated frog, they had to change the tank ignition sequence to be in a cave, instead of Metafight’s futuristic tank garage.

But enough about that for today.  It’s time for robots.

It’s been a while since I’ve visited the land of the video game playing robots, but I assure you, I have been thinking about them.  I think the next time I get back into them, assuming I ever do, the first thing I’ll do is organize the codebase.  It was built to get it to market, but not built for future expansion.  If I want to keep going with this, I’ll need to rewrite large sections of it and separate the movement interface and screen capture plumbing from the game specific recognition and logic code.  Although it won’t be quick, that should hopefully be reasonably straightforward to do.  From there, I’d like to work on improving the control of the paddle.  A few weeks ago, I think I may have improved the precision of the controls, but I still haven’t tested it out.

At any rate, I think Pong is the wrong game to try to develop precision controls.  The trajectory projection gets in the way of making sure the paddle is moving exactly where I want it to go as fast as I can get it there.  The paddle might very well be going where I want it, but by the time it gets there, that’s no longer where I want it.  So, I think I’m going to have to try another game to tune the paddle controls.  Right now, I’m leaning toward Kaboom! as the game of choice.  It should have easy to program recognition and logic (Bomb drops straight down, move to catch bomb, repeat), and it will absolutely require precision, accuracy, and speed.  Runner up is Indy 500, but I think the pathfinding and collision avoidance knock that one out at this point, not to mention the 360 degree driving paddle.  An interesting side-note is that pretty much whatever paddle game I choose, I’ll have to deal with something I didn’t care about in Pong:  The button.

Beyond the paddle, to really get things done on the Atari 2600, I’m going to need to be able to control a joystick.  I have several options, of course.  I can try some alternative controller, like the button operated Starplex or the gravity operated LeStick, but really, or maybe try to build my own controller, but really, to claim that I built a robot that can play an Atari 2600, I have to build something to handle a good old CX40 Atari Joystick.  That’s probably not going to be easy.  The controls won’t have to be as precise as the paddle, since there’s only nine options, however, it’s going to involve control on two axes that are somewhat dependent on one another.  I’ve had thoughts involving double arms that push or pull, a swing arm with a piston, a gantry crane like setup, and something that rotates and can push the stick, and none of those ideas seem any good at all.  I’m sure I’ll think of something.

1. And if you don’t know what Blaster Master is, well, you just need to play more NES games. [↩]

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

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.

Miscellaneous Failures In Robotics

Unfortunately, no explosions.  However, parts do fly.  If you pay close attention, you’ll see a gear get thrown during the first attempt, just before everything goes wrong.

Looks like I need to be able to lock the arm in place, or it’ll keep popping up.