3D Printed Force Feedback Yoke

  • OK let's start from the beginning then. It may be trivial or redundant to you but here was my thought process in creating controllers:

    - Hardware, never mind, it's done and that's where we can do (I'm mechanical engineer too, so that part is easy)

    - The big main issue IMO is getting an interface with window that is easy and usable, so for that it has to feature HID connection (whatever that really is)

    - The processor or board has to have all input output needed for the project.

    Raspi doesn't have digital input output so much, so it's not great, but it can be coupled with some systems (arduino or others), but that takes over some simplicity it is now a compound system, more headaches.

    Teensy is what a lot of people seem to be using and has the right I/O but it's back to C programming. The one you linked (STM32F4) also seems very interesting and perfect but also in C programming as far as I can tell.

    Now for you project (FFB) it needs a bit more advanced stuff like motor controllers. so that's one more level of complexity.

    Simcube is great, seems all done, I can't find what or how to program it though.

    Following the links I found IONI controller

    And it seems to connect to all kinds of "brain" (PC, microcontroller, Raspi) but it's a PCI board, so not sure how that works.

    and then if I understand it requires "granity' software to configure, another thing to figure out. The interaction is controlled via simplemotion V2 another SDK to learn;(

    Let me explain my view of C programming before people flame. I've done some programming for years, so I don't have a fundamental problem with C programming (or C derivatives). I just don't know C and the syntax is the major problem of learning a new language. C syntax is not obvious, and not very flexible, so I would try to avoid it if at all possible for a more flexible language (easier to tinker with). Like you I don't want to spend a lot of time learning a programming syntax.

    - Therefore my next point: relative ease of programming. For that I like node red for sure but it may have limitations I have not yet figured out, and so far that I can tell it may not have all the functionality needed. Any block can be programmed so technically it's possible, but it's now Javascript, another language again. I would keep it in mind as first try for its utter simplicity to use, but it may not work in the end. I've found step motors controllers blocks, and some kind of DC controller, all sensors and reporting is easy.

    If node red cannot do it, My next programming effort would be Python or Ruby, more complex, but still not too bad I think. Python seems to be the more accessible with this kind of hardware, but I haven't yet found the whole chain easily implemented.

    More specific to your question:

    - Raspi is probably plenty powerful, it's basically like a full computer. It can handle all calculations and be programmed in all kind of ways (node-red, python, etc..). The problem is I/O, it has some, but not the one we need for FFB, so drivers need to be found and interfaced, and therein lies the issue I think.

    - There are microcontrollers and boards that can do the trick, and are programmable in some form of Python (Micropython, or Circuitpython), but they may not be powerful enough for this application. More research needed.

    - STM32 and other boards (teensy, etc..) that have direct motor controllers (simcube) are great in that sense, and seem directly designed for the application, but they all seem to be programmable in C or derivative, so it's just about learning that programming. Although there may be a micropython implementation for STM32 that may be of help.

    - Modifying existing FFB solutions, I don't know.


  • - Raspi is probably plenty powerful, it's basically like a full computer. It can handle all calculations and be programmed in all kind of ways (node-red, python, etc..). The problem is I/O, it has some, but not the one we need for FFB, so drivers need to be found and interfaced, and therein lies the issue I think.

    Michael thank you for your educational input, I really appreciate it.

    More on the subject, don't you think that DC motor shield /HAT for Pi would solve the pin problem? It's basically "plug&play" H-bridge.


    I thought using H-bridge driver would be necessary anyway, no mater what board/micro controller as I need to feed DC motors up to 5A current.

    Over and Out


  • Yes that looks like part of a solution. I don't think it can handle 5A so you'll need another board. This one has 2 DC, but probably low amps, it doesn't say.

    I2C is good enough, with documentation you can do pretty much whatever with node red, I couldn't find the doc though.

    This one looks more like it. It can handle 2 DC but only 5A total if I understand well.

    I guess you just plug it and use the GPIO to control it, that may work just fine with Node red.

    The advantage of I2C is that you can control pretty much as many as you need. This later one I think you're limited to one as it takes the whole GPIO connector. I couldn't figure out if more can be stacked or not.

    I see you have 2 DC so that would most likely be enough for this yoke. My project I have 5 axis (pitch, roll, yaw, throttle and collective)

    Another thing, is I don't know yet how to get the raspi recognized as an HID object, so that once connected through USB it will see the whole thing as a joystick.

  • I looked more into that simucube and Ioni drive thing.

    Ioni drives are really nice.

    Simucube is also a good thing, as it seems to somewhat simplify the development. However my understanding is that it supports only one axis.

    Prices are 1 IONI drive (€150) plus 1 Simucube (€170) and that gives one channel of FFB

    The solution for 3-4 channels of FFB is the IONI cube 4 axis (€150) plus 3 or 4 IONI drives (€150 each) but the IONI cube 4 is not directly controllable as a HID unit, so I'm not sure what it means in terms of in between boards or systems. (they have kits too)

    It's controlled through a C library (SimpleMotion V2)

    While a nice set of hardware, it seems higher price and more complicated to use.

    I think a Raspi, 3 of the controllers, a bit of node red programming and voila a solution for less than $100. Remains the interface between Raspi and HID USB input

    OK it gets better. With a bit of research, the Raspi3 or actually any but the 0 cannot be set up as HID slave. So the one to use is the raspi 0 W, which can be set up as HID, then 3 of the controllers (can use the same programming and plugging as a regular Raspi). The raspi zero W (wifi) is $10.

    I think and hope the zero can handle the load and requirements, it looks like it can from a brief overlook.

    So in conclusion and in theory a Raspberry Zero W, with node red installed, turned into an HID unit with 3 Cytron controllers and you have a full system for controlling 3 axis, you can do all the calculation combining, mixes, etc.. you may wish for $50. The raspi can also handle many switches and toggles and LEDs. It would need something else to handle digital I/O though. Programming is probably 1-2 days at the most using a mouse to move blocks^^. Oh and it could report on a web page, just as easily so you can also monitor or control stuff on it from a tablet or cell phone on the same wifi network, it's trivial to program. (yes I mean a tablet can read FFB or any parameter and for example increase force with a slider, or whatever you set it up to do as you're using the system)

    I'm not sure of all the details at this moment (mostly how to read/write the USB HID data from the node red blocks, this maybe, or this), but it looks like it should work.

  • And now I'm thinking but that's a bit more farfetched although not much that since FS2 can broadcast flight parameters to a port, it is probably possible to tune the FFB to said flight parameters (speed, altitude, weather, plane, etc..) and relatively easily.

    OK I have to read more about the FFB mechanical concept. IONI board can torque control motors, but otherwise it seems some shortcuts have to be used to convert motion/position into force.

  • OK I have to read more about the FFB mechanical concept

    love your enthusiasm, it's good to know there are people willing to contribute..

    speaking of which I exchanged few more emails with the guy I mentioned earlier (ED Forum). It seems that the wheels are turning the right direction.

    As I wrote few posts ago, conclusion was that the arduino pro micro has not enough sram to become fully loaded three axis FFB device therefore I started search for another controller but didn't really look into other arduinos..

    Until this chap pointed out, we could use the existing code that he's done and port it into arduino due. Due has enough power and storage to run all functions we need and the large portion of the code is already writen. I can see the light, no need to reinvent already reinvented wheel :)

    Well there's still lot to do but one difficult part is sort of taken care of. Apparently the pro micro board is detected by DirectX Directives as FFB device so it has natural support from any game that provides FFB output.

    Don't ask me how (for me this guy is a genius) but it works. Reading axis positions, comparing with desired direction/force, sending signal to motors and pot readings back to sim.. I can't imagine this would be done within two hours even with node-red :)

    Now as you pointed out earlier, there has to be really good UI (win app) where people can setup pretty much everything .. Also for many civil simulators default feedback isn't good enough and some don't even have one ;)

    So the need now is to write piece of software that would be able to tap into multiple sims, override default FFB output (or provide one based on flight parameters), allow user to adjust particular forces or turn them off, provide saving profiles, manage connection with the board etc.

    I ques the hardest part would be to describe individual forces with certain range of available tuning. However since we've had this passionate discussion with members of this group about FFB last time, I'm quite sure there will be an opportunity to get this right with so many real pilot around..

    Would you have any idea where to start with the app?

    Regards Jay

    Over and Out


  • I was also thinking that maybe Jeff or who's the admin here may want to move this topic to Dev. section if it's a sore thumb here..

    Yeah, not a bad idea. I just moved it.

    IPACS Development Team Member

    I'm just a cook, I don't own the restaurant.
    On behalf of Torsten, Marc, and the rest of the IPACS team, we would all like to thank you for your continued support.



  • sorry my brain is overloaded and my teeth are killing me for several days already..

    There is this guy who's working on the Arduino part and he's got large portion of the script working already as native FFB device.

    Currently it's running on Pro micro which has certain limitations therefore I started looking for another controller thus our discussion last night.

    Today I've learned that there is an option to port his script from Pro micro to Due (with some modifications) and extend the script because Due can handle that.

    So yes, this part is kind of sorted..

    However as it is basically the same device like MSFFB2 stick, it's useless for AF2 or other sims without enhancing plugins like FSforce or Xforce because FSX and Xplane's default force feedback is rubbish and AF2 doesn't have one!

    That's the second part of the race. There have to be "control program/driver/app" running on your desktop, with sliders, profiles, and the ability to extract flight data from AF2 for example. Since we have SDK it should be possible.

    After that this app will send two parameters (direction & force) into Arduino over USB.

    So the new task is to write such app.

    Hope it's clearer now..

    Regads Jay

    Over and Out


  • OK thanks.

    Some app would be needed for FS2, got it. I would start with a generic FFB (no ties to any particular of the flight), then maybe find a way to interpret flight data broadcasted. Not great but that's the best I can think of until we have access to more airplane parameters.

    Since you have now an arduino controller with some software, the best would be to continue with that, and like you say provide input info for the existing system. I don't have any solution at this point. I'll look more into it eventually.