Nittany Tiger

Any tips to reduce floppy rocket syndrome? During some runs with my Saturn VB using my kOS script, after SRB jettison, my rocket loses all structural integrity and starts to gyrate around it's z-axis. This doesn't always happen, but I don't know when or why it does. I have attempted to strut up the weak joints, but that doesn't seem to help the problem.

Do you have Remote Tech installed?

Hmm. That's interesting. It doesn't mention you need that for kOS with Remote Tech. I guess it depends on if you're running from archive or not. I dunno. I haven't played with kOS with Remote Tech either. Sounds like a fluid dynamics problem, or maybe you can pull that from KSP's aerodynamics model. I'm sure it calculates lift, but I wouldn't know what model it uses or if you can get those values. Point is, a direct answer to your question would involve a discussion of things I'm not familiar with, which is the aerodynamics of a wing surface. I'm sure you can make some assumptions, go on Wikipedia, and if you're clever enough, figure out how to find that in KSP.

My first guess is that you're missing the part needed for kOS to run: I don't play with kOS in stock, so I don't know if you need that part on your rocket every time you want to use kOS. In RSS/RO, every command pod and probe core has a kOS module installed, so I never need to add this part.

Update time. Autopilot code is coming along, and after some trial and error, I have a gravity turn programmed in. I found that an initial pitchover of 10 degrees seems to give me the best gravity turn. I thought of finding the perfect pitch angle analytically, but it would mean solving this differential equation (provided I set it up properly): This is the equation for the accelerations on the rocket on ascent. I could probably solve in numerically, but I think it's a bit much for this project. Maybe another day. Anyway, the code so far. There is a lot of junk commenting and temporary code commented out, but I'll clean that up in the final version: //Saturn VB Autopilot program //Ctrl + C to kill? RUNPATH("AresLaunchDisplay.ks"). SET ddyn to 0. SET dynzero to 0. //If variables are lists, can I accees each element in loops below and make code more efficient? SET Inboard to SHIP:PARTSTAGGED("F1AInboard")[0]. SET Outboard to SHIP:PARTSTAGGED("F1AOutboard1")[0]. SET SRB to SHIP:PARTSTAGGED("SRB1")[0]. SET MSIC to SHIP:PARTSTAGGED("MS-IC")[0]. CLEARSCREEN. //in case we need this //Display event, throttle setting, F-1A thrust %, and SRB thrust %. //Lock steering to a variable to make it less intensive to run? LOCK STEERING to Autopilot. LOCK Autopilot to "Kill". LOCK THROTTLE to 1.0. //Temp - steering debug - delete after use //SET STEERINGMANAGER:SHOWSTEERINGSTATS to TRUE. //SET STEERINGMANAGER:SHOWFACINGVECTORS to TRUE. //SET STEERINGMANAGER:SHOWANGULARVECTORS to TRUE. STAGE. //F-1A ignition //Ultimate goal of steering program is to set rocket into pre-programmed circular orbit of 200 km - 250 km. //Pitch by x degrees, then follow prograde until rocket reaches certain altitude. //Finally, manage pitch to put Ares in circular orbit. //In launches using manual steering, Ares ends gravity turn between SRB sep and MS-IC burnout. //Adjust heading to meet propulsion stack inclination (or desired inclination). Could have this able to be set as input prior to launch. //At v(sfc) = 50 m/s, pitch over a bit to initiate gravity turn. //then hold prograde for gravity turn. (angle between v and a zero.) //Pitch and roll manuever. Correct initial pitch is trial and error right now. //Could the gravity turn be better programmed as a diff eq (predictive equation)? //Print that gravity turn is in progress - Integrate with LaunchDisplay function? WHEN SHIP:VELOCITY:SURFACE:MAG >= 50 THEN { //Pitch then roll for inclination (90 degrees for now). - smooth out move to pitch? LOCK Autopilot to HEADING(90,80). //175 km AP at SRB sep. SRB sep at 70 km. - Last setting, 78 degrees pitch, then 83 //Follow prograde next. WHEN SHIP:FACING:VECTOR:NORMALIZED:Z - SHIP:VELOCITY:SURFACE:NORMALIZED:Z <= 0 THEN { LOCK Autopilot to SHIP:VELOCITY:SURFACE. //SHIP:VELOCITY:SURFACE or SHIP:SRFPROGRADE? PRINT "Begin Gravity Turn" at (0,10). //Start PID loop for hitting set apoapsis - lasts until SECO. //Output pitch (or yaw) based on set final apoapsis. WHEN SHIP:ALTITUDE > 75000 THEN { //Lock Autopilot to HEADING(90,0). //turns way too sharply, also readjusts heading } } } //Countdown here? UNTIL (Outboard:THRUST/Outboard:MAXTHRUST) > 0.88 { IF(Outboard:MAXTHRUST > 0) { //Prevent NAN LaunchDisplay(0,2,Outboard:THRUST/Outboard:MAXTHRUST,0). } //WAIT 0.01. } STAGE. //SRB ignition and liftoff CLEARSCREEN. //Maybe countdown and abort mode display. //WAIT 0.01. //Display loop could continue on with a PRESERVE command after throttleback? UNTIL MISSIONTIME > 25 { IF(SRB:MAXTHRUST > 0 AND SRB:THRUST > 0) { //Prevent NAN //PRINT "Facing-vel srf Angle: " + VANG(SHIP:FACING:VECTOR, SHIP:VELOCITY:SURFACE) + " " at (0,4). //PRINT "Facing Z - Vel Srf Z (Normalized): " + (SHIP:FACING:VECTOR:NORMALIZED:Z - SHIP:VELOCITY:SURFACE:NORMALIZED:Z) at (0,5). //PRINT "Facing-target Angle: " + VANG(SHIP:FACING:VECTOR, STEERINGMANAGER:TARGET:VECTOR) + " " at (0,6). //PRINT "Facing - Target: " + (SHIP:FACING:VECTOR:Z - STEERINGMANAGER:TARGET:VECTOR:Z) + " " at (0,7). //PRINT "Facing Z: " + SHIP:FACING:VECTOR:Z + " "at (0,8). //PRINT "Vel Srf Z: " + SHIP:VELOCITY:SURFACE:Z + " "at (0,9). LaunchDisplay(1,2,Outboard:THRUST/Outboard:MAXTHRUST,SRB:THRUST/SRB:MAXTHRUST). } //WAIT 0.01. } CLEARSCREEN. LOCK THROTTLE to 0.01. //F-1A throttle to 60% for max Q //check dyn pressure change //if ddyn < -0.004kPa/0.01s or so, throttle to 85% (was -0.04kPa/0.1s) UNTIL ddyn <= -0.004 { LaunchDisplay(2,0,Outboard:THRUST/Outboard:MAXTHRUST,SRB:Thrust/SRB:MAXTHRUST). SET ddyn TO (SHIP:Q*constant:ATMtokPa) - dynzero. //units are kPa <- can be lock statement SET dynzero TO (SHIP:Q*constant:ATMtokPa). //<- these can be LOCK statements WAIT 0.01. //change to 0.1? <- can remove this when using lock and dividing by time. } LOCK THROTTLE to 0.63. //F-1A throttle to 85% CLEARSCREEN. //4+Gs before SRB tail-off. //Stage SRBs and throttle to 100% when SRB thrust < 10% UNTIL SRB:THRUST/SRB:MAXTHRUST < .1 { LaunchDisplay(3,1,Outboard:THRUST/Outboard:MAXTHRUST,SRB:Thrust/SRB:MAXTHRUST). //WAIT 0.01. } STAGE. //SRB jettison LOCK THROTTLE to 1.0. //F-1A throttle to 100% //Center engine shutdown at 26s before MS-IC burnout (G >= 3.8g) CLEARSCREEN. UNTIL (MSIC:MASS - MSIC:DRYMASS)/(Outboard:FUELFLOW * 5) < 26 { LaunchDisplay(4,2,Outboard:THRUST/Outboard:MAXTHRUST). //WAIT 0.01. } Inboard:SHUTDOWN. //Inboard cut-off. CLEARSCREEN. //Manage g-forces here? //Stage MS-IC UNTIL Outboard:FLAMEOUT = TRUE { IF Outboard:MAXTHRUST > 0 {//Prevent NAN LaunchDisplay(5,2,Outboard:Thrust/Outboard:MAXTHRUST). } //WAIT 0.01. } PRINT "Main Engine Cut-off ". WAIT 1. STAGE. //MS-IC staging. //Ignite MS-II CLEARSCREEN. WAIT 3. STAGE. //MS-II ignition. PRINT "Second stage ignition.". //Skirt seperation WAIT 30. STAGE. PRINT "Skirt separation.". //LES Tower jettison WAIT 6. AG27 on. PRINT "Launch escape tower jettison.". //Ignite MS-II and develop guidance to achieve circular orbit at ~200 km - 250 km //Code should monitor vert vel and time to AP, but code should find optimal pitch profile for MS-II flight and orbital insertion (lowest possible dV usage) //Set throttle to zero when code terminates. SET SHIP:CONTROL:PILOTMAINTHROTTLE to 1. //This will be changed to "set to 0" when the program is fully written. So now the next step in the steering code is to tell the rocket to make a circular orbit after getting mostly out of the atmosphere. I feel about 75km is the best time to start this part of the program because with the current gravity turn program, the apoapsis is already at 175 km when SRB sep happens at about 70km altitude. WARNING: MATH AHEAD!!! The first problem is deciding how to tell the rocket to steer itself to match a pre-set apoapsis. After some though and looking at equations for orbital velocity, velocity at apoapsis, orbital radius at apoapsis, and more, I decided to try to get the rocket to seek to hit a target apoapsis at secondary engine cut-off (SECO) through a PID loop. Using the equations for orbital velocity and apoapsis velocity, I assumed that I could represent orbital velocity as a function f(z) times apoapsis velocity: Substituting for v_orb and v_ap and solving for f(z), I get: Substituting that back in and letting v_orb = v_vert*sin(theta), where theta is the rocket pitch angle, and solving for r_ap, or the apoapsis (+ radius of the earth), I eventually get: Where mu = G*M. I think I'll have to solve this for theta since I'll be measuring errors between the final and current apoapsis to get a pitch for the rocket. I'll also need to limit the outputs so I don't get hard steering. If anyone wants to check my math, I can post the derivations, but I hope these equations will work for me. Also, I promise that I'll actually fly the mission. The autopilot is the last huge project I want to work on before I fly it.

Dunno if you can get it for 1.1.3 still. That's the last stable version I think. You just miss out on 1.2 features that I think are very useful for RSS/RO like auto-strutting and fuel flow management. You just have to find KSP version 1.1.3 somewhere. As far as myself, I installed RSS/RO last year well before 1.2 using CKAN. I copied the game from Steam, removed the mods I was using there, and then installed RSS/RO.

That's good. I tested engine activation with stock action groups, and the gimbal bug didn't pop up. It must be something with AGX.

I think the problem is that you can't use PRINT for a list, and PART:MODULES is a list. If you want to print out the modules, use LIST antenna:modules.

@GeKa do you have any parts whose name tags are set to "antenna"? SHIP:PARTSTAGGED() doesn't look for part with "antenna" in the name, but it looks for parts with their name tags set to "antenna."

Yeah, I think you're hitting the same bug I am where if you don't activate engines through staging but through action groups, then the engines don't gimbal. I don't know if it's an AGX bug or a stock bug, but it's not a kOS bug. The only way I know how to fix it is to activate your engines through staging. I also don't know if this is a bug in RSS/RO installs or stock ones. I think I just need to check myself where the bug is. In summary, your issue is that since you're trying to turn your engines on via AGX action groups (or stock action groups), the engine gimbals don't turn on. Currently, the only solution to that is to activate your engines through staging.

I know I once experienced a bug where if I didn't activate engines through staging, they would not gimbal. This wasn't a kOS problem, but a problem I experienced trying to activate engines through AGX. This might just be a stock bug. How are you activating your engines?

Since I launch vertically, and stock SAS holds vertical just fine, I decided to just lock steering to "kill," since that's the same as turning SAS on and setting it to stability assist mode. Maybe the statement about SAS is for post 1.0 versions of kOS.Plus, using cooked steering all the way seems to work so far for my rocket guidance. I start with LOCK STEERING to "kill" until my surface velocity exceeds 50 m/s (it's all vertical velocity because it's a vertical launch), and then I command the pitch and roll by using LOCK STEERING to HEADING(90,87). From experimentation, that seems to do what I want where the rocket pitches slightly for a gravity turn and rolls to a eastward heading. I'll try to lock it to prograde after the pitchover when the velocity and facing vectors are closely aligned and hopefully that will give me a good gravity turn. Is your rocket following cooked steering commands? Is it turning or holding still like you ask even though you're not getting a visible gimbal response?

https://ksp-kos.github.io/KOS/commands/flight.html I made a mistake in reading that you could have SAS on and have it not do anything. I was using SAS to help keep my ship pointed up to dampen any oscillations, but having it full on instead caused SAS and kOS to fight each other and produce those huge oscillations. The belief that I could have SAS on meant that I overlooked it as a problem until I reconsidered it today. I actually thought kOS's PID controllers were wonky, and was on the verge on writing my own. As fun as that could have been, I'm glad I found out the true cause of my issues, albeit it was a silly mistake. I should try SAS set to Stability Assist before I start coding the pitch maneuver since I want my ship to roll and then pitch after reaching 50 m/s, and it needs to be stable for a second or two during its ascent before the pitch and roll program are engaged. EDIT: Turns out default SAS setting was Stability Assist, so I dunno what was going on. I'm just going to leave SAS off in my code. I could try to figure out the problem later, or possibly it's a feature post 1.0, but I can replace SAS ON with LOCK STEERING to Up and get the same result I want hopefully without any steering silliness.

Looks like the problem with the kOS cooked steering was having SAS on while commanding the roll, so I guess I need to redo the tuning without SAS now. Two days of fighting a bad setting in kOS and never knowing it.

Actually, I may have solved my own problem. On a fluke, I set Kd to 90 and finally got a different steering behavior. I guess my PID parameters were just too low for my rocket. At worst, I'll just make my own PID loop. I was in the process of doing that if a high Kd setting didn't work for kOS's built-in Roll PID controller. EDIT: Turns out having SAS on is causing the undesired steering behavior. I noticed SAS was off, turned it on, and the severe oscillations returned. Therefore, I can only conclude the SAS was causing issues with kOS steering. This is something I overlooked, but I'm glad I found it. I assumed that SAS wouldn't have an effect during cooked steering because of what the kOS documentation said, but maybe it still does cause some unwanted effects in v1.0.

I have an issue with steering in kOS version 1.0 that I haven't been able to fix. I'm afraid to upgrade kOS to the latest version because I'm using kOS on an install of Real Solar System and Realism Overhaul that is still using KSP 1.1.3, and I don't think the mods I'm using are all update for KSP version 1.2. Anyway, as part of my Ares mission, I've been writing a kOS script for handling the launch. I've been able to write the staging and throtting commands just fine, but when it comes to steering, my rocket seems to act like a drunk man. My main launch scripts can be found here: Right now, I'm trying to test how to tell my rocket to roll 90 degrees clockwise. I've been using this command: //Execute 90-degree roll. SET roll to 180 - 90. LOCK STEERING to Up + R(0,0,roll). It's equivalent to LOCK STEERING to Up + R(0,0,90). When the command is executed, though, my rocket oversteers by up to twice the commanded roll, so for instance, the rocket rolls from 180 to 0 and back. I looked up the kOS documentation and got to work trying to solve the issue. First I tried adjusting the ROLLTS and observed no change in behavior. I tried adjusting ROLLTORQUEFACTOR and observed no change in behavior. Then I figured that I would have to tune the Roll PID controller itself. I wrote a script for doing so, hoping I was measuring the correct value for tuning: //Saturn VB PID Tuning //DECLARE PARAMETER Kd. RUNPATH("AresLaunchDisplay.ks"). //SET Inboard to SHIP:PARTSTAGGED("F1AInboard")[0]. SET Outboard to SHIP:PARTSTAGGED("F1AOutboard1")[0]. SET SRB to SHIP:PARTSTAGGED("SRB1")[0]. //Possibility for roll oversteer - kOS underestimates torque available. //STEERINGMANAGER:RESETPIDS(). //SET STEERINGMANAGER:ROLLPID:KP to 1. //Wrong parameters? //SET STEERINGMANAGER:ROLLPID:KI to 0. //SET STEERINGMANAGER:ROLLPID:KD to Kd. SET STEERINGMANAGER:ROLLTORQUEADJUST to -300000. //This should correct kOS's torque underestimation CLEARSCREEN. SAS ON. LOCK THROTTLE to 1.0. STAGE. //F-1A ignition UNTIL (Outboard:THRUST/Outboard:MAXTHRUST) > 0.88 { IF(Outboard:MAXTHRUST > 0) { //Prevent NAN LaunchDisplay(0,2,Outboard:THRUST/Outboard:MAXTHRUST,0). } } STAGE. //SRB ignition and liftoff CLEARSCREEN. LOG "Roll PID Tuning" TO Roll_Log.txt. LOG "Kd: " + STEERINGMANAGER:ROLLPID:KD TO Roll_Log.txt. LOG "t,Roll Deviation (Kd = " + STEERINGMANAGER:ROLLPID:KD +")" TO Roll_Log.txt. //Execute 90-degree roll. SET roll to 180 - 90. LOCK STEERING to Up + R(0,0,roll). //rotation not affected by PID settings because not cooked? //Print deviation from desired roll vs time. UNTIL MISSIONTIME > 90 { SET r to (SHIP:BEARING) - (-roll + 180). LOG MISSIONTIME + "," + r TO Roll_Log.txt. WAIT 0.001. //Should this wait go away? Is it causing cooked steering to malfunction? - NO } AresLaunchDisplay.ks //Display program for Ares Launch program. SET State to list("Ignition Sequence Start", "Liftoff", "Max Q", "Throttle Up", "SRB Sep", "Center Engine Shutdown", "Staging", "Stage Two Ignition", "Skirt Separation", "LES Jettison", "SECO"). SET Level to list("60", "85", "100"). function LaunchDisplay{ parameter statevariable. parameter throttlelevel. parameter liquidthrust. parameter SRBthrust is 0. CLEARVECDRAWS(). //Set Velocity to VECDRAW(V(0,0,0),SHIP:VELOCITY:SURFACE + R(0,-3,0),Blue,"v",5.0,TRUE,0.3). //Set Prograde to VECDRAW(V(0,0,0),50*SHIP:SRFPROGRADE:VECTOR,Green,"p",5.0,TRUE,0.3). PRINT State[statevariable] at (0,0). PRINT "Throttle Setting: " + Level[throttlelevel] + "%" at (0,1). IF statevariable <= 5 { PRINT "F-1A Thrust: " + ROUND(liquidthrust * 100,1) + "%." at (0,2). } ELSE { PRINT "J-2S Thrust: " + ROUND(liquidthrust * 100,1) + "%." at (0,2). } IF statevariable < 4 AND statevariable > 0 { PRINT "UA1564 Thrust: " + ROUND(SRBthrust * 100,1) + "%." at (0,3). } } The lines for the PID parameters and declare statement are commented out here only temporarily, and I uncomment them when I need them. I also didn't have the ROLLTORQUEADJUST line in the code when trying to tweak the PID parameters. So I went on to set KI and KD to zero and vary KP. No value of KP changed the behavior of the roll oscillations: Kp was set at 2000, 1, 0.001, and 100. I then fixed Kp to 1 and varied Kd. Also didn't see any real change in behavior except at bit of an amplitude variation at the end. Next I thought that maybe my engines are gimballing too much and tried to reduce the gimbal ranges. Again, no change in behavior. (no graph available right now). Finally, I thought that maybe kOS was underestimating the amount of available torque my craft had, so I set ROLLTORQUEADJUST to 300,000 kNm, which is what MechJeb said I was producing in the z-direction. No change in behavior. I subtracted 300,000kNm and also experienced no change in behavior. After that, I ran out of ideas. I did a test with MechJeb's SmartASS and it was able to perform the 90-degree roll with almost no overshoot, so I know that it's possible for some sort of script to make the craft roll properly. I'm not sure what, and I'm not even sure I'm tuning the right parameters or using the right commands to steer the craft or tuning the proper PID controller. If anyone has any ideas what I'm doing wrong, let me know, because I don't have an idea what might be going on. I'm not really familiar with PID controllers, and this is my first time using kOS to steer a rocket, and my first time trying to tune a PID controller.

I use some of the weaker engines to provide my current spaceplane with a bit of cross-range capability without adding too much launch mass, but I use the Juno, not the Weesley. This is not an SSTO, but launches vertically. There are two more Junos on the top right above the bottom ones. I would think Weesleys could be used in a similar way, providing non-SSTO spaceplanes some cross-range capability just in case you miss the KSC on re-entry. The inclusion of reverse thrust is a bonus as well. I personally haven't found much use for the Panther. Maybe it's because I don't really have a need or interest in atmospheric planes except for contracts on Kerbin, but even with the contracts I get, the Panther doesn't fill a role the other engines I have fill better. I thought maybe you could make a primitive SSTO with the Panther, but I haven't played with it enough to see that. I actually would love to see if you could make SSTOs with Weesleys or Panthers or even Goliaths because it seems like for space enthusiasts like myself, the only way to do an SSTO is with a Whiplash or RAPIER, which makes most of the jet engines a waste of science (and funds) in the career mode if your main interest is in space exploration. Of course, like @Snark said, many of the parts in KSP are made to be just useful in the early game and never again, so maybe the Weesley is one of these a stepping stone parts used to obtain a better jet engine later in the game.

Spent yesterday tuning a PID loop for my Saturn VB autopilot script in kOS and getting no results. I hope today is different, and I hope I'm doing the tuning properly. Maybe fixing the severe oversteer I get from commanding a roll to a Eastern heading is easier than PID tuning. (It's RSS/RO, not stock).

I spent all day yesterday trying to tune the proportional parameter of kOS's PID controller. I first had to debug my tuning script. Here was the final script I used: //Saturn VB PID Tuning DECLARE PARAMETER Kp. RUNPATH("AresLaunchDisplay.ks"). //SET Inboard to SHIP:PARTSTAGGED("F1AInboard")[0]. SET Outboard to SHIP:PARTSTAGGED("F1AOutboard1")[0]. SET SRB to SHIP:PARTSTAGGED("SRB1")[0]. SET STEERINGMANAGER:ROLLPID:KP to Kp. //Wrong parameters? SET STEERINGMANAGER:ROLLPID:KI to 0. SET STEERINGMANAGER:ROLLPID:KD to 0. CLEARSCREEN. SAS ON. LOCK THROTTLE to 1.0. STAGE. //F-1A ignition UNTIL (Outboard:THRUST/Outboard:MAXTHRUST) > 0.88 { IF(Outboard:MAXTHRUST > 0) { //Prevent NAN LaunchDisplay(0,2,Outboard:THRUST/Outboard:MAXTHRUST,0). } } STAGE. //SRB ignition and liftoff CLEARSCREEN. LOG "Roll PID Tuning" TO Roll_Log.txt. LOG "Kp: " + STEERINGMANAGER:ROLLPID:KP TO Roll_Log.txt. Log "t,Roll Deviation (Kp = " + Kp +")" TO Roll_Log.txt. //Execute 90-degree roll. SET roll to 180 - 90. LOCK STEERING to Up + R(0,0,roll). //rotation not affected by PID settings because not cooked? //Print deviation from desired roll vs time. UNTIL MISSIONTIME > 90 { SET r to (SHIP:BEARING) - (-roll + 180). LOG MISSIONTIME + "," + r TO Roll_Log.txt. WAIT 0.001. } You might be able to notice some commenting I did as I ran the rocket launch with different Kp setting. This is because varying Kp seemed to do nothing to my roll behavior. So I varied Kp from 0.001 all the way to 2000, and little or no change in my roll behavior was observed. Just for reference, Kp = 1 is the default Kp value, blue is Kp = 2000, purple is Kp = 0.001, and magenta is Kp = 100. I would think there would be some change with the roll behavior as Kp is varied, so I'm baffled as to what's going on, and even concerned I'm not commanding a roll properly in kOS. I may also just be improperly tuning the controller, as I have no experience and no knowledge of PID controllers up until trying to implement this steering program. Nonetheless, all literature seems to point to varying Kd as what I should be doing to dampen the oscillations. I will do this next instead of continuing to vary Kp to produce some sort of roll behavior different from what's observed above. My only other solution to the oversteer is to dampen the gimballing of the first stage engines. Hopefully varying Kd with Kp = 1 gives me some results. I'm welcome to advice or criticism of my tuning as I'm not familiar with PID tuning, and I'm just doing my best based on what I'm reading from Wikipedia and the kOS documentation. Plus, I don't want the kOS script itself to take over the purpose of this Ares recreation project, and I do want to fly the mission soon.

Have you skimmed the mod's thread for any potential bugs others are having? If not, I may give it a look. What SLS Block are you trying to fly? I assume the Block II. If so, what boosters are you using?

Been working on the steering portions of the autopilot. Oh boy is this fun. Seriously, though, this has been a lot of fun to learn, but it's not without stress and frustration. I've had to teach myself KSP and Unity's co-ordinate system since my first guesses at proper rotation and steering vectors led to wild and unpredictable rocket behavior, or so I thought. Anyway, I opened up GIMP and made myself a pic to visualize what I think KSP's co-ordinate system is like: I had also started doing a body diagram for the rocket during ascent beforehand to see what I would need to do to make kOS command a proper gravity turn for the rocket. Forgive me for any mathematical or physical errors in this diagram. There might be a few (like angle of attack might not be between v and a). This is all just in case I need to use kOS to model an equation for the pitch profile. Can you say differential equations? I'm excited. Haven't done those in a while. I decided to debug my steering issues by just having the rocket perform turns in one direction, starting with a roll maneuver. I wrote in the following line: LOCK STEERING to Up + R(0,0,90). and the rocket did roll clockwise to try to face East, but then overshot by 90 degrees before turning back and overshooting again by 90 degrees, and so on... Looks like the cooked steering doesn't like my craft. After trying a few things with the Steering Manager, I unfortunately concluded that I needed to do PID tuning, which is something I have never done before. Nonetheless, it's not something I can't try to figure out, and after examining some of kOS's documentation on PID controllers along with some documentation online, I think I can tune this controller. I already created a smaller script for recording the rocket's bearing deviations from the commanded roll heading versus time so I can plot that in Google Sheets and start to get a handle on the oversteer. I could also just guess some Kd values, but I figure this might be more accurate in the end. All this code does is fly the rocket straight up, perform the roll maneuver, and record the deviation. //Saturn VB PID Tuning RUNPATH("AresLaunchDisplay.ks"). //SET Inboard to SHIP:PARTSTAGGED("F1AInboard")[0]. SET Outboard to SHIP:PARTSTAGGED("F1AOutboard1")[0]. SET SRB to SHIP:PARTSTAGGED("SRB1")[0]. //SET STEERINGMANAGER:ROLLPID:KP to 0. SET STEERINGMANAGER:ROLLPID:KI to 0. SET STEERINGMANAGER:ROLLPID:KD to 0. CLEARSCREEN. SAS ON. LOCK THROTTLE to 1.0. STAGE. //F-1A ignition UNTIL (Outboard:THRUST/Outboard:MAXTHRUST) > 0.88 { IF(Outboard:MAXTHRUST > 0) { //Prevent NAN LaunchDisplay(0,2,Outboard:THRUST/Outboard:MAXTHRUST,0). } } STAGE. //SRB ignition and liftoff CLEARSCREEN. LOG "Roll PID Tuning" TO Roll_Log.txt. LOG "Kp: " + STEERINGMANAGER:ROLLPID:KP TO Roll_Log.txt. Log "t,Roll Deviation" TO Roll_Log.txt. //Execute 90-degree roll. SET roll to 180 - 90. LOCK STEERING to Up + R(0,0,roll). //Print deviation from desired roll vs time. UNTIL MISSIONTIME > 90 { SET r to (SHIP:BEARING) - (-roll + 180). LOG MISSIONTIME + "," + r TO Roll_Log.txt. } Hopefully, this won't take too long to do, and it should be fun to do something new. I assume I might have to tune the pitch script as well, but it should be easier once I get a handle on tuning in general.

First I've seen this. Every time I've done a Mun landing in KSP, I've done it using the LOR method (Or Munar Orbit Rendezvous in this case). I love Apollo too much to do it any other way. In comparison, I always use Kerbin Orbit Rendezvous for missions to Minmus. I've built various rockets to mimic the Apollo missions, from my first being this monstrosity from years ago: (I don't have a pic of the lander and upper stage, sorry), to my more refined craft: Wouldn't know my score on this mission. It was part of my career mode run and I was doing this for a contract, but I can make a guess if you guys are curious. EDIT: To respect the topic, I might import this rocket to sandbox and do the mission without any edits to see how many points it scores. It's almost all stock parts. It depends on if you count Porkjet's Stock Overhaul mod as stock or not, as my second stage engines are two retextured LV-T45s and my CSM and LM (MM) might use LV-T15s. Could also just give a mission report of what I did in career mode from memory.

I did not know there was another definition of ullage. I always knew of ullage having to do with propellant settling, which I referred from ullage motors being for propellant settling. I learn something new every day.

I love doing in-orbit assemblies. It's fun to dock the stuff, though docking itself is time-consuming. A lot of my stock missions to Minmus are Kerbin Orbit Rendezvous-style missions with a lander/return capsule mated to a drive stage. For Munar missions, I go with Munar Orbit Rendezvous because I love the Apollo missions and just like the style of a single-launch rocket with a lander and CSM. I'll post the craft I use in the relevant thread. Can't wait to see your RO stuff. Back on topic, here's my current version of my kOS launch script. I finally got a way to measure stage time after discovering some facts I overlooked. Turns out it's not too hard to get stage timing. I ended up diving the fuel mass of the MS-IC stage by five times the rate of fuel consumption of a single F-1A engine. Fuel mass was obtained by subtracting the total mass of the MS-IC stage by the dry mass. //Saturn VB Autopilot program RUNPATH("AresLaunchDisplay.ks"). SET ddyn to 0. SET dynzero to 0. //If variables are lists, can I accees each element in loops below and make code more efficient? SET Inboard to SHIP:PARTSTAGGED("F1AInboard")[0]. SET Outboard to SHIP:PARTSTAGGED("F1AOutboard1")[0]. SET SRB to SHIP:PARTSTAGGED("SRB1")[0]. SET MSIC to SHIP:PARTSTAGGED("MS-IC")[0]. CLEARSCREEN. //in case we need this //Display event, throttle setting, F-1A thrust %, and SRB thrust %. LOCK THROTTLE to 1.0. STAGE. //F-1A ignition //Countdown here? UNTIL (Outboard:THRUST/Outboard:MAXTHRUST) > 0.88 { IF(Outboard:MAXTHRUST > 0) { //Prevent NAN LaunchDisplay(0,2,Outboard:THRUST/Outboard:MAXTHRUST,0). } WAIT 0.01. } STAGE. //SRB ignition and liftoff CLEARSCREEN. //Maybe countdown and abort mode display. //Ultimate goal of steering program is to set rocket into pre-programmed circular orbit of 200 km - 250 km. //Pitch by x degrees, then follow prograde until rocket reaches //Print that gravity turn is in progress. //Pitch and roll program happen before T + 25. //Display loop could continue on with a PRESERVE command after throttleback. UNTIL MISSIONTIME > 25 { IF(SRB:MAXTHRUST > 0) { //Prevent NAN LaunchDisplay(1,2,Outboard:THRUST/Outboard:MAXTHRUST,SRB:THRUST/SRB:MAXTHRUST). } WAIT 0.01. } //Adjust heading to meet propulsion stack inclination (or desired inclination). Could have this able to be set as input prior to launch. CLEARSCREEN. LOCK THROTTLE to 0.01. //F-1A throttle to 60% for max Q //check dyn pressure change //if ddyn < -0.004kPa/0.01s or so, throttle to 85% (was -0.04kPa/0.1s) UNTIL ddyn <= -0.004 { LaunchDisplay(2,0,Outboard:THRUST/Outboard:MAXTHRUST,SRB:Thrust/SRB:MAXTHRUST). SET ddyn TO (SHIP:Q*constant:ATMtokPa) - dynzero. //units are kPa SET dynzero TO (SHIP:Q*constant:ATMtokPa). WAIT 0.01. //change to 0.1? } LOCK THROTTLE to 0.63. //F-1A throttle to 85% CLEARSCREEN. //4+Gs before SRB tail-off. //Stage SRBs and throttle to 100% when SRB thrust < 10% UNTIL SRB:THRUST/SRB:MAXTHRUST < .1 { LaunchDisplay(3,1,Outboard:THRUST/Outboard:MAXTHRUST,SRB:Thrust/SRB:MAXTHRUST). WAIT 0.01. } STAGE. //SRB jettison LOCK THROTTLE to 1.0. //F-1A throttle to 100% //Center engine shutdown at 26s before MS-IC burnout (G >= 3.8g) CLEARSCREEN. UNTIL (MSIC:MASS - MSIC:DRYMASS)/(Outboard:FUELFLOW * 5) < 26 { LaunchDisplay(4,2,Outboard:THRUST/Outboard:MAXTHRUST). WAIT 0.01. } Inboard:SHUTDOWN. //Inboard cut-off. CLEARSCREEN. //Manage g-forces here? //Stage MS-IC UNTIL Outboard:FLAMEOUT = TRUE { IF Outboard:MAXTHRUST > 0 {//Prevent NAN LaunchDisplay(5,2,Outboard:Thrust/Outboard:MAXTHRUST). } WAIT 0.01. } PRINT "Main Engine Cut-off" WAIT 1. STAGE. //MS-IC staging. //Ignite MS-II CLEARSCREEN. WAIT 3. STAGE. //MS-II ignition. PRINT "Second stage ignition.". //Skirt seperation WAIT 30. STAGE. PRINT "Skirt separation.". //LES Tower jettison WAIT 6. AG27 on. PRINT "Launch escape tower jettison.". //Ignite MS-II and develop guidance to achieve circular orbit at ~200 km - 250 km //Code should monitor vert vel and time to AP, but code should find optimal pitch profile for MS-II flight and orbital insertion (lowest possible dV usage) There has been no changes to the Ares Launch Display program, so I'm not reposting it. I may bring the list definitions to the main program to help it run faster. I also might need to remove some WAIT statements in loops that might be causing performance issues and are potentially unnecessary. I still have to write the display code for the second stage, but I'm going to switch focus first on potentially the most difficult part of this code, which is guidance.

You really can't use Procedural Fairing to build fairings in the same way as the stock game, and I think it always tries to create bulged fairings automatically based on whats inside. You can turn off auto-shape and mess with different dimension parameters, but I don't know if you can get the same amount of shape flexibility as with the stock game's fairing creation tool. On the upside, Procedural Fairings gives you a lot of texture options. It was perfect for making parts of my Saturn VB. I don't think the game cares if a tank is full or empty when simulating fuel distribution in RO. Simply put, no matter how full your tanks are, if you're in a zero-g or negative-g situation, you'll get a less-than-stable propellant situation and your engines won't fire. You'll have to use ullage motors to settle your tank propellants so that you can get fuel to them. Leaving your tanks with less fuel just means less mass to carry around, but in my opinion, if you're going to launch with less mass, you might as well shrink your tank sizes so you're not carrying around more mass that's doing nothing useful. There's no in-game advantage to carrying around more empty space, and likewise there's no advantage in real rocket science to carrying around more empty space. In real life, liquid fuels float around in tanks without some sort of acceleration present, while engines are connected to the tanks through piping that opens at one side of the tank (usually the "bottom", or the end of the tank closest to the rocket). This means that to get fuel to the engines, you have to get the fuel through the pipes. On the ground, gravity provides the means to accelerate the fuel through the pipes to the turbopumps and such. In space, the acceleration has to come from other means. Usually, this is accomplished through using ullage motors, which are motors that give the rocket a gentle nudge forward just enough for liquid propellants to be pushed towards one end of the fuel tanks, preferably the end where the piping is connected. In KSP, you can do this with SRBs, RCS, rotating the craft (inducing centrifugal acceleration), or using engines that don't require propellant settling. It's best to think of any situation where your liquid fuel might lurch forward due to inertia or float around so you know when you need to use ullage. For example, if you're staging during an ascent, your rocket will lose acceleration and stop, but your fuels will keep flying forward into the front of the tanks. This means that you have to think about a way to keep the fuel in your next stage collected at the rear so that when you ignite your engines, you don't end up with a lack of fuel. In real life, rocket engineers either used ullage engines, or they ignited the next stage while the previous stage was still firing, which is known as hot staging. You can do this in KSP as well. In conclusion, when it comes to ullage and propellant settling, remember you're playing Realism Overhaul, so think about what happens to liquid fuel in tanks in reality because RO tries to simulate this behavior as close to reality as possible.