Like a lot of people, I spend a lot of time trying to balance the need for exercise and fitness with the desire to sit on the couch and play video games.
So I figured why not combine the two.
To start with I picked up a treadmill – this one is a manual treadmill as I want its movement to be dictated by my running, not by some electric motor.
There is a small control panel on the treadmill which provides some statistics. It is completely optional and not required to use the treadmill. It gets it’s power from a separate battery supply.
Although this is not particularly useful to me, it does indicate there is some type of encoder in the treadmill assembly to measure these values. Before even taking the treadmill part I can surmise that this is most likely either a magnet and reed switch assembly, a hall effect sensor, or a rotary encoder.
Once I got the treadmill, I could see a simple 2-wire lead from the base of the unit through to the control panel, connected with a 3.5mm jack.
I breadboarded a small breakout so that I could connect the oscilloscope and see what kind of signal was being passed.
This revealed that there’s 2.5v being sent down the line (tip of jack is positive), and that the signal would transition between high and low as the treadmill was used, and the frequency would increase as the speed increases.
In it’s most basic form, if we can translate those state transitions to key presses, that should work.
There was however a whole lot of noise in the signal which seemed to be caused by resonance in the treadmill frame, as there would be severe jumps simply by my touching it.
Initial Implementation
An initial attempt to use an Arduino and have the signal trigger interrupts wasn’t successful due to the noise, and filtering attempts became quickly time consuming.
The requirement for the filtering and the requirement for it to be an input device led me to a MakeyMakey development board.
This board is advertised as an educational toy, that allows users to turn anything into a key. In order to do this it provides a significant amount of signal processing and filtering. So in other words, exactly what I’m looking for.
This means that very little is required on the software side, as the Makey Makey presents inputs to the computer the same as a keyboard would, and applications generally will not notice any difference.
By simply connecting a crocodile clip from the tip of the 3.5mm jack to an ‘key’ on the Makey Makey, and connecting the body of the jack to the ground of it, that is already enough to get some response. Every pulse sent by the treadmill gets interpreted as a key press and release by the Makey Makey.
Problems
The only problem with that is with the treadmill in normal operation, the pulses (and therefore keypresses) are so quick that they do not translate real world movement into equivalent in-game movement.
 |
| With the treadmill running, the red marks show the time that the key is pressed. The two ‘bursts’ of movement on the treadmill appear as a total of 14 short keypresses. |
Instead, either the rapid tap causes the character to barely move, or if the treadmill stops when the signal is high, the character runs at full speed without needing any further movement on the treadmill.
 |
| The treadmill stopped when the signal is high – making it look like the key is held down indefinitely, even though the user is not running |
What I want to do is to bring the game input more “in step” (ha) with the movement of the treadmill, so that the same two bursts of treadmill movement would look more like the following:
 |
| The two bursts of activity are represented as two longer keypresses, as if the key were held down for the time the treadmill is moving |
To do this, I forked the source repository of the Makey Makey project, and made some edits.
The changes are mostly in the updateInputStates function, and focus on the ‘right’ key on the Makey Makey, as I will be using a side-scroller game to test.
Demo
To demonstrate what this change does, below are two screenshots which represent a few seconds of continuous running on the treadmill.
The first is with the treadmill connected to the “Up” key, which is unaffected by the code changes. The input is shown as repeated press and release events.
The second is with the treadmill connected to the “Right” key, which is the one that I have changed.
The impact is shown any as press events, up until the point that the treadmill stops. This is the same as if the key were held down.
The test code is based on KeyEventDemo – the only change is that I removed the KeyTyped event as it is not relevant to this exercise.
 |
 |
Implementation
Unfortunately there is no way of determining the treadmills direction of travel as it was obviously not designed for that, but in a game I may want to change direction.
What I have done is a workaround for now is I have made the same change for the left key as I did for the right and have wired the treadmill to the Makey Makey like so:
This means by simply flicking the switch I can change direction. In a subsequent moment of inspiration I swapped the switch for a pair of reed switches and a magnet attached to one of the cross-fit handlebars that are on the treadmill - allowing for the direction to be controlled with the left lever.
I have also wired a simple momentary switch to the space key to allow my character to jump.
For now this whole contraption is held together by screw terminals and crocodile clips as it is only a prototype and is a platform I want to expand on in future.
The Game
For this initial experiment I wanted to use a game where input is limited, as a proof of concept.
To keep with the theme of running and speed Sonic the Hedgehog seemed like a suitable choice.
I will be running this on a PC with a Sega Genesis/Mega Drive emulator.
Please note the various copyright and legal complexities around the use of emulators and ROMs - the short version is that you should not use ROMs of games you don't own.
I actually own two copies of the game - an original Mega Drive cartridge, and a PC version as part of the "Sega Mega Collection Plus". It's just that the Mega Drive emulated ROM is easier to interface with.
The end result:
