When I wrote my first update, the Metal Race Game was just getting started. I'd played around with multi-directional control of motors with an h-bridge and done some tests of construction methods for the race course itself with soldered paperclips.
Since then, I've made a huge amount of progress, even getting to a basic functioning prototype I demoed in class this morning. To my surprise, building the mechanical part of the game turned out to be dramatically more difficult than the electronic part. After an afternoon getting motors to move, I spent two weeks trying to turn their motion into the useful work I needed for the game.
This post is largely a log of the obstacles I encountered in that process and what I learned along the way. At this stage, the result is still relatively sketchy (mostly due to my poor construction and fabrication skills), but it's far enough along that the idea I was aiming for comes through. I plan on continuing to refine the game in the coming weeks as a platform for learning the additional mechanics and construction skills I discovered I so sorely lack in the course of putting together this prototype.
First, a reminder as to what we're building here. It's a physical game based on the old school TI-83 calculator game, RACE. RACE looks like this:
and my initial sketch for how to achieve a physical version looked like this:
It's two DC motors, one from a CD-ROM drive I dissected and one from Radio Shack. The CD-ROM motor moves a triangle-shaped paperclip up and down under the player's control while the Radio Shack motor scrolls a course made of paperclips across its plane. The player has to navigate the triangle (the "car") so that it doesn't crash into the edges of the course.
Picking up where I left off last time: after getting the first draft of the motor control circuits working, I set about building the actual race course. I measured the maximum vertical travel range of the CD-ROM motor and then soldered together a series of paperclips to build a maze track that would travel no more than that maximum distance (pictured above).
Once I had these two separate pieces of metal, I soldered them onto a support system along the plan of my original drawing: vertical support pieces connecting the track to a rectangular frame so that both sides of the course would be one continuous piece of metal, but the whole thing would still be open on one side so the 'car' piece could enter the track.
The resulting metal course was very fragile and wobbly, so I hot glued it to a wooden frame I'd put together from scrap wood.
In my first draft, I'd connected the RadioShack motor up to a long band from a printer. When I started trying to use that setup to move around the framed course, I quickly found that the band slipped rather than actually being able to move an object of anything like the size I was going to need. Also, the band repeatedly fell off of the motor and gear. I needed a very different approach to making the horizontal motion.
After some frustration, I consulted with Zeven, a fellow ITPer, who recommended pushing the frame along via friction. In other words, I would place the frame atop a low-friction surface and place the motor (with some high-friction rubber around it) flush against its side so the motor's rotation would force the frame along. I decided to give this a shot.
Unfortunately, in this setup, there was too much friction between the frame and the 2x4 it was resting on for the low-torque DC motor to be able to move it. The motor would make a high-pitched whine and heat up and the frame would just sit there. In response to this setback, Zeven suggested mounting bearings into the 2x4 to reduce the friction enough for the frame to move. So, I was off to Paragon Sports to pickup some skateboard bearings. I routed big slots in the top of the 2x4 to mount the bearings.
At first, I mounted the bearings too flush to the top of the 2x4 and they made very little difference. Once I got them to sit up above the level by about a quarter of an inch, then the frame really started to slide smoothly. I fixed the bearings in place with dowels passed through the 2x4 and hot glued (hot glue was them main and nearly only construction technique for this project).
At this stage the frame would actually start to slide when I applied the motor to it:
As you can see from this video, though, it was extremely unstable. If it wasn't for the spare pair of hands holding the frame in place, it would fall over instantly. So, now the task was to figure out a way to guide the frame along as it rolled. Also, I'd need to attach the motor to the 2x4 so that it would be in the right position to apply consistent torque to the frame.
A lot of trial and error later, I settled on the idea of building a backing wall to guide the frame along. This complemented a side guide built from a piece of scrap wood that held the frame against the motor itself, keeping if from falling the other direction towards the motor.
I mounted that back piece on two triangles of wood and positioned it close to the 2x4 with the frame on it. I left it unattached so that it wouldn't cause too much friction against the frame. The problem with this was that it meant I was constantly adjusting it to get it in the correct position.
In order to further improve the stability, I attached a run of stranded wire to two hot glued paperclip pieces across the back board. Then I attached a loop of paperclip to the top of the frame to act as a kind of ski lift hook.
This combination of efforts meant that I finally had the frame moving smooth enough to test out the multi-direction control of it with the motor. Unfortunately, at this point I discovered that powering the h-bridge with the 5v from the Arduino (as I'd been doing up to that point) wasn't enough to overcome the reduced friction of this new setup. But, when I plugged the motor directly into the 5v power rail from the Arduino, it moved the frame smoothly:
I deduced from this that I needed to feed the h-bridge with a higher voltage power source separate from the Arduino, something that turns out to pretty much be correct practice anyway, I rapidly learned. I picked up a 9v battery and an adapter at Radio Shack and used those to power the circuit, which got things moving smoothy for the time being.
Now it was time to figure out how to mount the motor in place. The motor needed to be positioned relatively precisely: tight enough to move the frame but not so tightly that the friction would overcome its limited amount of torque. After a failed experiment and much frustration in trying to hot glue the motor directly to the 2x4, I decided to hot glue the motor to a flexible piece of metal which I then in turn glued to the 2x4. This made for enough flexibility to make the small position adjustments necessary to get the friction just right. Also, the metal's springiness meant that it held the motor in place even again the rough and non-square edge of the frame's wood (which I filed down as smooth as possible but which was still pretty uneven).
After getting the horizontal motion working somewhat smoothly, I started working on the vertical one. This came much easier. I hot glued the CD-ROM motor to a strip of scrap wood which I then attached to a triangular base piece so it could be anchored in position with the 2x4.
Once I had that in place, I hooked up the vertical motor to the second side of the h-bridge and soldered up two arcade-style buttons to control it.
I programmed the Arduino to move the motor up when one button was pressed and down with the other. I used PWM pins on the Arduino so that I could move the motor at less than its full possible speed to make it possible for a player to control its motion:
Later on, I modified the Arduino code to stop the motor when neither button was being pressed to eliminate the sliding effect you can see here. One minor surprise to me was the fact that it took a lower PWM value to achieve the same speed moving down as up. Gravity is a factor.
Here's what the circuit looked like at this point:
Controlling both motors worked great so long as the horizontal motor wasn't under any load. As soon as I brought the frame back into play, 9v of external power was no longer enough to move both motors.
A side note about powering the h-bridge: I noticed around this stage that the h-bridge would get alarmingly hot during testing. With Robert Carlsen (an ITP 2nd year)'s help, I looked through the data sheet and discovered that it recommended attaching a heat sink to the ground pins on both sides. Further, we discovered that the h-bridge has an internal thermal shutoff mechanism that is supposed to stop its operation if the chip reaches 70 degrees celsius. That made me much less worried about the heat issue, especially since it was only becoming alarming when I was running the motors continuously back and forth for long periods, something very unlikely to happen under normal game operation. We also tried a series of experiments with powering both the Arduino and the h-bridge from the same 9v battery via the Arduino's Vin functionality. This seemed to make a small difference in the rate at which the h-bridge would heat up, but not a dramatic one. It also resulted in my accidentally plugging in the USB cable to my computer without unplugging the 9v power supply, causing an overcurrent notice that was so bad that my machine shut itself off. Thankfully, nothing was harmed in the process, but the danger of doing this repeatedly during debugging seemed to outweigh the advantage of heat reduction in the h-bridge.
Above all, reading the h-bridge data sheet told me that the part could take motor power voltages up to 30v, which meant that I could upgrade to a 12v wall-wort supply in order to get better simultaneous performance out of both motors without worrying about frying the chip.
I went down to the NYU computer store, picked up a 12v power brick and an adapter header. I soldered some wires onto the header, and plugged it into the h-bridge where the 9v had been attached.
Suddenly, things started working! I had enough power to both move the vertical motor and to push the frame along. I soldered a car-shaped paperclip onto the vertical motor and was in business:
Here's some video of the game in action:
You can see from this clip that the horizontal frame motion is still very erratic. I have to push and prod it to get it going and then once it does start it moves way too fast. The game is playable but would be much improved if this aspect was smoother and more consistent. Also, I'm not actually taking advantage of the h-bridge control of the horizontal motor since the frame almost always comes off it's track at the end making it impossible to drive it back into position with the motor.
Moving forward to refine this project, I plan to see if I can rebuild the mounting for the frame so that it moves more smoothly and consistently. Secondly, I plan to add crash detection: wire up the frame and the car to one of the Arduino's digital input pins so that I can detect when the car crashes in order to trigger a buzzer or some lights to indicate failure. Finally, I've been exploring stepper motors which are much more complicated to use but have a bunch of properties that might make them more appropriate for this project including higher torque at low speed and the ability to stop and change direction more rapidly.
More generally, I'm conceptually excited about the idea of bringing virtual interfaces and aesthetics, especially old fashioned, low res, or 8-bit ones, into physical form. I'm planning a trip up to the Retro Arcade Museum in Beacon which has a bunch of these kinds of games as well as some amazing electromechanical arcade games that create amazingly fluid illusion and game experiences out of these kinds of mechanisms. Here are a couple of examples from a recent BoingBoing post of some of the more inspiring ones that could be sources for this kind of work: Sega Moto Champ
and the Bally Hill Climb: