YukMingLaw / ArduinoJoystickWithFFBLibrary

An Arduino Joystick Library With Force Feedback Feature
GNU Lesser General Public License v3.0
216 stars 56 forks source link

cpOffset from Spring Effect troubles #18

Open BenjaminMeier opened 3 years ago

BenjaminMeier commented 3 years ago

First a great thank you for this library!

Thanks to this i restarted my ffb stick project for use in Condor2.

When using ForceTest or force_edit everything seems to work fine, however when i try to use the test setup with Condor2 i do not get the desired change in CenterPoint of the spring effect when i change the trim. This works fine with my old msffb sidewinder2. I tried to have a look at the usb packets with USBlyzers 33 day free trial but i dont seem to find where it is going wrong. The Negative and Positive Force coefficients work (change with changing airspeed).

This is the last step missing to move from my proof of concept onto a real working setup. Does anybody experience this with other software as well? Or does someone know where it could go wrong?

LeonardoOnlyTrim.zip

SchmidtFranz commented 3 years ago

Do you have any news to this problem? I had the same poblem and using this old fork rectified the problem with the offset spring center, i have no idea why but with this it works.

https://github.com/jmriego/ArduinoJoystickWithFFBLibrary

jonlidgard commented 3 years ago

There is a problem in the effects calculator. It doesn't correctly implement the PID specification:

If the number of Condition report blocks is equal to the number of axes for the effect, then the first report block applies to the first axis, the second applies to the second axis, and so on. For example, a two-axis spring condition with CP Offset set to zero in both Condition report blocks would have the same effect as the joystick self-centering spring. When a condition is defined for each axis in this way, the effect must not be rotated.

If there is a single Condition report block for an effect with more than one axis, then the direction along which the parameters of the Condition report block are in effect is determined by the direction parameters passed in the Direction field of the Effect report block. For example, a friction condition rotated 45 degrees (in polar coordinates) would resist joystick motion in the northeast-southwest direction but would have no effect on joystick motion in the northwest-southeast direction.

The spring effect is being sent with the DIRECTION_ENABLE flag set (not individual axis enable bits) but with 2 parameter blocks (X & Y). The code is seeing DIRECTION_ENABLE & setting condition var to zero so it's only applying the first parameter block, regardless of the axis i.e. the Y axis is using the X axis parameter block. The code needs to count the number of parameter blocks set (as the effect get's built from the HID reports) & if more than one block, apply the relevant parameter block to each axis. If there is only one parameter block, then the effect needs to be scaled by the angle_ratio. (paragraph 2) I had the same problem developing multi-axis code for OpenFFBoard &, after studying the HID reports using USBlyzer & the output from FEdit.exe, this is the fix. Now in XPlane, when I trim the cpOffset moves the pitch (Y) axis correctly. Luckily, it's an easy fix.

SchmidtFranz commented 3 years ago

Jonlidgard, thanks, for your input on this, what you wrote is way above my head (the low level usb stuff), but I can recommend you to look into the FINO fork of this library, Wich is maintained and receives regular updates/fixes, with a very responsive creator. We also identified another problem Wich has to do with the groves effect not working properly in forcetest exe.

jonlidgard commented 3 years ago

Thanks, I'll take a look - is this issue fixed in the FINO fork?

SchmidtFranz commented 3 years ago

As far as I can tell yes, but I have to take a closer look at the weekend again, if you find issues with this fork just open a issue and the creator is looking in to it.

jonlidgard commented 3 years ago

Ok great, I'll take a close look. In the meantime I've just sent a Pull Request with it fixed (needs testing)

SchmidtFranz commented 3 years ago

I don't think this pull will be merged because the last activity was in late 2020 and since then nothing happened with this library.

jonlidgard commented 3 years ago

Well I've had a quick look at FINO (both branches) & it doesn't appear to be fixed there either. My code is here: https://github.com/jonlidgard/ArduinoJoystickWithFFBLibrary/tree/conditionEffect It needs someone to test it as I don't have an Arduino setup but should work as it's a copy of what I've done with OpenFFBoard.

jonlidgard commented 3 years ago

Probably better merged into FINO if this isn't being maintained.

SchmidtFranz commented 3 years ago

Just wanted to write that, if you have time maybe you could merge this with fino

SchmidtFranz commented 3 years ago

In a bit (next week if the shipping goods give it their approval) I will have a proper test setup done with encoders and bldc motors to test everything