Documentation for users interested in implementing new representations

[juliohm]

Hi @ronisbr , thanks again for this package. Could you please share the steps necessary to implement a new representation in a downstream package?

Best, -Julio

[ronisbr]

Hi @juliohm !

The representations are somewhat decoupled. I followed a different approach from Rotations.jl, for example. We do not have a global structure that represents a rotation, we have separate structures. Hence, the only thing you want to do when creating a new representation is defining the operations between those structures and, possibly, ways to convert to the existing ones.

Let's say you want to create the representation foo. Thus, to be very integrated with this package, you want to define the following conversions:

foo_to_dcm
foo_to_quaternion
foo_to_angles
foo_to_angleaxis
dcm_to_foo
quaternion_to_foo
angles_to_foo
angleaxis_to_foo

It is also nice to add support to those API functions:

inv_rotation
compose_rotation

[pbouffard]

Relatedly (sort of) since there's a fair bit of overlap with Rotations.jl it would be nice to have some interoperability. I'm not versed in this but if I'm not mistaken that would involve writing some convert methods. Is that something you've thought about?

I guess to avoid a dependency either way that would need to go in some third package though...?

[ronisbr]

Hi @pbouffard

Yes! This is a nice project. The best thing is to create a third package so that neither ReferenceFrameRotations.jl nor Rotations.jl need to add additional dependencies.

The only "problem" is that ReferenceFrameRotations.jl works with passive rotations (the reference rotates) whereas Rotations.jl works with active rotations (the vector rotates). This will requires some work to make everything work correctly.

[pbouffard]

Yeah I think that makes sense w.r.t. dependencies.

On the active vs. passive they are just reverses of one another so I think the conversion routine can just take care of then when it does it’s thing.

On Mar 20, 2021, at 6:52 AM, Ronan Arraes Jardim Chagas @.***> wrote:

Hi @pbouffard https://github.com/pbouffard Yes! This is a nice project. The best thing is to create a third package so that neither ReferenceFrameRotations.jl nor Rotations.jl need to add additional dependencies.

The only "problem" is that ReferenceFrameRotations.jl works with passive rotations (the reference rotates) whereas Rotations.jl works with active rotations (the vector rotates). This will requires some work to make everything work correctly.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JuliaSpace/ReferenceFrameRotations.jl/issues/12#issuecomment-803330185, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABYPMQF4U6I7PTUITFRSLLTESSCRANCNFSM4X2UPLOA.

[juliohm]

After reading the source code more carefully I realized that we need to formalize an API for these rotation types otherwise it becomes difficult to automatically convert between different representations. The fact that we don't a shared API between the rotation types inhibits us from composing different rotation types in sequence R1 \circ R2 \circ R3 ...

[ronisbr]

With the conversion methods in master, we should be able to add some conversion rules so that this kind of composition between different rotations can work. I just need some help because I am not sure how is the best way to do this.

[juliohm]

Thank you @ronisbr for all the support as usual. Closing the issue as no longer relevant.