Typo: two "the"
For robotics/inverse pose applications, don't people usually use a 3x3 matrix (three rotations, three spatial) for coordinate representation? Otherwise you get weird gimbal lock issues (I think).
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.