There are many types of randomness, but for my money they can be divided into two broad categories, which I'll call 'stochastic' and 'orthogonally causal'.
By stochastic randomness, I mean to indicate the traditional connotation of randomness used in the sciences: a condition where a system's future state is not derivable from its current state. In other words, in a stochastic system, there is some element that is non-determinative, that can't be predicted even with a perfect understanding of the forces at work, for example quantum indeterminacy.
The second form of randomness is more modest, but also a bit harder to explain. By 'orthogonally causal' randomness I mean the use of data that is unrelated to a given situation in order to produce information or behavior that seems random within the context of the given situation. In other words, even though the unrelated data may be determinative within its own context, its determining rule is completely alien to the context in which it's being used and hence it appears non-determinative. This form of randomness is preferred in many practical applications where generating hard-to-predict data can be useful; for example, many computer programs use the current time in seconds or some other piece of arbitrary data as a random seed when generating passwords or suprising behavior in game AIs.
This week, Jason Aston and I set out to build a piece for Living Art that embodied orthogonally causal randomness: a basketball-shooting robot that aimed based on the price of the stock market.
Within the system of aiming and shooting a basketball, the price of the stock market — structured and patterned though it, arguably, may be — appears highly non-deterministic. The spatial relationship between the shooting arm and the basket is almost completely orthogonal to the changes in the DOW, hence aiming based on that metric will appear highly random.
Aesthetically, we liked this combination for a number of reasons. Firstly, it combined two cliched signs of hyper-masculinity: high-powered finance and competitive sports. Secondly, the outcome (a small robot arm repeatedly failing to shoot a ball into a miniature hoop and, in the process, hurling balls all over the place) had a certain pathetic quality that seemed to resonate with the sorry state of the international financial system the last few years.
A video showing the evolution and final form of the bot:
A Random Project: Hoop Dreams with Wall Street Vim from Jason Aston on Vimeo.
As you can see in the video, we started designing the project by experimenting with a rotary solenoid. We hooked the solenoid up to a bench supply and tweaked the voltage until we started seeing it snap back and forth vigorously. For our model, that turned out to be about 25 volts.
Next, we worked on prototyping a ball-loading mechanism that would allow the repeating motion of the solenoid to fire off a series of miniature basketballs. That's the wood-paneled box the arm is thwacking early on in the video:
After some experiments, we settled on a design that used a hinged door and a single spring to restrain the balls while still allowing the arm to pull them out. Finding a spring with just the right force and placing it far enough back on the lid that it would simultaneously hold the balls in, not be too hard for the arm to pull-down, but not allow too many balls out with each throw was a challenge.
Once we'd gotten a prototype that we thought would work, we went over to K-Mart to shop for balls. We ended up settling on ping pong balls. Even though the don't look like basketballs, they were light enough and about the right size for our arm.
We brought the balls back to the shop and proceeded to rebuild the loading mechanism to the appropriate dimensions for the ping pong balls. We also mounted it and the throwing arm on a stand so that their relative position would be just right for getting a consistent launch.
As you can see in this picture, we left the throwing arm on a hinge so we could make small adjustments to its angle. After many experiments with it, we ended up concluding that we actually needed to tip the arm and loader back at an angle to get the balls to fly out at a basketball shot-like angle and to reduce the frequency of multiple firings that could result from two balls slipping out when the arm pulled down the trap door.
You can also see, in that picture, the basketball hoop we built. We looked at some pictures online and then Jason sanded a piece of balsa wood into the shape of the backboard. We built the rim out of a piece of red-shielded solid core wire that we soldered to itself. The cutting board base gave a nice court texture to the piece.
Once we'd gotten this shooting mechanism down, we had to work on the aiming. We used the H-Bridge lab instructions and the Arduino Stepper library to connect up a Nema 17 from Makerbot. We did the basic stepper hello world of getting the motor moving back and forth in both directions and then proceeded to work on getting in the stock market data.
To accomplish this, I transcribed the weekly closes of the Dow Jones Industrial Average over the all of 2008 and 2009 from Google Finance. Then, I manipulated the data a bit with Ruby to generate an array containing the price changes from week to week during that period. We copied and pasted this into our Arduino sketch, did some mapping so that drops in the market would correspond to proportional counterclockwise moves and rises to clockwise ones. Before we knew it, the stepper was spinning back and forth with the rising and falling (mostly falling) fortunes of the market.
Finally, all that remained was mounting the throwing arm and ball loader on top of the stepper. This turned out to be slightly trickier than we imagined.
First we tried using a lazy susan ball bearing. The idea was to remove the burden of actually holding up the weight of the arm platform from the stepper so that it only had to put force into rotating things. We mounted a wooden piece on one half of the bearing and attached a shaft collar that we'd drilled out to fit the stepper:
This let us mate the stepper to the top half of the bearing and still have the bottom half free to mount on a base. Jason then cut a square hole out of a piece of wood to restrain the stepper so that its rotation would be fully transfered into the assemblage above.
However, when we got the whole thing mounted in place, we found that the two sides of our box weren't precisely even and so the bottom bearing surface wasn't exactly perpendicular to the stepper's shaft. The result was that as the stepper tried to turn to one side, tension would increase dramatically and it wouldn't be able to continue. This effect far outweighed the benefits of relieving the weight so we removed the lazy susan bearing and mounted the arm platform onto the shaft directly, using the restraining mounting we'd built as a seat to channel the weight directly through the motor into the box as a whole:
Even though things weren't perfect and the motor would wobble and make minor complaining sounds, the setup worked well enough and we decided to finish up. We closed up the box around the circuit so that the hoop could sit at the same level as the shooting arm and the ugly electronics would be less visible:
Finally, at the very last minute, we experimented with trying to add a display screen in Processing that would show the percentage change to the stock market each week in sync with the arm's moves and shots:
The idea was to hint at the stock market-derived nature of the aiming data without actually declaring it directly. As if the percentage change was some kind of metric the machine was using (very poorly) to try to correct its own aim. Unfortunately, we didn't have time to get this piece of the project working before the demo (trying to integrate a serial handshake in 10 minutes at 9am just before presenting isn't the greatest idea).
As you can see in the video above, the actual performance of the machine in class was a blur of flying ping pong balls that sent our classmates to giggling and scurrying around the room.
The best feedback we received in the critique was that the we should work on the timing of the turn, aim, fire loop more in order to bring out more of the personality of the machine. In other words, if it turned, waited deliberately (as if carefully lining up its shot), then fired, then waited again (as if watching the result with interest), and then turned, etc. it would be much easier for people to project intention and other human qualities onto it which would make the drama of it missing so badly more effective.
Another interesting point, with which I'm not sure I agree, was that people wanted to see it using real time stock market data.
They also wanted us to build a more human looking arm around the throwing arm, something we intended to do, but simply ran out of time for with the engineering challenges around mounting the stepper.
Jason and I are going to continue to work on this project some in the coming weeks, hopefully sorting out some of the mechanical problems with the stepper and making the whole thing more aesthetically attractive.
]]>
