P-Compin aint easy.
Test your sensors early in the process.
Code is sooo much more reliable than real world. In code, you have complete control.
When Tom assigned us to make a network Pong controller, I thought it would be cool to make a Pong Controller out of a ping pone paddle. I figured I’d use a range finder to determine the distance someone had moved the paddle from center, then have the code determine how to position the virtual paddle.
Seemed simple. It was not. Lets start at the begining:
Getting the Xport to talk to the server was non-trivial. It didn’t help that I lost my arduinos and had to borrow an Arduino Mini (thanks Corey), which I’d never worked with before. More importantly, when working with something as complicated as Xport, a USB to serial device, and an Arduino (with limited understanding)…well, let’s just say there are a lot of places to screw up. I finally got it all working together and ping the Pong Server (sorry for the terrible pun). Here’s proof:
Now, it came time to make the controller. With my limited construction skills it came out like this:
I found the range finder I wanted to use wasn’t reliable when I left it out in the open. I was dissappointed, but I decided to build a little box to contain it. This meant that you’d have to move your paddle inside the box instead of like a real paddle, but with I had to work with there weren’t many options. Here’s the box:
Not pretty, and as it turned out, not effective. The values I got from the range finder were better, but I still got enough noise that my orginal idea wouldn’t fly. I tried several averaging techniques to counter act the noise, but nothing seemed effective enough. Combined with server lag, it was clear I had to alter my approach.
Initially, I made it so that if the paddle was moved to the left of center, it sent a left signal to the server, if it was to the right, it sent a right. This was pretty effective, however, it was also kinda lame. The problem was that it was nearly impossible to center the paddle, thus it was constantly moving left and right.
So, I wussed out, put the paddle on a pot, and decided to try to pick up a personal challenge Tom had set down for me: Hack the server.
I didn’t want to change the server code. I considered that cheating. However, if I used the options given to us by the server and simple made a client that took advantage of that…well, that’s fair game. In my Xport struggles, I noticed that if you unplugged you Xport without letting the server know you were disconnecting, it would keep your old paddle there. Even if you reconnected to the server, the old paddle remained. I called these old paddles “zombies” and I decided to use them to my advantage.
The approach goes like this: set up a button that sends the connect string to the server. Connect to the server. Position the paddle strategically. Then, reset the Xport. When the Xport is running again, send the connection string again. Position the new paddle. Repeat until you have an invincible army of paddles defending your side.
Look at all the 102s! Those are all me!
The lesson as always: I’m a better coder than I am a Pcomper. Perhaps some day that will change…
Lessons reinforced: Buying things is easier than building them.
Lessons relearned: Common Ground is your friend.
So, Tom wanted us to show him our Pcomp skills. He’s probably familiar with mine, since he taught me everything I know.
After some consideration, I decided to make a Thinking Cap. One of the things Tom taught me was that it’s easier to buy something than build it. So I bought a hat and one of those as Seen On TV Light Bulbs (though I ended up going to 3 places to find one…)
I disesembled the light bulb and found that there was a simple switch that triggered it. I removed the switch, replaced it with a subtle one of my own (that also sent a digital in to my Ardunio).
I had the Ardunio send a serial message to Processing that triggered some crazy WebCam action to demonstrate how the world can be changed by the power of a great idea.