Accela behaves erratically on negative values #231
Comments
|
I have also noticed this problem, and only on newer version rc17. I'm looking to downgrade now to solve it. I'll have to check if there is any relation to my jostick -- I have an X52, but I'm almost certain it's been unplugged during this issue. I've noticed this while in ARMA 3. There's a constant jitter, just like you describe. |
|
I'll look into it soon. Problem's identified, just needs tuning. |
Users report increased need for deadzone since last change. Issue: #231
Submitted-by: @FlyingCircus- Issue: #231
|
Try this test build and report back, thx. https://www.dropbox.com/s/ea0ayzbxmj07eou/opentrack-test-20150903.7z |
|
I'm still getting stuttering in rc18 and in the test build. I did make an interesting discovery though: it only seems to happen when at least one axis (pitch/yaw) is negative. Might even be worse when both axes are negative. But if both axes are outputting positive values, it doesn't seem to stutter. |
|
I'm also getting this issue in rc17 and rc18. I notice it primarily when looking to my left (right relative to the camera) -- I had previously been blaming this on my track clip sitting on the left side of my headset (so more vulnerable to occlusion-y stuff?) but the "negative" answer looks potentially reasonable too. |
|
In rc18 the gain for small values is even more gentle than it was before. Translation gain is now more even throughout. Which one is broken now? |
|
The negative thing looks serious. I'll look into it but give me some time. |
|
I believe the +- sign doesn't change anything. It might be your device working worse on one side. Gentler Accela works better for me at least. The numbers from rc16 require way more filtering for a stable image. |
|
It's a very distinct variation. When I look to the left, I get this jittery behavior. When I look to the right, it behaves as smoothly as rc15 did. |
|
I think I found a bug. It was there since Accela mk2. Please confirm: https://www.dropbox.com/s/olxbrajg2dktir1/opentrack-test-20151001_1.7z It's not yet committed since this is pure speculation. |
Accela attempted to guard against both negative and positive value overstepping the last value due to gain, but the check for negative values was incorrect. Issue: #231 Reported-by: @nanospork, @alterscape, @SgtGrumbles
|
I think this only happens when you rapidly change from positive to negative yaw (or any other axis). Say, +1 deg to the right, then go to -4 rapidly. |
sthalik
changed the title
|
Still experiencing this symptom with the 20151001_1 testbuild. I am almost certain this is not an issue with my point tracker hardware -- looking just slightly down-left is severely jittery; looking down-right is fine. In both cases I'm getting solid tracking with high confidence. The issue seems to persist no matter what Accela settings I use. Would it be helpful if I generated a video of my specific symptoms and settings? |
|
A video feed from camera and model dimensions are definitely helpful. That is, your .ini and the video that opentrack receives from camera. This way, I can at least reproduce the error through the video. |
|
OK -- I've emailed you my .ini and a small video clip off-list. Hopefully this works -- let me know if you didn't receive the video or if there's anything else I can provide to help troubleshoot. |
|
For those of you experiencing this problem, are you using an older version that doesn't have this. and if so, which version? |
|
I'm using rc15 for now, it does not exhibit this behavior. |
|
I have a theory why this might be happening. In particular, there were no changes to Accela or PT that could cause that. I think freetrack protocol changes might cause it. Stand by. |
|
Try this one - https://www.dropbox.com/s/2gymru6al3v73tq/opentrack-test-20151003_1.7z?dl=0 If it still doesn't work we can try replacing npclient.dll. It will however break arma battleye. |
|
This one seems equally bad on both positive and negative yaw. I'm going to capture some in-game footage so you can see what I mean. Right yaw and pitch above the horizon seems to be the only situation where it works. I'm going to capture some in-game footage and email/post so you can see the exact symptoms: https://youtu.be/W3Ct2nd9eus (framerate is low, sorry -- apparently capture + 3600x1920 display is unpleasant for my GPU). FWIW I'm using DCS World with Freetrack 2.0 enhanced protocol. |
|
Have to agree with alterscape. I'm getting stuttering all over now. In fact, right yaw and pitch above the horizon seems to be just as bad. Is input mapped before or after it's filtered? If before, is it possible that the mapping is not feeding the filter the right numbers? I know the mapping code was one of the main changes between rc15 and rc17. |
|
I'm trying to find a way to explain what I'm experiencing -- the video I uploaded doesn't quite do it justice because of the low framerate. It almost feels like it increments to the next increment, then smooths back towards the actual value -- tick -2 degree left, let's say, then +0.1 deg right from there several times, then -2 degree left again, then +0.1 deg or something like that? It feels very strange. |
|
I'm gonna make a logging tracker, with an option to replay the data. Got a bunch of paid work still, it's gonna take time. I'm not sure the problem lies in Accela at all, it could be protocol as per @alterscape
The thing changed was added synchronization to freetrack protocol. |
|
Try this one: https://www.dropbox.com/s/xg14q55f9ab7gc8/opentrack-2.3-rc18-28-g7e85f86.zip What changes in the new build? |
|
By changes I mean the way mapping curves are calculated changed sometime between rc15 and rc17. They used to be all straight line segments, now they are splines/curves. I'm wondering if the error is somewhere in there. If it helps, I don't know if I've mentioned this before, but I'm using Microsoft FSX SimConnect protocol, not freetrack protocol. The stuttering appears in both, so I don't think the issue is with the freetrack protocol. Also, the new build does not show improvement. It did introduce a weird UI bug though: the selected protocol is the one below the visibly selected one (i.e. to get to Microsoft FSX SimConnect, I have to select VJoy.) |
|
YouTube vidoes are still processing, but here is an example of the stuttering bug on my end: https://youtu.be/4GMkRQ_NKNQ |
|
@nanospork great insight. There's a spline editor precision decrease just like you say, after rc15p1. See https://www.dropbox.com/s/cq2sog7jew4md1j/opentrack-2.3-rc18-34-ga657514.zip The sort order glitch you reported is gone. |
Sort order was applied only to combobox but not to tracker list. Reported-by: @nanospork cf. #231 (comment)
Go from uint16_t to uint32_t. If it still doesn't help we have to back to using floats. Reported-by: @nanospork Issue: #231
|
FWIW in the future I'm gonna commit to "work" first these experimental changes. The "work" branch will be rebased at any time. |
|
@nanospork note that Accela uses the same spline editor as the mapping window that I increased the precision of. |
|
Try this one https://www.dropbox.com/s/szngzyf53fu4puh/opentrack-2.3-rc18-36-ga9b4aa0.zip It has Accela reverted to rc15. At least the important part. |
|
Still getting stuttering, no noticeable improvement. More interesting observations though: I'm noticing a bit of a "bump", or perhaps lag, as I yaw over zero Game Data 0. When I purposely mis-centered my tracker, I confirmed that this "bump" happens only as I move over Game Data 0, not over Raw Tracker Data 0. Same applies to pitch. I also found that if I use any curve that is not totally linear, the entire stuttering problem gets much worse. The exaggeration helped me confirm that the stuttering is worse when either pitch or yaw are negative. However there is still some jumpiness even when both are positive, just not as much. |
|
Is it possible that the code generating the splines just isn't making smooth splines? |
|
Yes. There are discrete points. I've increased the amount to what was in rc15, see https://www.dropbox.com/s/c4x1vz2hhxpjwlr/opentrack-2.3-rc18-36-g7abfd95.zip Is it any better? I need to leave now but I'll be logging in remotely in a few hours. |
|
It seems to be quite a bit better, but not quite as good as rc15. Definitely much closer to being useable though. The bump/lag/deadzone around each zero axis is still there too. |
|
is it only the deadzone or also filtering still? for mapping, show me a screenshot of yaw mapping. you can paste images into this submit box. |
|
Please confirm https://www.dropbox.com/s/cnte080zrx83120/opentrack-2.3-rc18-42-g5441b2a.zip we should all be good now. |
|
Confirmed working for me! No deadzone/bump and no more stuttering! Out of curiosity, what was the actual issue? I see you reverted to floats, is it that the precision was not great enough with the fixed point format? Or an overflow thing? As usual, thank you so much for your work on this! |
|
Can confirm this completely fixes the jerky/stutter issue. Thank you! |
|
@nanospork precision, and after rc18 I made an Accela bug so it was jerking hardly sometimes too. Thank you guys for testing, I'm releasing rc19 like there's no tomorrow. |
I'm opening a new Issue to encourage community feedback on this issue.
When my headtracker is unmoving or very slow moving, there is very visible jittering/stuttering in the output in rc17. In rc15, there was occasional slight "wobble" due presumably to noise, but this motion was smooth rather than stuttering.
The stuttering appears to persist despite a variety of Accela filter settings. I tested with linear mapping curves, and I'm using a joystick (EDTracker 2 with Magnetometer) input and the FSX Sim Connect Protocol.
If anyone else is having this or a similar issue, please comment with as much information as possible!
The text was updated successfully, but these errors were encountered: