Main > Driving & Racing Cabinets
DIY Home Steering Wheel
twistedsymphony:
for FFB there are three ways I can think of to hook a motor to a shaft by gear or by belt or by chain.
Chain would probably be the easiest and cheapest since bicycle parts are cheap and easy to source (just buy some old 10-speed from a yard sale) and that would give you a lot of gearing options to play with and get the tension right.
the biggest problem with both gears and chains is backlash so when you have things change directions you'll be able to feel the "slop" in the system... most chain systems are designed to only be run in 1 direction because of this. with gears you can get rid of this if you get the tooth spacing right but you typically end up wearing down the teeth faster and putting more stress on the system as a whole. (this is why cars often have gear noise in reverse, the reverse gears are cut differently in order to deal with the change in direction)
This is probably why most arcade systems use belts for FFB, the transition when changing direction with a belt is a lot smoother and more natural than other systems and the elasticity of the belt helps with that a lot too... it will probably also last a lot longer in that type of setup.
lots of pulleys and belts from automotive accessory drives you can use for this task... the hardest part is keeping everything aligned if you have the pulley's misaligned at all you can very easily end up with the belt jumping off the pulleys frequently. One way to reduce this is to use crowned pulleys like this example:
of course you could always steal the pulleys from an arcade setup too :P
Howard_Casto:
Well the physical attachment of the motor isn't the issue usually. Rather it's the programming. I've yet to see a homebrew interface/library that actually implements FF properly. If somebody knows one then by all mean post it, because I've been looking for one.
BadMouth:
--- Quote from: Howard_Casto on May 07, 2014, 11:44:52 am ---Well the physical attachment of the motor isn't the issue usually. Rather it's the programming. I've yet to see a homebrew interface/library that actually implements FF properly. If somebody knows one then by all mean post it, because I've been looking for one.
--- End quote ---
It's probably a pretty tall order.
Nearly every ffb wheel device anyone is familiar with use an Immersion chip and Immersion's technology for creating the effects.
Logitech and the other PC wheel manufacturer's license it, even though you don't see any Immersion logos.
Not sure about the Sega arcade stuff. They might be one of the few that don't.
Is my thinking correct on these?
It's not just a matter of sending "left" or "right" commands to the wheel.
The hardware in the wheel itself contains a catalog of effects which can be triggered.
Someone would have to emulate or replicate what the Immersion chip is doing in order to recreate the same feel.
Simpler than that? Worse than that?
twistedsymphony:
--- Quote from: BadMouth on May 07, 2014, 12:08:12 pm ---
--- Quote from: Howard_Casto on May 07, 2014, 11:44:52 am ---Well the physical attachment of the motor isn't the issue usually. Rather it's the programming. I've yet to see a homebrew interface/library that actually implements FF properly. If somebody knows one then by all mean post it, because I've been looking for one.
--- End quote ---
It's probably a pretty tall order.
Nearly every ffb wheel device anyone is familiar with use an Immersion chip and Immersion's technology for creating the effects.
Logitech and the other PC wheel manufacturer's license it, even though you don't see any Immersion logos.
Not sure about the Sega arcade stuff. They might be one of the few that don't.
Is my thinking correct on these?
It's not just a matter of sending "left" or "right" commands to the wheel.
The hardware in the wheel itself contains a catalog of effects which can be triggered.
Someone would have to emulate or replicate what the Immersion chip is doing in order to recreate the same feel.
Simpler than that? Worse than that?
--- End quote ---
I don't think that's right... well, I don't doubt that the immersion hardware is able to handle effects and things of that nature but most of the arcade hardware (and even some home console FFB wheels) that I've played around with (such as the GameCube Wheel) don't work like that.
For instance the HAPP FFB board had inputs for intensity and direction... THATS IT, the hardware just exists to scale that information across the 24V that the motor requires to function.... everything else is taken care of in-game (either built into the PCB or in code). This isn't old tech either, this exact hardware is used by Atosmiwave drivers such as Faster than Speed (I own a complete setup).
I don't see any real reason to use hardware to accomplish effects when they can be taken care of in software with nothing but the results (intensity and direction) being sent out.
EDIT:
Thinking about this a bit more you could probably reverse engineer the immersion effects by recording the voltage levels that are output to the motor when each effect is triggered (you can trigger them discretely through the windows driver). I would also disconnect the position sensor from the wheel and setup an arduino or similar device to output voltage sweeps on the position pot inputs to see how it affects the effects.
Howard_Casto:
A chip isn't needed no, but I bet it would help. There are 5-10 styles of effects (depending upon how you count them) and if I understand what I've read correctly, DirectInput basically sends a command that says something like "play a constant force effect with a direction of 90 degrees and a magnitude of 10000" to the hardware/driver and then the interface has to figure out what the hell to do with it.
You can get away with supporting one or two effects, but if you want your wheel to work with any old game you play, you really need to support most or all of them. Now for most effects the actual math and requirements aren't too bad. I mean constant force on a wheel only needs to support two directions an a voltage step. (Actually you really need to use some math to make the effect weaker the closer the direction is to being vertical, but whatever) Ramp effects, again not that bad.... increase the voltage by this many steps over this period of time. Also a pulse width modulation should be doable... just swap the polarity periodically.
But sine-wave effects and spring effects... man I don't know. Sine waves are bad enough, but a direction can be applied as well. Even assuming you get the math right, would your typical consumer-level AVR be fast enough to smoothly and quickly produce the wave? And spring effects... how would you do that? Constantly check the wheel position and attempt to fire the motor to move it back? How would you keep the motor from going nuts if you move the wheel around a lot?
And of course hardware has to support multiple effects layered on top of each other. I limit myself to 10 when writing software but I think you are supposed to officially support a ridiculously high number... 255? Now in theory a simple "OR" function should blend them, but you've still got to have enough processing power to keep track of them all on the avr.
I suppose someone could write a driver and have this taken care of on the pc end (which would help with hardware limitations), but honestly if you want to make something future-proof you need to use a full-on HID interface.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version