---
# System prepended metadata

title: Rough notes and distillation prior to 24-03-26 Tudat Developer Meeting

---

# Rough notes and distillation prior to 24-03-26 Tudat Developer Meeting


## Ways in which orientations are defined in Tudat (especially thrust orientations)

	-   Issues that the current implementation has
	-   What we would want the (refactored) functionality to do; define any boundary conditions of the implementation

**J** (**issue**): Personally, the **issue** I have with the current setup is that **we encourage users to define orientations separately for thrust, rotational dynamics, aerodynamic guidance**, etc.

**J** (**want**): I would be in **favour** of making the user setup the body-fixed orientation separately beforehand (in most cases). This body-fixed orientation would then serve as a basis for the thrust orientation.

---

**D**: `DependentOrientationCalculator` _only available during the propagation, and not before after it?_

**D**: `DependentOrientationCalculator`  requires the environment to be updated to the current time/state, and this is presently only supported inside the numerical propagation. This design could also be modified, but would take quite some work (and testing).

**D**: Depending on whether you are in the propagation or not, states would have to come from _either_ the current propagated state _or_ from the environment

**D**:  `DependentOrientationCalculator` _only available during the propagation, and not before after it?

**D**: The guidance algorithm would need to 'know' which environmental properties need to be updated, and which need not be

**D**: Although I don't see any fundamental issues in changing the above, I propose that if we choose to tackle this issue, we do it separately from making the interfaces unified. One possible argument for _not_ doing this separately would be to subsume the `DependentOrientationCalculator`  stuff into the `RotationalEphemeris`

**D**: Is it worth our time?

**D**: At present, there are (roughly) three distinct ways in which to define the body's orientation  
- `RotationalEphemeris`, obtained from the environment during propagation, independent of propagation, exists as a function of time `f(t)`
- ODE integration of rotational dynamics. `f(x0, torque)` defined prior to simulation.
	-  *Users can use these results as `RotationalEphemeris` after obtaining results.* An `Interpolator` is a dependent in this optional step.
-  `DependentOrientationCalculator` , Orientation can be defined by an algorithm which is dependent on the current translational state of the vehicle.
	- `f(angle-of-attack, sideslip, bank)` defining trajectory <-> body-fixed
	- 

**J**: Reading all of this made me think that, perhaps, we should simply force users to propagate rotational dynamics every time?  

**D/J:** Overkill in most cases.

**D**: I would be in favour of keeping interfaces for actually defining what is propagated different from an _a priori_ definition of the rotation. But, making the interfaces for a rotational ephemeris (fully defined _a priori_) and a 'dependent orientation calculator' (defining _a priori_ how the orientation is calculated from the state) less distinct, or even identical

> Perhaps they should stay distinct

*F*: I totally agree with this point! The important distinction is between numerical propagation of orientation _and_ prescribed orientation. Whether the prescribed orientation is set through Rotational Ephemerides or through a calculator that is used at every time step should not matter too much, in my opinion.

***D***: This is, I think, an important design driver for the new interfaces

## Compiled

(I intended on compiled boiled down points here, didn't really manage prior to the meeting)

- users define orientations separately for thrust, rotational dynamics, aerodynamic guidance.