NAVBALL from std - Question

[PhilouDS]

I'm trying the navball function with the script below.

// Kontrol System v0.5.8.3
use { yield, sleep, current_time } from ksp::game
use { CONSOLE } from ksp::console
use { CONSOLE_WINDOW } from ksp::ui
use { Vessel, AutopilotMode } from ksp::vessel
use { Direction, GlobalDirection, Vec3, vec3, vec2 } from ksp::math
use { acos_deg, atan2_deg } from core::math
use { navball } from std::navball

pub fn main_flight (vessel: Vessel) -> Unit = {
  CONSOLE.clear()
  CONSOLE_WINDOW.open()
  CONSOLE_WINDOW.size = vec2(500,350)

  vessel.autopilot.enabled = false // SAS
  vessel.autopilot.mode = AutopilotMode.Autopilot

  let nav_vec = navball(vessel, vessel.orbit.prograde(current_time()).to_direction())

  while (true) {
    nav_vec = navball(vessel, vessel.orbit.prograde(current_time()).to_direction())
    vessel.autopilot.target_orientation = vessel.orbit.prograde(current_time())

    CONSOLE.print_at(0, 0, $" -- SHIP --")
    CONSOLE.print_at(1, 0, $"Pitch: {vessel.pitch_yaw_roll.x:N0}°    ")
    CONSOLE.print_at(2, 0, $"  Yaw: {vessel.pitch_yaw_roll.y:N0}°    ")
    CONSOLE.print_at(3, 0, $" Roll: {vessel.pitch_yaw_roll.z:N0}°    ")

    CONSOLE.print_at(5, 0, $" -- NAV MARKER --")
    CONSOLE.print_at(6, 0, $"Pitch: {nav_vec.x:N0}°    ")
    CONSOLE.print_at(7, 0, $"  Yaw: {nav_vec.y:N0}°    ")
    CONSOLE.print_at(8, 0, $" Roll: {nav_vec.z:N0}°    ")
    yield()
  }
}

Everything looks ok.

But... when I change the target_orientation with the line vessel.autopilot.target_orientation = nav_vec, the pitch and the yaw don't fit anymore. Why's that?

[PhilouDS]

My idea behind this is to change the yaw (the azimuth) of the retrograde vector. For example, here, retrograde's yaw = 100°. Imagine I want it to be equal to 95°, I have to define my ship's yaw to ~110° and start my engine to "push" the retrograde vector.

[untoldwind]

I am not entirely sure, but I assume that updating the SAS with a new target vector on every game update update messes up the internal PIDLoops somehow. Usually I try to use the vessel.autopilot.target_orientation just once and then wait for the ship to be aligned with that vector.

I simple test would be to replace the yield with a sleep(0.5) (or even sleep(1.0)) to give the SAS some time to catch-up

[PhilouDS]

I am not entirely sure, but I assume that updating the SAS with a new target vector on every game update update messes up the internal PIDLoops somehow. Usually I try to use the vessel.autopilot.target_orientation just once and then wait for the ship to be aligned with that vector.

I simple test would be to replace the yield with a sleep(0.5) (or even sleep(1.0)) to give the SAS some time to catch-up

Unfortunately, it didn't work, even with sleep(1). I try with a constant vec3(90,45,0) defined outside the loop. I tried with target_orientation either outside or inside the loop. Still weird results.

I try to use vessel.set_steering(nav_vec) but the vessel spins indefinitely :( By the way, how do you use this set_steering? Does it really work?

[untoldwind]

Well, the vessel.set_steering sets the steering (i.e. flight input of the vessel), it does set the desired direction of the vessel.

What you want to use instead is the std::control::steering::control_steering, and then either use set_direction or set_heading: Example:

// Kontrol System v0.5.8.3
use { yield, sleep, current_time } from ksp::game
use { CONSOLE } from ksp::console
use { CONSOLE_WINDOW } from ksp::ui
use { Vessel, AutopilotMode } from ksp::vessel
use { Direction, GlobalDirection, Vec3, vec3, vec2 } from ksp::math
use { acos_deg, atan2_deg } from core::math
use { navball } from std::navball
use { control_steering } from std::control::steering

pub fn main_flight (vessel: Vessel) -> Unit = {
  CONSOLE.clear()
  CONSOLE_WINDOW.open()
  CONSOLE_WINDOW.size = vec2(500,350)

  vessel.autopilot.enabled = false // SAS off
  const steering = control_steering(vessel)

  let nav_vec = navball(vessel, vessel.orbit.prograde(current_time()).to_direction())

  while (true) {
    nav_vec = navball(vessel, vessel.orbit.prograde(current_time()).to_direction())
    // Point vessel to prograde
    steering.set_direction(vessel.orbit.prograde(current_time()).to_direction())
    // Alternative: Point vessel to heading 40 (yaw), 15 above horizon (pitch) and 0 roll
    // steering.set_heading(40, 15, 0)

    CONSOLE.print_at(0, 0, $" -- SHIP --")
    CONSOLE.print_at(1, 0, $"Pitch: {vessel.pitch_yaw_roll.x:N0}°    ")
    CONSOLE.print_at(2, 0, $"  Yaw: {vessel.pitch_yaw_roll.y:N0}°    ")
    CONSOLE.print_at(3, 0, $" Roll: {vessel.pitch_yaw_roll.z:N0}°    ")

    CONSOLE.print_at(5, 0, $" -- NAV MARKER --")
    CONSOLE.print_at(6, 0, $"Pitch: {nav_vec.x:N0}°    ")
    CONSOLE.print_at(7, 0, $"  Yaw: {nav_vec.y:N0}°    ")
    CONSOLE.print_at(8, 0, $" Roll: {nav_vec.z:N0}°    ")
    yield()
  }
}

But actually have a hard time reproducing your example with one of my test vessels. Is it possible that the command-module is somehow "twisted", there was an issue with that some time ago and I am not sure if the navball function produces correct results in these cases.

[PhilouDS]

But actually have a hard time reproducing your example with one of my test vessels. Is it possible that the command-module is somehow "twisted", there was an issue with that some time ago and I am not sure if the navball function produces correct results in these cases.

Those simple examples don't work either:

steering.set_direction(vec3(34,275,-56).to_direction())
//steering.set_heading(34,275,-56)

I'm doing my tests with a little satellite. The probe is the OKTO.

In navball.to2, you use angle_to_360 and angle_to_180 from utils.to2. Any differences with clamp_degrees360 and clamp_degrees180 from core::math?

[untoldwind]

Ah ... now I get it: I think there is a misunderstanding about v.to_direction(): This creates a direction/rotation pointing in direction of v (i.e. the values of v are not supposed to be angles). There is a ksp::math::euler function to create a direction from Euler-angles ... but these angles do not match up with navball since that one is based on the horizon not the celestial frame.

There are two ways to get a direction from navball euler-angles:

• Do the trigonometry in std::navball in reverse (i.e. use vessel.up, vessel.east and vessel.north as frame of reference)
• Use the vessel.horizon_frame:

  steering.set_direction(euler(-34,275,-56).to_global(vessel.horizon_frame).to_local(vessel.celestial_frame))

  Note: The pitch is negative here ... because that seems to be how the navball works in-game for some reason

[PhilouDS]

Euler... him again! He's really everywhere 😂

Note: The pitch is negative here ... because that seems to be how the navball works in-game for some reason

I did some test. The sign of the pitch is reversed. steering.set_direction(euler(-90, 0, 0).to_global(vessel.horizon_frame).to_local(vessel.celestial_frame)) points to the "up" of the navball (the blue part). steering.set_direction(euler(90, 0, 0).to_global(vessel.horizon_frame).to_local(vessel.celestial_frame)) points down.

Also, this seems to work too: vessel.autopilot.target_orientation = (euler(-34, 50,20).to_global(vessel.horizon_frame).to_local(vessel.celestial_frame)).vector edit: I spoke to fast: the target_orientation doesn't do anything with the roll value.

[untoldwind]

Yes, it seems that the SAS is only able to stabilize the roll but not set it to a desired value ... or at least I was never able to activate that part. The easiest way to control the roll might be the std::control::steering::control_steering. Alternatively it might be feasible have the SAS handle the pitch and yaw and use the new vessel.pilot_input.override_roll to control the roll "manually", though I have not tried that one yet.

[lefouvert]

Note: The pitch is negative here ... because that seems to be how the navball works in-game for some reason

Isn't it a KSP1 legacy which is, as far as I remember, left-hand framed ?

[untoldwind]

That might very well be possible. If I remember correctly the y-axis of the vessel frame was pointing downward.

[github-actions[bot]]

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

[github-actions[bot]]

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