Control to interpret speed as axis/button? (pedal to play!)

[vputz]

Okay, I'm trying to find a way to physically justify all my computer gaming, so I'd like a way to interface a stationary bike or treadmill into a game control (lol--hey, it's not a bad idea).

I'd actually be using this more on the computer than on the MAME box, but the challenge is similar and this board was so helpful when I built my CP that I thought folks might have ideas...

I'm thinking that starting with a rotational encoder would be a good start, but then I hit a wall, because of course I don't want the output sent as mickeys or a position going around and around--I want to encode the speed as an axis measurement.  It could be that some sort of PIC is what I need -- but the problem gets worse, because I want to have the output not just as an axis/throttle measurement, but also have the option to set ranges to button presses or keyboard outputs (if speed > X then press "walk", but if > Y then press "shift+walk"; you get the idea).  I can find "arbitrary switch or potentiometer to HID device" circuits, but I'm a little flummoxed as to how to encode the speed or write the logic to drive the output (or, I know of at least one board which could do the logic if I wrote an on-computer program to get the signals, but I don't know from there how to insert keystrokes into the input chain or make a "virtual device" which could then serve those inputs...

Any suggestions on this ridiculous idea?  I'm SURE it's possible for me to do this--I just need the big steps (grin)

[MonMotha]

Certainly not rediculous, though I know of no ready-made solution to do it.  I could probably whip up the code required for a USB HID AVR or similar to do it given a little time if you can't find anything at all that's premade.  There are devices with multi-channel ADC inputs and of course plenty of IO for buttons and such, so I wouldn't put it past somebody to have already cooked up a solution, though you may have to look more at devices designed for instrumentation.

The biggest issue is to know what kind of outputs you need and how to get them.  From the sound of it, a rotary encoder could do just fine - a uC could interpret the incoming pulses however required and back out speed or similar from them.  No ADCs needed, then.  If you have incoming voltage or current levels that vary in an analog nature, then you'd need ADCs.  That's fairly easy to deal with, as well (argubaly easier to just map to joystick axes and throw some thresholds on for keypresses).

I'm guessing you can find something that would suit your needs if you look hard enough, but if not, I could do something for you.

[tkuper05]

Hook up two bikes and interface the controls with Track and Field lol.

[Kremmit]

Didja ever stick playing cards in your bike's spokes so it sounded like a motorcycle?  Just stick a leafswitch in there instead. 

[vputz]

Certainly not rediculous, though I know of no ready-made solution to do it.  I could probably whip up the code required for a USB HID AVR or similar to do it given a little time if you can't find anything at all that's premade.

Heh--thanks; I may take you up on that yet, but I'd like to flail around a while and see what I can create.

The biggest issue is to know what kind of outputs you need and how to get them.  From the sound of it, a rotary encoder could do just fine - a uC could interpret the incoming pulses however required and back out speed or similar from them.

That's my current thought, at least, and that's where I'm going to start, maybe encoding things and reading them with a programmable board like an Arduino (www.arduino.cc) or some such device just to get the basic idea down ("Can I read the spinner?")--and then use that device to control a HID controller.  Having two bits of electronics drives the cost up, but it's not like I'm going to be making a bunch of these or anything.

The irritating thing about this is the programmability, because particularly in computer games you never know if games are going to accept keypresses or game devices--or even rarer, if games will accept multiple devices (for example, I may want to play a racing game, steering with the gamepad but taking throttle input from the pedals--well, they're not part of the same controller, so the game goes wonky).

I've even thought about making a generic HID device driver which accepts input from user-space programs, but last time I wrote a device driver I wound up doing a LOT of hard drive recovery (imagine that).  Hey, it got my SpaceOrb working under XP; I can't complain--but I'd rather avoid it if possible.

I'll keep poking around.  Thanks for the suggestions! ("leaf switch in the spokes" indeed, lol!)

[Derrick Renaud]

Hmm...

Playing Lunar Lander on a bike that you have to pedal faster for more thrust.

Interesting.

D.

[vputz]

Playing Lunar Lander on a bike that you have to pedal faster for more thrust.

Hmm--I guess maybe there are some arcade games that this could work for.

At any rate, I may have a partial answer along the lines of MonMotha's suggestion; a fellow has already done the bulk of the "use an AVR as a USB HID device" work (http://www.mindaugas.com/projects/MJoy/), so using that software as a starting point it should be possible to add in some code which treats the encoder as a speed input (or at least calculates speed to use as an input) and do the other logic.  I've written him to see if that sounds reasonable.  Of course, there's still the "learning how to program the AVR chips" problem, but now that I know what's possible, I really must learn; it sounds fun and can't be any worse than writing my "SpaceOrb HID device driver" experiment (lol).

Hmm.  I'm very intrigued now.

[MonMotha]

I'm curious why they used an ATMega8.  Atmel sells devices designed specifically for USB (the cool thing is that you can program them over USB, too).  I'm guessing those parts weren't out when that design was done.  I'd be interested to see how they're doing the USB on there...people don't usually bit-bang USB (it's electrically difficult to do other things as well).  His FAQ addresses this somewhat, but I know digi-key carries many of the USB Atmel chips (as well as the Cypress ones).  If you only want one, you'll get hit with a $5 handling fee, but that isn't too bad.  Seeing as how I know of no places near me that sell anything that new anyway, I'd be stuck mail ordering things no matter what.  If you're really nice, you can usually get Atmel to give you freebies.

You should be able to add thresholds for the analog inputs fairly easily.  Just make the USB enumerate with a 2nd function of a keyboard (if it isn't already) and simulate keypresses.  Rotary/Optical encoders are pretty easy to deal with: they just output two waves in quadrature that lets you tell which direction it's being rotated.  You can then use a timer (ATMega has tons) to determine how fast the pulses are flying by and calibrate that to speed (basically, just count the pulses between timer events and divide by the time elapsed, then apply a linear calibration curve).  You could then map that either to an axis or again do thresholds and keypresses.

AVR is a pretty easy arch to work with.  The instruction set is pretty nice, and C compilers are readily available (gcc targets it, for pete's sake).  If you have a flash based device, you could set it up so you wouldn't even need special drivers other than for programming thresholds or recalibrating speeds (like if you changed wheel diameter or gearing ratios).

[vputz]

Probably right as to why the AtMega8 (he has a board which uses the AtMega16, though).  Problem is, I'm way way at sea with this so hesitant about jumping to a new part without guidance.  Maybe the folks at avrfreaks.net would be able to help... not sure there.

The problem with USB devices "programmable over USB" is that then I would think you'd have the "is it a programmable chip, or is it a hid input device?" problem, ie if it's acting like a HID device, wouldn't you then be unable to program it?

Any pointers on the Atmel USB parts, even which ones you mean?  I'm probably going to have to go through Digikey myself (not positive, but it's very likely), so the mail-order aspect doesn't bother me (I'd probably buy at least two for when I fry the first one trying to make a programmer circuit).

But yes, that's the idea--a flash-based beastie.  If I could, I'd like to enable it to recieve HID packets from the computer side and use that to change thresholds/speeds (I arranged my SpaceOrb driver to do that--a user-space program would forward a HID packet of some sort, can't remember the name, to the device, which would then alter its messages in response--for calibration and the like).

Grr... software guy.  I fear circuits.  This'll be a fun learning experience, though.

[MonMotha]

Atmel has a wide selection of USB enabled microcontrollers, both AVR and 8051 based.  The AVR devices, while probably easier to program, are only available in "really tiny" packages (like QFN or TQFP).  The 8051 devices are available in PLCC or, probably even easier to work with, SOIC.

These can all take a command over the USB control endpoint to accept a new firmware download, and of course software on the device could accept commands to program new thresholds and such.  I know the 8051 devices can reprogram their own flash via internal firmware, and I'm guessing the AVR devices are similar.  Unfortunately, most of my experience is on 8051, not AVR (though I'm looking at doing a new product using the AVR series - the instruction set is nicer and performance is higher, not to mention they have some REALLY TINY devices).

The ATMega with bit-banged USB should be able to be programmed in a similar manner.  My only issue is handling the electrical characteristics of USB correctly.  That's not easy to do with general purpose I/O pins (though it is quite possible) - I'm surprised they didn't use a device like the Fairchild USB USB1T11A to handle that for them.

If you want to really homebrew a solution, there are also USB chips from Cypress and Microchip.  Cypress is on my baddie list due to EOLing a product with no warning, and I've hear that Microchip's USB enabled PICs are buggy, but YMMV.  I've used the older Cypress devices extensively, and they do work well.  I'm currently looking at the Atmel AT89C5131A-L and AT90USB646 (there's a version with 128k flash, as well) for a new product since Cypress pulled a no-no.  The former is an 8051, while the latter is an AVR.  The AVR version also has 8 channel 10-bit A/D, but is only available in small packages

[rdagger]

Atmel just sent me some samples of their new AT90USB1287 AVR chips.  These will probably be the cheapest and easiest USB uC's next to PIC's.   Although I probably should not use the word easy.  Working with USB and HID descriptors is complicated and the documentation is very voluminous and unfriendly.

[MonMotha]

The old Cypress chips were probably the easiest that I've seen to use.  You can actually use them without writing any of your own descriptors at all and just using a default configuration.  Unfortunately, they EOL'd them recently...without bothing to mention they were going to (they just up and did it one day).  I believe they got them from Anchor or something like that through an acquisition.

The new Cypress chips are quite a bit more difficult to use (amongst other things, the package has half the pin pitch). unfortunately.

Apparently, the Atmel USB devices aren't quite released yet.  I've talked with Atmel and they keep saying "soon", and I can get samples, but I haven't been able to coax a production release date out of them yet.

[vputz]

MonMotha--

Aside from being a notable figure in the Jedi community (er, well, I thought it was "Mon Mothma", but my memory is fragile), you and rdagger made the mistake of seeming knowledgeable, so I must pester you.

See, I was hoping to avoid having to learn both "soldering tiny parts" and "programming microcontrollers" in the same project (I'd like to ensure that errors are due to either my hardware inadequacies or my coding inadequacies, but not both simultaneously)... and for that I needed a circuit which could represent itself as a HID device--and I'm willing to pay a bit extra for that.  The MJoy8 and MJoy16 could do that for me (the MJoy16 is available prebuilt) but your discussion on proper USB devices made me want to avoid the bit-banging idea even on principle.

After running across various "USB on AVR" projects and one interesting masters' thesis on connecting the AtMega chips with a philips USB chip--written in danish, so terribly helpful--I looked on Atmel's site and found a reference to their USB Key Demo Board, which incorporates an AT90USB1287 controller (nicely soldered in) and exposes all the IO pins with solder pads (solder-yer-own headers).  It looks to me like their sample software on that page includes examples of how to use the board to create HID devices (mouse and keyboard) and, well, it looks like a pretty good starting point.

And best of all, Digi-key seems to have them in stock for $31.25 (I searched for the part number, AT90USBKEY)-- which, since you can apparently upload firmware over the USB port would save me the trouble/cost of making/getting an ISP cable (I think I understand that right--via the bootloader and "FLIP"...?  There's a reference to using a JTAGS something to do programming, but I think that's different from the regular ISP, but as mentioned I'm pretty green at this).

Anyway, I don't want to pester you too much, but could one of you tell me if this is a decent starting point or if I'm way off-base?  It seems like the right product for this sort of project (even if it's a bit more than I need), but I honestly can't tell.

Thanks-->VPutz

[MonMotha]

$31.25 is cheap for a dev board.  Dev/eval boards are a great way to get started with a chip for precisely the reasons you've cited.  I'd grab it and have at it if the part on it has all the features you want.

AVR parts usually have multiple methods of programming: parallel (for traditional programmers - not on all models), synchronous serial (for the smaller stuff - easily bit-banged off a parallel port), JTAG (also includes in circuit debugging), and, for USB parts, download via USB.  So you'll have your choice of how to program it.  The last option (USB) would require just the USB cable, so that's probably what you'll chose to go with, but if the part you pick has full JTAG, you may find that handy when debugging your firmware.  What will happen is that the blank chip will enumerate with a default descriptor that is just good enough to download code to the flash, then you reset it and your code boots.

[vputz]

Thanks; that was the impetus I needed; I ordered two boards (this way I have a backup when I break one--and if by a miracle I don't, then I already have a project lined up for the second.  They are, it turns out, on back order (which is fine; should be available beginning of June), which gives me time to learn about the programming methods you mentioned (I'll be using the USB cable and hoping the bootloader lasts until I can learn a backup method.  The part is (I think) JTAG-capable, but I don't know squat about JTAG, so I've got some reading to do.

Thanks for the help.  Worst thing that happens is I'm out $60-$100 and learned a lot.

[brandon]

Didja ever stick playing cards in your bike's spokes so it sounded like a motorcycle?  Just stick a leafswitch in there instead. 

ya know.. I think something mechanical like that is actually not a bad idea  How about something centrifugal attached to the wheel.. something like the governor on a lawn mower. You could attach a poteniometer to a lever.. one side being pulled by a spring the other side being pulled my the centrifugal/governor mechanism.  I dunno.. just a thought...

[hanelyp]

A capaciter + a couple diodes would suffice to turn a pulse train from an encoder into a current proportional to frequency,  which could then be treated like the output from an analog joystick.

[MonMotha]

Depends on the type of encoder he has.  Some output a variable duty cycle pulse train.  Your method would work for this, though if you've got a microcontroller, why not just measure the duty cycle directly rather than converting it to analog only to convert it right back to a digital value with an A/D?

Some output two square waves with fixed duty cycle (almost always 50%) in quadrature.  The rate at which the edges come by is the speed at which the device is being turned and you can back direction out from which edge you get on one while the other is constant.  You can do this pretty easily on a microcontroller, as well.

Using a couple digital IOs on a micro is a more universal (and, in my opinion, probably more reliable and simpler) solution than making things analog.  Unless your goal is to hack the input to an existing joystick (which I hate doing - it's bulky, ugly, and tends to be failure prone), a little USB micro is the way to go.  That'll let you map pretty much any input even to arbitrary HID events: keypresses, joystick buttons/axes, mouse movements, etc.

[MinerAl]

A lot of this thread is over my head, so if this is a dumb suggestion, I apologize.

Couldn't you just place an "optical" mouse so that it is very close to the spinning bicycle wheel, and then take the axis reading from it?