The button pressing motor just hit the button so hard that it knocked the paddle out of the cage AND knocked the entire motor assembly off the base.

I think I need to tune the power levels a bit…

NXC has a basic serializer.

Flatten(obj) gives you a “string” representation of the item you pass it.

UnflattenVar(str, obj) will take the “string” and turn it into an object.

I put “string” in quotes, because it’s really just bytes, so you’re not getting a text representation of the object, it’s just moving a byte array around.  Still, it’s very useful.  It’s letting me pass a small packet to the NXT with one Bluetooth message, instead of three.

So, I finally got a new paddle cage put together.  While the old one was all stylish and minimalist, this one looks like it’s built out of Legos.  Real Legos, too, not those lame Technic beams.

Features include gearing to hopefully reduce the impact of the motor overrun, a button pressing motor (Not yet active), and flexible support arm for the angled knob.

I wrote a test program that will repeatedly rotate it like crazy and hopefully shake out the bugs.  Here’s video of it in action.

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

Of course, what kind of test would it be if it didn’t end in catastrophic structural failure?  Unfortunately, the camera was not rolling for the chaos, but I assure you it was about as spectacular as it could be given what it is.  Anyway, I did record the aftermath.

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

The flaw is fairly obvious in the first video, there’s some tall connector blocks on the spinner that kept knocking against the gear bar.  Eventually one of them caught and didn’t knock loose, but the motor spun the 360 anyway.  It kinda popped loose for a bit, then shuddered, before eventually collapsing.  I’ve since fixed the problem ((I was going to fix it before even running it the first time, but I wanted to see if it would cause a catastrophic structural failure…)) and had it run for upwards of ten minutes without issue.

It feels good to have some forward progress.

For those curious, the paddle in the cage is one of the Indy 500 Driving Paddles with a free 360 degree range of motion.  That’s how it was able to spin all it wanted without running into the range limitation that’s in a normal paddle.

I’ve managed to get a centered spinner arm built and a new cage that can handle a button presser motor.  I still have to figure out how to get the spinner arm positioned so that it can fit on the knob correctly.  Atari Paddle knobs are at a slight angle, and Legos are not at a slight angle, so that’s going to be a problem.

My paddle gripper isn’t centered on the paddle knob.  I hadn’t noticed that before.  That would be why the paddle worked better when it wasn’t constrained in the cage:  It could move where it needed to be to counteract the off-balance.

I’m going to have to try to fix that…

I’ve been able to write an NXC application that will turn the motor a certain number of degrees, then stop instantly.  No waggle.  Trouble is that the number of degrees it goes doesn’t seem to be directly connected to the number of degrees I tell it to go.  It’s always a little bit more.  For instance, I tell it to go 10 degrees and it goes 23.  I tell it to go 360 degrees and it goes 420.

But, it seems to be consistent.  It seems to overrun by the same amount each time you tell it to go a certain distance.  That means that I should be able to compensate for it.  However, if a ten degree turn causes a 13 degree overrun, that really sucks.  I don’t know that there’s going to be a way to compensate for that, given that most of my movements will need to be less than 10 degrees.

Maybe it’s time to learn a little something about gears, too…