Fix acceleration axis and leg tweaks

[9il]

Fixes #1006

This PR fixes the axis for leg tweaks! However, an additional update of thresholds may be required.

@ImUrX, please test it in standard mode with leg tweaks like skating correction.

I don't have slimes for testing.

[Stermere]

This won't affect skating-correction since the magnitude of acceleration is not being changed. The logic looks good as far as I can tell

[9il]

This won't affect skating-correction since the magnitude of acceleration is not being changed.

Not really. Some code uses only the two components, like Vector3(footDif.x, 0f, footDif.z) . It uses x and z components, which correspond to trackers to original (x y) components in this PR and trackers (y z) in the current main branch. z in the tracker coordinates corresponds to the gravity direction. That is what the fix is about.

	private fun correctUnlockedFootTracker(footPosition: Vector3, previousFootPosition: Vector3, previousFootPositionCorrected: Vector3, footVelocity: Vector3, framesUnlocked: Int): Vector3 {
		var newFootPosition = footPosition
		var footDif = footPosition - previousFootPositionCorrected
		footDif = Vector3(footDif.x, 0f, footDif.z)

[Stermere]

This won't affect skating-correction since the magnitude of acceleration is not being changed.

Not really. Some code uses only the two components, like Vector3(footDif.x, 0f, footDif.z) . It uses x and z components, which correspond to trackers to original (x y) components in this PR and trackers (y z) in the current main branch. z in the tracker coordinates corresponds to the gravity direction. That is what the fix is about.

	private fun correctUnlockedFootTracker(footPosition: Vector3, previousFootPosition: Vector3, previousFootPositionCorrected: Vector3, footVelocity: Vector3, framesUnlocked: Int): Vector3 {
		var newFootPosition = footPosition
		var footDif = footPosition - previousFootPositionCorrected
		footDif = Vector3(footDif.x, 0f, footDif.z)

That is a positional correction, the acceleration is not used like that, I just checked. Mocap mode does use the acceleration direction though so this will help that!

[9il]

@ImUrX is anything else required for this PR to be merged?

[ImUrX]

You need to wait for more reviewers

[9il]

I though that two reviwers are enough. Should we ping someone to make a review?

[Erimelowo]

code itself looks good but testing with official SlimeVR trackers, looking at the values on the GUI (not the preview), it still seems like the original way was the right way (Vector3(v.y, v.x, v.z)). Maybe it'd be worth looking in the firmware if the acceleration is transformed.

However, the accel arrows preview and the local -> global conversion for accel are both broken in some way

[9il]

@Stermere id don't know if the fusion does the order right, but, at least, they in the right order during packet formation.

If you like I could take the original AXES_OFFSET and apply it both to rotation and acceleration. So, it will be defined by mostly by software, not a math.

On the other hand, if the bug is in the fustion, than the firmware has to be fixed instead of tuning the server for the firmware. At least, we could define a new version of protocol. The reason is because slime wants to be a kind of opensource standard for VR.

The current acceleratoin offsets is defenetely wrong. Some code may work better now because it was tuned for the current wrong offsets. That could work for now but it can be so for a robust code evolution.