A Crazy Project Weekend is when I take an extended weekend and dedicate my time to a AAA project:  One that is Achievable, Awesome, and slightly Abnormal.  There are a couple of rules, made up on the spot this instant, guiding the Crazy Project:

• Work must be done within the limited weekend time frame.  You cannot begin any concrete work prior to the time window, and if you do not complete by the end of the time, you have failed.  You may do some preparation ahead of time, such as feasibility research or acquiring necessary materials, however, nothing should be built and there should be no written plans.  The point is to see what can be done in five days, not what can be done in five days and a couple of hours an evening for three weeks prior to those five days. 
• It must not be something you would otherwise normally do.  Setting up a website with a blog and a bunch of pictures of the dog doesn’t count.  Cleaning the garage doesn’t count.  It must not be something that anyone would normally do.
• You have to learn something.  If you know exactly what you’re doing going in, then it’s no fun.  One of the central pieces of the project must involve something you’ve never worked with before.  There must be several moments where you have no idea what in the hell you’re doing and wonder what you’ve gotten yourself into.
• You must post regular progress updates throughout the weekend, detailing what you’re doing and what you’ve done.  Viewers must be able to get a glimpse of your thought process and understand what you’re going through.  You should talk about initial goals and milestones, obstacles you see on the path to those milestones, and the general approach you plan to take.
• Reaction from outsiders to your project must be a mix of “Why did you do that?” and “Oh man, that is AWESOME”.
• It’s fine to have a mental plan going in, to make sure that you’ve appropriately scoped the project so you have a reasonable chance of success, no matter how unreasonable the project itself may be.
• Continuing the effort from a previous Crazy Project Weekend is acceptable, even though it violates some of the previous rules.

The first Crazy Weekend Project was over Labor Day Weekend, in September 2009.  I decided that it would be a good use of my time to build a robot out of Lego Mindstorms that could play a game of Pong on an unmodified Atari 2600 and win.  Initially, I had planned to make it play a perfect game of Pong, but I didn’t get there.  Full details here:  https://mathpirate.net/log/category/crazy-weekend-project-1-pong-robot/

The second Crazy Weekend Project was over Thanksgiving 2009.  It was limited, in that I only dedicated about half the day to the project (The other half being dedicated to XBox 360…).  There were two goals for this project:  Put together a speech recognition system capable of recognizing and responding to a set series of commands, as well as write a system that could identify faces.  Speech recognition came together very quickly, so the bulk of the time was spent trying to make Wesley Crusher disappear from episodes of Star Trek: The Next Generation.  Full details here:  https://mathpirate.net/log/category/crazy-weekend-project-2/

This will be my third Crazy Weekend Project.

Of course, I kept going a little bit after I told myself to stop, but I ended up with something that sort of resembles progress.  I was able to get it to turn pretty much the number of degrees I told it to turn, which is good.

Trouble is that now the motor appears to be doing a binary search to find the right angle.  I tell it to go 90, and it goes to 110, then 80, then 95, then 87, before eventually landing on 90.  It could just be a matter of overpower.  Perhaps if I drop it back a notch, it’ll hit the target more cleanly.  At any rate, it is moving a certain number of degrees when I tell it to.  Eventually…  I don’t know what this will look like in the game, though.

I still need to add another line to control the motor power remotely.  I also need to look into the ability to send a packet of information across, because I don’t want another Bluetooth recv block for every input variable.  That has to be expensive.

I spent some time last night diving back into the world of Lego Mindstorms, trying to solve one of the outstanding problems from the Pong Robot that I built a few weeks ago.  If you recall, one of the biggest problems I had was with precision movement of the servo that was rotating the paddle knob.  It would consistently overshoot the mark or simply not move at all.  This was very frustrating, and I tried several different movement techniques before coming across one that worked well enough…  Until I recharged the batteries.

One of the problems I had was that I couldn’t tell the motor how far to rotate.  I had to tell it to turn on, then, sometime later, tell it to stop.  This meant that processing delay could have been the cause of most of the overshoots.  By the time the stop message had gotten to the motor, the paddle had gone too far, leading the movement processor to send a command telling the paddle to move the other direction, where it promptly overshot the mark heading in the other direction.  What I needed was to tell the motor exactly how many degrees to turn.

Now, I tried the degree method before, sort of.  Unfortunately, I was limited to fixed angles that were set up in the Lego Graphical Program that I wrote (If you can call drag and drop programming “writing”…), so it didn’t end up working that well.  In general, it overshot worse using these angles.  And movements got stacked up in the queue, so it kept moving long after it should have stopped.  All in all, a failure.

I eventually bypassed the program altogether and moved to using the Mindstorms Direct Command API, which lets you send commands to the NXT over Bluetooth.  Using Direct Commands, I had slightly more control over when to start and stop, although the primary benefit was turnaround time.  All of my logic was centralized in the same C# application, rather than being spread between C# and the Lego Graphical Program.  I could tweak a setting and run and see what it did, rather than drag a couple of program bricks around, redeploy, run the program on the NXT, then run the desktop app, only to find out it didn’t work at all.  However, what I didn’t find was any way to provide a movement angle at all.  There were all sorts of settings, like power, braking mode, even some used for twin motor locomotion.  But no “rotation angle”.  So, I made do with simply adjusting the power.  The “success” of the robot was less a factor of going where it was supposed to go than luck in having it correct from its mistakes fast enough to hit the ball.

Obviously, luck wasn’t going to cut it.  The robot would perform reasonably at the standard speed, but as soon as you bumped up the speed a notch, it didn’t stand a chance.  I could tell that it would have problems if I wanted to expand to games like Breakout, where the speed is variable in normal play, and there was no way that the current movement would work for games like Kaboom!, where you have to have pinpoint movement control and be thinking five moves ahead to have any kind of hope of survival.

Yesterday, I decided to look at the problem again.  In reading what other people had written about the Direct Command API, I discovered that the semi-obscurely named “Tacho Limit” parameter that I’d been ignoring was actually the number of degrees to rotate with the movement command.  Great!  That’s precisely what I needed.  Except for the minor fact that this Tacho Limit was obeyed like someone on a crotch rocket obeys the speed limit.  Somewhere around the Tacho Limit the motor would sort of decide to stop moving, but would then coast for another random length of time.  At full power, this random length of time tended to mean somewhere in the neighborhood of 720 degrees.

Two full revolutions past the mark is not my idea of precise.

And then, on top of that, there’s a counter in the motor that keeps track of how far you’ve wanted to go and how far it’s actually gone and won’t move again until you’ve told it to move past where it landed.  Which means, if you tell it to rotate 360 degrees, and it goes 1080, the motor won’t go anywhere at all until you’ve told it to move more than the difference of 720 degrees.  And then, it only travels the difference over the error.  So, needless to say, quite frequently, I was telling to move and it refused to go anywhere, and when it finally did decide to move, it didn’t move anywhere near the distance I wanted it to go.

Basically, I would have gotten more precise movement if I’d handed the paddle to a three-year-old that I’d pre-loaded with PixyStix.

I don’t understand it.  I’ve seen the motor move fast and stop with such force that the entire assembly shudders.  Why is it just gradually coasting to a stop now when it should be moving precisely 30 degrees.  Not 34, not 37.  30.

I’m back in the graphical environment now, trying to drag and drop a program that’ll give me more control over the rotation, but which will hopefully cause the motor to actually stop when it’s supposed to stop.  I’m debugging using a happy face icon and a bunch of sleepy ZZzzzs.  This is all I will ever be able to think about the next time someone tries to show me a UML diagram.

And speaking of stopping, I really need to stop now, given that I happen to have something that could be described as “work” in the morning.   Just like the motor overshoot, this could easily continue for another hour or two if I let it.   When I’m half asleep at the morning meeting, I don’t think the excuse “I was playing with Legos all night” is gonna fly…

Full Video

I’m working on a YouTube friendly condensed version at the moment.

[Edit: Here’s the YouTube version.]

21-9!  Take that and dance, 30+ year old technology!  I’ve got two words for you:  Inyo and Face!

Video coming soon.

I am really starting to hate those robotic motors.  Sometimes they won’t move at all, and other times they’ll overcompensate for all the times they don’t move and end up flying across the screen when the ball is two pixels away.  They just do not want to be controlled.  The battery change has given them new life.  Actions that were once just right are now wildly off the mark.

Stupid real devices.  Does anyone know how to attach a debugger to the laws of physics so I can see what’s going wrong?

Now I just need to make the robot recharge its own batteries, perhaps even make it run off solar power…

Booyah!  Chew on that, Stella!

I’m not sure that playing nice and writing a proper Mindstorms program is going to work out.  It’s too difficult to tweak the motor settings on the fly, and drag and drop programming isn’t exactly conducive to setting up a complex command system where you send a packet that contains all of the motor settings.

So, I’m going to try something new…

You see, Mindstorms are popular because they’re not locked down.  Lego has released many technical documents on how the NxT Brick works.  Those documents include highly useful things like this:

 

I can simply send a message directly over Bluetooth that tells the motor what to do.  That way, all of the control is on the PC application side, where it’s easy to tweak settings.

Hopefully this will make things run happier.

I just tried a suggested alternative method of playing.  Rather than moving to the predicted point, why not try to track the ball, like the CPU paddle does.  Well…  Here’s what happened with that attempt:

1. Paddle shoots WAY up.
2. Paddle overcorrects WAY down.
3. Paddle is off the screen.
4. System is confused.

Not terribly successful.  I’ll try again with lower motor settings, since it seems like the motor has kicked up the power since last night for some reason.