Random header image... Refresh for more!

Well, that was fun.

The more complex a system becomes, the more interesting it is likely to be when a catastrophe strikes.

Take, for example, a cup of water on an empty table.  When the cup gets knocked over, the water spills out on the table and isn’t terribly exciting.  Let’s replace the water with some Hawaiian Punch.  Now you knock it over and you get a red pool on the table and a red stain left behind once you clean it up.  See?  More interesting.

So let’s add a bit more to it.  Like, say, a computer.  You know, keyboard, mouse, tower.  Stuff like that.  And speakers.  And a rat’s nest of cabling to connect it all together.  Change the table to a computer desk.  Put a nice light colored carpet underneath all of it.  We can’t forget the power strips on the ground behind the set up, either.  And, oh yeah, a slight incline making the desk higher in the front.

Now tip over the cup.

The mouse pad, keyboard, speaker cable, and tower effectively contain all of the liquid in a small space on the desk.  Nothing spills out the front, nothing spills out the side.  However, let’s not forget the incline.  The incline causes what would be a containment fence on a level surface to become a funnel, which swiftly and efficiently drains the pool of sugary liquid through a narrow space between a section of the desk and the computer tower, and out the backside of the desk, where it produces a red cascade directly onto the rat’s nest of wiring, the power strips, and the white carpeting below.

Yeah.  That was -AWESOME-  You just can’t anticipate that kind of failure.

April 17, 2010   No Comments

Achievement Unlocked: Big Truck Of Fail

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.

March 1, 2010   No Comments

Well, That Could Have Something To Do With It…

public CvPoint GetAverageVelocity()
    double avgX = BombPositions.Average(bomb => bomb.X);
    double avgY = BombPositions.Average(bomb => bomb.Y);

    return new CvPoint((int)avgX, (int)avgY);

And that’s why I don’t work for NASA.

March 1, 2010   No Comments

Bug Tracking

That ain’t right.

And I only have five hours left.

March 1, 2010   No Comments

Robot Rampage

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

On the other…  Well…  This:


March 1, 2010   No Comments

That Could Be A Problem

Can you spot the bug here?

public void ButtonDown()
    Rotate(NxcMotorPort.OUT_B, -50, 45);
public void ButtonUp()
    Rotate(NxcMotorPort.OUT_B, -50, 45);

February 28, 2010   No Comments

7 > 0

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

February 28, 2010   No Comments

Stronger Than Anticipated.

The gripper piece of the spinner assembly is a bit stronger than I’d anticipated.

That wasn’t supposed to happen…

February 28, 2010   No Comments

Achievement Unlocked: RTFM

“Any controller that uses the Atari digital joystick standard will work with these products. Included are the Atari 130/400/800/2600, Commodore 64, Sega Master System, and others. Analog controllers like the paddles are not supported.


Well…  So much for that idea.  Unless I can get a Stelladaptor in the next hour somehow, I think that plan is out.

February 26, 2010   No Comments

“Takes Directions”: Needs Improvement

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.

February 26, 2010   No Comments