Jump to content

Open Source Joystick FFB / DIY FFB Joystick


Berniyh
 Share

Recommended Posts

Cool.

 

I'm not expecting anything highly refined or anything.

Really I just want a testing rig to be able to try things out.

 

 

I've been trying to assemble a testing rig on my own but I just can't get things to work. In particular I've just got no idea what I'm doing in respect to the motors/gearing.

 

I've ordered a couple of 'N20' motors of eBay but it's such a hassle waiting for things to find their way round to this side of the planet ;)

SKU133076%20(1).jpg

 

Anyway, my 3D printer should be here in a week or so so hopefully I'll be able to get something working with that ;)


Edited by Slartibartfast
Link to comment
Share on other sites

  • Replies 419
  • Created
  • Last Reply

Top Posters In This Topic

Hi

I am using gears so I can get higher torkwith weaker/smaller Motors.

Using weaker Motors for testing is helpingso that I can use an easier to Setup test board. (Only a dual H-Bridge)

For the final Version everybody can usewhat suites him most. As Long as the Controller Output is supported.

MetalGear_Honk

The threemost dangerous threads to Programmers:

  • Fresh air
  • Bright sun light
  • The horrifying screams of singingbirds

Link to comment
Share on other sites

I think the best way to go is belt and not gears... too much backlash/play with the gears...

 

I agree, and it looks like belts may well be employed in the final solution but here we're just talking about scratching together a test rig to get an idea of how things work. The final version will be a great deal more refined and will most likely use belts (or possibly servo motors, or wound wire or perhaps even something else). For a test rig though gears are probably the simplest way to get something functional to work with, which is all we're discussing here.

Link to comment
Share on other sites

Hi

here are the STL's it is very WIP

you will need

1 Center1

1 Center3

2 Center4

1 Frame

4 bblocks

4 scews (2.5x12 spax)

8 Ballbearings 608

FFB_STL1.zip

 

the gears and Motors are still missing. but can be mounted on the 8mm rod.

 

MetalGear_Honk

The threemost dangerous threads to Programmers:

  • Fresh air
  • Bright sun light
  • The horrifying screams of singingbirds

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

For me, I only want something that properly simulates the force trim in a helicopter setup.

I don't need and actually don't want to have a flight stick that goes wild.

 

Not to distract you, but did you see this cyclic build (https://forums.eagle.ru/showthread.php?t=188055)? It handles force trim mechanically, much the same way as the Huey.

 

-Erik

i7 6700K - 32GB Corsair Dominator DDR4 - Corsair i100 water cooler - Samsung 1TB 960pro SSD - EVGA 1080ti FTW3 Hybrid - Gigabyte Z170X Gaming 6 MoBo

 

Oculus Rift CV1

TM Warthog HOTAS w/10cm stick extension & greased gimbals

MFG Crosswind pedals

 

Win10 Pro x64

 

DCS 2.5 (Huey & P-51, mainly; have all the other rotors, but haven't explored their depths as yet)

Link to comment
Share on other sites

Hi

 

sorry for the delay.

The Project is still proceeding.

I am working on the 16bit Axis and some shift registers to add some more Buttons. As soon as I have it working I will update the download.

At that point it should be able to use is as a working stick. But don't expect too much. It is moving and all but not all is as expected.

I am also working on the Gimbal design. I am happy with the version I printed. But I hope to add gears the design.

 

There is still many Bugs and missing effects.

 

MetalGear_Honk

The threemost dangerous threads to Programmers:

  • Fresh air
  • Bright sun light
  • The horrifying screams of singingbirds

Link to comment
Share on other sites

Ok, here's a different perspective that resolves many of the issues that have been discussed here, and addresses limitations in the motor/gear design, namely gear ratio, cogging, sensitivity, motor inertia/speed/torque, etc.

 

I propose a different route, that builds on the existing roller/cam design of current high-end joystick gimbals. The roller/cam design approximates increased stick pressure (centering) as deflection from 0 increases. The problem with this is it's static. You have to choose one cam profile that is the best compromise for all aircraft.

 

BUT, if you could dynamically reshape that cam profile in real time, based on feedback from the FFB protocol, you would not only be able to adjust the feel based on airspeed/stall, but you could have different profiles for different types of aircraft (little-to-no cyclic centering for rotary aircraft, for instance). If you were to break that cam yoke into two halves, you could alter their slopes to be steeper with higher airspeed, to flat for a stall. There could either be separate motors for each half (if differential forces were needed for each direction), or a single motor that operated both in a scissor-type motion. The advantage to this is that small, cheap, low-torque motors could be employed (brushed, brushless, stepper, servo, whatever), because altering the slope of the cam can be done with a worm drive mechanism. The rolling action of the gimbal is no longer limited by steps, play in the gears, backlash, or any of the other concerns inherent to directly acting on the axis.

This design also scales well to accommodate longer/shorter stick lengths, as the only difference need be the shape of the cam, not the strength of the motors.

 

The downside is that the available effects are those related to airspeed and forces on the control surfaces. I would argue, however, that this provides a more accurate simulation. Why would you wish to introduce effects from cannon fire, landing bumps, etc. into your control axis, anyway (especially since hall sensors will pick up such events as control inputs)? Doing so makes sense in driving simulations, since the wheel has a more direct and stronger contact with the driving surface. In Aircraft simulations, however, such effects (vibrations and shocks to the airframe) are probably better executed through a tactile transducer mounted to the enclosure, and directed there via software. Keep the stick forces related to the control surfaces (turbulence forces can probably be accurately transferred to the stick via "warbling" the cam profile).

 

I realize this represents a big departure from the current designs being talked about, but I think the benefits, in terms of complexity, cost, and fidelity make it worthy of consideration. I haven't had time to mock-up anything in SketchUp as yet to give a visual of what my idea is (my 3D modelling skills are very amateurish), but I'll try to put something together.

 

-Erik

i7 6700K - 32GB Corsair Dominator DDR4 - Corsair i100 water cooler - Samsung 1TB 960pro SSD - EVGA 1080ti FTW3 Hybrid - Gigabyte Z170X Gaming 6 MoBo

 

Oculus Rift CV1

TM Warthog HOTAS w/10cm stick extension & greased gimbals

MFG Crosswind pedals

 

Win10 Pro x64

 

DCS 2.5 (Huey & P-51, mainly; have all the other rotors, but haven't explored their depths as yet)

Link to comment
Share on other sites

Im currently building a prototype based on ¨indirect¨ force feedback with worm gear motors. I had also done 2 others prototypes with a direct gear motor and a cam based centering.

 

This is the 3rd and current prototype without any cams, the centering force feel fine, it look like some mods done for the Thrustmaster Cougar. Everything pivot point are on ball bearing and digital (i2c) Hall effect sensor will be used, so even without the functional FFB the feeling should be great. To simulate different force, I was thinking of using the motor in a more dynamic way like following the stick to reduce the spring force instead of simply offsetting them from 0 like a helicopter force trim.

FVXsje9.png

2te5au6.jpg

 

The new PCB design is almost finished and the boards for the new Hall effect sensor are ordered, I should be able to have something working in a month or two if everything go wells. The source code of the FFB stick is also mostly done to be able to check the functionality, it even have a CLI interface:megalol: (the first prototype firmware will still need some fix)

 

The first prototype with direct geared motor was probably too strong. The force and feeling when pushing against theses brushed and geared motors was not great, the coggig of the motor was quite bothersome. The force was strong enough to be able to lift a Thrustmaster Warthog from horizontal with about a foot long extension.

 

The second prototype with cam based centering had a loose center, the shape I used for the cam was probably wrong and the springs I had were too weak.

 

An album with the other prototypes pictures:

https://imgur.com/a/5bji6

 

Ok, here's a different perspective that resolves many of the issues that have been discussed here, and addresses limitations in the motor/gear design, namely gear ratio, cogging, sensitivity, motor inertia/speed/torque, etc.

 

I propose a different route, that builds on the existing roller/cam design of current high-end joystick gimbals. The roller/cam design approximates increased stick pressure (centering) as deflection from 0 increases. The problem with this is it's static. You have to choose one cam profile that is the best compromise for all aircraft.

 

BUT, if you could dynamically reshape that cam profile in real time, based on feedback from the FFB protocol, you would not only be able to adjust the feel based on airspeed/stall, but you could have different profiles for different types of aircraft (little-to-no cyclic centering for rotary aircraft, for instance). If you were to break that cam yoke into two halves, you could alter their slopes to be steeper with higher airspeed, to flat for a stall. There could either be separate motors for each half (if differential forces were needed for each direction), or a single motor that operated both in a scissor-type motion. The advantage to this is that small, cheap, low-torque motors could be employed (brushed, brushless, stepper, servo, whatever), because altering the slope of the cam can be done with a worm drive mechanism. The rolling action of the gimbal is no longer limited by steps, play in the gears, backlash, or any of the other concerns inherent to directly acting on the axis.

This design also scales well to accommodate longer/shorter stick lengths, as the only difference need be the shape of the cam, not the strength of the motors.

 

The downside is that the available effects are those related to airspeed and forces on the control surfaces. I would argue, however, that this provides a more accurate simulation. Why would you wish to introduce effects from cannon fire, landing bumps, etc. into your control axis, anyway (especially since hall sensors will pick up such events as control inputs)? Doing so makes sense in driving simulations, since the wheel has a more direct and stronger contact with the driving surface. In Aircraft simulations, however, such effects (vibrations and shocks to the airframe) are probably better executed through a tactile transducer mounted to the enclosure, and directed there via software. Keep the stick forces related to the control surfaces (turbulence forces can probably be accurately transferred to the stick via "warbling" the cam profile).

 

I realize this represents a big departure from the current designs being talked about, but I think the benefits, in terms of complexity, cost, and fidelity make it worthy of consideration. I haven't had time to mock-up anything in SketchUp as yet to give a visual of what my idea is (my 3D modelling skills are very amateurish), but I'll try to put something together.

 

-Erik

Link to comment
Share on other sites

Hi

looks interesting.

Are you using the Motors as counterweight?

And how do you simulate near Stall speeds (loss of control Authority)

how do you integrate the FFB communication in your controller?

And what controller are you using?

I have so many questions :-)

are you willed to share some more information’s with us?

 

MetalGear_Honk

The threemost dangerous threads to Programmers:

  • Fresh air
  • Bright sun light
  • The horrifying screams of singingbirds

Link to comment
Share on other sites

Uhhhhhh THANKS for the 6 hour long video... Any chance you give us a hint where in this video there is a reference to the FFB stick you posted an image of? I just cannot watch 6 hours of that.

 

39:30

i7 6700K - 32GB Corsair Dominator DDR4 - Corsair i100 water cooler - Samsung 1TB 960pro SSD - EVGA 1080ti FTW3 Hybrid - Gigabyte Z170X Gaming 6 MoBo

 

Oculus Rift CV1

TM Warthog HOTAS w/10cm stick extension & greased gimbals

MFG Crosswind pedals

 

Win10 Pro x64

 

DCS 2.5 (Huey & P-51, mainly; have all the other rotors, but haven't explored their depths as yet)

Link to comment
Share on other sites

Hi

looks interesting.

Are you using the Motors as counterweight?

And how do you simulate near Stall speeds (loss of control Authority)

how do you integrate the FFB communication in your controller?

And what controller are you using?

I have so many questions :-)

are you willed to share some more information’s with us?

 

MetalGear_Honk

 

The motors are not used as counterweight, one of the axis is sitting level because the motor is in-axis with the gimbal, while the other axis is tilted in the picture because the weight of the motor is pulling on one side. This is intended to be a floor mounted joystick with the rotation point somewhere halfway between the seat and the floor. There will be a counterweight under pivot point to balance the grip and to keep it neutral on all axis.

 

I was intending this as mostly a helicopter force-trim, but I think I can simulate control loading by moving the motor depending of the axis position.

 

Im currently using a overkill STM32L476RG (about 9$), I could use a cheaper micro controller but this kind of optimization is not worth it a the low production count sim equipment have (and I might only produce my stick... ). The controller is detected as a FFB stick and I can receive the command that DCS send to the stick. That code was done about 1 or 2 years ago so im a bit fuzzy on the details.

 

There are 2 hall sensor per axis, one of them is used to send the data to the computer without any backlash. The other sensor is used to read the position of the offset created by the motor, the difference between the 2 measure will be used to control the offset created when the cyclic is trimmed.

 

I also intent to link a set of FFB pedals with the same controller, this will enable force-trim on the pedal when the stick receive the trim command.

 

The board also have connections to read and send the button press of a Thrustmaster Warthog, I intend to intercept theses button press to be able to set a force-trim in simulator that does not support FFB.

Link to comment
Share on other sites

Hi

with the Liking up a FFB Paddle du you mean to add another USB-Class to the controller?

Or do you know a way to integrate more than 2 Axis into a FFB-Class?

And would it be possible to give me/us some insight in your code?

I would love to get a look at your effect calculations so I can copy those that I am not able to get working. :music_whistling:

 

MetalGear_Honk

The threemost dangerous threads to Programmers:

  • Fresh air
  • Bright sun light
  • The horrifying screams of singingbirds

Link to comment
Share on other sites

For the pedals I was only thinking of faking the ffb and make assumption based on the commands received to the XY axis and send similar force command to the pedals. From what I read and remember DCS does not support 2 FFB devices, so only the stick will be properly detected as a FFB device, and I will simply add another axis on the USB controller to send the positions of the pedals.

 

This is mostly for force-trim on a helicopter, so when the XY axis will receive a different spring center command, I will also change the spring center on the pedals. Either that or I will intercept the trim button press on the stick and will change the spring center of the pedals that way.

Link to comment
Share on other sites

  • 5 weeks later...
Actually I don't recommend using the driven pot circuit at all, or any other diy interface because it represents an astronomical amount of work and very limited usability. I recommend instead using a MSFFII modified to output 400% the stock torque and connect that to real motors using your own psu in the form of simply 24 power bricks. No idea what you mean by 'threat' lol.

 

As to shaft winding, as far as mechanical systems go you are not going to find much simpler an arrangement to construct, especially one with no backlash or cogging which are (or should be considered) deal breakers for what you are trying to do. Steel cable is subject to creep and stretch and would eventually need tightening however kevlar (Spectra/Dyneema etc) is not. Such a system would req little if any tuning and it would be pretty straight forward to incorporate a cable tension mechanism where it mounts on the bellcrank, or even little idler pulleys.

 

Steel cable is like a rubber band made of stabby needles though, where it elongates some 35% at break vs kevlar which is more like 3.5%. Kevlar also doesn't poke holes in your fingers and instead feels like a waxy shoelace. There are rl aircraft that use it over steel now in control circuits.

 

Best of luck whatever you guys decide...

 

 

 

I hate self-quoting, but it's relevant to my current thoughts and plans and it made more sense than editing a buried post...

 

Now that Condor2 (sailplane/soaring sim) is soon releasing(!), I'm really keen to get a force feedback stick working in short order. The Condor devs have MSFFII sticks and really use them to great effect (rl glider pilots that have tuned the game to that stick... I fly glides too and can they did indeed do a good job of it and have provisions for pedals too along with UDP output streams for motion platforms etc) here so it reinforces my inclination to use it as the interface vs rolling my own. For now I'm just soldering some resistors in a MSFFII to double the current with the existing hardware to run a longer stick, much like in this example.

 

Later I'm going to double it again (400% original current, like this example), which req upgrading some diodes/caps/mosfets and using my own power supply, in this case a 24v 7a power brick. I found reasonable priced/sized motors suitable for this, brushed 24vdc servomotors with skewed armatures designed to minimize magnetic cogging. Pittman Lo-Cog 14000 series have good form factors for this too.

 

My long winded preamble that makes it relevant to this thread that has different options for all of the above, is that I have revisited the idea of belt drive again for power transmission. After seeing how Fanatec uses belts in their excellent wheels it got me thinking. Then after looking at the cross-section of HTD belts with their semi-circular teeth it seems apparent why the 'zipper effect' is so minimal on their gear.

 

Auto_Timing_Belt.gif

 

They don't use HTD but something very similar but one of the things Fanatec does that makes theirs behave so smoothly is use idler wheels to increase the contact area the belt is on the pulleys. Here's the pic that shows ~270deg of the pulley in contact.

 

CSL-E-RW-PS4-M02.png

 

 

 

 

 

 

 

 

 

Getting the wrap ratio really high like that will go a long way to minimizing the effect each individual tooth makes when coming in contact with the pulley, thus minimizing the tactile effect. This combined with the rounded tooth pattern of HTD belts should be subtle enough to be a non-issue for this application, so I plan on getting some HTD 3m x9mm belts/pulleys to build with. If it turns out to be an issue, I can always switch back to shaft-winding using the same hardware and COTS solutions get the ball rolling.

 

Another issue I've been considering which I brought up earlier was mechanical advantage ratios. Again looking to the MSFFII as a benchmark to draw from, I'm going to stick with their 24:1 ratio (+/-15 deg stick travel = +/- 1 full motor revolution). My thinking is this. Microsoft had real engineers really think their design through, including min/maxing torque advantage vs undesirable inertial effects. Although the motors I'm going to be using are bigger/heavier, torque equations scale linearly so the true min/max ratio would still be in the same ballpark, given similar motor construction so seems an ideal baseline. Unless I'm putting 2 and 2 together and coming up with 22 :p

 

TL;DR: I changed my mind about belt drive in light of Fanatec hardware, and think 24:1 gear ratio MS used in the FFII is likely the ideal ratio as a starting point

Link to comment
Share on other sites

Those motors are expensive.

 

For motors suitable for FF they are quite reasonably priced, and because they are brushed they don't require an expensive drive to go along with them and can be told what to do by a modded MSFFII. By suitable I mean they have skewed armatures to reduce magnetic cogging (reluctance torque). This property is not a given for motors (uncommon in fact) but a key ingredient for force feedback because power needs to be smoooooth even though the motors are barely moving.

 

Once you get into applications that req high torque/low RPM you are no longer shopping for just any old motor that happens to fit or look good on paper. Also, Pittman makes a lot of these so they can actually be found as surplus or used, making them more attractive than any other options I've considered for this in a long time.

 

Whether brushed or brushless, if the motors you want to use were not -specifically designed for low rpm/high torque- it's a recipe for disappointment for FF. Here's a chart for brushed motors showing cogging vs rpm, comparing a straight armature vs a skewed one: https://www.infolytica.com/en/applications/ex0075/

 

Speed%20vs%20TORQUE%20in%20SKEWED%20UNSKEWED%20MOTOR.png

 

If you know where to get cheaper motors suitable for FF, brushed or brushless I'd be interested in adding them to my bookmarks.

 

My post was not about the motors but aimed at validating belt drive as power transmission, and bringing up the 24:1 gear ratio since I think 50:1 is the last I remember being seen thrown about. I talked down belt drive in several previous posts but have since changed my mind after looking closer at the belts themselves and how Fanatec uses them once I realized how nice their wheels are and it seemed relevant to this thread.

Link to comment
Share on other sites

There's that word again. Spending $400 on motors before anything else is not reasonable for most people.

 

 

 

Motors are the heart of these things that without suitable ones FF is a nonstarter so by all means please show us all and link what you think are reasonable cost motors that are suitable for FF.

Link to comment
Share on other sites

If the gear ratios need to be increased so we can use a higher RPM, so be it, pulleys and belts are cheap. If I have to put up with a tiny amount of cogging that'll be damped somewhat by the backlash in the belts anyway, that's ok. I'm not saying you can't burn money if you want to, but consider the rest of us in your design. Because ultimately accepting some very minor flaws to get decent force feedback is far more reasonable than not having any force feedback because a very small number of people are happy to throw large sums of money chasing diminishing returns. Excessive amounts of money are what make it a non starter long before any minor inconveniences, so please consider the what is achievable to us with less money to spend in your design.

 

https://www.xsimulator.net/community/threads/diy-ffb-steering-wheel-mmosffb-in-progress.7769/

If these guys can build better than commercial racing wheels with $35 motors there shouldn't be any reason why we can't do similar.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...