That’s it.  I’m calling it.  This Crazy Project Weekend is over.

And it’s a big truck of fail.

The biggest problems are the motors.  They just don’t do what I tell them to do.  If they did, this would be a different story.  But I’ve spent over three days tweaking the motors and the robotics and I just can’t get it working.  Maybe I can get a Stelladaptor and try tweaking it with direct feedback.  Maybe I’d be able to do continuous smooth motion if I could have tracked all the bombs properly.  Maybe I just don’t know what I’m doing.

At least I was able to identify the playfield elements and get the computer to tell what the next move should be, even if I couldn’t actually get it to make that move.  The basic recognition and logic was a lot easier than it was for Pong, mainly because trajectories didn’t really matter.  However, I wasn’t quite able to get the bomb tracking/prediction logic working, which would have reduced the tendency for the robot to get distracted temporarily and miss a bomb.  The full tracking also would have made it possible to detect patterns and move smarter.  I also get the feeling that there’s something already in OpenCV that would have taken care of the object detection and motion tracking for me.  That library is so big and I’m not a computer vision expert, so I don’t really know what’s there or how to use it all.  The book and the documentation aren’t always enough.

And then that virus.  Stupid virus.  Make me waste half a day because the bloody computer stops working.  THAT WAS AWESOME.

The segmented auto-calibration thing did work.  I was able to adjust the robot power and swap out gears and the calibration generally figured out the new pixel/degree ratio.  If the motors were more consistent, then it probably would have worked better.  At any rate, that’s a decent technique that I’ll have to remember for the future.  And I’ll have to clean up the code for it, right now it’s kinda messy.

In the end, I did not accomplish what I set out to do.  The best score the robot ever got was 63, and that was a fluke.  And I didn’t even get close to trying to get it to play on a real TV.

I’ve spent the better part of the last two hours trying to look for a way to make the robot slightly less homocidal.  I came up with someone else who needs to do the same thing I do, that is, rotate the motor 45 degrees exactly and not have it go all wobbly or insane. He’s got loads of graphs, but no solutions.  Apparently there’s another firmware which does really great, if you want to put a non-standard firmware on the NXT and risk bricking the brick.

Then there’s another guy who’s produced a 37 KB executable that’s suppose to do quick and precise rotation.  Never mind that it’s 37 KB worth of code for an embedded system with limited RAM.  Never mind that it’s tainted by the GPL (And the “You Suck Microsoft” GPLv3, at that).  If it does what I need, I’ll use it.

Except…  It doesn’t do what I need.  In fact, it appears to have absolutely no redeeming qualities about it.  The motor still waggles, pretty much the same amount as the normal command.  On top of that, it makes the brick beep.  WTF?  Why do I want the brick to beep when I’m moving a motor?  Then it’s got some questionable coding practices, including encoding command messages as ASCII characters which have to be parsed and interpreted, because obviously, you want to add all the overhead you can when you’re dealing with embedded systems and time-critical operations.  And it’s an executable, not a library, so if there’s anything else you want to do on the NXT side, you’re screwed.

So, I still don’t have happy movement.  I think I’m just going to tone down the motor power a bit and hope it behaves better.

I only have one day left to get it right.

On the one hand, I’ve solved the delay problem.

On the other…  Well…  This:

[mediaplayer src=’/log/wp-content/uploads/RobotRampage.wmv’ ]

IT’S OUT OF CONTROL!  RUN FOR YOUR LIVES!

It made it through Round 1 and got a score of 56 points.  Time to take a step back and analyze what I’ve observed.

• The biggest problem is losing track of the bomb.  It will be on track to catch the lowest bomb, when suddenly the detection will skip a beat and it’ll take off across the screen for something else and can’t get back fast enough to catch the bomb.  I have to fix this first.  I’m pretty sure I have outlier detection from the Pong game that I can reuse here.
• The segmented calibration that I described back on the first day seems to be working fairly well.  That’s where the robot moves the paddle knob a known number of degrees, then the program sees how far that moved the buckets on screen, and calculates how many pixels a degree is.  This lets the program know that to catch the bomb that’s 70 pixels away, it will have to rotate the paddle 30 degrees.  I suspect that I will have to tweak the algorithm a bit, though.  Mainly, I think it will need to do several calibration turns to refine the numbers.
• The response time is going to be a killer.  I have little doubt that the motor itself can move the paddle into position fast enough.  When it moves, it zips across the screen.  The problem is that it doesn’t get moving as fast as it needs to and there’s an unacceptable lag between commands.  I think I might still be seeing an echo of the waggle.  It’s not as visible, due to the weight on the spinner assembly now, but I think that delay is still there.  If I can fix some of the other issues, I suspect that the response time is going to prevent the robot from getting past around level 3.
• The NXT has an inactivity timer.  The robot turned itself off in the middle of a game.  Gotta take care of that…
• I don’t want to keep hitting the button to start a round.  I’m going to have to implement the button press.  Unfortunately, implementing the button press means I’ll have to change around how the PaddleController class works.  It’s a dirty hack right now, I gotta clean that up.
• I like that Kaboom! is a much faster game cycle than Pong.  With Pong, I couldn’t always tell what was wrong right away.  Sometimes it took a minute or two to get the ball in a situation where something went wrong.  I’d implement a fix and try again, and again, it would take a minute or two.  Kaboom! doesn’t last that long.  The games at this point are less than a minute long, sometimes much less.  If the robot is going to lose, it’s going to lose fast.  It’s not going to end up in a cycle where the ball keeps bouncing around between the same two points over and over and over for five minutes.  If a game in Kaboom! lasts five minutes, then it’s an amazing success.

In that game that it got past round 1, it ended up getting 56 points overall.

Doubled its score in just a few minutes.  If I can keep on this rate of improvement, it’ll be awesome in no time!

Okay, now just 2993 more points to go for the prize!

AH CRAP.

I’ve got it under control for now.  It doesn’t have wheels, so it can’t go anywhere, but we can’t take any chances.  Does someone have a spare Unintended Self-Awareness Containment Unit that I could use before this gets out of control?

I think I’m going to have to put together a finite state machine for the robot.  The robot for Pong had essentially two states:  “Playing” and “Totally Flipping Out”.  I need to do a better job than that for this one.

Here’s the basic states for Kaboom!:

• Bombs on screen:  Track the lowest bomb.
• No Bombs on Screen: Press button.
• No Buckets on Screen:  Hit Game Reset switch.

At this time, it won’t be able to hit the Game Reset switch itself, so it should probably put a notice on the screen for human intervention.  ((And I don’t want to give it the ability to hit the reset switch itself.  You teach it how to do that and you never know what it’s capable of.))  For the “No Bombs on Screen” state, it’s going to have to hit the button, then wait before trying to hit the button again, otherwise it’ll hit the button a second time, before the bombs start to fall, and it’ll lose precious reaction time.  When the bombs are on the screen, it’s going to have to be careful and make sure that it doesn’t get fooled by blips where the lowest bomb disappears for a frame.  However, it can’t be too careful, since it’s going to have to move to the next spot as soon as it catches a bomb.

For now, I’ll get the “Bombs on Screen” state going, since that’s the one that’s important.  I can hit the button myself for now, as long as I’m careful to keep my fingers clear of the spinning bricks.