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

See, here’s the problem.  It moves the distance I’m expecting very fast, a full 360 degrees in half a second, then it wastes another half second waggling to a stop.  And it’s always wasting about half a second.  It can do 90 degrees in about .2 seconds, then it loses another .5 seconds coming to a stop.  The movements I need for games are going to be less than 90 degrees most of the time, too, so the problem gets worse.

You absolutely cannot be losing half a second with every move and still expect to be able to play a game well, especially a game like Kaboom!

Because everything’s better in slow-motion, here’s what it looks like at 1/10th the speed:

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

It’s like it’s doing a binary search for the correct point.  If I could get rid of the waggle, I’d probably have something useful.

I ended yesterday worse off than when I started.  When I started, I had a robot that could play a decent game of Pong.  I finished the day with a twitchy robot that wasn’t good for much of anything.

That kind of progress isn’t going to lead to success.

I’m not up against the wall and out of ideas yet.  It could be that I’m just pushing it too fast or that I’m doing a hard brake instead of a gentle ease out.  Maybe there’s something else I can do that will work better.  Do I have to try gearing it?  I’ve seen videos of people doing crazy things with Mindstorms, so I know these motors and this hardware is capable of more than what it’s giving me.

Well, back at it.

So, that’s what was wrong with the rotation.  I was reading from the “Yes/No” pin, instead of the “Logic” pin.

You see, while the Logic pin gives you a  Boolean true/false value, the “Yes/No” pin gives you a Boolean true/false value that just happens to always be false.  Maybe it’s about time I look into something like NXC instead of the graphical Lego Programming tool…

I moved it to the right pin and now it looks like the motor is moving both clockwise AND counter-clockwise.

I still think it’s trying to kill me, though…

At any rate, enough for today.  I’m already about a day behind plan, so staying up any longer trying to make the robot less scary isn’t going to help much.

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.

When attempting to test out a robot creation, it really helps to turn on the robotic creation first.

So, my code on the PC was sending “Go!, direction, angle” because the code on the NXT was expecting “Go!, direction, angle”.

Turns out that’s wrong.

Since the NXT is expecting “Go!, direction, angle”, you obviously have to have the PC send “direction, angle, Go!”.  Because that’s what makes sense.

Whatever.  It’s working now.

So, I fix the bug with the waiting and I realize there’s another bug close behind.  It’s now properly waiting for the action to complete, the trouble is that the action is the last action I told it to do.  In other words, I start it up and tell it to rotate 10 degrees and it does nothing.  Then I tell it to rotate 360 degrees and it goes 10.  Then I tell it to go 180 and it goes 360.

The NXT program is supposed to wait for a “Go!” signal, then read two packets from the same mailbox for values to pass to the motor.  The mailbox is a queue, so if it’s reading the Go! signal, then racing to the motor command before the other two messages arrive, then the mailbox should be out of sync for the next Go! signal.

But that’s the scenario that makes the most sense here.  It gets a “Go!” then goes straight to the motor before the next two packets arrive.  So it reads zero and does nothing.  Then the next Go! code comes in.  By then, the values have been written from the first request, so they’re what gets sent to the motor.  But that would make it out of sync.  The second Go! code would be reading a boolean, then there’d be a number where a bool should be, and finally, the bit that should have a number will get the string “Go!”.

So…  WTF?

The checkbox says “Wait for Completion”.  I would think that means that it would wait for completion before proceeding.  So why is it immediately continuing and sending me the “Done” signal?  The motor acts different if I have the box checked or not, so I know it’s doing something.  I’m just not sure what it’s doing.

I think it’s using a different definition of completion than I am.

I’m sure this made sense to me at some point.

Pong is not enough.

The Atari Robot is bored.  Pong is undeniably a classic game, but it’s classic in the same way Shakespeare is.  Everyone looks at it and praises it, but they really want nothing to do with it because it’s so old and dull.  Back and forth, back and forth.  For hours.  Even to lose a game takes twenty minutes sometimes.  And it’s not really pushing anything to the limit.

The Atari Robot wanted more out of life.

At first, it talked at great length about a kitten object that it had fallen in love with and wanted to search the world for.  For a time, this plan was compelling, however, my apartment is strictly full of non-kitten objects, and acquiring a kitten-object for this endeavor would not have been wise.

Atari Robot was sad.

It looked around at other famous robots.  There’s the robots that build cars, but there’s no romance or excitement in that.  Then it found what it wanted to be.  One of the most well known uses of robots in the world today is in bomb disposal.  Excitement and adventure, becoming a bomb disposal robot would be sure to make all the female Atari Robots fall for him.  However, my apartment is strictly full of non-explosive objects, and acquiring an explosive object for this endeavor would not have been wise.

Atari Robot was sad.

Then I realized that there was a way for Atari Robot to live its dream and keep all my fingers and not get arrested.  I have a bomb disposal simulator that Atari Robot could use.  Atari Robot could join the Bucket Brigade to stop the Mad Bomber!

Atari Robot was happy.