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:

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

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