The LifeOn2 FFB Wheel Controller

Pax7 · Oct 21, 2012

Hello All,

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

Pax7 · Jun 1, 2014

Hello there guys,

It has been a while since the last proper update; I am always busy with some SW or HW dev work, and when I am not doing that (or going about my _real_ life

) I am too tired to write usually, and/or I really need to go to bed

I am in fact pretty tired now too after a few hours of coding in the middle of the night (4:50 AM here now...), but I hope to make some sense at least :S

So, what has happened since last?

* The "new control scheme" project progresses, I have the state-of-the-art evaluation platform hooked up here in the lab since a number of weeks. Most works, but there is one essential aspect that does not yet work glitch free. Initially I thought the problem was electromagnetic interference between my stuff and the evaluation platform, but after rather lengthy EMI minimization work I am sure that is not the issue.

Due to my specific requirements on the platform for FFB and maximum performance, we have taken one "creative" path HW-wise, which well can be part of the issue. Or it is just a SW bug on the platform (which I hope for).
As I mentioned I work together with another engineer on this, and he is rather slow (or busy I should say

) so correction is not progressing as fast as I would like (luckily I have plenty of other things to work with meanwhile :S ).

I have evaluated one other performance/fidelity improvement aspect that the platform brings though, and that is sexy!

Pax7 said:
Late Saturday evening I sat down for a session with Assetto Corsa to try out/evaluate the crop of vehicles added and other improvements in the last few builds. During that session I came up with a new little idea for FFB control, which I think should be a good addition to increase fidelity.

* The above is implemented since a number of weeks, and it gives a definite increase in fidelity IMO!

* Another activity since last is IT-related; I have sourced a new (used) workstation laptop to replace my trusty HP ditto. I wanted a very specific top-of-the-line model with 16:10 screen, and those are so rare I had to buy it from the US. It is a DELL, with a core-I7 extreme CPU. So far so good, but what is not so good is the damn thing has taken me some 30 hours of fiddling and I am still not finished...

Turned out it had been through some rough nights, and e.g. the primary HDD is impossible to get out of its bay to install a proper SSD. So I installed the SSD in the secondary bay instead, but M$ Windows as usual does not let the user decide so it would not install the MBR on the SSD , but on the other disk... After reading up more on MBR structure and some Windows rescue tools, I managed to get the OS to boot though (and luckily there are low-level Linux tools to help get the job done).

Next issues were I could not get the fingerprint reader to work, and the touchpad HW and/or SW is dodgy as he**. DELL's patch/SW update scheme is a complete mess, with incompatible SW, non-existing documentation etc etc. I even had to install Win7 32-bit just to update the fingerprint reader FW!
Added to this the DELL build quality and ergonomics is worse than the HP - but it is fast!
Could anyway be this is both my first and last DELL...

Oh well, next:

* The last number of days I have worked on SW/FW to actually take advantage of one of the new HW-capabilities introduced by the new PCB design from Feb. (above). This has included some Windows-coding and as usual that is a roller-coaster ride!

Some functionality/APIs are quite good and nice to work with and some not so much :S I spent 8 hours the other two nights just to realize some undocumented requirements of one API... It works fine now though and I have had good progress since, with fun new stuff that will add usability and some cool diagnostics.

Lastly, the pic of the night!

This shows a little setup to interface between some of my stuff and the evaluation platform. It is a differential signal/step-up line driver. Notice the metal foil going down to the left. That is home-made EMI suppression at its best my friends!
(And yes, I have cropped the real interesting stuff from the picture...

)

BR,

Torque1980 · Jun 5, 2014

hi pax
can you give us some informations about the components compatible with your wheel controller?

Zizza17 · Jul 11, 2014

Any news?

GamerMuscle · Jul 12, 2014

I'd also be really grateful for an update if possible even if nothing has changed !

For people willing to spend the money and not wanting to go for the DIY solution its worth mentioning that from what I can gather Sim-experience are expected to put there servo wheel on the market for Q4 2014 for around $2k.

Andreas Forslund · Jul 15, 2014

Maybe Pax is taking a well deserved summer vacation

bumer1M · Jul 31, 2014

I see that Pax is wisiting forum daily. What about some update? Or have you or maybe Mizoo teamed up with ECsimShop as they seem to come out with their servo wheel using what looks to be MiGe servo most that have Mizoo software are using.

Pax7 · Aug 4, 2014

Hey guys!

I am alive but have been travelling for quite a few weeks and have been on the mobile almost exclusively. After being back at the lab I have been busy implementing some new stuff, which is ready now! (...and I have been discussing some "interesting" theories over at the iR forum)

Anyway, sorry for no update - I will post one in not very long!

BR,

GamerMuscle · Aug 8, 2014

Pax7 said:
Hey guys!

I am alive but have been travelling for quite a few weeks and have been on the mobile almost exclusively. After being back at the lab I have been busy implementing some new stuff, which is ready now! (...and I have been discussing some "interesting" theories over at the iR forum)

Anyway, sorry for no update - I will post one in not very long!

BR,

thanks for the update

exited to see what you have been up to !

Chris Dawson · Aug 15, 2014

Cheers Pax7,

Excited at the prospect of moving from my G27 to a servo system at the earliest possible opportunity

Pax7 · Aug 30, 2014

Hello there guys,

Just some side info I thought I'd share!

While tinkering with some practical stuff I ran WheelCheck on the FFB wheel setup I have currently mounted. This run was performed with no artificial limits in effect, and serves to show how capable a system like this can be.

Talk about how "fast" a wheel is (its terminal velocity capability) is no longer very relevant. The wheel is waaay faster than one would ever need it to be. During normal use, limits are imposed not to make the wheel too fast.

Below is a plot from the WheelCheck run. The blue curve represents a wheel which is infinitely fast, i.e. it hits its -450 degree bump stop in 0 seconds (900 deg total range in this example run). The red curve shows one of my LifeOn2 FFB wheel configurations. As you can see, it hits its bump stop at -450 degrees in less than 60 ms. It reaches terminal velocity in around 20 ms.

From this, one just tunes terminal velocity to ones liking to achieve the desired characteristics for actual use in-sim.

BR,

Chris Dawson · Aug 31, 2014

Looks epic!

Any news on the progress of the hardware to achieve this?

GamerMuscle · Sep 5, 2014

Awesome

broken wrists here we come !

3ller · Sep 5, 2014

Good to see you are progressing nicely, cannot wait for it!

assettonoob · Sep 6, 2014

Pax7 said:
Hello there guys,

Just some side info I thought I'd share!

While tinkering with some practical stuff I ran WheelCheck on the FFB wheel setup I have currently mounted. This run was performed with no artificial limits in effect, and serves to show how capable a system like this can be.

Talk about how "fast" a wheel is (its terminal velocity capability) is no longer very relevant. The wheel is waaay faster than one would ever need it to be. During normal use, limits are imposed not to make the wheel too fast.

Below is a plot from the WheelCheck run. The blue curve represents a wheel which is infinitely fast, i.e. it hits its -450 degree bump stop in 0 seconds (900 deg total range in this example run). The red curve shows one of my LifeOn2 FFB wheel configurations. As you can see, it hits its bump stop at -450 degrees in less than 60 ms. It reaches terminal velocity in around 20 ms.

From this, one just tunes terminal velocity to ones liking to achieve the desired characteristics for actual use in-sim.

BR,

As you're chart shows all wheels take more than a frame at 60hz/fps to even start moving or producing torque when unloaded. When loaded they are far slower. Also as your chart shows motors have inertia and they can't stop or start instantly it takes time. Also they over and under estimate the torque and speed they need to hit a target when moving or already producing torque. Especially when trying to hit a very fast oscillating moving torque/speed target at varying loads. Also the wheel oscillates with a static signal as your chart shows.

It's almost impossible to get it right even with a servo motor. Your chart shows it takes a tenth of a second for a wheel to react to a signal and then get to the value it thinks is 'correct' and that's unloaded. It first overshoots the target signal massively and then oscillates around a value it thinks is correct trying to stabilise itself.

I don't think it's possible with current technology to get realistic steering with a single motor, I think you at least need dual direct drive servo motors with the motors running in opposite directions. I think you would then need a clever motor controller to sort out the control so the motors can react as fast as possible with no over/under shoot of target values because of motor/wheel inertia, etc.

Chris Dawson · Sep 6, 2014

Some interesting thoughts, but I don't know if I agree with your two assertions.

A real steering rack is not infinitely stiff, so that when forces are experienced at the wheels on the road they are not transmitted instantly in the temporal domain or at their peak load. What happens will be that when a force is experienced at the wheels, it will begin to transmit load to each of the mechanical components of the rack in turn, and apply compression, tension or torque to them. The result of this at the steering wheel should not be an instantaneous force at full load, but a build up of force over time until the balancing load is reached. There will also be stored energy in the rack components and you will get some oscillation as this is dissipated through the rack and the components interact with one another.

Now, different steering mechanisms and geometries will behave differently, and I could not tell you what the time domains of these effects would be. All I am suggesting is that you would not experience full instant torque at the steering wheel from an effect on the road wheels. In reality there would be a build up of force over time and some lag.

Your concept of using two drives in a push-pull arrangement is interesting (I think some wheels do this), but I could foresee some issues. Firstly you can't direct drive the wheel from a single motor shaft anymore, so you would have to have to use a belt or gear drive which would introduce flexibility and backlash into the drive train. Secondly each drive would have to be clutched in some way so that it only drives the wheel and not its matching motor, otherwise when the 'left' motor starts up it would be trying to decelerate the 'right' motor before being able to accelerate the wheel and its opposing motor. A clutching mechanism would not be instantaneous and would be lossy also, so combined with the additional drive train needed you may not be any better off (and may be much worse off) than a direct drive system.

Maybe there are some clever ways around this?