So, all this talk about it, and all these videos of the thing going wrong, and yet I haven’t actually posted a video of what the thing does when it’s actually working right?  Well, here you go.

And the YouTube version:

It’s a lot more subdued than when I started this morning.  The robot I had in the morning could have torn your hand off.  Now it’s much more mellow.  (Of course, I’m afraid that it’ll kill me in my sleep, but whatever…)

Two days remain, and there is still much to be done.

21-13, the best score yet.  I tweaked the motion yet again.  I went back to continuous motion, for starters, since the angular was constantly starting and stopping over and over and over and over, slowing it down.  I think part of the main problem before was the message buffering.  The same thing that was happening with the LEFT LEFT LEFT stuff I talked about earlier was happening in continuous motion mode, too.  The solution here doesn’t have to be async, though, which is nice.  Instead, all I have to do is not send the same message more than once in a row.  You can tell me LEFT LEFT LEFT LEFT LEFT all you want, and I only tell the robot a single LEFT and I leave it at that.  It’s now hardly ever overshooting the mark, and when it does, it can usually recover with a quick nudge back in the right direction.

Also, with this game, the robot was briefly in the lead!

So, now, why isn’t it winning?  It’s supposed to be a perfect robot, why is it still losing to a 30 year old processor?  Two big apparent reasons:

1. It’s not moving fast enough.  I need to alter it so that it will race from one side to the other when the projected point is far away.
2. It’s not going to the right place.  The trajectory projection isn’t perfect.  It’ll sometimes miss the mark.  I’ll need to go back and work on that a bit to improve the prediction.

Still, I’m very pleased with what’s come together in the last hour or so.  The day wasn’t going so well until then.  Right now, I’m at the point where I’d hoped to be by about 2 PM…  The problems today have all been little stupid ones that can only be fixed by experimentation.  There hasn’t been much problem solving, it’s all been iterative failure toward a higher goal.

Changing to basic angles seems to have helped considerably.  The movements are now more controlled.  The problem is, now they’re completely overshooting the mark.  I think the problem is that I’m sending rotate requests with every frame, and they’re getting queued up on the robot.  So, I say LEFT LEFT LEFT LEFT LEFT LEFT LEFT STOP, but it’s hit the mark after just two LEFTs. yet it still runs through the remaining five LEFTs before it sees my STOP.

Looks like I need to go async here and have the robot tell me when it’s done moving before I send it another command.

Here is the panel where I’ve been spending most of my time lately.

When I first did it, the power was way too high, so I made it lower.  The power is still way too high, so I made it lower.  Then it was too low to move.  That’s when I discovered what the “Motor Power” control does.  It’s like traction control in your car, it will adjust power to make the motor move at the same speed, even if there’s resistance.  That got things moving.

Unfortunately, the only movement that happened was the paddle moving off the bottom of the screen and getting lost.  When a paddle gets lost, weird things begin to happen.  The logic ends up royally confused, sometimes thinking that the ball is the paddle.  At any rate, it continues to tell the paddle to move down, so it ends up continually telling the robot to rotate left.  Eventually, the paddle hits the left endpoint of its range, and BLAM!  The spinner assembly kicks a gear and the whole thing keeps on spinning.

 

ktktktktktktktktktktktktktktktktktkt

Computer Vision Processing Game Screen? Check.
Game Play Logic Predicting Ball Trajectory? Check.
Mindstorm Robot Attached To Paddle? Check.
Bluetooth Communication To Robot? Check.
Linking Trajectory Prediction to Robot Communication? Check.

Okay! Let’s go!

Maiden Voyage

Complex Systems Interacting To Produce Failure? Check.

That high pitched noise at the end after it jams is coming from the motor. Motors are not supposed to give off high pitched noises. Additionally, prior to jamming, it forced the potentiometer inside the paddle to skip past the end of its range a couple of times (The loud clicks that you heard). That can’t be a good thing to have it doing…

It looks like videos from my video camera will work in a Silverlight player after all. The screen capture videos don’t work, but I think they’re using some crazy codec. Hopefully these will work for people and you won’t have to download the videos to watch them.

Robot Demonstration

Things Going Wrong

A robot must obey any orders given to it by human beings, except where such orders would conflict with the First Law.

Done.  It’s now responding to my commands and is no longer clicking.

[Click for Video]

It is also very obvious that this is going to be way too fast for the Atari Paddle.  I think I’m going to have to have slow, medium, and fast commands, too.

Miscellaneous Failures In Robotics

Unfortunately, no explosions.  However, parts do fly.  If you pay close attention, you’ll see a gear get thrown during the first attempt, just before everything goes wrong.

Looks like I need to be able to lock the arm in place, or it’ll keep popping up.

The clicking was the motor moving.  I fixed the serial port reading issues, so now it doesn’t hang after the first command.

Unfortunately, the clicking is the motor turning on and turning off very rapidly.  I can send commands and see the servo turn.  Very very slowly…  I think it’s reading the command in one cycle, so it’s sending the command to the motor, then in the next cycle, there’s no command, so it shuts the motor down.  Gotta take care of that.

It’s clicking.  My robot is clicking.

Well, okay, it only clicks once, then it stops responding altogether.

But still, that click means it’s doing something, right?

Right?

I mean, it should be rotating the paddle spinner left or right until I press stop, and it’s obviously not doing that, but a click means that the command is getting to the NXT over Bluetooth, so at least something is working right.  That is progress, isn’t it?

I guess I should actually be reading the return message.  And maybe I shouldn’t be closing the serial port every time.

Whatever.  I’ll look at it in the morning.