untoldwind / KontrolSystem2

Autopilot scripting system for KSP2
Other
54 stars 15 forks source link

exec_node doesn't work #68

Closed SodaPopinski closed 1 year ago

SodaPopinski commented 1 year ago

It appears even while the vessel is lined up with the maneuver node, vessel.main_body.next_node() doesn't match vessel.global_facing.vector.normalized.

So the program just stays on "waiting for ship to align."

I suspect it may have to do with the new roll function. I noticed when the vessel is facing the same point, vessel.global_facing.vector.normalized changes based on roll.

As an example, while I have the vessel lined up the maneuver node, this code gives me this output code: const frame = vessel.main_body.celestial_frame const node = vessel.maneuver.next_node()? const dv0 = node.global_burn_vector.vector CONSOLE.print_at(0,0,"global_facing " + vessel.global_facing.vector.normalized.to_fixed(frame, 3)) CONSOLE.print_at(1,0,"pitch_yaw_roll " + vessel.pitch_yaw_roll.normalized.to_fixed(3)) CONSOLE.print_at(2,0,"maneuver_node " + dv0.normalized.to_fixed(frame, 3))

output: global_facing [-0.612, -0.791, 0.013]] pitch_yaw_roll [0.028, 0.856, -0.517]] maneuver_node [-0.086, 0.006, -0.996]

SodaPopinski commented 1 year ago

I fixed part of it by use of vessel.autopilot.target_orientation.

Now, it's seems to zero out dv once I reach the maneuver node, so it never throttles up.

Edit: It looks like node.global_burn_vector.vector.magnitude doesn't change as the burn continues. For now, I'm just getting the difference between initial orbital_velocity.magnitude and current. It's pretty rough though. Alternatively, I can calculate dV remaining in the stage.

If nobody else is having this issue, it may be a mod I installed.

untoldwind commented 1 year ago

Yes, the burn_vector is a constant now, which seems to be more of a feature than a bug. Internally the calculations for the remaining dV are actually quite complicated. The best approximation if found was using the node.expected_orbit as a reference, but this seems to have issues as well.

I do not think I have touched global_facing or node.global_burn_vector.vector in the latest patch though. I did change pitch_yaw_roll and heading_direction (i.e. feeding pitch_yaw_roll back into heading_direction should now be the same as global_facing).

Can you give me your version of the exec_node function/script, I can really reproduce this in my test scenarios

untoldwind commented 1 year ago

I did some testing with 0.1.2.0 as the internal API has slightly changed. I noticed that after adding a node the data was not immediately up to date. I.e.

const node = vessel.maneuver.add_burn_vector(UT - half_burn_time, delta_v)?

node.expected_orbit

was creating a different result as

const node = vessel.maneuver.add_burn_vector(UT - half_burn_time, delta_v)?

sleep(0.2)

node.expected_orbit

Not sure if this applies to your problem, but this should be fixed now.

SodaPopinski commented 1 year ago

I haven't tried the stock exec_node since the new KSP2 patch.

The version of exec_node I was using giving me the problems was the stock version. It broke down into two problems. The first one, as mentioned, was global_facing and node.global_burn_vector numbers aren't equal when they line up on the NavBall, so exec_node always thinks it's unaligned.

Secondly, it would start the burn because I was using an SSTO, and had no other stages with engines. The staging trigger function check requires an engine with another stage. Removing that check makes that part work.

arcykojot commented 1 year ago

I have no mods, only those required for this to run and I have same issue with my SSTO on 0.1.2 KSP2 patch. It is only showing "Waiting for ship to align".

Below my SSTO config for testing, just paste raw code in VAB to get it: https://gist.github.com/arcykojot/f2ffb37384be133acbb9124f9600846d

SodaPopinski commented 1 year ago

I suspect it may have to do with plane designs vs. rockets. I don't get the issue with "Waiting for the ship to align" if I use a rocket, but I do when I use a spaceplane. I'll see if it's a cockpit / capsule specific thing. I've had the same problem with a spaceplane either using an inline spaceplane cockpit, or no cockpit (probe control).

untoldwind commented 1 year ago

Yes, for space planes the control_frame is 90-degree flipped in comparison to a rocket. That should not affect the "facing" vector though.

untoldwind commented 1 year ago

I did some digging and found some strange difference between the internal ControlTransform.bodyFrame and ControlTransform.coordinateSystem. This should be fixed (or rather circumvented) in 0.3.4

arcykojot commented 1 year ago

I confirm that it works now ok.