KSP-KOS / KOS

Fully programmable autopilot mod for KSP. Originally By Nivekk
Other
692 stars 229 forks source link

[1.2] kOS and Control Surfaces #1852

Closed NCommander closed 7 years ago

NCommander commented 7 years ago

When using cooked steering, control surfaces don't appear to be influenced at all, I've been using the following launch script and craft file to put my craft into orbit, and the control surfaces don't appear to be moving at all. If I fly the craft manually, they move just fine. I'm somewhat of a newbie to coding with kOS, but the documentation suggests that steeringmanager should manipulate control surfaces if they're enabled for Yaw/Pitch/Roll.

NCommander commented 7 years ago

Script:

//first.ks
// This program launches a ship from the KSC and flies it into orbit

//Set the ship to a known configuration
SAS off.
RCS on.
lights on.
lock throttle to 0. //Throttle is a decimal from 0.0 to 1.0
gear off.

clearscreen.

set targetApoapsis to 75000. //Target apoapsis in meters
set targetPeriapsis to 75000. //Target periapsis in meters

LIST ENGINES IN elist.

set seperation to false.

set runmode to 2. //Safety in case we start mid-flight
if ALT:RADAR < 50 { //Guess if we are waiting for take off
    set runmode to 1.
    }

until runmode = 0 { //Run until we end the program

    if runmode = 1 { //Ship is on the launchpad
        set TVAL to 1.        //Throttle up to 100%
        stage.                //Same thing as pressing Space-bar
        set runmode to 2.     //Go to the next runmode
        }

    else if runmode = 2 { // Fly UP to start cause of solids
        lock steering to heading (90,90). //Straight up.
        set TVAL to 1.
        if SHIP:ALTITUDE > 500 { 
            //Once altitude is higher than 2km, go to Gravity Turn mode
            set runmode to 3.
            }
        } //Make sure you always close out your if statements.

    else if runmode = 3 {
      lock steering to heading (90, 80). // Enter a gravity turn once we're above 500m
      if SHIP:ALTITUDE > 10000 {
        // Switch over to full g-turn mode at 10k
        set runmode to 4.
      }
    }
    else if runmode = 4 { //Gravity turn
        set targetPitch to max( 5, 90 * (1 - ALT:RADAR / 50000)). 
            //Pitch over gradually until levelling out to 5 degrees at 50km
        lock steering to heading ( 90, targetPitch). //Heading 90' (East), then target pitch
        set TVAL to 1.

        if SHIP:APOAPSIS > targetApoapsis {
            set runmode to 5.
            }
        }

    else if runmode = 5 { //Coast to Ap
        lock steering to heading ( 90, 3). //Stay pointing 3 degrees above horizon
        set TVAL to 0. //Engines off.
        if (SHIP:ALTITUDE > 70000) and (ETA:APOAPSIS > 60) and (VERTICALSPEED > 0) {
            if WARP = 0 {        // If we are not time warping
                wait 1.         //Wait to make sure the ship is stable
                SET WARP TO 3. //Be really careful about warping
                }
            }.
        else if ETA:APOAPSIS < 60 {
            SET WARP to 0.
            set runmode to 6.
            }
        }

    else if runmode = 6 { //Burn to raise Periapsis
        if ETA:APOAPSIS < 5 or VERTICALSPEED < 0 { //If we're less 5 seconds from Ap or loosing altitude
            set TVAL to 1.
            }
        if (SHIP:PERIAPSIS > targetPeriapsis) or (SHIP:PERIAPSIS > targetApoapsis * 0.95) {
            //If the periapsis is high enough or getting close to the apoapsis
            set TVAL to 0.
            set runmode to 10.
            }
        }

    else if runmode = 10 { //Final touches
        set TVAL to 0. //Shutdown engine.
        panels on.     //Deploy solar panels
        lights on.
        unlock steering.
        print "SHIP SHOULD NOW BE IN SPACE!".
        set runmode to 0.
        }

    if (seperation) {
      list engines in elist.
      set seperation to false.
    }

    for e in elist {
      if (e:FLAMEOUT and STAGE:READY) {
        STAGE.
        set seperation to true.
      }
    }

    set finalTVAL to TVAL.
    lock throttle to finalTVAL. //Write our planned throttle to the physical throttle

    //Print data to screen.
    print "RUNMODE:    " + runmode + "      " at (5,4).
    print "ALTITUDE:   " + round(SHIP:ALTITUDE) + "      " at (5,5).
    print "APOAPSIS:   " + round(SHIP:APOAPSIS) + "      " at (5,6).
    print "PERIAPSIS:  " + round(SHIP:PERIAPSIS) + "      " at (5,7).
    print "ETA to AP:  " + round(ETA:APOAPSIS) + "      " at (5,8).

    }
NCommander commented 7 years ago

Craft: DER Meep Meep.zip

hvacengi commented 7 years ago

In my testing the control surfaces are actuated just fine. Are you sure that you aren't running into an issue where kOS is lightly adjusting the controls, so the control surfaces do not move very much? Because kOS can make smaller and more accurate adjustments than you can make by hand, you often will not see a very noticeable deflection unless the steering error is very high, or you tweak the steering parameters for a stronger response.

Other than not noticing the control surfaces moving, are you seeing an issue where the steering seems to be under-compensating? Because the control authority of the control surfaces is taken into account when calculating how to steer, an having less torque than expected should cause the control to under-compensate.

kOS doesn't do anything special to control the ship, it's input is the exact same as input from SAS, and essentially the same as you adjusting the controls manually. It's also the same method that other mods like MechJeb use to integrate with the controls. There is no need nor way to subscribe to "steering using reaction wheels and gimbal only" that I'm aware of.

NCommander commented 7 years ago

I've tested this with a few other designs. I think the best way to compare it is fly manually and see how more responsive it is to left/right, etc. Stock SAS also has no problem holding a heading during launch.

The control surfaces are actually used, but they're not deflecting as much as they should. What I've had to do is cancel my script, hold a direction key to get it pointed closer to where it actually wants to go, and then that does it since it needs much smaller inputs once I'm tilted to 90/80. Throughout the flight, while on kOS control, the control inputs flail like crazy. Maybe its a problem with my coding skills/lack of kOS knowledge, but I feel like if I can point a ship to a heading with standard WASD easily, I don't understand why I can't get the autopilot to do the same.

I should note that for vechiles that have passive control surfaces (aka fins), and use RCS and/or reaction wheels, I get the expected behavior, tilt and fly off into orbit.

hvacengi commented 7 years ago

The cooked steering PID is not tuned for heavy reliance on control surfaces (see the advantages/disadvangtages discussion). If you want to used cooked steering for major control in the atmosphere mainly using control surfaces you'll have to be willing to tune the steering algorithm to fit your needs unfortunately. There is no good way for us to ensure that the settings will work well all of the time. Particularly at issue is the fact that the potential torque generated by control surfaces varies greatly with angle of attack, speed, and altitude/air pressure. http://ksp-kos.github.io/KOS_DOC/commands/flight/cooked.html#tuning-cooked-steering

All that being said, KSP did make one change to the torque code for 1.2.0 that I have not yet taken into account: they now expose positive and negative torque separately. Our steering model depends on the two directions being relatively symmetrical, so it's possible for a configuration to be inaccurate if it's outside of that assumption. I'm not yet really sure what to do about that however.

NCommander commented 7 years ago

On the first point, I'm a bit unclear on which values need to be tuned. The problem shows as the controls being pegged to one point in the UI but not moving. I'd be willing to test stuff.

On the second, it sounds like you could average the two together to get a 'net' torque value for the old interface of code. I could try help testing and/or debugging stuff if you like; I'd like to aid in kOS if I can help w/ limited time.

hvacengi commented 7 years ago

I may have spoken too soon regarding the issues with control surfaces. I just saw this post on the forum which makes it look the issue isn't so much that kOS isn't tuned properly as it isn't getting the correct torque value at higher speeds. The higher the speed, the higher the torque should read.

If you're still interested in doing a little testing, you might look into what kOS is registering for the torque values. If you compile kOS in Debug mode, the steering manager will expose additional suffixes, most notable to experimentation is STEERINGMANAGER:RAWTORQUE as it should show you what it calculates as "available" torque based on the part modules that implement ITorqueProvider. The x component should be pitch, the z should be yaw, and the y should be roll. As the available torque goes down, the actuation should go up, except that it is limited by two things: lower torque decreases the available actuation because of MAXSTOPPINGTIME, and the torque is one of the parameters affecting the PID tuning. You might also consider increasing MAXSTOPPINGTIME.

hvacengi commented 7 years ago

I did some poking around myself tonight. Turns out that in some configurations the control surfaces are returning a negative value for the "positive" torque. So I'm taking your suggestion and averaging the two values. It looks like that's resulting in kOS having more consistent performance for the time being. If you'd like to try it yourself before I submit the pull request, you can just replace line 598 of SteeringManager.cs with the following 3 lines:

                rawTorque.x += (Math.Abs(pos.x) + Math.Abs(neg.x)) / 2;
                rawTorque.y += (Math.Abs(pos.y) + Math.Abs(neg.y)) / 2;
                rawTorque.z += (Math.Abs(pos.z) + Math.Abs(neg.z)) / 2;

In fact, the more testing we have before the PR gets merged, the better we'll be.

NCommander commented 7 years ago

I probably won't have time to setup Unity SDK and such for at least or day or two. If you can shove the DLLs somewhere, I can grab it and launch some test rockets.

On Tue, Oct 25, 2016 at 11:36 PM, Brad White notifications@github.com wrote:

I did some poking around myself tonight. Turns out that in some configurations the control surfaces are returning a negative value for the "positive" torque. So I'm taking your suggestion and averaging the two values. It looks like that's resulting in kOS having more consistent performance for the time being. If you'd like to try it yourself before I submit the pull request, you can just replace line 598 of SteeringManager.cs with the following 3 lines:

            rawTorque.x += (Math.Abs(pos.x) + Math.Abs(neg.x)) / 2;
            rawTorque.y += (Math.Abs(pos.y) + Math.Abs(neg.y)) / 2;
            rawTorque.z += (Math.Abs(pos.z) + Math.Abs(neg.z)) / 2;

In fact, the more testing we have before the PR gets merged, the better we'll be.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KSP-KOS/KOS/issues/1852#issuecomment-256241435, or mute the thread https://github.com/notifications/unsubscribe-auth/AALDQHOAOKsOQ0ItXIrhpDMPof8AgOSAks5q3srZgaJpZM4KeD-8 .

hvacengi commented 7 years ago

You don't need a full Unity SDK, just Visual Studio or Mono Develop and the dll's shipped with KSP. Here's a temporary link to compiled binaries: https://www.dropbox.com/s/b7lgela51zwvs91/kOS.zip?dl=0

NCommander commented 7 years ago

Got it, thanks. Didn't realize I just needed Visual Studio, which I do have. I haven't done much in mod development. I won't be able to test this much in the near future, but what I might do is see if I hav e aKSP 1.1 install, and get it to echo out the angle of attack as it flies the same craft on both to see how the cooked steering is working.

On Thu, Oct 27, 2016 at 12:13 AM, Brad White notifications@github.com wrote:

You don't need a full Unity SDK, just Visual Studio or Mono Develop and the dll's shipped with KSP. Here's a temporary link to compiled binaries: https://www.dropbox.com/s/b7lgela51zwvs91/kOS.zip?dl=0

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KSP-KOS/KOS/issues/1852#issuecomment-256542342, or mute the thread https://github.com/notifications/unsubscribe-auth/AALDQH_qasxnT4qSpuAtorrxcSpVcqoLks5q4CTmgaJpZM4KeD-8 .