kOS Autopilot

[erendrake]

Interesting. Well since it is happening when returning to a vessel it could be like that. The code errors outs, I think in RT itself, and then KSP just bails.

Does kos throw any exceptions in the log? I can look at the confignode code. its pretty strange

[Agathorn]

@erendrake: IF you want to look at the offending code, you can see it in this commit: https://github.com/jwvanderbeck/KOS/commit/0bfd67e9ac286d58bb4a4213d0892616b626d729

Essentially I just disabled the ability for RT to take over the autopilot and it fixes the problem. As soon as I let it take over, the problem comes back.

[erendrake]

Essentially I just disabled the ability for RT to take over the autopilot and it fixes the problem.

Are you comfortable merging this into the main trunk then? if so lets get it into v0.11 I still have so much documentation work to do that there doesnt seem to be much sense in waiting.

[masTerTorch]

I can confirm the bug is gone with the new test release. I ran the same script on the same vessel like yesterday and found out that with the new release

lock steering to nextnode.

is broken. After sending the command the vessel will spin in circles. Any ideas?

EDIT: Ok, got the same problem with

set direction to retrograde.
lock steering to direction.

Seems to be a steering problem. kOS is trying to face the vessel in the right direction, then overshoots, turns around and is overshooting again...

Edited February 4, 2014 by masTerTorch

[Agathorn]

I can confirm the bug is gone with the new test release. I ran the same script on the same vessel like yesterday and found out that with the new release

lock steering to nextnode.

is broken. After sending the command the vessel will spin in circles. Any ideas?

Can you give me a .craft file and let me know what addons if any it uses?

[Agathorn]

I can confirm the bug is gone with the new test release. I ran the same script on the same vessel like yesterday and found out that with the new release

lock steering to nextnode.

is broken. After sending the command the vessel will spin in circles. Any ideas?

EDIT: Ok, got the same problem with

set direction to retrograde.
lock steering to direction.

Seems to be a steering problem. kOS is trying to face the vessel in the right direction, then overshoots, turns around and is overshooting again...

Yeah I suspect this is because of some steering changes I made, because on my rockets I was seeing severe UNDERsteer. If you can give me a craft to test with that would be great. Otherwise, I will revert that change when I get home and see if I can find another way to deal with the understeer.

Does your craft use reaction wheels?

[erendrake]

Yeah I suspect this is because of some steering changes I made, because on my rockets I was seeing severe UNDERsteer. If you can give me a craft to test with that would be great. Otherwise, I will revert that change when I get home and see if I can find another way to deal with the understeer.

Does your craft use reaction wheels?

you might want to pull my latest change, a lot of direction based math was not working because i forgot to include an interface on the Direction class.

https://github.com/erendrake/KOS/issues/15

Edited February 4, 2014 by erendrake

[Agathorn]

you might want to pull my latest change, a lot of direction based math was not working because i forgot to include an interface on the Direction class.

https://github.com/erendrake/KOS/issues/15

Interesting. I'll merge up to your latest when I get home tonight, as well as revert my steering changes.

[Agathorn]

I still get horrible steering with that build, if I remove my steering changes.

The problem as I found it, is that since my rocket has NO reaction wheels, the kOS code that determines how much available toque I have returns a very small number. This number is in turn used by the steering system to determine maximum control deflection, so it barely moves the controls, which results in basically no steering at all for my rocket.

I'm betting that @masTerTorch is using reaction wheels, which seems to be the case the code was designed for. So my steering changes were causing oversteer for them, yet the changes I had made caused perfect steering for my craft with no reaction wheels.

Need to figure out how to make it work for both ways.

[Agathorn]

Actually it is worse than I thought. I put some debug code into the steering helper to see what values it was determining.

[LOG 19:04:22.758] kOS: DEBUG Steering torque = [0, 0, 0]
[LOG 19:04:22.759] kOS: DEBUG Steering inertia = [Infinity, -Infinity, -Infinity]
[LOG 19:04:22.759] kOS: DEBUG Steering precision = 0.5
[LOG 19:04:22.760] kOS: DEBUG Steering driveLimit = 1

EDIT: Think I found my specific problem. The function that detects thrust vectoring isn't detecting my engines. So it returns 0, and I have no other control surfaces.

Edited February 5, 2014 by Agathorn

[Agathorn]

So i'm still testing things, but this seems to be a better method of determing steering torque from engines:

        public static double GetThrustTorque(Part p, Vessel vessel)
        {
            var centerOfMass = vessel.CoM;
            if (p.State == PartStates.ACTIVE)
            {
                UnityEngine.Debug.Log("kOS: Checking thrust on ACTIVE part:" + p.name + " - " + p.stagingIcon);
                ModuleEngines engine = p.Modules.OfType<ModuleEngines>().FirstOrDefault();
                if (engine != null && engine.isOperational)
                {
                    float thrust = engine.CalculateThrust();
                    ModuleGimbal gimbal = p.Modules.OfType<ModuleGimbal>().FirstOrDefault();
                    if (gimbal != null && !gimbal.gimbalLock)
                    {
                        UnityEngine.Debug.Log("kOS: DEBUG return gimbal data on engine with THRUST: " + thrust + " and GIMBAL: " + gimbal.gimbalRange);
                        return Math.Sin(Math.Abs(gimbal.gimbalRange) * Math.PI / 180) *
                               thrust * (p.Rigidbody.worldCenterOfMass - centerOfMass).magnitude;
                    }
                }
            }
            return 0;
        }

1) It actually detects the engines. That's a bonus.

2) It uses the engine's current thrust rather than its max thrust. Since steering and throttle are separate in kOS, calculating steering from max thrust seems pointless since only the current thrust matters/

[erendrake]

So i'm still testing things, but this seems to be a better method of determing steering torque from engines:

        public static double GetThrustTorque(Part p, Vessel vessel)
        {
            var centerOfMass = vessel.CoM;
            if (p.State == PartStates.ACTIVE)
            {
                UnityEngine.Debug.Log("kOS: Checking thrust on ACTIVE part:" + p.name + " - " + p.stagingIcon);
                ModuleEngines engine = p.Modules.OfType<ModuleEngines>().FirstOrDefault();
                if (engine != null && engine.isOperational)
                {
                    float thrust = engine.CalculateThrust();
                    ModuleGimbal gimbal = p.Modules.OfType<ModuleGimbal>().FirstOrDefault();
                    if (gimbal != null && !gimbal.gimbalLock)
                    {
                        UnityEngine.Debug.Log("kOS: DEBUG return gimbal data on engine with THRUST: " + thrust + " and GIMBAL: " + gimbal.gimbalRange);
                        return Math.Sin(Math.Abs(gimbal.gimbalRange) * Math.PI / 180) *
                               thrust * (p.Rigidbody.worldCenterOfMass - centerOfMass).magnitude;
                    }
                }
            }
            return 0;
        }

1) It actually detects the engines. That's a bonus.

2) It uses the engine's current thrust rather than its max thrust. Since steering and throttle are separate in kOS, calculating steering from max thrust seems pointless since only the current thrust matters/

    public static double GetThrustTorque(Part p, Vessel vessel)
        {
            if (p.State == PartStates.ACTIVE)
            {
                ModuleEngines moduleEngine = null;
                ModuleGimbal moduleGimbal = null;
                foreach (PartModule partModule in p.Modules)
                {
                    var foundModuleEngine = partModule as ModuleEngines;
                    var foundModuleGimbal = partModule as ModuleGimbal;
                    if (foundModuleEngine != null)
                    {
                        moduleEngine = foundModuleEngine;
                    }
                    else if (foundModuleGimbal != null)
                    {
                        moduleGimbal = foundModuleGimbal;
                    }
                }
                if (moduleGimbal == null || moduleEngine == null)
                {
                    return 0;
                }

                var gimbalRange = Math.Sin(Math.Abs(moduleGimbal.gimbalRange));
                var maxTrust = moduleEngine.maxThrust;
                var magnitude = (p.Rigidbody.worldCenterOfMass - vessel.CoM).magnitude;

                var output = gimbalRange*maxTrust*magnitude;
                UnityEngine.Debug.Log("EngineTorque Found: " + output);
                return output;
            }

            return 0;
        }

This was my effort before work this morning i think we might have come to a very similar place. I know it might seem silly but i really like having each term of these equations broken out and labeled.

[Agathorn]

I always prefer readable code over super efficient code. In my defense C# isn't my language, nor am I that familiar with the KSP API yet, so I was trying to change as little of the original code as possible

EDIT: I do think it should use current thrust instead of max thrust though. Since the steering doesn't adjust thrust at all, what does max thrust have to do with anything? Seems that the actual current thrust is all that really matters.

[erendrake]

EDIT: I do think it should use current thrust instead of max thrust though. Since the steering doesn't adjust thrust at all, what does max thrust have to do with anything? Seems that the actual current thrust is all that really matters.

I Concur with your current thrust argument. max is not the correct value to use.

I actually like your OfType syntax better than my foreach loop.

[Agathorn]

I'm still trying to figure out how to make it work for engines using vector thrust for ROLL which some plugins do.

EDIT: To clarify i'm trying to find a way to do it cleanly. I can get it to work by brute force by detecting if one of the known mods that provide roll vectoring is installed, but that seems like a crap way to do ti.

Edited February 5, 2014 by Agathorn

[erendrake]

I'm still trying to figure out how to make it work for engines using vector thrust for ROLL which some plugins do.

If what we have will make steering work, im happy with not getting roll and getting v0.11 out. v0.12 will have all kinds of goodies like gimbaled roll steering if we want it

[Agathorn]

If what we have will make steering work, im happy with not getting roll and getting v0.11 out. v0.12 will have all kinds of goodies like gimbaled roll steering if we want it

Easy for you to say. You don't have craft with nothing but vectored thrust for maneuvering

In all seriousness if you are happy with the steering changes go for it. Unfortunately without roll working I still can't verify proper steering on my rockets

[Agathorn]

BTW if you go with the current thrust method, make sure you also modify the calls so it doesn't multiply by current throttle.

[Zander]

Hey guys.

I have some realism specific needs for KOS that I want to request for my mod that I am making (which is super super realistic)..

1. The whole idea of 10KB limit to simulate 60s technology is actually unrealistic. When code is compiled variable names are removed because they mean nothing to the computer anyways. Code becomes a lot smaller after being compiled. Can you please remove the 10KB limit or increase it to something more reasonable. the apollo computer programs were thousands of lines long. Now 2 or 3 hundred is the limit.

2. I need multiple KOS modules to be able to run different programs independently but use the same window. This is extremely important for example.

(In the terminal)

rename volume 1 to guidance.

rename volume 2 to staging.

switch to guidance.

run guidanceprogram.txt.

switch to staging.

run staging program.txt.

And both programs will "print" to the same terminal window. So no matter how many Computer parts you add. there is only one terminal window.

3.Multiple KOS units running without causing insane lag. Right now I am running 3 programs on 3 kos units which is very little but the lag is unbelievable.

4. THE ABILITY TO TERMINATE A PROGRAM EARLY FOR GODS SAKE

5. Compatibility with NathanKells Real fuels.

6. steering and RCS utillization on ships with no reaction wheels. ( saw aragorn working on that already very nice)

7. A goto IS DESPERATELY NEEDED

example:

#part 1.

do stuff.

#part 2.

do stuff.

if some condition {goto #part 1.}.

then the script starts over from part 1.

8. A not.. like

if not brakes {brakes on}.

if not x=1 {do this stuff}.

9. ability to detect parts being destroyed. (not critical)

10. the ability to set global variables for all running kos units. (important).

IF you guys could please get these implemented I would be forever gratefully.

thank you very much.

Edited February 6, 2014 by Zander

[Agathorn]

#5 and #6 are already on my realism list. The rest, well I just woke up so i'll need to read it again when i'm awake

[erendrake]

Hey guys.

I have some realism specific needs for KOS that I want to request for my mod that I am making (which is super super realistic)..

1. No

2. Great Idea, Something like that should not be insane to accomplish.

3. We have a ton of work ahead of us to make KOS faster, pull requests are always welcome.

4. Are you talking about from within the script? or with a user keypress? Or an API for you to call from your mod?

7. No

8. Kevin had a good start on adding this and it is clearly needed

9. Do you just want to know when the part count has changed? that would be simple. or do you want a list of parts that has been destroyed? or maybe an event API for registering an action or external function to happen whenever a part is destroyed?

10. would you like them to be instantly available to all running KOS units in the universe? or just on one ship? To have information travel instantly across the solar system is not very realistic

IF you guys could please get these implemented I would be forever gratefully.

thank you very much.

I wish you well on your mod and we will do what we can to help you out. if you want all of these soon, please consider issuing some pull requests for us to review.

[Agathorn]

#4 I think kOS definitely should have more flow control. Something akin to sys.exit(); to terminate a program at that point. As well as continue; and break; equivalent statements.

That said while I think it shoudl have them, I don' tknow how easy or insane it would be to try and implement them. They seem so obvious that I have to wonder if there is a good reason they were not included originally.

[erendrake]

#4 I think kOS definitely should have more flow control.

I agree, they should not be hard.

[Vladthemad]

What ever happened to the little Kerbal kicking a computer loading screen as seen in some of the videos on youtube?

[erendrake]

What ever happened to the little Kerbal kicking a computer loading screen as seen in some of the videos on youtube?

Its still there if you toggle power off and on again. We should restore it on launch