One Dimensional Pedal Poetry

The preliminary proof-of-concept run is now published:



So far, you can only control one dimension: rotational speed controls the speed at which you fly through Dasher. As a result, the text is a bit wonky, but fun nonetheless!

The resulting text from that run:

Like to ME,' said not officiate".This corporates mcliest called but fromulous mention of the horse then with has becauses, and see, Shallades, was 

Which I'm pretty sure comes straight from Finnegan's Wake.

The Final Countdown

Did I mention I can control the mouse position with the reed switch now? Yep. Using the Java robot class, I can position the mouse on the screen based on the incoming RPMs from the rotating reed switch (I'll edit a screen cap in in a bit). Right now it's ugly -- I need to work a smoothing function in there, but I'm happy that it works at all.

And have I mentioned exactly what's going to come of this? Meet Pedal Poetry, where predictive text meets stream of consciousness, and the need for speed meets the need to read. How fast can you pedal and still produce sensible language?

From Wikimedia Commons

Pedaling controls your position on the x axis, which controls the speed at which you fly through an alphabetical landscape that adapts to your words. Two buttons control movement on the y axis, which controls which box you ultimately fly through. You can stop, but you can't backspace! ...because I have no way of detecting which direction you're pedaling in.

There are only a few aspects left to hammer out:

• Button control: I've got the button board set up, looking like a lofi NES controller or something, and I've got the Arduino to relay button presses to the computer, but I haven't done anything with them yet.
• Smoothing: Right now, RPM changes translate to jolty changes in the mouse position. I'll be setting up a control loop to smooth things out
• Reassembling the bike: It's been much easier to prototype while the rotation mechanism is on my desk rather than in the bike. So far I've been "pedaling" by spinning the switch by hand. I'll need to reassemble the bike and figure out a decent way to mount everything on it safely.
• Putting it all together: The batch file that runs the input/mouse movement program will also need to load Dasher in fullscreen mode. And then it's time to pedal bikes like Percy Bysshe.

I'll be posting progress updates throughout the day, so keep an eye out. Today is the last day of finals, but I'll probably keep tweaking things long afterward. It's not over yet!

Success and Anxiety

Oh joy of joys! I just tested the reed switch with the Arduino, and it works! I was pretty nervous about that one, since I hadn't had any luck with the multimeter, and I wasn't entirely sure what I would do if the reed switch was out of commission. Observe:

The magnet is far from the reed switch, and the circuit is broken.  Light off.

The magnet is close to the reed switch, and the circuit is complete. Light on (the lower light).

I wrote a simple Arduino sketch that checks for a transition in the reed switch. If the switch goes from off to on, it sends a single bit to the serial port. Otherwise, it does nothing. The RXTX package (see my last post) is event-driven, meaning it is not constantly polling for input and instead only does something when it receives data. I took this one step further and decided to send data only once per rotation, giving the program basically the lowest possible overhead: one bit per rotation. Next I'll be adapting my Robot and serial test classes (did I forget to mention those?) to take in that serial data and move the mouse cursor accordingly. 

The only thing I'm really afraid of right now is reassembling the bike itself. It's got a pretty complicated internal structure; obviously they didn't intend for any tampering. When I disassembled the bike, I carefully arranged the pieces in a protective case so that I would remember which went where. And then my cat, the adorable little agent of chaos, knocked the case onto the floor, jumbling the pieces within. Wish me luck! At the very least, I'll have a working example of a rotating reed switch controlling mouse cursor position within Dasher, and a broken bike.

Keaton the Cat, proponent of entropy and avid consumer of the arts.

Total Eclipse of the Smart

I've been writing Java since high school, but I've never personally used Eclipse before this project -- only in passing, to help a friend through CS 1301, in a simple setting and already properly configured. I do think the "spellcheck" feature is nifty, but for certain applications I find its interface to be cumbersome. I'm using it now a) spellcheck, like I said, and b) because I know that the UGA CS department uses it, and in case I ever need to teach/grade a course that uses Eclipse, I'd like to be familiar with it.

There are only two main libraries available for serial communication in Java -- The Java Communiations API Extension, which is apparently not well documented or supported, and RXTX, which is used by Arduino and is included in the folders included with the Arduino IDE. I opted to use the latter, since I already had copies on my harddrive and the Arduino website features a nice tutorial on interfacing with the Arduino and RXTX. Perfect! The tutorial goes into extensive detail on usage: The rxtxSerial.dll needs to be included in the PATH, and the RXTXcomm.jar needs to be included in the CLASSPATH.

The latter is not always so easy with Eclipse. JAR files, folders, and projects are all added to the CLASSPATH seperately, and there are seperate CLASSPATH setups for building and running. This is all detailed (for a slightly old but still followable version) here, but following these instructions wasn't enough for my purposes. The author of these instructions had similar qualms:

It seems to me Add Variables, Add Libraries, and Add JARS all add collections of classpath elements that are defined inside Eclipse, but I don't know their differences. When I specify classpath in any IDE, I like to explicitly spell out Jar files and directories, without using any IDE-specific artifacts. I suppose the whole purpose of having them is to reuse them in other projects, but I find it's pretty unrealistic due to various jar version differences.

I don't care about the difference between a jar file and a directory, both of them are just an element in the classpath. I like the fact that NetBeans combine them into one single Add JAR/Folder button.

I actually had no luck until I broke down and just made a batch file to run the SerialTest program (similar to that found in the Use Sample Code section of the interfacing tutorial, except I put the dll in my main jdk folder, and the jars in my source folder), and I think that's how I'll keep it. Instant success, after hours wasted trying to interface with Eclipse when I already had working code. So if I do ever end up teaching a Java course, I think I'd give the following advice: Sure, use Eclipse for the simple stuff, and use it as a write-time error checker to save time on compiling, but for anything complicated, don't let your code be a slave to your IDE; just use the command line.

Digital, not Analog

I finally dug into the bowels of the Vitamaster, and found this little number. Our motor theory was wrong. Rather than depending on analog voltage input from a motor in the wheel, the Vitamaster uses what is misleadingly called an "electronic watch." I'm just glad they printed the patent number on that thing, or I may never have figured it out. Behold:

Getting this out without destroying anything proved difficult, but probably not as difficult as putting it all back together

Though patent descriptions read like dry nested story puzzles, it looks like this device is basically two rotating magnets and a reed switch, turned by that uppermost blue arm when the bike's wheel spins. Which (I assume) would mean we would actually be getting digital readings -- an on/off pulse -- and reading the pulse rate. Every time the wheel rotates, the magnets in the rotating trough pull the reed switch together, completing the circuit and thus sending a brief "on" signal once (or twice?) per rotation. Apparently mine is missing one magnet. I'm not sure if/how this affects performance.

Given my earlier (failed) attempt at reading voltage with a multimeter, this now makes more sense: A reed switch, when connected to an ohmmeter, should read either zero or infinity, depending on whether it's closed or open, respectively. I'll have to run another test tomorrow. 

Specifics, In General

So I (finally) hooked the Vitamaster's motor up to my multimeter, and the results were...

(drumroll)....

Nothing. Maybe it's just me, but I tried pretty much every combination and got absolutely no reading. Which probably just means I need to get a new motor. Fair enough. It is over a decade old.

But in the meantime, I've spent a lot of time thinking about how to control a video game with this thing. The thing is, there aren't a lot of games which use a gradient for motion control. In most games, you're either moving or you're not. In some, you move faster depending on the tilt of the joystick, but even then there are generally just two or three different speeds you're able to move. On top of that, joysticks are generally USB HID devices, and the Arduino is only capable of delivering a serial stream on its own. People who want to use Arduino as a USB HID device seem to pair it up with a Teensy controller, but I'm not so sure I want to emulate a joystick anyway, so I might just save the money and instead simulate mouse input. I have already successfully turned analog input into a serial stream, so writing a small program that can translate serial input into simulated mouse input shouldn't be a problem. The problem is... what game should I control?

The thing is, using a bicycle as a game controller is not practical for general usage. Kids won't be buying this thing in order to work out while they play Halo, as far as I can see. For this thing to be any amount of fun, games will have to be platform specific. While the inspiration for this whole thing came from Wii Fit (specifically the biking game, where you pretend to pedal while standing on a board), I don't see hacking the Wii Fit board as a viable solution for the current problem. I could put pressure sensitive pads or accelerometers on the pedals of the bike to simulate the steps taken in Wii Fit, but figuring out how to communicate with the Wii Fit would be brand new research, and with my level of experience, I don't see that happening by December.

So what can I do? I can start by syncing analog voltage to mouse position with the Java Robot class and demonstrate this through Dasher, which is not a game exactly, but then design a rudimentary game where player velocity is based on a mouse coordinate. After all, this is the basis of something bigger, so I'm really building some basic elements which will later be elaborated upon.

Analog Input

Example 6 of Getting Started is the first example to use analog input rather than digital input, specifically from a light meter. Now, instead of getting on/off impulses from a button, we will be taking values in the range of 0-1023, representing voltages from 0 to 5 volts.

In Example 6A, we still used a digital output, in that we used the input from the light meter to control how fast an LED blinked. Specifically, the input value was used directly as the delay value, so that increasing the amount of light present slowed the blinking of the light. No pictures for that, since it's rather difficult to photograph the rate of a blinking light. Given that it was some ten or so lines of code and used (almost) the same circuit as that which I used for Example 6B (pictured below), I can assure you that it worked. I did have to toy with the resistance a bit though, since I worked on this one before I labeled all of my resistors. The lower the resistance, the slower the light blinked. Makes sense!

Example 6B used both analog input and output. This time, the input from the light meter directly controlled the PWM of the LED, just like in Example 4:

     val = analogRead(0);     //sensor is at pin 0
     analogWrite(LED, val/4); //send that (modified) value to the LED!

So when the meter is getting full light...

...the light is superflous!

And when the meter is getting no light...

...the light is pointless!

So for any practical purposes, this is about the opposite of what you would want, but it does demonstrate a direct relationship between analog input and output. By the way, I believe all you would need for a practical reworking of this (say, a night light or solar powered porch light) would be the reciprocal (4/val), and an exception case for val == 0, though val never seems to come out as 0 for some reason.

Next time, we'll be sending data back to the computer through a virtual serial connection, which, believe it or not, completes the basic knowledge necessary to make this bike work: analog input routed through USB to a computer.