-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Adding an optional way to use not only rotational information but also posicional data could improve the precision of the algorithm in corner cases.
The issue
Algorithm explanation
The current algorithm, introduced in #14 does the following:
- Extracts the current rotation from the Quaternion input
$\Omega_n$ - Calculates the delta rotation
$\Delta\Omega = \Omega_n - \Omega_{n-1}$ (in quaternion form$Q_{\Delta\Omega} = Q_{\Omega_n}\times Q_{\Omega_{n-1}}^*$ ) - Uses
$\Omega_{n-1}$ to get a normalized vector$\vec{V_L}$ that represents the local "up" of the headstage in global coordinates. i.e.: the vector that represents the direction the tether is going out of the headstage - Gets a static
$V_G$ which is a normalized vector that represents the direction the tether enters the commutator - Gets the projections of
$\Delta\Omega$ over$\vec{V_L}$ and$\vec{V_G}$ , getting the local and global twist$T_L$ and$T_G$ - Gets the angle
$\Theta$ between$\vec{V_L}$ and$\vec{V_G}$ - Returns a twist
$\tau = \frac{T_L + T_G}{1+cos(\Theta)}$
Mathematical explanation
The algorithm assumes that
a) an orbit around the commutator axis
b) a twist of the cable over the headstage axis
projected
and also that the total twist is a combination of both
Since we are dealing with small incremental rotations and a quaternion is defined as
we can assume that for a small incremental rotation
We are defining the projections as
We can then assume that the rotation increment is caused by a lineal combination of both of its elements
The projections can be approximated as:
where
and, again, the total twist
Solving this equation system gives us
(note that the actual solution is
The issue
In truth, this system is an approximation from incomplete information. Pure rotational information lacks information about the physical reality of the headstage-tether-commutator system.
One clear effect of this can be seen on the indeterminations on the general solution seen above:
Let's split this in two cases:
- k = 1: Vectors are aligned
In this case, it is impossible to tell apart when a rotation
In fact
In this case, since both projections will be equal
This case is mostly safe and will follow the animal movements.
- k = -1: Vectors are aligned but opposite
In this case, rotations are opposed. Likewise, the algorithm has no way of knowing if a given rotation is produced by a twist of an orbit. However, in this case, the sign of the twist is inverted: A counter-clockwise rotation on the headstage will produce a clockwise rotation on the commutator while a counter-clockwise orbit will still produce a counter-clockwise rotation. In this case, for a given
Mathematically, there is a non-convergent pole.
For this reason, the current algorithm has condition of the form
if (cos_angle > FallbackThreshold)
twist = (localTwist + globalTwist) / (1.0 + cos_angle);
else
twist = FallbackRotation == FallbackRotationModes.Global ? globalTwist : localTwist;So when approaching a threshold, the user can select which rotations is most likely to be the cause of the movement.
However, this threshold can not be too close to -1. Since the equation approaches an indetermination, for small denominators, small noise variations can be greatly amplified, resulting in instability.
Refining twist with positional data
With positional data, it would not be necessary to estimate the orbit motion from the IMU quaternion.
It would be possible to just calculate the orbit angle by knowing the position of the headstage in relationship to the commutator. In this scenario, it would be possible to extract two twist components:
- The global orbit
$\omega_G$ would be extracted from positional data - The local twist
$\omega_L$ would be extraced by the current projection of the IMU rotation over the headstage local axis
The impossible rotation
There is a case that is extremely challenging, if not outright impossible, to solve. This is if the animal where to coil the tether along an axis orthogonal or near-orthogonal to the commutator.
With IMU data only, there is no way if the coiling is done, for example, in the +X or -X direction. A same winding sense (CW or CCW) would result in opposite twists, depending on the direction.
With positional data, it could be possible to solve this, but would be challenging. Very precise movement information would be required.
But, physically, it would probably be an impossible situation. In such a situation, there would be actual windings over the animal or knots in the cable, which are situations which a simple rotating commutator can not solve. So care is still required in the tether physical attachment so these kind of twists are not possible.