KontrolSystem2 icon indicating copy to clipboard operation
KontrolSystem2 copied to clipboard

Question about `angular_velocity`, `angular_momentum` and `moment_of_inertia`

Open lefouvert opened this issue 1 year ago • 6 comments

version 0.5.7.6 (Ckan) gessed tag : Question

Hi,

As I'm struggling to detect a perfect «It's in place, and it will not move anymore if I disengage SAS», I'm taking a look at thoses three properties of the vessel :

  • vessel.global_angular_velocity
  • vessel.global_angular_momentum
  • vessel.global_moment_of_inertia

I wrote this code in order to have a more accurate view of what is going on :

// code which makes my vessel move
ksp::console::CONSOLE.print_at(19, 50, "Torque : " + vessel.total_torque.to_string())
const framesAnalysis = (frames: [self.ship.control_frame, self.ship.body_frame, self.ship.horizon_frame, self.ship.celestial_frame, self.ship.main_body.body_frame, self.ship.main_body.celestial_frame, self.ship.orbit.reference_frame, ksp::orbit::galactic_origin()], names: ["vessel.control_frame", "vessel.body_frame", "vessel.horizon_frame","vessel.celestial_frame", "vessel.main_body.body_frame", "vessel.main_body.celestial_frame", "vessel.orbit.reference_frame", "galactic_origin"])
while(true) {
    for(i in (0..framesAnalysis.frames.length)) {
        ksp::console::CONSOLE.clear_line(21 + i)
        ksp::console::CONSOLE.print_at(21 + i, 50, "AngVel " + framesAnalysis.names[i].pad_left(35) + ": " + vessel.global_angular_velocity.to_local(framesAnalysis.frames[i]).magnitude.to_string())
        ksp::console::CONSOLE.clear_line(21 + framesAnalysis.frames.length + i)
        ksp::console::CONSOLE.print_at(21 + framesAnalysis.frames.length + i, 50, "Moment " + framesAnalysis.names[i].pad_left(35) + ": " + vessel.global_angular_momentum.to_local(framesAnalysis.frames[i]).magnitude.to_string())
        ksp::console::CONSOLE.clear_line(21 + 2 * framesAnalysis.frames.length + i)
        ksp::console::CONSOLE.print_at(21 + 2 * framesAnalysis.frames.length + i, 50, "Inerti " + framesAnalysis.names[i].pad_left(35) + ": " + vessel.global_moment_of_inertia.to_local(framesAnalysis.frames[i]).magnitude.to_string())
    }
}

First thing unnoticeable on pics : The more higher is my orbit, the less near to zero is vessel.angular_velocity (not directly referenced into the code above, but can be found with this reference : vessel.global_angular_velocity.to_local(vessel.main_body.celestial_frame))

Now, when the vessel is rotating : image

And now, when the vessel is static since many seconds : image

Question I'm not facing :

  • angular_velocity at zero from body/control frame. It's Ok, it's expected.

Question I'm facing :

  • Why overall moments of inertia barely change ?
  • Why overall angulars velocities never reach zero when I'm not rotating ?
  • Why overall angulars velocities seems to be higher when the altitude is higher ?
  • Why angular velocity in main_body.celestial_frame is the only one which is different from other angular velocities ?
  • Why angular momentums have the same values than angular velocities ? (However, I understand why it's in vessel.(control/body)_frame. But I dont understand why in vessel.horizon_frame we got the same value)
  • Why the angular moment is null in (vessel/body).celestial_frame, orbit.reference_frame and galactic_origin ?
  • Why angular momentum in vessel.main_body.body_frame is the same I'm rotating or not ?
  • Isn't it unexpected galactic_origin seems to be Kerbin's celestial frame ?
  • Does thoses datas reliables ?

Maybe it's because my lack of knowledge/undertandings about thoses concepts, but I really read all the litteracy on wikipedia in english AND in my native language about thoses, and I didn't found anything which enlight me.

lefouvert avatar Apr 03 '24 03:04 lefouvert

A lot of these questions require some deep dive into the underlying calculations as I am (for the most part) take them from the underlying game objects.

As for the moment of inertia though: This is not supposed to change, unless the mass or mass-distribution of the vessel changes (e.g. fuel burn or resources moved to different tanks) ... that is, if the game as the same definition of "moment of inertia" as my old physics schoolbook ;)

untoldwind avatar Apr 03 '24 17:04 untoldwind

... from what I can tell so far:

  • The angular_velocity is actually taken from the angular_velocity (i.e. the rotation) if the underlying transformation frame. Since the body_frame and control_frame do not rotate to each other the angular velocity is expected to be 0
  • The horizon_frame is attached to the celestial body (like the .main_body.body_frame), so the rotation of the planet has to be considered.
  • A lot of the calculations seem to happen in the physics space (already mentioned that), which moves around with the vessel somewhat asynchronously ... that might be the cause for some jitter (not sure though)

What still eludes me:

  • The angular_momentum is supposed to be the motion of interia in the rotation direction multiplied with the angular_velocity ... this does not match up

untoldwind avatar Apr 03 '24 20:04 untoldwind

Seems like I have a taste for question which implies deep diving... It's not on purpose, I promise !

For Moment of Inertia, it's a topic I never studied. The only thing I've read about comes from Wikipedia, and I think to have get only the "Inertia" part; It's seems to be a «fake force» resulting from the inertial mass submitted to a «real work force». So it's seems to be legit than it don't change if mass don't change since I don't apply any thrust. However, Moment of inertia is still out of my intellectual reach. I assume it have a relationship with rotation since it have "moment" in the name. Moreover, the language barrier comes to me, since I believed than the word "Momentum" means "inertia". So I assume angular_momentum refer to motion quantity of a point M from the point of view of the point O where a force Vector P is deduced, written in this way : angular_momentum = Vector OM crossVector Vector P.

I didn't goes more far than 'Static Mecanics' at school (and it's far away, now) and a mathematic tool I don't know the name in english : the Torsor (Google Translate and Chat GPT agreed with this translation). But the french (my native language, as you have probably guessed) Torsor Wikipedia page lead to the Screw theory in english, which seems not be the same thing. Weird. In short, the tool allow to calculate the angular moment at one point knowing joint freedom for translation and rotation and applied force vector. This tool come with usefull operations as "adding" and "moving reference point". Obviously, all thoses computation have to be in uniform rectilinear motion. 'Dynamic Mechanic' is a field I never had the occasion to learn (I just know the expression 'uniformly accelerated rectilinear motion' which seems to be again a restricted context).

However, all my (small) × (knowledge and math skills) applied to the numbers and concept given by the game's object don't match.

In short :

As for the moment of inertia though: This is not supposed to change, unless the mass or mass-distribution of the vessel changes (e.g. fuel burn or resources moved to different tanks) ... that is, if the game as the same definition of "moment of inertia" as my old physics schoolbook ;)

Good to know.

The angular_velocity is actually taken from the angular_velocity (i.e. the rotation) if the underlying transformation frame. Since the body_frame and control_frame do not rotate to each other the angular velocity is expected to be 0

I get that ^^

The horizon_frame is attached to the celestial body (like the .main_body.body_frame), so the rotation of the planet has to be considered.

But... Why angular_moment in vessel.horizon_frame is so close to the one in vessel.body_frame, and so far of vessel.main_body.body_frame since the horizon/body.body frames are linked ?

A lot of the calculations seem to happen in the physics space (already mentioned that), which moves around with the vessel somewhat asynchronously ... that might be the cause for some jitter (not sure though)

I'm afraid about that. And I'm more afraid about calculation error margin going up with altitude. It's why I explored the more frames I could in order to found the 'more accurate' context dependant.

lefouvert avatar Apr 03 '24 22:04 lefouvert

First, let's take a look at the angular_velocity: The angular velocity should be a vector in direction of the rotation axis and its magnitude should be the angle-velocity in radians per second. So:

use { Vessel } from ksp::vessel
use { CONSOLE } from ksp::console
use { sleep } from ksp::game
use { DEG_TO_RAD } from core::math

pub fn main_flight(vessel: Vessel) -> Result<Unit, string> = {
    CONSOLE.clear()

    const pi = vessel.pilot_input

    pi.override_pitch = Some(1.0)

    while(true) {

        const start = vessel.facing

        sleep(0.1)

        const current = vessel.facing
        const diff =  current * start.inverse

        CONSOLE.clear()

        CONSOLE.print_line($"AV: {vessel.angular_velocity.normalized} {vessel.angular_velocity.magnitude}")
        CONSOLE.print_line($"    {diff.axis} {diff.angle * DEG_TO_RAD / 0.1}")
    }
}

(Note: I added .axis and .angle to the prerelease-branch, as a reverse operation to ksp::math::angle_axis ... it will be part of the API with the next release) These values align very nicely, so I am pretty certain that vessel.angular_velocity returns the correct results.

As for the jitter: When observing just the diff rotation it becomes obvious that the vessel is never really at rest when the physics engine of the game is running ... so, yes there is always some motion (and the SAS is always performing small adjustments). At this stage of development, it is really hard to tell if this is a bug or a feature.

Now for the ugly stuff: I decided to drop .angular_momentum and .global_angular_momentum from the API as the underlying calculations do not make much sense (and obviously produce bogus results). As it is now the "moment of inertia" is good to estimate how much angular acceleration is available around the major axes for a given torque, but that is about it.

... I say "estimate", because ... * take deep breath * ...

In space every vessel could be considered to be a rigid body under Euler's rotation equations, in these the mass distribution of the body is reduced to 3 principal moments of inertia (which should be the result of vessel.moment_of_inertia). But ... this only works in a very specific frame of reference (the principal axes of the body). Unless I am missing something it is just implicitly assumed that the vessel.body_frame aligns with these axes, which might be true if the vessel has high symmetry ... for asymmetric vessels though, probably not. To do this correctly one would actually need the complete inertia tensor (a 3x3 matrix) of the vessel. To get that one it would be necessary to get down to the underlying objects of the physics engine (i.e. this thing here: https://docs.unity3d.com/ScriptReference/Rigidbody.html).

untoldwind avatar Apr 04 '24 15:04 untoldwind

(Note: I added .axis and .angle to the prerelease-branch, as a reverse operation to ksp::math::angle_axis ... it will be part of the API with the next release)

Nice ! I could already imagine some pretty stuff to do with.

These values align very nicely, so I am pretty certain that vessel.angular_velocity returns the correct results.

Good to know, but not really surprised since it's so far the more reliable datas I get.

As for the jitter: When observing just the diff rotation it becomes obvious that the vessel is never really at rest when the physics engine of the game is running ... so, yes there is always some motion (and the SAS is always performing small adjustments). At this stage of development, it is really hard to tell if this is a bug or a feature. PTSD margin error incoming :) I hope some reference frame to be less impacted, or at least altitude related than others. vessel.celestial_frame should be Ok.

Now for the ugly stuff: I decided to drop .angular_momentum and .global_angular_momentum from the API as the underlying calculations do not make much sense (and obviously produce bogus results).

It's kind of reassuring my misundertandings not only comes from my unability to understand but also because of meaningless computings.

... I say "estimate", because ... * take deep breath * ... (i.e. this thing here: https://docs.unity3d.com/ScriptReference/Rigidbody.html).

Or not ^^' https://en.wikipedia.org/wiki/Paracetamol However, I think I get it. At least a lil' bit.

lefouvert avatar Apr 04 '24 17:04 lefouvert

Hmm ... when looking at the paracetamol molecule ... there is also the tennis-racket-theorem (aka Dzhanibekov effect ... ok had to look that one up ;) ): https://www.youtube.com/watch?v=1x5UiwEEvpQ

Would be interesting to test if the KSP2 physics engine covers this.

untoldwind avatar Apr 04 '24 17:04 untoldwind

This issue is stale because it has been open for 60 days with no activity.

github-actions[bot] avatar Jun 04 '24 02:06 github-actions[bot]

This issue was closed because it has been inactive for 14 days since being marked as stale.

github-actions[bot] avatar Jun 18 '24 02:06 github-actions[bot]