b8d6bc2eb1
The spiraling issue occurs when the vision rotation standard deviation is very high relative to the odometry rotation standard deviation and the vision measurements have a large rotation error. (Scaling the rotation component of a twist without scaling the translation component causes the direction of overall translation to change, leading to spiraling around (either towards or away) the vision measurement instead of moving towards it.) Using a transform instead of a twist avoids this issue. In general, scaling twist components is more mathematically correct than scaling transform components. However, although twists are correct for modeling uncertainty in an odometry-only pose estimate, they are not correct for the difference between the odometry-only pose estimate and a vision measurement. Since neither twists nor transforms are completely correct (and the pose estimator as a whole is not mathematically correct), but using transforms can guarantee that the pose estimate approaches the vision measurement (instead of potentially spiraling away), they are the least bad option.
wpimath
wpimath contains utilities for robot control (feedforward/feedback), state estimation (filters, Kalman and otherwise), 2D/3D geometry, kinematics, trajectory generation, and trajectory optimization.
Implementation guidelines
A lot of wpimath features directly implement equations from books or papers. The following guidelines make that code easier to maintain and audit for correctness.
Citations
Cite source books/papers at the top of the function (e.g., See section 5.6 of "book name".). If multiple items from a given work are referenced, write a bibliography entry for the work to reference later.
Cite the equation numbers each line of code implements, if applicable. For example, See equation (#.#) of [1]. where [1] is a bibliography reference number.
Comments
Comment each line of code with its pretty-printed math equivalent.
// xₖ₊₁ = Axₖ + Buₖ
x = A * x + B * u;
Link to explanatory material where appropriate to explain background knowledge and/or notation choice.
Variable naming
Follow established mathematical convention where possible (e.g., use A, B, C, D for state-space notation instead of stateTransitionMatrix).
Use math symbols in variable names (see Unicodeit) to match source papers. This usually entails some Greek letters (α), but diacritics, superscripts, and subscripts need to be spelled out (ẋ → x_dot, αₖ² → α_k_sq) since compilers reject them, and the small features make variable names difficult to read.
Derivations
Put small derivations in comments within the function. Put large derivations in algorithms.md and link to them.
Unicodeit
When writing math expressions in documentation, use https://www.unicodeit.net/ to convert LaTeX to a Unicode equivalent that's easier to read. Not all expressions will translate (e.g., superscripts of superscripts) so focus on making it readable by someone who isn't familiar with LaTeX. If content on multiple lines needs to be aligned in Doxygen/Javadoc comments (e.g., integration/summation limits, matrices packed with square brackets and superscripts for them), put them in @verbatim/@endverbatim blocks in Doxygen or <pre> tags in Javadoc so they render with monospace font.
The LaTeX to Unicode conversions can also be done locally via the unicodeit Python package. To install it, execute:
pip install --user unicodeit
Here's example usage:
$ python -m unicodeit.cli 'x_{k+1} = Ax_k + Bu_k'
xₖ₊₁ = Axₖ + Buₖ
On Linux, this process can be streamlined further by adding the following Bash function to your .bashrc (requires wl-clipboard on Wayland or xclip on X11):
# Converts LaTeX to Unicode, prints the result, and copies it to the clipboard
uc() {
if [ $WAYLAND_DISPLAY ]; then
python -m unicodeit.cli $@ | tee >(wl-copy -n)
else
python -m unicodeit.cli $@ | tee >(xclip -sel)
fi
}
Here's example usage:
$ uc 'x_{k+1} = Ax_k + Bu_k'
xₖ₊₁ = Axₖ + Buₖ