This post and interactive explanations have been on my backlog to read and internalize: https://thenumb.at/Exponential-Rotations/
(Also: Thanks for pointing out the typo, I just deployed a fix.)
But here's my "why didn't you just"
Since you have a forward simulation function (pose to measurements), why didn't you use an iterative solver to reverse it? Coordinate descent is easy to code and if you have a constrained range of poses you can probably just use multiple starting points to avoid getting stuck with a local minimum. Then use the last solution as a starting point for the next one to save iterations.
Sure it's not closed-form like an NN and it can still have pathological cases, but the code is a little more transparent
When you say "coordinate descent" do you mean gradient descent? I.e., updating a potential pose using the gradient of a loss term (e.g., (predicted sensor reading - actual sensor reading)**2)?
I bet that would work, but a tricky part would be calculating gradients. I'm not sure if the Python libraries I'm using support that. My understanding is that automatic differentiation through libraries might be easier in a language like Julia where dual numbers flow through everything via the multiple dispatch mechanism.
No, coordinate descent is a stupider gradient-optional method: https://en.wikipedia.org/wiki/Coordinate_descent
It's slow and sub-optimal, but the code is very easy to follow and you don't have to wonder whether your gradient is correct.