Unclear "direction" definition

[barsk]

Hello and very sorry to make this an issue. How do you even send a message to a github user?

I am using your excellent library for making a yoke (a flight control wheel with two axis). The wheel can move left and right (X-axis) and in and out (Y-axis). That is all and well, and I have the Joystick part set up and working fine. It tracks just as a joystick.

However, I have been struggling with setting up the FFB forces correctly and that is due to the lack of definition of what a "direction" as per the USB PID specifications mean. I have ended up with getting spring forces to work perfectly, i.e centering the device. But when used in a gaming scenario with MS Flight Simulator for instance (with the XPForce plugin to provide FFB) I get some mirrored effects on the Y-axis. I.e the yoke should pull itself forward because of the weight of the elevator when parked. But instead it get pulled out, which is totally wrong.

Now, this is NOT a bug in your code. I am merely trying to understand what the direction angle mean. There is an excellent free tool (ForceTester.exe) which I guess you are aware of that provides a way to test this with constant force + direction. Now, what way should the yoke go for the direction: 90, 270 (x-axis) Which is left and which is right? Same for y-axis. Direction 0, 180. What is toward you (yoke pulled out) and what is away from you (yoke pulled in)? I need to understand what the direction angles mean so I can correct the code properly.

Again, sorry to make an issue of this instead of a message or chat somewhere.! No idea how to reach you for this pretty fundamental and easy question.

Best Regards

[barsk]

https://www.fs-force.com/support.php#ForceTest

[jmriego]

no worries! I think I can open a section for discussions in this repo. But totally fine by me to discuss it here.
I'm sorry but I cannot remember right now as I haven't had to modify this in a while and I have no access to my stuff right now, but I'll check in a week or so.

I can recommend you to use the sketch included here and change the first line to (remove the NO word).

#define DEBUG

That way you'll get in the Serial monitor some variables that will help you debug things. This is the part of the code that will print Fx and Fy for forces in the X and Y axis:
https://github.com/jmriego/Fino/blob/master/joystick.ino#L90

With this and the program you're referring to is easy to figure out which direction it should use. But I'm happy to have a look at this properly once I'm back.

Hope this helped!

[barsk]

Hi,
thanks for your support! I'll start by saying that I am an experienced software developer. No problems understanding or writing code.

The direction I am referring to is the one in ForceTest.exe and it is the main question at this time. I have others regarding what differs between this code and YukMingLaw's, but we'll take that later.

I have the joystick parts set up correctly. I can verify in the Microsoft Joystick Gamepad app that it works as intended. I.e the "dot" in the panel moves left when turning wheel left and up when pushing yoke in. All set.
What confuses me is the ForceTest applikation where you can test constant force with a "direction" that by default is 90 in the app. Should the wheel pull left or right for direction=90?
Should the yoke pull in or out for direction=0?
That is what I need to know to be able to verify the forces works correctly. There is no definition of the "direction" anywhere I can find. Spring force works fine pulling to center, but it is possible to have the joystick work, spring work and still have forces mirrored. Yes, I had that in MS Flight Simulator... :)

[jmriego]

sounds good! yes, I get what you're trying to do. I sent the previous message because I remember that a while ago I had to investigate it exactly this way.

What I'm saying is that if you run the debug mode that will give you some kind of logs with the previous instructions and run with forcetest or similar something that will give you a force with a certain direction, then you will see what's supposed to happen.

For example, you try a constant force angle=0 and force=1000 and you see that the debug lines show Fx=1000 then you know angle=0 means force towards the right. Does that make sense?

[barsk]

Well, the thing is that with your approach you first have to define the coordinate system. Is positive to the left or the right? Up or down? The axes may be reversed, and the encoder count order may be reversed, I can define it as CLOCK_WISE or COUNTER_CLOCKWISE. There are too many possibilities. To be able to analyze debug, your first have to define all that. There is no clear definition of those basic aspects which makes it all a bit - unclear...

ForceTest will give you the ultimate verification right off the bat as it works with a defined definition (AFAIK) of the direction angles. If I hook up a standard FFB wheel it wil pull the wheel in a specific direction for the 90 direction.
I believe 90 means left and 0 means down (as per the MS joystick control panel dialog -joy.cpl).
I hope that is correct, and that is what I need confirmed.

Unfortunately when I hook up a MS or Logitech FFB wheel ForceTest bugs out with an error, so I cannot confirm at least the X axis by that.
WheelChecker from iRacing is another tool that works for both the yoke and the wheel. It does not use "direction" but instead a slider to offset CP offset for the spring force. Both yoke and wheel pull the same direction (X axis) with Simple Spring and when I pull the offset slider right or left. Seems to verify that X-axis is correct, but a bit unsure still. The Y-axis is not defined if it should pull or out when i slide the CP offset left or right, so it does not help until I now what way it should go. Testing in MS Flight Simulator seems to indicate that elevator droop works in the right direction. Maybe I have it all set now...?

The best and clearest verification would still be understand the defined directions of ForceTest.exe...
The absolute best would be if Forcetest instead of having an angle had a dropdown of predefined directions to test: (Left, Right, Up, Down). That would make everything superclear! Maybe I will make my own tool mimicing the functionality of ForceTest. Since I am looking into possibly fork VPForce (the Rhino FFB joystick) telemetry FFB plugin to make it talk to an USB device with PID (FFB) protocol I need to understand how to code FFB protocols in Python anyway. Well, that is for my next project. :)

[barsk]

I got this from the creator of FS Force, whom I think is also the creator of ForceTest.exe. This confirms the directions as to what I believed was the case. The linked specification (that eluded my when googling) is excellent in clarifying all the missing info.

"Hi,
Forces are specified by where the force comes “from”. So 0 pushes the stick towards you, 90 pushes it to the left.

See the DirectX/DirectInput docs for more info (Effect Direction).

Russel Dirks
FS Force"

[barsk]

Hello again @jmriego!
Hope all is well for you. I wanted to ask a few more questions about the Fino library and what is different from @YukMingLaw's version. My problem is that my code for an Micro Pro is limited to 32 KB Flash and even with some heavy optimizations I am at the bleeding edge of what fits. Actually I had to disable some code for some of the less used forces (sawtooth, ramp, square, triangle) to make it fit. The code in Fino is essentially the same with regards to DynamicHID and joystick stuff. But there are some differences in the FFB code. Among those:

1. Some force calculations have moved to float instead of int32_t. Why is this? Since the Atmega microprocessor cannot do float natively it is handled by the Math library with extra code, and it also takes quite a bit extra time. Integer math on the other hand is quick and occupies less flash space. Is there some real need for float, i.e for handling overflows? Or does 32 bit integers as there is in YukMingLaws version? For sure there is some code that need to be in float, such as the one for sin() related, but that is the case in YukMingLaws code as well.
2. One addition to Fino is the LowPassFilters which works great. That will stay.
3. The method forceCalulator() in joystick.cpp contains some extra code compared to YukMingLaw. I'm not sure exactly what the difference applies to. But one part of it has these comments:
   // if this is a directional conditional calculate the conditional parameters
   // as the length in the direction of its angle. This is the same as the dot product of the vectors
   YukMingLaws code could be handling the same "directional conditionals" but in another way maybe?
4. The setGain() metod copies the gains data to a private variable instead of reading it by pointer reference as YukMingLaws code does. I can't see that the gains data is modified anywhere so why not use a pointer reference? The gains struct is pretty large so a fair bit of RAM could be saved here I think.

I don't use the Fino code as a library, but instead have copied the code (and slightly modified it at places). I tried to swap in YukMingLaws code as a direct replacement and to my surprise it was fairly easy. Some variable types that differed etc. I also added the missing LowPassFilters. The main difference though was that now all code fiitted in 32 KB, with all the effects active. That leads me to the question if I am missing out on something that @jmriego added?

[jmriego]

Hi! sorry for the delay but I was just able to do some checking.
The forces should point in these directions depending on angle (0 down or towards you, 90 left, 180 up, 270 right).

I've also been wanting to get rid of the float library but it would have taken me quite some effort to do that. The main issue I found is that I tried every single effect in YukMingLaws version compared to a MS FFB2 joystick and some effects were not the same.
I managed to solve that doing big changes in conditional and angle parameters. That was years ago now so I'd have to review what was exactly the reason but I remember problems with directional forces mostly related to friction, inertia, etc.

As far as I'm aware, this is a common issue with many FFB libraries as YukMingLaws version also pulls from previous libraries which he improved.

The reason to change setGain to a private variable was to make gain configurable on the fly with a pot or similar. There are some existing FFB joysticks and wheels that do that. But if you don't have any need for that, you can absolutely change to a reference.

To make this short, what you would be missing by using YukMingLaws code is some of the more rare effects might not work as expected. I have no idea which games would it affect I'm afraid.
I'm also running this code in a 32KB Micro if that helps but it's true that it's close to the limit. Are you trying to add extra functionality?

[barsk]

@jmriego, the directional angles is indeed as you say (0 towards you, 90 to left. The attached MS document in a previous post outlines this in a clear way too. And yes, my yoke is working as expected with the forces.

Ok so I get it that you used as MS FFB2 joystick as a reference for correct forces. Let's hope that that device was indeed interpreting things correctly itself.

If you remember what the issue was with YukMingLaws version I would be interested in knowing more. But I get that in your opinion your code is the more evolved and correct in comparison to YukMingLaws. Maybe a return to integer calculations where possible would be a solution, retaining all your improvements otherwise. It could save quite a lot of bytes hopefully.

One question, is your code based on version 1.0 of YukMingLaws code or an earlier version? He claims to have fixed some calculations, but maybe you have that covered already?

My code is based on Gagagu's code for a FFB Yoke with 775 motors so it adds a bit of handling for calibrations with encoders, error handling with a buzzer tone, a complete GUI for setting gain and other params etc. I have modified and refined that code and the hardware to add a few extra functionalities, amongst them handling with two AS5600 magnetic encoders and a solution for "software" endstops. I.e reducing the travel slightly so the yoke does not bang into the physical endstop when a constant or spring force direct it there with full power. Having a soft endstop just before the physical, which in simple terms means apply reverse force when over the travel boundary, means that the yoke brakes by the soft stop. Works pretty well, but was harder to achieve than one could think. The soft stop algorithm differs when a force pushes into it or when pushing out, and there is also a buffer zone in thereto stop vibrations and such when pushing against the soft stop,
All this in 32 KB flash is a bit of a stretch, and I am just at the limit (or slightly above with all forces enabled). So looking for ways to optimize your code where it is possible. The float stuff may be one thing. I could also disable code for unneeded axis and stuff in DynamicHID that is not used also. Every litte thing helps.

I'm aiming at releaseing all this as a fork of Gagagus already excellent yoke.