[lynaghk]

For my application I need just the translations and Euler angles. The range of poses is mechanically constrained so I don't have to worry about gimbal lock. But yeah, my limited understanding matches yours that other parameterizations are more useful in general contexts.

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.)

[01HNNWZ0MV43FF]

Hey there op. I don't know what your sensors are measuring (distance to a point maybe? Or angle from a Valve lighthouse for inside-out tracking?)

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

[lynaghk]

That's a reasonable idea, but unfortunately wouldn't work in my case since the simulation relies on a lot of scientific libraries in Python and I need the inversion to happen on the microcontroller.

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.

[01HNNWZ0MV43FF]

Ah makes sense.

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.