Close
0%
0%

Open FFBoard

A modular and open source force feedback interface and motor driver for DIY wheels and controllers

Public Chat
Similar projects worth following
The goal of this project is to develop a simple and comparably affordable force feedback interface for stepper motors and servos for hobbyists as an alternative to expensive commercial options.

This will allow for example to build DIY direct drive wheel with high accuracy and responsive force feedback yourself or any crazy simulation interface you can dream of.

While there are several commercial toy grade FFB steering wheels and some higher end simulator grade producs these are very expensive and and are often not moddable or come with their own expensive ecosystem.

It makes sense to focus this project on a simple open source force feedback interface as this is the part where the community lacks a good and open solution.

Therefore the main goal will be to develop a universal FFB controller (Open FFBoard).

It will provide a modular architecture with interchangable motor drivers (think about vesc and odrive compatibility) and a reference motor driver board based on the TMC4671 still usable on its own.
(If you were here because of the servo control aspect the previous prototype promised)

The FFBoard is just an interface for USB HID, encoders, buttons and pedals.
The software is modifiable for different motor drivers and control outputs (USB HID for most users. Could also be a PPM output).

  • 1 × STM32F411RE Main Processor
  • 1 × LM5050 Power Management ICs / MOSFET, Bridge Drivers and Controllers
  • 2 × 1.5mOhm 2512 Shunts
  • 4 × LEDS 0805 Electronic Components / Misc. Electronic Components
  • 1 × 8MHz Crystal

View all 10 components

  • Developing a GUI

    Yannick (Gigawipf)03/27/2020 at 11:15 1 comment

    The setup procedure via command line can be confusing and error prone.
    Therefore a graphical interface should help with the setup and tuning of parameters.

    I chose python with Qt as this allows rapid development of a nice interface for changing main classes or setting up the motor driver.

    This is a very early version and later the most common setups might be done via a simplified wizard to reduce problems.
    The DFU mode allows to flash new firmwares without a debugger. Remember to do a full erase if problems occur as sometimes the ST programming tool does not erase the correct sectors...
    Later the DFU programmer will hopefully be integrated as well.


    The GUI can be found on Github (Ultrawipf/OpenFFBoard-configurator).

  • Announcement video

    Yannick (Gigawipf)03/13/2020 at 15:03 2 comments

    After working on this project for a year now i feel its finally time to make an official announcement video detailing some of the ideas and the current state of this project.

    Due to some requests in the end are also some longer racing demos of the OpenFFBoard in a wheel configuration.


    In this video i am showing project cars 1 and assetto corsa.
    Project cars 2 feels also great with that. Pretty much any racing sim should work nicely with this without drivers.

  • Finally FFB again!

    Yannick (Gigawipf)02/15/2020 at 13:56 4 comments

    The last days i spent preparing the firmware for a modular architecture, porting the old FFB code and improving it to a usable point.


    Constants for the driver and some settings are stored in flash and loaded at boot so you only have to set parameters like motor type, main class, encoder parameters and button sources once.

    Thrustmaster wheels with buttons are supported now as well as 8 local digital pins as button sources.

    Most of the effects are implemented and set to reasonable values.
    Its HID Physical Interface compatible so it works without drivers for any supported platform and game.

    Here is a short race with the new boards on low/medium power for checking some parameters:

    No comments on my driving or the mess of a table please^^

    The motor used is a Nema34 with a 10k ppr encoder on the back with a supply of 19V (Notebook psu).

    The large cap on the left is connected to the internal motor power rails to buffer the power without enabling the braking resistor too often. You don't need a cap this large but having more capacity is always a good idea here.

    I am now waiting for a new version of pcbs to arrive with better hall/encoder filtering as with some very noisy motors the pwm can cause some issues. Apart from that i am pleased with how good it works and feels and with some tuning it should get even better.

  • Improving noise with filters and better amps

    Yannick (Gigawipf)02/04/2020 at 17:23 1 comment

    In the first version of the TMC board i tried INA282 current shunt amplifiers.

    It turns out despite having very good specs on paper they are extremely susceptible to fast rising common mode voltages.

    And we have these a lot as the TMC needs to measure currents on the floating motor outputs.

    This meant extremely bad noise on the current measurements.
    As an alternative there are the AD8417 which are much better suited for this application for the same price.

    See for yourself what a difference this makes:

    3 Phase openloop current
    Open loop current of slow 3 phase motor

    Looks pretty good considering that this is on a low scale and we can go MUCH higher and maybe even improve the noise with filter tuning.

    INA282
    INA282 at more than double the current

    Looks very bad right?
    This is because the INAs output spikes >1V up or down for up to 15µs after almost every pwm cycle (25-50khz).

    This is the output of the INA282 with no motor current. Only pwm active. yup. pretty bad.

    Obviously we are now using the AD8467. For even better noise the AD8468 with low gain could be used but this would decrease the maximum current even more. I am aiming for >25A fullrange for this version for now.

    By using different shunts or the lower gain AD8468 we can decrease or increase the limit depending on the application.

    We will also add low pass filters to the encoder and hall inputs as with some motors significant pwm noise gets back through these lines and causes glitches. This means even more components to solder :/

    Next step is to order new pcbs to fix the previous errors and write the firmware.
    The firmware is currently in a stage where most base features are working and i am implementing an example for FFB soon

    Also as the board is quite small there is not much room to add capacitors causing high ripple on the motor voltage rail when backdriven as there is currently only space for one larger cap.
    When used with large motors it is recommended to add external caps between GND and PB+.

  • Boards. More Boards. Finally TMC4671!

    Yannick (Gigawipf)01/29/2020 at 22:25 0 comments

    After a long time planning the pcb and waiting for parts the first motor driver board is finally assembled.


    This is a fully featured motor driver with dedicated power stage for high currents, support for a braking resistor and active backfeed protection for high efficiency.

    Braking resistor can be activated either automatically via the TMC at a hard voltage level or forced externally at lower levels as well (if internal voltage higher than external for example)

    Encoder and Hall effect inputs are buffered and protect the TMC. All pins of the TMC are broken out to accessible headers.

    This board is not just for the FFBoard. It can be used for other projects as well.


    Its made to connect to the STM board via a ribbon cable or stack directly under the STM board for a compact setup.

    STM Boards for USB interfaces
    USB Interfaces

    Yes! First open loop rotations! (Connected to a Trinamic Landungsbrücke via SPI)

    Motor Driver
    TMC4671 powered first rotation

    Of course there are still issues as this is the first hardware prototype of this version and changes might be made:

    1. INA232 shunt amplifiers are extremely common mode step sensitive despite very high claimed CMMR. The slopes are too steep while switching. This causes high noise in the measurements.
      1. Change amps to AD8417 which might behave better but with higher gain maximum current is slightly lower
      2. Smooth spikes out with more aggressive low pass filtering
      3. AD8478 and higher value shunts for even better noise but lower efficiency
    2. Embarrasing error: The Oscillator is permanently disabled due to gnd at tristate pin... Fix: Scraped pad off... Easy fix in next pcb revision.
    3. Despite analog inputs on the tmc being 0-5V the single ended VM input only measures half range and a maximum of 1.25V. Very strange decision from tmc...
      1.  I did not catch this before so we will need a new pcb for this. Not a big deal for now because its only relevant for the forced brake resistor failsafe enable by the tmc which should not even be needed as the STM will do this normally

    Apart from these issues that can be easily fixed in the next revision the important parts seem to work correctly and the board can be used to start developing the software interface and initialisation routines.

    Also those industrial terminals are pretty expensive and might be changed to open screw terminal style which are also better for some permanent installations.

  • Testing the TMC4671

    Yannick (Gigawipf)11/23/2019 at 11:56 0 comments

    As mentioned before the reference motor driver could be powered by a Trinamic TMC4671.
    This motor controller promises everything a universal torque mode motor driver should do while being compatible with 2 phase steppers, 3 phase servos and DC motors with the same power stage. Nice.

    Big thanks to Trinamic MC for sending me a TMC4671 Devkit. This way i can begin testing the features before the fixed chip is sold again and the final pcb is manufactured.


    I tested the chip with the TMC IDE Trinamic provides for this kit. This software nicely explains with wizards in the form of a tutorial how to setup the core parameters of the TMC4671.
    It also helps debugging with graphs and register browsers.
    I have made a setup with a 2 phase stepper, an 8192ppr encoder and torque mode to see how it responds and it pretty much does everything the old OHSC with the powerstep01 did but much better and in hardware. Nice.

    A modular design would also allow support for multiple TMC Motor Drivers on one SPI bus for 2 or 3 axis systems.

    Video of the TMC4671 running

    And if you perfectly align the encoder speeds impossible for normals stepper drivers can be achieved.

    The next step is to finish a pcb and wait until the TMC4671 is sold again. This might be the best solution fo a reference motor driver for this project.

    *Update*
    Trinamic said to me that the TMC4671 in the fixed version is planned to be released in march 2020.
    Until then the current version is sold that has a few hardware problems.
    This means that the next prototype will still have the old version of the chip.
    For SPI control and FFB the bugs should not be an issue apart from having to slow down the spi clock a bit for now to avoid a data corruption issue.

    The step/dir interface does not work and the adc and spi MSB might have sporadic glitches which fortunately did not affect the motor control in the tests.
    All known issues are listed in the errata of the datasheet.

  • Change of project direction. More FFB, more compatibility

    Yannick (Gigawipf)11/04/2019 at 11:29 0 comments

    The goal of this project was originally to create an open source motor driver focussed on racing simulation controls.

    There are many different motor drivers but not many of them were really suited for the task AND hobby budget friendly.

    It makes sense to focus this project on a simple open source force feedback interface as this is the part where the community lacks a good and open solution.

    Therefore the main goal will be to develop a universal FFB controller (Open FFBoard).

    While the first prototype (OHSC) did kind of accomplish this goal it was clear that for reliable use and high accuracy the powerstep01 was not suited. They sometimes locked up or died as they were not used as intended and only provided 7 bits of resolution. I realized there is no way to reach the goal of reliable and high fidelity torque control with this device and there is a reason servo drivers are expensive.


    I was pointed to the Trinamic TMC4671 motion controller which would do everything needed directly in hardware and can be configured for steppers, 3 phase servos and DC motors simply via spi with the same hardware. The TMC4671 had as few issues in the first revision but will be fixed soon Trinamic promised me. Therefore i am confident that it should make things more robust and simpler on the software side if the task of controlling the motors is completely done by a separate chip.

    Building an external 4 half bridge power stage is more complex and expensive but will allow for much better cooling and higher currents.
    The goal remains to create a budget friendly kit but it is clear that the motor driver will get more expensive. (Think ~30$ parts OHSC -> ~50$ BOM cost TMC board + more work. We need 10 mosfets and drivers... etc.). From my calculations it should still be possible to make a kit like this below 100$ :)

    The current idea for the project will split into two main parts:
    1.
    An open source Force Feedback interface board with an STM32F411 for usb communication and control.
    This will support different motor drivers and will be modular. You can use your own motor driver or control schemes by writing c++ classes for this controller. The main software parts will be the motor control part for encoder input or force output and the control interface which will be USB HID for most users but could also be changed into a class that outputs PPM values depending on the steering wheel position and receives force values back to pass to the motor interface.
    For example a VESC or a commercial servo driver could be made compatible.

    2.
    A reference motor driver based on the TMC4671. This will be the intended motor driver for a direct drive wheel but can also be used as a standalone motor driver or development board for arduinos and different purposes. The STM board will be optimized for this motor driver.

    The next step is to test if the TMC4671 fits this goal and which motor drivers are a good alternative.

    This will be interesting and i will keep you updated. The new boards are almost finished and i am waiting for Trinamic to release the chip soon.

  • Update on FFB

    Yannick (Gigawipf)06/09/2019 at 11:37 0 comments

    One main goal of this project is to make a force feedback wheel kit.
    Therefore usb HID gamepad and PID must be supported.
    Also a braking resistor to dissipate any generated power for quick movements was added with an anti backfeed circuit.

    Reports are sent at 1khz which makes for a very smooth steering experience. (Torque resolution still only 7 bits which makes ffb a bit less smooth...)

    Implementing a basic HID gamepad is relatively easy, making it FFB capable a whole other story. 
    At least with the ST HAL library it is for example not possible to even send HID feature get requests.
    This had to be patched in and the whole HID descriptor with PID is in the kilobyte range.

    After many days of studying the 20 year old specification and sparse examples about PID basic FFB is now supported.
    Strangely some programs and games seem to not send the "Actuators Enable" command after sending a reset but instead a stop. But some do send a more sensible "stop, reset, start" sequence.
    Well... thats a story for another time.

    The main part of the current log is that most games use constant force, friction and spring effects and these are currently implemented in a simple way and work for assetto corsa for example nicely.

    The motor driver of the current prototype is still the powerstep01 but sadly two of them burned out after locking up. SPI commands can not be sent too quickly and the current resolution is limited to 7 bits. This might be fine in a slow robotic arm but not that great for FFB and any quicker applications that require precise torque.
    Therefore the plan is to use a more capable motor drive solution. This will get more expensive but opens up some possibilities like the use of 3 phase servos and steppers with the same hardware and more accurate torque control and better heat dissipation when using external power mosfets.

    Here is a short video demo with a FFB test and a scene of me trying to drift in assetto corsa without a shifter:


    Additional analog axes and buttons can be added via the inputs. Up to 16 buttons and 6 additional analog inputs are present for shifters, pedals and other controls. Maybe even add a thrustmaster wheel with SPI buttons to the free SPI port?

    Compared to the Thrustmaster TX this has of course still lower torque resolution and fewer base effects, but feels much sharper and very strong if you turn up the power. I would say it comes close and should be able to surpass the consumer wheels later maybe even for a lower price.

    Next Steps: persistent user configuration, code cleanup, new motor driver.

  • Choice of processor and control

    Yannick (Gigawipf)04/17/2019 at 13:17 0 comments

    Of course we need some way to send data and control signals to the OHSC for setup and direct control of important parameters.

    A good option would be a serial port. This would make it usable in programs and in a terminal for human users.

    It already has a hardware uart interface planned that could always be used to control everything important. But this needs a uart interface so in normal operation it would be nice to just use one usb port.

    As it is planned that the device can also be used as a HID gamepad for FFB we need some way to control it when HID is active. One option would be to use a hardware uart for that or HID feature reports that would make it impossible for a human user to control without a pc application.

    The best option would be to have hardware uart pins open and in hid mode setup a composite usb device with HID and CDC com port at the same time and if you don' need HID it just enables the CDC part.

    This is pretty hard to do with STs HAL libraries but should be the most compatible and usable option.

    So this is what i tried to setup and kind of succeeded until i found the reason why it would never transmit via CDC or break the HID part depending on the used endpoints.

    It turns out that the F4 only has 4 usb endpoints and HID needs two, CDC needs two or 3 with CMD and then there is EP0... So i need at least 5 endpoints.
    I could have spotted this by reading the datasheet more carefully which advertises "4 bidirectional usb endpoints". I thought that meant 4 IN and 4 OUT each but that is ~~not~~ the case. *it is. i had the buffers set incorrectly.*


    Now there are some options for the next iteration:

    • Stay with F4 (Limited endpoints but should still work)
    • Hardware uart interface and have 2 usb ports and F4
    • STM32F103RC without HW float (not really needed but nice to have)
    • STM32F7 (much more expensive, way faster and generally overkill)
    • STM32F2? Still a cortex M3 like the F1 but a bit more capable in terms of usb and speed.

    At the moment i would probably try the slower and cheaper F1 to stay in budget and keep the board small as there are some more modifications needed for the next iteration like braking resistors and anti backfeed.

    The pinouts are compatible and only the usb resistors would have to be changed to switch to an F7 or stay with the F4. Everything else is software configuration.

    The F1 would cost around 4.50€ in single quantities and very easy to get, the F4 almost the same with 5€ and the F7 would be about 8€ and make the device a bit more expensive.

    The F411 has a usable clock speed of 96MHz and the F1 only 72MHz but that is still more than enough. The F7 clocks at over 200MHz and is pretty overkill for the rather slow usage as most of the time is already spent waiting on spi and usb and the encoder is managed by a HW timer.


    I chose the F103RC for the second version because of the usb features and low price.
    This allows for a more versatile and user friendly configuration. Hardware float is not strictly needed because most if not all calculations can be done in fixpoint.
    The second version still retained the possibility for both F1 and F4 but was built with the F1.
    The F1 also has separate ADCs which could provide some separation for voltage measurement and analog inputs for gamepad axes and control signals.


    The next version will feature separate control and motor driver boards. And i might get back to the F411 as it seems like the endpoints would be sufficient and it costs the same as the F103.

  • First PCB tested

    Yannick (Gigawipf)03/28/2019 at 19:32 3 comments

    Finally the first pcb arrived and is tested to find any errors in the design and see if there are any major issues.

    Soldering everything by hand takes some patience but everything works as it should.

    A few problems spotted in the first design:

    1. Vias under the current shunts are too close to the pads and can be bridged to the resistor while soldering and short out the shunt voltage.

    2. Pullups of encoder were connected to 5v instead of 3.3v. Easy to bodge for now and fixed in the next version.

    3. 3.5mm terminals might be too small for big motor wires. Maybe add a 5mm footprint and move the caps and buttons.

    4. USB footprint from eagle not exactly the correct one for the ports. Drilled holes are in slightly different spots.
    Strange as the part numbers were identical and can be fixed by bending the mounting pins of the port inwards but should be changed to the correct one.

    Apart from that the driver and processor work correctly. I chose the STM32F411 as the main processor running at 96MHz. 2 LEDs for status messages, one power led and one direct driver flag led for critical errors are present on the board.

    And of course the gamepad communication is working with 16 buttons and 8 analog inputs.
    The encoder input is correctly scaled to 1080° of rotation and perfectly matches the virtual wheel in project cars.

View all 12 project logs

Enjoy this project?

Share

Discussions

paytufo wrote 3 days ago point

Wow!!! I'm realy shocking!!! Congrats!!!

Will this work to use with a bike as a turbo trainer with programs as zwift?? The idea is very similar but simulating inclination and some other fisic parameters.

  Are you sure? yes | no

Sean McVeigh wrote 02/28/2020 at 19:02 point

I'm working on a similar project to yours (even considering using TMC4671 early in the design stage, but I expanded my project to a custom FOC design). Its not for FFB, but does implement closed-loop torque control.

"INA232 shunt amplifiers are extremely common mode step sensitive despite very high claimed CMMR. The slopes are too steep while switching. This causes high noise in the measurements."

TI has an APP notes (sboa170b and sboa174a) and on currents sense amplifiers that describes this. There are three types of current sensing for an H-bridge: high side, low side, and inline. The TMC4671 expects you to use inline (at least the eval design uses it). One of the primary disadvantages of inline is the dV/dt. 

"We will also add low pass filters to the encoder and hall inputs as with some motors significant pwm noise gets back through these lines and causes glitches. This means even more components to solder :/"

Check out note sboa170b:

"For applications that require measuring current in a high dv/dt common mode transients like motor control and solenoid control, the INA253 is specifically design to reject PWM signals with a settling time of <10μs."

  Are you sure? yes | no

Crousti wrote 12/17/2019 at 14:37 point

Hi, i kind of stumbled on your project as i am currently making one myself.

I am using a stm32f4 discovery board,  a Xnucleo powerstep01 for control, a hybrid 2 phase stepper that consumes a maximum of 6A per phase, with a 1000PPR encoder.

I am trying to adapt the software  from simucube instead of MMOS, as it is supposed to work better, but it seems i still have a very long way to go.

I am also building a 8 speeds H shifter that will be connected to the board.

For now i'd really like to see the thing moving. I will surely follow your example and use the TMC driver when it is released, but for now i'd like to get the first step, with the powerstep.

It does not matter If it fries, or is not good enough. It will motivate me to continue ...
Since you abandoned the powerstep solution, would it be possible to get a look at your code ?

Thanks :)

  Are you sure? yes | no

Yannick (Gigawipf) wrote 12/20/2019 at 11:00 point

The main part will now be a stm32f4 based usb interface with a modular software architecture. This would be kind of an open source alternative to mmos if you are interested.
You could use it to also control a powerstep based motor driver. I can send you some ressources, but while it worked, it was also far from finished.
Therefore the new modular software approach.
The first boards for that should arrive soon. Think of it like the top half of the old board with a bunch of headers for extension and your own motor drivers.

  Are you sure? yes | no

julien.greffeuille wrote 12/04/2019 at 18:18 point

Hi Yannick, i'm looking to make a diy nema 34 based steering for over 2 years, i'm now in first year of electronic school (hopefully i would be able to created circuits like you one day :) ). I'm looking at your project for several months now and i would be glade to be one on the first to try this circuit when it will be finish.

  Are you sure? yes | no

Yannick (Gigawipf) wrote 12/05/2019 at 12:49 point

The next motor driver board will probably be made soon once the pcb design is final.
Its pretty much almost finished. I will post a log once it runs and if you have any requests you can message me via PM or the group chat.

  Are you sure? yes | no

Benjamin wrote 11/22/2019 at 21:27 point

It would be wonderful if you could add 2 axis/joystick force feedback to this project. An open source solution is much in demand.

  Are you sure? yes | no

Yannick (Gigawipf) wrote 11/23/2019 at 18:24 point

Currently not the main goal as i am trying to get a reference motor driver finished and the boards done, but certainly possible to implement later.

----
The design will be modular with the ability to have up to 3 motor drivers on one bus. It should be possible to implement that in software.

  Are you sure? yes | no

Dmitriy wrote 07/08/2019 at 10:30 point

Great project! Any chance you can show piece of code for maintaining constant torque while changing position? I'm just curious of powerstep01 capabilities

  Are you sure? yes | no

Yannick (Gigawipf) wrote 11/23/2019 at 18:21 point

I have used a foc like control scheme by sending bursts of step pulses to align the measured encoder angle to the current phase of the powerstep. Crude but worked. The the motor current was changed to set the torque together with a 90° phase offset of these step bursts. The next version will feature a real FOC motor driver and should run much better.

  Are you sure? yes | no

Daren Schwenke wrote 05/11/2019 at 19:35 point

I have always dreamed of a controller board which could handle both steppers and BLDC motors.  FOC applies to both in the realm of what you have done here.  The H-bridges required don't care if they are all bound to a single motor, so the same board could effectively handle both 3 stepper motors (6 H-bridges required), or 2 BLDC (3 phase delta wired) motors (6 H-bridges required) and use FOC control.  Just a thought...  :)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates