feat: add conversion of frames for TabulatedDynamics contributions #386
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
THIS IS A WIP DRAFT that I am leaving on the side for a bit, DO NOT REVIEW
It turns out that we often use the
CartesianVelocity
coordinate subset as a derivative and not as itself to actually represent the acceleration. However, when you want to convert coordinates between reference frames, the best way to do it is to use the CoordinateSubset.inFrame() method since it handles higher order effects for frame conversions (like the coriolis and centripetal acceleration for velocity frame conversions for example). However, since we're usingCartesianVelocity
to represent the derivative of acceleration, it expects a CartesianPosition subset within the coordinate vector to reference so that it can correctly apply the Coriolis term if going to or from a non-inertial frame. So it raises an error when that happens.For our purposes, we can get away with converting acceleration vectors between frames just as we would convert position vectors between frames, that is without needing to consider higher order effect that comes from non-inertial coriolis terms etc (the angular velocity rates of the frame we deal with cause these higher order effects to be negligable).
So, if we want to support converting frames in the
TabualtedDynamics.computeContribution()
method, we will need to add a add another CoordinateSubset derived class for CartesianAcceleration that we can use to actually represent accelerations for cases like these, in order to use the .inFrame method. It can essentially be a copy of theCartesianPosition
class (since we can just use theapplyToVector
method from Transform open-space-collective/open-space-toolkit-physics@main/src/OpenSpaceToolkit/Physics/Coordinate/Transform.cpp#L333 since we don't need to consider non-inertial fictitious accelerations (after checking that the angular velocity of the new frame is low enough for it to be safely ignored).