A Crazy Project Weekend is when I take an extended weekend and dedicate my time to a AAA project:  One that is Achievable, Awesome, and slightly Abnormal.  There are a couple of rules, made up on the spot this instant, guiding the Crazy Project:

• Work must be done within the limited weekend time frame.  You cannot begin any concrete work prior to the time window, and if you do not complete by the end of the time, you have failed.  You may do some preparation ahead of time, such as feasibility research or acquiring necessary materials, however, nothing should be built and there should be no written plans.  The point is to see what can be done in five days, not what can be done in five days and a couple of hours an evening for three weeks prior to those five days. 
• It must not be something you would otherwise normally do.  Setting up a website with a blog and a bunch of pictures of the dog doesn’t count.  Cleaning the garage doesn’t count.  It must not be something that anyone would normally do.
• You have to learn something.  If you know exactly what you’re doing going in, then it’s no fun.  One of the central pieces of the project must involve something you’ve never worked with before.  There must be several moments where you have no idea what in the hell you’re doing and wonder what you’ve gotten yourself into.
• You must post regular progress updates throughout the weekend, detailing what you’re doing and what you’ve done.  Viewers must be able to get a glimpse of your thought process and understand what you’re going through.  You should talk about initial goals and milestones, obstacles you see on the path to those milestones, and the general approach you plan to take.
• Reaction from outsiders to your project must be a mix of “Why did you do that?” and “Oh man, that is AWESOME”.
• It’s fine to have a mental plan going in, to make sure that you’ve appropriately scoped the project so you have a reasonable chance of success, no matter how unreasonable the project itself may be.
• Continuing the effort from a previous Crazy Project Weekend is acceptable, even though it violates some of the previous rules.

The first Crazy Weekend Project was over Labor Day Weekend, in September 2009.  I decided that it would be a good use of my time to build a robot out of Lego Mindstorms that could play a game of Pong on an unmodified Atari 2600 and win.  Initially, I had planned to make it play a perfect game of Pong, but I didn’t get there.  Full details here:  https://mathpirate.net/log/category/crazy-weekend-project-1-pong-robot/

The second Crazy Weekend Project was over Thanksgiving 2009.  It was limited, in that I only dedicated about half the day to the project (The other half being dedicated to XBox 360…).  There were two goals for this project:  Put together a speech recognition system capable of recognizing and responding to a set series of commands, as well as write a system that could identify faces.  Speech recognition came together very quickly, so the bulk of the time was spent trying to make Wesley Crusher disappear from episodes of Star Trek: The Next Generation.  Full details here:  https://mathpirate.net/log/category/crazy-weekend-project-2/

This will be my third Crazy Weekend Project.

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. ((And if you don’t know what Blaster Master is, well, you just need to play more NES games.))  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.

I spent some time last night diving back into the world of Lego Mindstorms, trying to solve one of the outstanding problems from the Pong Robot that I built a few weeks ago.  If you recall, one of the biggest problems I had was with precision movement of the servo that was rotating the paddle knob.  It would consistently overshoot the mark or simply not move at all.  This was very frustrating, and I tried several different movement techniques before coming across one that worked well enough…  Until I recharged the batteries.

One of the problems I had was that I couldn’t tell the motor how far to rotate.  I had to tell it to turn on, then, sometime later, tell it to stop.  This meant that processing delay could have been the cause of most of the overshoots.  By the time the stop message had gotten to the motor, the paddle had gone too far, leading the movement processor to send a command telling the paddle to move the other direction, where it promptly overshot the mark heading in the other direction.  What I needed was to tell the motor exactly how many degrees to turn.

Now, I tried the degree method before, sort of.  Unfortunately, I was limited to fixed angles that were set up in the Lego Graphical Program that I wrote (If you can call drag and drop programming “writing”…), so it didn’t end up working that well.  In general, it overshot worse using these angles.  And movements got stacked up in the queue, so it kept moving long after it should have stopped.  All in all, a failure.

I eventually bypassed the program altogether and moved to using the Mindstorms Direct Command API, which lets you send commands to the NXT over Bluetooth.  Using Direct Commands, I had slightly more control over when to start and stop, although the primary benefit was turnaround time.  All of my logic was centralized in the same C# application, rather than being spread between C# and the Lego Graphical Program.  I could tweak a setting and run and see what it did, rather than drag a couple of program bricks around, redeploy, run the program on the NXT, then run the desktop app, only to find out it didn’t work at all.  However, what I didn’t find was any way to provide a movement angle at all.  There were all sorts of settings, like power, braking mode, even some used for twin motor locomotion.  But no “rotation angle”.  So, I made do with simply adjusting the power.  The “success” of the robot was less a factor of going where it was supposed to go than luck in having it correct from its mistakes fast enough to hit the ball.

Obviously, luck wasn’t going to cut it.  The robot would perform reasonably at the standard speed, but as soon as you bumped up the speed a notch, it didn’t stand a chance.  I could tell that it would have problems if I wanted to expand to games like Breakout, where the speed is variable in normal play, and there was no way that the current movement would work for games like Kaboom!, where you have to have pinpoint movement control and be thinking five moves ahead to have any kind of hope of survival.

Yesterday, I decided to look at the problem again.  In reading what other people had written about the Direct Command API, I discovered that the semi-obscurely named “Tacho Limit” parameter that I’d been ignoring was actually the number of degrees to rotate with the movement command.  Great!  That’s precisely what I needed.  Except for the minor fact that this Tacho Limit was obeyed like someone on a crotch rocket obeys the speed limit.  Somewhere around the Tacho Limit the motor would sort of decide to stop moving, but would then coast for another random length of time.  At full power, this random length of time tended to mean somewhere in the neighborhood of 720 degrees.

Two full revolutions past the mark is not my idea of precise.

And then, on top of that, there’s a counter in the motor that keeps track of how far you’ve wanted to go and how far it’s actually gone and won’t move again until you’ve told it to move past where it landed.  Which means, if you tell it to rotate 360 degrees, and it goes 1080, the motor won’t go anywhere at all until you’ve told it to move more than the difference of 720 degrees.  And then, it only travels the difference over the error.  So, needless to say, quite frequently, I was telling to move and it refused to go anywhere, and when it finally did decide to move, it didn’t move anywhere near the distance I wanted it to go.

Basically, I would have gotten more precise movement if I’d handed the paddle to a three-year-old that I’d pre-loaded with PixyStix.

I don’t understand it.  I’ve seen the motor move fast and stop with such force that the entire assembly shudders.  Why is it just gradually coasting to a stop now when it should be moving precisely 30 degrees.  Not 34, not 37.  30.

I’m back in the graphical environment now, trying to drag and drop a program that’ll give me more control over the rotation, but which will hopefully cause the motor to actually stop when it’s supposed to stop.  I’m debugging using a happy face icon and a bunch of sleepy ZZzzzs.  This is all I will ever be able to think about the next time someone tries to show me a UML diagram.

And speaking of stopping, I really need to stop now, given that I happen to have something that could be described as “work” in the morning.   Just like the motor overshoot, this could easily continue for another hour or two if I let it.   When I’m half asleep at the morning meeting, I don’t think the excuse “I was playing with Legos all night” is gonna fly…

21-9!  Take that and dance, 30+ year old technology!  I’ve got two words for you:  Inyo and Face!

Video coming soon.

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?

Booyah!  Chew on that, Stella!

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.

I’m not sure that playing nice and writing a proper Mindstorms program is going to work out.  It’s too difficult to tweak the motor settings on the fly, and drag and drop programming isn’t exactly conducive to setting up a complex command system where you send a packet that contains all of the motor settings.

So, I’m going to try something new…

You see, Mindstorms are popular because they’re not locked down.  Lego has released many technical documents on how the NxT Brick works.  Those documents include highly useful things like this:

 

I can simply send a message directly over Bluetooth that tells the motor what to do.  That way, all of the control is on the PC application side, where it’s easy to tweak settings.

Hopefully this will make things run happier.

I just tried a suggested alternative method of playing.  Rather than moving to the predicted point, why not try to track the ball, like the CPU paddle does.  Well…  Here’s what happened with that attempt:

1. Paddle shoots WAY up.
2. Paddle overcorrects WAY down.
3. Paddle is off the screen.
4. System is confused.

Not terribly successful.  I’ll try again with lower motor settings, since it seems like the motor has kicked up the power since last night for some reason.

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