The LifeOn2 FFB Wheel Controller

LifeOn2 Development

After a number of months of research, planning and implementation I am happy to present the results of my latest project: implementation of a FFB wheel controller.

The controller is built around an ARM 32 bit RISC processor, the Cortex M3. The M3 has a wealth of peripherals, including an USB 2.0 interface, which I have programmed to communicate with a PC host. The Cortex M3 is paired with a base board which has an electric motor drive stage and monitoring capabilities. The drive stage can be controlled via the Cortex M3 to power a variety of motor types, including brushed DC motors (Found in the Logitech, Thrustmaster, Fanatec, Frex and ECCI FFB wheels) as well as brushless servo motors. The drive stage can output 300W, which is more than the Fanatec CSW and I think also the Frex TypeG and ECCI 7000.

My plan has been to use a high performance type servo motor also for this initial FFB controller prototype, but as sourcing of a servo motor with the specifications I wanted has been an issue, I decided to use a brushed DC motor instead. I will drive a proper servo motor going forward.

The status of the project now is that I have a FFB controller capable of driving a brushed DC motor (the FFB) and reading of a rotary encoder for steering wheel position.
I have also worked with a brushless DC motor, which is closer to the type of servo I will use going forward. But, as the BLDC motor has some properties not suitable for FFB application, I use the brushed DC motor instead for now.

I have furthermore implemented USB communication between the FFB controller and the PC, and the FFB controller presents itself to the PC as a FFB device. I have followed the specification from USB-IF on FFB/haptic devices. This means I did not have to implement USB device drivers in Windows, as Windows includes FFB device drivers for USB-IF FFB/haptic devices.

The drawback of using the USB-IF specification is however that the specification and its communication protocol is quite complex and has too many features not used in an FFB simulator steering wheel.

Here is a screenshot of the FFB controller (wheel) attached in Windows 7:

The FFB controller is capable of receiving FFB commands at 1000 Hz, and it can report wheel position to the PC at 500 Hz. I plan to increase that to 1000 Hz too though.

Below is a video I shot earlier tonight of the FFB controller connected to the brushed DC motor and rotary encoder and used as a FFB wheel in iRacing.

As you can see, I have not bothered to attach any gearing and other devices (belts etc) to create a proper wheel, but the important stuff is all there. Gearing and other mechanical stuff are the easy parts...

Some eagle eyed readers might recognize the motor, rotary encoder and bracket - they are taken from a Frex SimWHEEL MkI. I have a broken SimWHEEL standing in the closet, so I thought it could come to some use...

-----------------------

In addition to switching to drive a servo motor, I also have other plans which I hope to be able to share/demonstrate the results of going forward.

Thanks,

-----------------------

PS. I will share a bonus photo; this is the LifeOn2 Development work place, where most of the more hardware oriented work is done

I walk the line.

Pax7, my hats off to you on this project. This is something the DIY crowd has been yearning for. There are a couple projects out their at the moment and I wish you luck on yours. With that I do have some questions.

On your workstation I see some PCB's laying there. My first concern is the size of those are it. DAMN!!!! Some big boards going on there. If those are the boards that will be used I'm assuming that you would have to use an external enclosure to house them. Not a big deal to me but to others it might be.

Second, will this also support buttons, switched, rotaries, etc.. on the board?

LifeOn2 Development

Pax7, my hats off to you on this project. This is something the DIY crowd has been yearning for. There are a couple projects out their at the moment and I wish you luck on yours. With that I do have some questions.

On your workstation I see some PCB's laying there. My first concern is the size of those are it. DAMN!!!! Some big boards going on there. If those are the boards that will be used I'm assuming that you would have to use an external enclosure to house them. Not a big deal to me but to others it might be.

Second, will this also support buttons, switched, rotaries, etc.. on the board?

How is the compatibility with other games/Sims so far?

What is the round about cost of the board so far?

Thanks brother I will be watching this one closely.

Click to expand...

Hello Mike,

these PCBs are prototyping units, which is the reason they are so large. Prototyping units are very suitable to use during early development as they give access to much of the capabilities of the microcontroller. They also expose pin headers and measure points for oscilloscope and logic analyzers. All this adds up to large physical size.

After prototyping, a purpose built PCB will be significantly smaller.

Support for buttons etc. is easy compared to getting the power supply and motor drive circuitry right, so yes, in a final design such things would be included

I have not implemented support for funky canned effects and such, only stuff for serious simulators.

LifeOn2 Development

I have worked with ARM based processors/IP and related since 2002, so choosing an ARM processor for this project was natural. There are other popular alternatives out there, e.g. Microchip. Their advantages are good documentation and good reference software stacks. But, they are generally less powerful than ARM based systems, and I don't mind doing some SW work myself.

When I started with ARM in 2002, we used primarily ARM7s for microcontroller applications, but nowadays the ARM processor series for microcontrollers is the Cortex M series, hence I chose that.

I started out prototyping on a Cortex M0, but as I needed USB support and wanted a high MIPS core for the more sophisticated algorithms involved in some brushless servo control, the choice fell on the M3. An M4 would also have been an alternative of course; they are both so cheap the price is not an issue anyway.

When ready and you know your computing power/capacity demand, you can also of course downgrade to a lower class microcontroller.

LifeOn2 Development

Heh, I have a good relationship with Leo and I am sure he welcomes good technical development by the community.

Leo does really not target the home market with his system either, but rather simulator installations at real racing teams. I think his system is clearly too expensive for 99.99% of the home simulator users too.

Your system Mizoo with the modular approach using commercial servo drives I think is good for the community however, as it is realistically deployable and can be offered in a few standardized configurations or relatively simple DIY. If it also is at least reasonably affordable, then

Overall I think these types of projects shows what can be achieved, and hopefully it wakes up not least Fanatec

Any idea on a target price for the final PCB and timing to get to that stage?

Like others have said, there is going to be a lot of interest in this because I believe at the end of the day, half the fun of this hobby is building ones own equipment. Your design allows us to get closer to doing this with our own FFB wheel.

Reiza Studios

Are you saying that these professional simulators are using some other data for force feedback besides what is generated by the game, or Sim? Or did you mean something else by that?

Sorry for my confusion...

Click to expand...

I don't really know what the norm is, but I can't imagine a simulator programmer / electrical engineer to implement the complex game FFB standard. They probably make their own CAN or USB or other interface specifically for the job, or use existing professional motor controller interfaces.

What I mean is there is no need to follow the force feedback 'standard' when you're making a simulator from scratch. The 'wheel' doesn't have to work with all games, just your simulator..

I don't really know what the norm is, but I can't imagine a simulator programmer / electrical engineer to implement the complex game FFB standard. They probably make their own CAN or USB or other interface specifically for the job, or use existing professional motor controller interfaces.

What I mean is there is no need to follow the force feedback 'standard' when you're making a simulator from scratch. The 'wheel' doesn't have to work with all games, just your simulator..

Click to expand...

While the games used on that simulator sends data to it wich needs to be compatible or the code involved in the soft.

LifeOn2 Development

I don't really know what the norm is, but I can't imagine a simulator programmer / electrical engineer to implement the complex game FFB standard. They probably make their own CAN or USB or other interface specifically for the job, or use existing professional motor controller interfaces.

What I mean is there is no need to follow the force feedback 'standard' when you're making a simulator from scratch. The 'wheel' doesn't have to work with all games, just your simulator..

Click to expand...

Sure, if you have control from simulator software to steering wheel controller you could bypass DirectInput in Windows and write your own purpose designed protocol. Writing a e.g. USB driver for the PC host and corresponding steering device firmware for such a protocol would not be very difficult.

I have not checked, but maybe e.g. rFactor Pro has a plugin architecture for steering controls that would let you do just that.

Regarding what we have, DirectInput was designed over 15(!) years ago, and the USB-IF spec on FFB/haptics is almost as old. They are ancient and written in a time and for applications where high fidelity and frequency physics based simulator FFB was not on the charts... Instead, they are filled with horrible canned effects support etc. that make them very bloated for car simluator use.

Nevertheless, I think very good results can be achieved with them, once you have a working implementation in place. With a high end FFB wheel, rFactor2 clearly shows how good it can be, using high frequency FFB effects update rate.

I don't really know what the norm is, but I can't imagine a simulator programmer / electrical engineer to implement the complex game FFB standard. They probably make their own CAN or USB or other interface specifically for the job, or use existing professional motor controller interfaces.

What I mean is there is no need to follow the force feedback 'standard' when you're making a simulator from scratch. The 'wheel' doesn't have to work with all games, just your simulator..