DCM optimizations

[juliohm]

The DCM representation is currently an alias for SMatrix. That is nice but we could do even better if we specify properties of rotation matrices that are not implemented by a generic SMatrix. That is what Rotations.jl does with inv == transpose for example.

Maybe DCM should be a new type of StaticMatrix, and that is possible with StaticArrays.jl interface:

# inherit most basic methods like SMatrix
struct DCM{T} <: StaticArray{3,T} end

# add specific methods for rotations
inv(D::DCM) = transpose(D)
...

[ronisbr]

No, this cannot be done in this package. I think Rotations.jl assumes that a DCM is always orthornormalized, meaning that the inverse is the transposed matrix. Here, we do not do this. DCMs can be propagated given the angular velocity and they loose the normalization due to numerical errors. The process to orthornormalize at each step can be costly and not useful for some applications (small sampling step, small angular velocity, etc.). That's why I make this design choice. Finally, if the DCM is not orthornormalized, it is better to obtain is inverse to compute the inverse rotation than to use its transpose.

[juliohm]

I think the issue of taking inverses is orthogonal to the issue of making DCM a StaticMatrix subtype. We can still provide a new DCM type that is more than just an alias to SMatrix. This would give us power to define conversions without type piracy and would also help us design more specific behavior for rotation matrices. Right now we can't exploit the fact that these are rotation matrices because we can't specialize methods on SMatrix. Makes sense?

The current design ReferenceFrameRotations.jl is very centered around MATLAB users as you said and as a consequence we are loosing a lot of potential in terms of dispatch and automatic conversion between different kinds of rotations.

[ronisbr]

I think the issue of taking inverses is orthogonal to the issue of making DCM a StaticMatrix subtype. We can still provide a new DCM type that is more than just an alias to SMatrix. This would give us power to define conversions without type piracy and would also help us design more specific behavior for rotation matrices. Right now we can't exploit the fact that these are rotation matrices because we can't specialize methods on SMatrix. Makes sense?

Ok, this makes sense! However, we must be 100% sure that the implementation will behave precisely the same as we have now. A lot of code currently depends on this package and I really do not want to update all of them :D Thus, unfortunately, backward compatibility must be a goal in the short term. For practical purposes, I think it is enough to make sure that the current test set passes.

The current design ReferenceFrameRotations.jl is very centered around MATLAB users as you said and as a consequence we are loosing a lot of potential in terms of dispatch and automatic conversion between different kinds of rotations.

Yes, this is also something I do not want to change. I will guess that 90% of the students learn reference frame rotations in Aerospace Engineering using MATLAB, so it is more or less the industry standard right now. It is a good thing to have an API close to that.

However, I agree we are loosing nice Julian features here. But I really think we can make those two things to coexist just fine.

[ronisbr]

Hi @juliohm !

To implement random samplers for DCM, I needed to create a custom type just like you suggested. The code is already in master, can you please check if everything is fine?

[ronisbr]

I will close this issue because it was already implemented in master. Now, we have a custom type for DCM and it enables us to define the conversion functions without messing up with StaticArrays.