Category — Crazy Weekend Project 3: Atari Robot 2

No no no, that just won’t do.  Won’t do at all.

I think the idea will work, but the implementation needs refinement.

And my pi looks like a stick figure cow.

Let’s see if this works…

I’ve got just under 7 hours to make this work.

This is the last day.  I have to get things working today or it’s over.

I never got the motors to behave last night.  The closest I came was by telling the robot to immediately reverse the motor when it hit the target angle.  That seemed to stop it at the right point, but then the reverse bounced it back a ways.  So, the waggle is only a problem when the motor stops.

Of course, in a game like Kaboom!, the motor doesn’t have to stop.  If I can work out the math to have the motor continuously tracking at variable speeds, that just might work.

I also never got the occasional blips taken care of.  I was too busy with the motors to even care.  I should probably put the motors back how they were for now, then try to get this part sorted out, as it’s the bigger problem at the moment and will be a problem however the motors run.

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:

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

Can you spot the bug here?

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.