My homemade FFB controller

[Mizoo]

Hi, simracer fans

I just wanted to show you my last project.
After seeing the Steph Bord and V8Ben videos I wanted an FFB Happ steering wheel too !

But, instead of hacking a logitech board, I built my own FFB controller:

It's based on a Blueboard LPC1768H (I have also a version for LPCXPRESSO), 34$.

The main specs are:
- 1 kHz refresh rate output signal (ie: for AMC)
- 1 kHz refresh rate for USB data coming from game (even if most games actually update the data only 60-100 times per sec.)
- incremental rotary encoder for the steering wheel position (I'm using a 2048CPR, 8192 position per rotation, on direct drive)
- compatible with G25 pedals (and shifter soon)
- configuration via OLED display (soon)
- FFB monitoring, to avoid clipping (currently via serial port, and on OLED soon)
- no need to any driver

To drive the motor, I'm currently using an AMC servo drive, but I will build my own motor controller once the firmware is finished (for brushed and brushless motors).

I also removed the mechanical stop of the steering wheel, since it's managed with the motor (the steering angle is configurable).

This setup is more strong and fun than my G25 (I rediscover rFactor that I disliked before).
I can have strong FFB effects without clipping.

I think to provide a firmware soon (maybe for few bucks or donation).

 

[SergioCarr]

That wheel looks fantastic UAU ... thread is long by it caught my eye so I start backwards

 

[Stef Bord]

Granite Device evolution for the ION future servo-drive, new 500W power rating 12-80V spec.. The good power for the FFB homemade...

http://granitedevices.com/digital-servo-drive-ion

 

[bberger]

Yeah, those Ion things could really be interesting. Just depends on the price at the end and hopefully by having a torque mode.

The good thing is: they should run the same version of the SimpleMotion V2 API like the Argon does. Should minimize the compatibility issues.

 

[Chris Dawson]

Might it still be worth going for the Argon in terms of cost due to the fact that it can all be run from mains, and you don't require any additional PSUs?

 

[bberger]

Depends heavily on the price..

 

[3ller]

it will fill the gap of the vsd in my opinion on the price range, the thing is the A that the thing will deliver, if it does 48V 10 A 480 W its a winner for us

 

[bberger]

I think so too.. I'm mainly going for the Argon because of the programmable Cortex ARM uC directly on the drive as I can do some lowlevelstuff directly on the drive..

 

[lipecpereira]

Hello guys!
is there any way to do tests using only the motor encoder? Without the servo drive. The encoder of my engine is this: http://www.audin.fr/pdf/documentations/sick/codeurs/codeurs-boucle-fermee/SKS36.pdf
What do you think? Can I connect the Arduino to send information directly to the game? again sorry for bad english and thank you very much!

 

[bberger]

Hey guys,

I'm having some minor troubles getting to work the motor reliably with the Argon drive stage (I'm sure it's entirely my fault btw) as it enters error state as soon as I try to move the motor more than a few degrees in position mode.

I'd like to doublecheck the settings in Granity for the MiGe 130ST-M10010 (the one used here in the forums):

[AXT] Axis Type & units: Rotary (revolution)
[AXS] Axis Scale: 1 revolution per motor revolution rotation
[AXI] Invert Axis Direction: false

[MT] Motor Type: 3Phase AC or BLDC
[MMS] Maximum Speed: 1000rpm
[MPC] Motor Pole Count: 8 poles (4 pairs of 2), confirmed by MiGe and magicfr)
[MCC] Motor Continuus Current Limit: 4.5A
[MMC] Motor Peak Current Limit: 6,345A (4.5 * 1.41 to get peak of sine)
[MR] Coil Resistance: 2.7Ohms
[ML] Coil Inductance: 8.8mH
[MTC] Thermal Time Constant: 2300 seconds (according to Argon manual you can take as a mark motor weight (11.5kg * 200) wich leaves me with 2300 seconds. On the motor data sheet the Thermal Time Constant is specified as 3.93 Ms (what the hell are Ms?)

[FBD] Feedback Device: Quadrature Encoder 1
[FBR] Feedback Device Resolution: 2500ppr
[FBI] Invert Feedback Direction: false
[FBH] Hall Sensors: off

I've marked the parameters that are most in question red. I'd appreciate if someone could help me out here as I'm getting slowly frustrated..

 

[magicfr]

Hello,
I have 130ST-M05025 but it same for all Mige, it's 8 poles
Here's my config , you should have same first 3 parameters :

Also you should have Maximum Peak Current and Maximum Continuous current as close as possible.

Put your DC Power maximum current in Current Fault limit parameter.

Don't mind my own values they are wrong we didn't knews about the sinus peak at this time
Now I configured for 7A max peak.cont. current at the motor ( so 9.87A in the config ), so with my belt I have 14Nm at the steering shaft.

 

[bberger]

Thank you magicfr,

I've just got an email from MiGe wich confirms the 8 poles (4 pairs of poles). They also stated the peak current to be 13.5A, but I'd advise strongly against setting it that high.. What magicfr said makes sense as the drive would fall back after a brief amount of time from the maximum to the continuos value anyways.

I'll edit my post above and remove the red mark of the confirmed values.

//Edit: overlooked sth in your post: the Argon drive doesn't need an external PSU and the limits seem to be 10A cont. and 15A peak (1s). Seem because they spec sheet states it one time as 20A peak and one time as 15A peak.

//Edit2: yeah, with the 8 pole configuration it works flawlessly now. Finally I can fine tune the motor. I'll post the Argon Settings File when I've got some good results. Right now the motor makes a bit too much audible noise for my taste..

 

[fvalido]

Hi bberger, did you tested any initial code managing any sim software FFB and the Argon-MiGe system?

 

[bberger]

Only in theory. My first goal is to make it run with iRacing telemetry output (which in fact should work out of the box as the telemetry outputs the steering shaft torque in Nm, as well as the used calculated FFB output).

I did test that with an experimental setup (G27 controller with some custom DirectInput/FFB implementation) reading from iR telemetry and output constant force on my G27, using vJoy to give position feedback to the sim. It worked surprisingly well I must say. I have talked to David from the iR staff who will introduce some gimmicks into the SDK with the next build/maintainance update so that I could drive the Argon purely from telemetry and get some nice results.
My first goal is to provide a (plugin-)extendible application to feed the Argon from various sims that provide the neccesary data. I will only provide the feeder app and some interfaces for the plugins to drive the argon at first though, as I have next to no knowledge from other sim's APIs to make that work in a foreign environment. I will however look out for skilled programmers who have the neccesary knowledge and interest to make that work for as many sims as possible. A first prorotype version of this approach is hopefully available in a few weeks..

The nice thing about the SimpleMotion V2 library (used on Argon and Ion drives) is that it has a programmable ARM M3 microcontroller that allows setting virtually any parameter from the outside (no need for GDTool if you have parameterized and tuned the drive to the motor's specifications), so people having various motors could provide a standardized settings file for each motor (say one for the MiGe, one for an Kollmorgan AKM etc.) which would allow for great versatility in terms of motors to use. So Motor-Profiles is one big point on my agenda.

The other big emphasis after creating the argon telemetry feeder would be (and this is a FAR way to go..) would be native FFB support. As the argon has a programmable µC it would be technically possible to implement FFB specific things like changing the dampening or playing canned effects directly on the Argon (Granite Devices already offered help on this task) and therefore kill the need for an external µC. Implementing an USB stack to make the Argon HID compatible however seems to be out of my comfort zone (though it should be possible), so I'm actually thinking of going another route and fork the vJoy project and create a custom windows driver to make a Gamecontroller device out of the Argon. (Connect the Argon to the PC and Motor, Install drivers, load motor configuration file, done.). As the SimpleMotion V2 adapter supports up to 10.000 commands per seconds that shouldn't be a limiting factor, writing the driver and implementing the custom effects on the Argon µC however is time comsuming, has a steep learning curve and WILL take up a lot of time and effort for me to get it working. I wouldn't expect any useful results in this area for at least 6 months, realisticly maybe even a year..
That's the reason my first emphasis is on getting the telemetry -> feeder workflow to run and making it as easily extendible as possible, so people can actually build from that.

With Mizoo working on his µC FFB-Firmware implementation (and hopefully releasing it at some point^^) there should be at least one alternative to have native FFB support along the way, so people could actually choose which technology they want to use. This is another big emphasis for me that I don't kill his project, but provide an alternative for the time until his version is ready so that people can actually build the system already and maybe switch to his implementation in the future as the two systems will be compatible.

As I already statet many times: I do not want to make his work obsolete, nor do I want to compete against him, I want to provide an alternative approach to his work using compatible (and in many cases virtually the same) hardware he and others have used to make this DIY project work. My development is running parallel and my main focus is to keep it compatible with his doing. Unfortunately I can only guess on that account as I don't have his firmware to test against, but I shouldn't do anything that compromises his approach anyways.

The only thing that I can say for now is: I'd strongly recommend to choose the Argon over the VSD-E or Ion drives as a) Granity is imho a way better tool than GDTool to tune your motor and b) the SimpleMotion V2 library is a killer, especially in context with the programmable µC on the drive, and it also is WAY easier to wire up than the VSD-E as you can omit the power supplies (only a low cost 24V / 20W PSU is needed to drive the logic).

Puh.. I actually didn't want to write that much, but seems like my muse was in a good mood and nearby..

 

[bberger]

Btw guys.. do yourself a favour and ask the manufacturer to either take out the key from the keyway or omit it to begin with.. I just wasted 1 hour of my life getting that piece of love out.. I've done everything from inserting the screw and try to push it out by screwing (the screw broke), to making a new hole+thread (where I destroyed the thread and had the M4 screw in my hands..), to using a hammer and a chisel (yeah, worst idea so far as it split the key....) and ended up making 5mm holes along the whole key to break the tension to get that beast out because I've lend my dremel to a friend over the holidays..

So.. as long as you don't have either luck with the screw or have the proper tool at home / work - do yourself a favour and ask the manufacturer to avoid shipping the motor with a key inserted in the first place.. gosh..

 

[fvalido]

Thank you bberger for sharing your project with us so good. In my particular case it would be nice to guarantee a easy first complete working system before spending my limited money on the motor And argon. I have only basics programing knowledge not to go alone or helping you. I only need a first step to guarantee the Mige working with rfactor like my G27 actually does not more. After the future could be better. I am not able to evaluate if it could be posible using a rfactor telemetry plugin And vjoy. I suppose this opción is Slower And not so accurate as uC FFB firmware or native. What do you mind?

 

[bberger]

rF1 calculates physics and outputs telemetry and direct input (ffb) commands at 90Hz if I remember correctly. The SimpleMotion V2 API can process up to 10.000 commands per second (10.000Hz). So that really isn't an issue.

It actually doesn't matter which route you go at the end as it virtually doesn't matter where you do the processing (either on your PC which has timers (XP and later) that are supposed to be accurate up to 1ms (1KHz) so it's just the matter of how efficient your code is (CPU usage). If you can update the commands at 500Hz that's plenty and not really a problem on either the PC or a ARM uC) from a bandwith perspective.

The advantage of doing the work on the uC is that you don't have to share any ressources with your PC applications and that it will run consistently across all platforms (that is processing of the commands, meaning turning a FFB command to the electrical equivalent, simplified spoken). Most of the time consuming work is calculating the position from the encoder on the current systems and adjusting the torque output accodringly - this task is handled by the Argon?VSD-E/etc with ease..

The hard part is implementing the FFB/HID protocol as it is very poorly documented, full of non working examples and a steep learning curve. Most of the non trivial motor related tasks like the the torque controller and readinc/calculating position is already done by GD. The missing part is the implementation of the FFB protocol as already said.

Back to your question: nah, it really makes no difference at all lag/performance wise. The native FFB way is the way we aim for. The telemetry stuff is just a gimmick to pass the time until then and provide some alternatives. uC or driver doesn't matter as this is mostly just the communication part. uC/HID has the advantage that you don't even need a driver as windows/linux/mac already provide a standard driver for the HID gamecontroller class / communication, but the workflow is the same: tell windows that there is a joystick connected, tell the game to output ffb information to and read joystick position from that device, translate that information/commands to the protocol the motor controller understands and then have fun with it

So I'd suggest you one of the following things:
a) get a Argon (+ accessories) + BlueBoard or equivalent + some blind trust that we make this work
b) wait for Pat7 (that's his name I think) to complete his project
c) wait for SimXperience to finish their product
d) get a Bodnar if you have the money and want sth that really works as it is.

If you opt for a) you should be aware that you WILL have to do soldering and and basic mechanical stuff as well as put some trust into community members that you will either get a working firmware of driver or telemetry application to actually benefit from the stuff as it still is expensive up to a point. The only thing I can clearly recommend when doing this is to get a Argon and nothing else. The Argon is the common thing where either my software or Mizoo's controller will work and where you will have to do less electrical wiring than with the VSD-E/Ion drives. I will at no point support anything else than the Argon as it has some features I need for my way.

..oh the "lag" between DirectInput and telemetry output is usually non existent as both are realtime data and output at the same point in code (in iR e.g. the difference is about 0.2-0.5 MILLIseconds, depending on the system, and both are output in a 16.6ms interval..)

 

[fvalido]

Hi, all your post looks very logical and full of sence to me. Pax7 or Simxperience can be an option for me but it depends on price and i dont know how much MORE time is need to wait. Argon and telemetry app sounds good for me. I will wait your next developments and have luck you continue your info. Thanks

 

[GamerMuscle]

Awesome work bberger !

I think everyone in this thread and people that have used a pro simulator or have had chance to build there own servo wheel all know that all the current consumer wheels simply are not good enough.

G25-T500-CSW all have fundamental issues that make the basic input and handling way more abstract than it has to be. (though not to knock them as they are very impressive devices in there own rights considering cost and market size )

I think its awesome that by the end of 2014 things might be such that "joe blogs" could go out spend £500-£900 and get a FFB wheel that actually mimics what a real car wheel does.

It will be interesting what happens when sim-racers at large realise the importance of these projects , I'd say for sim racing driving with a servo wheel is more significant than a device like the oculus rift , when it comes to immersion and practical enjoyment of the sport/hobby.

 

[fvalido]

Hi bberger, how is going with your apps for Argon?

 

[bberger]

Actually it's progressing very well and the support from Granite Devices has been superb! Tero is a really good guy and has been very forthcoming. I even got a firmware update on request to include PWM duty cycle control to limit the wheel speed (having this thing turn on you @ 1000rpm is just insane (trust me, I had a flesh wound on one hand and a pretty hefty burn from the suede rubbing against my other hand)

As far as gaming goes: iRacing works pretty well by now and, I hope that I can take on AC next week.

There are some security features which still have to be implemented before I will release anything though.