Jump to content

Open Source Joystick FFB / DIY FFB Joystick


Recommended Posts

  • Replies 419
  • Created
  • Last Reply

Top Posters In This Topic

Hi

@Dracoz

Yes I use some Floating-point Calculations and of course sin/cos for Directions

I tried to use Lookups for Directions but getting Problems with Memory space as I have to save most Memory space for preloading the Forces. (the ATMega16u4 can Only save 15 Forces in my Code)

As for Interrupts I only use one timer-interrupt for counting up to get milliseconds since force start.

 

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

You might want to look at a different processor. If you are used to the atmel dev environments then maybe the cortex chips would be better and you can still get cheap dev boards to base a FFB controller around.

 

I have used the arm cortex line from TI and I reckon it wouldnt be too hard to port code over from the mega the cortex.

Link to comment
Share on other sites

MetalGear, that's what I thought. I had considered all these issues a few years ago as well when speaking about the same issues with Grendel on the 3DPVert. I don't profess to have solutions to them, but that's just the point - the solution is to spend time massaging the code to work, and if you make any changes to the code later, it results in significantly messing up the timings again and lot's more time wasted trying to re-fix the timing. It's a never ending problem. The solution is to have a processor that is fast enough to put all timing related stuff in an interrupt, or timer driven loop, and all other work is done outside of that loop as time allows. On an 8-bit ATMega, that may be difficult, but with a modern 32bit processor, especially one with better built in USB support, it might significantly ease the process.

 

Most my experience is with ARM7 architectures (Phillips, now NXP 2000 series). For timing, I've used a timer interrupt to make sure all timed events happen at a specific interval. For example, I was working on a system were serial busses like I2C were being bit banged (all done in software, no hardware assist) and the timing is critical. I guess that's what you are doing using an interrupt to count ms since start. Then all events occur on intervals of some number of ms in your primary loop. This has worked well for me in data acquisition tasks in the past, but I didn't do USB which is much faster than the I2C stuff I did - well, assuming USB 2.0 support perhaps.

 

 

I bought another Teensy 2.0 so I can dive back into the adapt-ffb-joy projects and start where I left off a couple years ago. But I have always planned to move to a 32-bit processor with much better capabilities, RAM, and ROM, and better USB hardware support. They are so cheap these days. The only reason for me to stick with the Teensy 2.0 is because as I'm learning, I wanted to stick with what the Adapt-ffb-joy project started on. My next goal was to re-write my own code on a TI processor or similar (32 bit with good memory and good USB support).

Link to comment
Share on other sites

Hi all

I was also thinking about using a 32bit MCU but as I am/was not active working on FFB I skipped the idea. I was programming 8bit MCU at Work so I stuck with them.

I was thinking about exporting the USB communication inside an Interrupt Routine. With fixed Timings. And let the FFB calculation run in main. So I will not lose connection. And the FFB Timings are not as critical.

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

If the USB timings are the main concern, then yes, export that to the interrupt routine and see if it works better.

 

Also, if you are missing button push events, it might be a good idea to debounce them externally using a debounce circuit (something to make the key press a little longer as well as debounce it) so if you are in the USB interrupt routine, you don't have to catch every button press exactly on time. We haven't had to use hardware debounce circuits for a couple decades, just re-sampling in software. But in this case, a hardware debounce circuit might be a good idea. There may even be an I2C GPIO chip that does this for us. The goal is to off load stuff from the CPU - not because the CPU can't do it, but because the time you'll spend making the software do it well might not be worth the effort when a couple dollars in external parts might make things much easier.

 

Alternatively maybe place the button detection circuit at the end of the USB routine in the Interrupt routine. Keep it simple to detect a button press, but do the debounce in software outside the interrupt routine in your main loop.

 

As for analog sensing, I would hope it isn't so critical that it be sensed on a regular schedule. If there are long delays between sensing analog movement, you can probably average the analog signal and extrapolate (if that is even needed).

 

Forgive me if I am suggesting stuff you have already thought of.

Link to comment
Share on other sites

Hi

Any Idea is welcome.

For Buttons I normally use Shift in (HC165D). 4 in daisy and a second set for parallel reading the second chain. That way I get 64 Inputs. And you do not need denouncing. The load pin takes care of it. As you only set load active for 2-4 Cycles. Thru that can result in a few millis delay in triggering a button.

Reading the shifters in main will allow the MCU to send Status even if a Chain is not fully read in.

For analog Inputs I normally use an ADS1115 for 16bit ADC it communicates thru I2C and is set to constant reading. And it Needs 3Byte per Port. So it takes 12 Byte for all ports to Transfer.

That Setup is working on my actual Setup. And it will be implemented in my MK2 (if I ever get it done).

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

  • 3 weeks later...

Hello

I made a Little Progress with the Software.

The Device is not losing connection anymore. And I can trigger different Forces with FEdit (or any other test Program)

My new main Problem is that it seems that the Attack Timings are no longer correct, and I still have some Forces not working.

I can upload the new Version if someone will test is as well.

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

Hi. I am studying production technology. I have solid works on my hands I am still new to it but learning fast. I you need some custom parts or potential design prototypes that can be printed by 3d printer laser cur or CNCed I could try to give a hand. My first internship big project due next yer. Would love to use the free time to practice. PM me if you want some brainstorming in shaping the joystick.

 

Currently I am trying to fool around with arduino and make myself a switch/trim board.

Link to comment
Share on other sites

  • 2 weeks later...

Hi

Looks very promising. Plenty of stuff to burn. :-)

I was a bit busy building a new conventional Joystick. So I have did not work much on the Firmware.

But I will try to Setup plans for some Controller. So I can test the Software in more Detail.

The threemost dangerous threads to Programmers:

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

Link to comment
Share on other sites

  • 2 months later...
Heya guys,

 

Any progress on this subject? There are now on market two great joysticks where I can see a lot of potential in adding this custom FFB....

 

Thank you!

 

Unfortunately it looks like this project has died. It is sad because it was a fantastic initiative. I would like to be wrong of course.

[sIGPIC][/sIGPIC]



KG13 Control Grip Building

Control Stick and Rudder Design



 

i7 8700K, Asus Z370-E, 1080 Ti, 32Gb RAM, EVO960 500Gb, Oculus CV1

Link to comment
Share on other sites

I can't speak for the others, but I am still interested in this and I still plan to hook up the Teensy board I bought to an existing FFB stick I have as a test platform and do some work on the software from MetalGear. But it is about 5th on my list right now unfortunately. I am working on some other joystick/game controller related projects first.

Link to comment
Share on other sites

  • 1 month later...

Back from dead or something?

 

I'm also still poking around the concept. At work I have access to all kinds of nice & necessary equipment, and have lately been working eg. with industrial servos (the sort familiar from OSW). Although those wouldn't be a reasonable DIY solution, I'm thinking on trying them out to get more understanding on limiting factors, values etc; it's easier to "dumb down" servos with software than upgrade hardware.

 

MetalGear_Honk, could you post the source code here or on github? Integrating to and extending your software could be the easiest path here (as MMOs FFB system only works with one axis, and the developer doesn't seem to be interested in more development.) I could also look at the effect problems at source level.

 

hegykc. reading telemetry and building FFB effects on that like you suggested is a path that has been and can be used, although it needs a bit of work for each simulator. I'd like to add that it has one option that you kind of mentioned: gun effects. Because - rant warning - I've seen enough games and even simulations having insane gun FFB effects. Yes, technically firing the gun creates a force, but the scale! A Bf-109 weighs 3 tons, P-47 6 tons - firing a gun doesn't throw the plane around much, and definitely doesn't throw the _stick_ around related to the plane. Some Logitech FF joystick hardware layout made it even worse, with the motor jerking potentiometer around and effectively ending the gun run right away.

So.. with DIY/OSS solution, one can either 1) skip creating gun effects altogether or 2) if using USB interface, possibly identify (on per-game basis) the gun effects(sine, ramp, ...) and switch them off.

 

Regarding motors I'll throw in a couple links. First, steppers are out as-is, with "normal" control they simply can't deliver what's needed. But this is quite interesting, more advanced control for a stepper:

https://hackaday.io/project/11224/

Next, a controller for using hobby grade brushless motors for servo-type control. This could be a option between plain DC motors and expensive real servos:

https://hackaday.io/project/11583-odrive-high-performance-motor-control/

 

Everybody, thanks for good input on this thread. Hopefully this will lead to something!

Link to comment
Share on other sites

Hi

I had to put my FFB Stick on hold oncemore.

I deeded a new Hotas so I was busybuilding one myself. (Will Show pics when I have all Setup and ready)

My code is not very public friendly andeven parts of it are not my own work. So I would need to ask around first if Ican post it.

On another note I started on a test environmentfor the FFB. I use DC Motors and Hall sensors it is working out quit well. AlsoI currently use very weak DC's.

As I got still Problems on Timings I wasthinking of changing to the much stronger asm Chips. But that would mean torestart from scratch.

MetalGeaar_Honk

The threemost dangerous threads to Programmers:

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

Link to comment
Share on other sites

Hi

I restarted the FFB Source again.

First I am hoping for some help inoptimizing the code.

But as it is very chaotic I would need toclean it up first, and ad comments (now my code is documentation for me :-)

Is there someone with some mc knowledgeand willing to help? Otherwise I see no Need to order my code and can work onit as it is.

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

  • 2 weeks later...

Wow, I just stumbled across this discussion and devoured every post in eager anticipation of the result but just a few posts from the end was surprised at how the wind just seemed to fall from the sails. What's happened?

 

For my part I have been working on building my own joystick but ran into trouble when it came to designing the centring mechanism so have been scouring the internet for Open Source/DIY threads about joysticks when I happened across this one. I absolutely love the concept of this project and would like to encourage its continuation in any way I can. I myself am a software engineer/developer with many years of experience and would love to contribute to this project however I am a rank amateur when it comes to electronics, but do let me know if there is anything I can do to contribute.

 

The reason I am designing my own joystick is that I am wanting to build a sim-pit that represents the ergonomics of a glider and have been completely unable to find a suitable joystick for such a build. The best I can find are helicopter cyclic controls however they are extremely expensive and are still a relatively poor approximation of a gliders control stick, so I've been building my own. I have run into problems though when it comes to implementing the return to centre spring (especially if you consider trying a add a trim control to the mechanism) so this FFB approach seems perfect for my needs! For my part the joystick I'm building is to be about 250mm in length but will only require a relatively light touch in terms of feedback.

Link to comment
Share on other sites

Apologies if this has been mentioned already as I didn't read the entire thread, but Microhelis.de has a force trim module in development for their helicopter cyclic that should become available pretty soon. They have a working prototype and at least one person on the DCS forums had the opportunity to stop by their shop and try it out!

 

I'm very much looking forward to that myself.

[sIGPIC][/sIGPIC]

Demo of my 6DOF Motion VR Sim:

Link to comment
Share on other sites

Hi

I am still working on the FFB.

For a Centering I also found that themost difficult part.

For the Project:

I am working on a 3D Printed Version forthe Gears and Motor Mounts.

So it is easier for everybody to replicateand test.

I am not an 3d-Artist so it is painfulslow in Progress.

The MC is still the STK600 from Atmel but Ialso started to use a ProMicro clone. I am not very happy with the ArduinoBootloader and so I might switch it in favor of the Lufa Bootloader.

But all that depends on the ability to getthe Angle calculation speeded up. Or at least split up between USB send Cycles.

Greeting

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

Hi all

I have a Raspi here but it is natively aUSB-host not a USB-device.

I have no idea if it can be changed.

An alternative would be a CortexController like the SAM series from Atmel.

But I don't have one around.

@Sokol1

Do you have any info about thatStick?

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

While googling for FFB stuff I found out that Grendel's old adapter for MS gameport joysticks has been "updated", and it now supports FF on Sidewinder FFB gameport version. The code can be found at https://github.com/tloimu/adapt-ffb-joy and seems to be useful for this project too.

 

Beefier MCU than AVR would indeed be a smart idea, though. AVR starts to be a bottleneck if one would eg. implement vector control (for brushless motors) to reduce commutation jerk - a lot can be done, but it doesn't make sense to spend time fighting with a small (but equally expensive) MCU. Raspi was mentioned; the regular ones can't be used as USB devices, Raspi Zero can be but it doesn't (iirc) have ADC inputs or such. Lighter cores such as STM32* would be suitable. I recall someone mentioned doing development on ARM & FF?

 

http://imgur.com/a/zfItq Nice.. Linear motors and what not. Guess we'll hear more soon. And the book under the joystick tells me this is no Joyrider (google it up)

 

Slartibartfast: I'm participating in a similar project, simpit in a glider hull. Pretty much at starting point, and summer (flying season) doesn't help. How's your project going?


Edited by jusu_d
additional comment
Link to comment
Share on other sites

  • Recently Browsing   0 members

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