Name changes

[shivChitinous]

This adopts the new convention where dx and dy are the changes in unity x and y ("allocentric coordinates"). Previously called dx, dy are now renamed dx_ft and dy_ft to reflect that these are changes in forward and rightward directions respectively. Further, in ftDf, we keep exactly the same conventions as fictrac where wx_ft refers to leftward movement, wy_ft refers to forward movement and wz_ft refers to leftward rotation of the animal on the ball. posAnalysis is modified to reflect these changes. We also modify how vR and vT are computed and filtered.

[hjmh]

I need a few more clarifications:

Previously called dx, dy are now renamed dx_ft and dy_ft to reflect that these are changes in forward and rightward directions respectively.

Here the new variables dx_ft and dy_ft are the changes the fictrac "lab" reference frame, correct?

Further, in ftDf, we keep exactly the same conventions as fictrac where wx_ft refers to leftward movement, wy_ft refers to forward movement and wz_ft refers to leftward rotation of the animal on the ball. posAnalysis is modified to reflect these changes.

I don't understand what the "w" is supposed to denote here?

Another, more general comment, is that because you can change the way you define the x/y/z axis in fictrac, there is no set definition of which axis in fictrac corresponds to which world space. I think it's dangerous to imply this here. On fictrac side the definition depends on the settings in the config file/process (c2a_cnrs_xy etc) and how the square is drawn. On the unity side, the definition depends on how the functions
Translation() and RotationDegrees()
are defined in https://github.com/JaneliaSciComp/janelia-unity-toolkit/blob/master/org.janelia.fictrac-collision/Runtime/FicTracUpdater.cs

I will need to go through the reasoning again carefully, but I think we went with a different x/y/z convention for the fictrac setting compared to what is recommended because it was come conveninent with the unity coordinate definition.