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. 

Resistor coding for the colorblind

With the help of one of my more color savvy friends, i was able to label all of my resistors with twist ties. So far it seems as though the metal in the ties does not affect the circuit in any way, but i think i'll go back and relabel them with masking tape, just in case.

Check one two...

Testing blogspot's mobile update feature. This should be nifty since i already use my phone to take the pictures. Btw, the included picture is from Example 6A, which isn't quite working right, I'm guessing because I've got the wrong resistor hooked up to the sensor. This would be much easier if I weren't red/green colorblind...

The Evolution Will Not Be Televised...

...but it will show up on your blogroll. CSCI 4560 (Evolutionary Computing) has been taking up a lot of my time lately. And it's been fairly kicking my butt. But I will persevere, and it will be well worth my time. Why? Because it could be instrumental in the final design of the pedal powered video game controller.

In case you don't know, the term "Evolutionary Computing" is a lot more like it sounds like than it sounds like. When I first heard about the class, I assumed it was either a history-like class, or dynamic programming of some sort. Most people I've told about the class think it must be something other than the obvious -- computing which mimics evolution and genetics. Think about it: If you need to solve a problem that involves a large number of variables and a complex goal, searching through the possible combinations can be a nearly impossible task. Even designers can be wrong about where to optimize.

But if you think of each variable as a "gene" which can have a range of values and think of an individual as the result of a combination of these variables, you can create a population of "individuals" which compete, breed, and mutate, and improve.

For example, if I were to design a bike and I wanted to maximize power output and minimize cost and weight, given various combinations of wheel size, materials used, resistance, etc., those various variables (genes) would make up the individual which is the bike, and the "fitness" of the bike could increase when power output increases and decrease when cost or weight increases. You can look for individuals within a given range or which break a record or... well, anything you want. This is a typical example of a "knapsack problem" (maximizing value while minimizing cost), which happen to be one of the prime uses for evolutionary computing.

Of course, more research is in order to determine where to start, but it's possible that this could design a controller which outputs power enough to rival other methods while being cheap enough to rival with other video game peripherals...

Fade in, Fade out

Example 4 showed us how to fade an LED in and out (like a Macbook while it's sleeping, I hesitate to exemplify). This is essentially simple. The Arduino's analog outputs allow you to send an integer between 0 and 255 which corresponds to pulse-width modulation, which in turn corresponds to the brightness of the LED. So looping an integer variable from 0 to 255 and back with a 10ms delay allows the LED to fade in and out every half second or so. I have no pictures because I got ahead of myself and started building the next circuit, but luckily the circuit necessary for Example 5 happens to combine the circuits from Examples 4 and 3. Let's take a look:

Rather a quintopus of a circuit

Though it's hard to distinguish given the quality of my cell phone's camera (Dirty South), the button circuit from the last example has basically been pushed to the right and connected to an LED circuit. This is an example of how basic elements can be joined together to make a more complex whole.

So now, when you press the button, it turns on or off. When you hold the button while turning it on, the brightness changes. This is done by checking to see whether the button has been held for longer than 500ms and whether the light is currently on.

Next time, we control the LED based on some more continuous analog input: a light-dependent resistor.

And after that, we connect a few LEDs to the internet and alter them based on RSS info... and then on to the meat -- the Vitamaster itself.

More Pushbutton Action

Moving right along, Exercise 3 involves a button that stays on after you let go of the button. Sounds simple enough, but the exercise is a three-step trial and error process:

In trial one, if the button is pressed down, you change the state of the light from on to off or vice versa:

void loop(){
    val = digitalRead(BUTTON); //read input value and store it

    if (val == HIGH){ //if there is voltage coming in from the button
        state = 1 - state; //change the state, which later is used to
    }                      //turn the light on or off 

    //...etc...
}

But since instructions are executed so rapidly, if the button is held for more than a split second, the "state" of the light will change as many hundreds of a second as you held it. The next example attempts to fix this by making sure there has actually been a transition:

void loop(){
    val = digitalRead(BUTTON); //read input value and store it
    if ((val == HIGH) && (old_val == LOW){ //check for transition
        state = 1 - state;
    }                     
    
    old_val = val; //now remember whether the button was pressed
    //...etc...
}


This works to some extent, but there is still a problem: when you press a button, the spring within it bounces and contact is made and broken a few (short) times in a fraction of a second. The final revision of Example 3 includes "simple debouncing" by including a delay of between 10 and 50 ms (I used 25) after the state change. The result is a working pushbutton light.

Push button (and release), receive light!

Example 3 complete!

Getting Started with the Arduino

In order to use the Arduino, I must first learn it. Luckily, Make Magazine and the cofounder of Arduino put out a nifty book entitled Getting Started with the Arduino. And someone was also nice enough to put a parts package together on Amazon, containing everything you'll need to go through the book.

A nifty starter pack

The first exercise went by so fast I forgot to take a picture. It was basically the "Hello World" of the circuit world: make an LED blink once per second. Exercise 2 would be nearly just as simple, as long as you're not color deficient. I understand that resistors are color coded because they were too tiny to print numbers on, but trying to differentiate between brown, red, and green paint on a 2mm surface under lamp light at night (and on a beige table no less) is no easy task for a red/green colorblind like myself. But I made it work. I'll have to get a second opinion on the rest of my resistors, and keep them sorted and labeled. 

Anyway, Exercise 2 implements a pushbutton for the light, which stays on as long as the button is held. Welcome to your keychain penlight. Mystery solved. 

Light off...

Light on!

That's all for now! Join us next time, when we look into the guts of the Vitamaster itself.

Hacking the Vitamaster: Introduction

Throughout this semester, I will be turning a 15+ year old Vitamaster exercise bike into a videogame controller. In particular, I will be measuring the rotational speed of the wheel and using that data (via an Arduino Uno) to control some aspect of a videogame. If time permits, more control aspects will be added to the bike. It would be nice to do more than control forward motion, after all.

[image: the Vitamaster in all its haggard glory]

This blog will act as my research journal, a semiformal confidant through the good times and bad, tracking my progress and/or struggles, and possibly acting as a guide to others in some fashion.