Closed eglische closed 6 months ago
... which would maybe also explain the issue: " Sometimes hard shakes #26 "
i also found in the joystick.h of Heironimus the corresponding range deceleration:
#define JOYSTICK_DEFAULT_AXIS_MINIMUM 0
#define JOYSTICK_DEFAULT_AXIS_MAXIMUM 1023
#define JOYSTICK_DEFAULT_SIMULATOR_MINIMUM 0
#define JOYSTICK_DEFAULT_SIMULATOR_MAXIMUM 1023
but i also noticed that the calibration will display raw data from (somewhere) -32768 to 32767, despite the fact that i altered them to the 0-1023
so i guess at this stage, that the joystick driver is "superimposing" also this range and applying it to the 0-1023, thus every time he reads a small actual change in the single digit - it gets amplified. out of the regular 1-2 fluctuation will become somewhat like 40 or 70, thus moving the crosshair in the calibration in windows.
-eliminating the range from the arduino (chaning the maxY and maxX to 0-1023) in my mind only leaves the windows usb joystick driver to read the 0-1023 serial values and blowing them up.
apologies, i hope i make sense
-update 1: i retarded the feedback loop by adding a capacitor to the circut (ceramic) and a electrolytic one to stabilize the 5v to the sensors. much smoother now. i am going to play around with this too maybe: https://github.com/dxinteractive/ResponsiveAnalogRead
on another side, the thing works now with force, the feedback is questionable at the moment, it seams only shaking going on (when going over ground) and dampening force. but that's software side i think. i just finished the setup of the 250w motor, and oh boy, this is going to take some pulling, just like in the real thing. i hope i get the autopilot follow thing going on too soon, msfs is a bit iffy i think when it comes to force feedback. i'm using xpforce because of that, but still, seams every airplane is different - some even don't give feedback at all.
hi! to be honest I'm using this with an already created joystick so I didn't have to figure out many things about the sensors. I'll try to help if I can. That yoke is cool! I hope you can get that working.
Things that are fixed:
The rest you can play with.
I don't think that mapping the axis values to a max of 1024 will change things, but you can totally change #define minX
and related variables to test.
I'd probably try this things:
NODEBUG
to DEBUG
on the first line. Then open Arduino IDE Serial port graph and you'll see in real time a graph of the X and Y valuesconfig.h
. I'd probably start by changing #define default_gain 1.0
to a smaller value and testing the spring effectHello!
Thanks :-)
to your first point; i am testing it with the h-bridge disconnected, so not to induce em, so basically it is without force :) but the real time values are a good hint, so far i've been using just a serial script that does a readout of the pots individually to verify the wiring etc. i'll tinker around the debug tho, it sounds very usefull
to your second point, i did the lowering of force by limiting the analog write to to the force function - works as i still got my manhood intact. :D
over all it works now, but i am not sure about the feedback tho, is there a program other than the force tester, that shows the expected forces? for example, when in game that i can check what should be and what is?
it's a 250w motor so maybe you need to wear rugby protections or something 😂
I mostly used the ForceTest.exe
to debug things and when you do the serial plot thing I mentioned, you can see the values of the forces with the Fx and Fy variables.
Another thing that might work is the fedit.exe
program. With that one you can choose effects to run and it shows you a graph with how those effects look before you run them
has to be that strong, i love old planes and cars, when powersteering and flyby wasn't a thing, the servo was a pilots arms, if one of those oldtimers where diving, you had to really pull that yoke back. so basically that's why it's build that way :D
anyhow, the fedit.exe only starts and does nothing for me, taskmanager show it's there but no window appears.
but i think we can conclude this here. the joystick works, the workaround was dampening the input from the analog pin with a ceramic capacitor, and stabilizing the 5v main bus voltage with another capacitor.
time to do some flying, warm her up Jock
Hello!
I'm aware that this portion i'm talking about is commented out, and therefore not expected to work right out of the box. With that said, i'm not sure how to deal with it, because of my limited knowhow in coding...
First i thought it's my potentiometers who cased the well known jitter, but actually, in the code i've found that the "pos" is mapped from analog to a super imposed and much finer resolution to the min/max global variables. here are the corresponding snippets i'm talking about:
Reading the input:
pos[0] = map(analogRead(A0), 0, 1023, minX, maxX); //roll pos[1] = map(analogRead(A5), 0, 1023, minY, maxY); //pitch
Joystick related Settings: `#define minX -32768
define maxX 32767
define minY -32768
define maxY 32767`
So when i understand that correctly, it reads the pots and then maps from 0 and 1023 the values to -32768 and 32767 given that neither a poti, nor a hall nor a optical encoder's resolution will fulfill this application without the "jitter" going on.
i'm just a bit out of depth here. i was already soldering a lowpass filter on to the pots and cursin when it was not working, after which i had a look on the code. in my actual drunken stage at 3 in the morning - it makes sense that this is the cause of the issue, as the frequency of the ardu leo dictates the fluctuation as it reads in the interval as the clocking speed is dictating and calculates the deviation thus creates the "jitter", which i belief in this case is just the different computation in the cycle?
to better understand, maybe some pictures help, in how far your work inspired me to go so far :-)