arthur106

I've been out of the game for about 2 years do to work and other obligations but have recently started up again. Before leaving, I was trying to work out drag mechanics so that I could totally nerd out creating Matlab simulations and KOS scripts with a great deal of precision. I never quite figured anything out, so I thought I'd pick up where I left off. I hope this information is not repetitive. It's been mentioned before that the coefficient of drag (Cd) is a function of a pseudo-Reynolds number (Re=rho*v) and of Mach number (M=v/c). I wasn't sure what exactly to make of this, so I started playing around with Kerbal Wind Tunnel to get more information. I have found so far that the function relating Cd to Re and M [Cd = f(Re,M)] is merely the product of two simpler functions [i.e. f(Re,M) = g(Re)*h(M)]. Basically, there are two "drag multipliers", one based on pseudo-Reynold's Number, and the other based solely on Mach Number; these multipliers are independent of each other. From my reading on the forums thus far, this fact was not obvious; I had feared that the Cd was a more complex function of both Re and M. It is worth mentioning that when I write Cd, I am actually referring to CdA. The equation for drag is Fd = 1/2*rho*v^2*Cd*A. Since A (surface area) is a constant, it sometimes just gets lumped in with Cd. The benefit of knowing this information is that it is much simpler to "flight test" a given craft to find the relationship between Cd, Re, and M. The following graph shows what I mean; the values in green were measured using Kerbal Wind Tunnel while the remaining values were calculated using the relationship explained in the second paragraph. Note, the bold values were also measured using KWT merely to confirm this relationship. Using these values of Cd, I was able to make an excel "program" that can calculate the altitude and velocity of a test rocket up to 70,000m within a few [m] and [m/s] of accuracy. Now this got me thinking..."what if the shape of g(Re) and h(M) were always the same for every craft, and only varied by a constant? Wouldn't that be convenient?!" (i.e. what if for a given Re, the Cd at Mach 2 was always X times larger than the Cd at Mach 1.5?...or if for a given Mach, the Cd at an Re of 400 was always Y times more than at an Re of 200?). The benefit if that were true would be that you'd only have to obtain one single data point to calculated the entire drag profile of a new craft. I created a second test craft to test this theory and obtained a very similar function g(Re); it was hard to tell if it was actually different, or if I was just seeing rounding errors. Unfortunately, h(M) was entirely different. So for now, the only way I can think of to obtain an entire drag profile for a craft is to use KWT to obtain Cd at several dozen data points and use a simple excel program to fill in the blanks. This is unfortunately a timely process. If only I were more computer savvy, I could maybe get into the API and create a simple C program to run these tests for me and obtain a matrix of data as shown in the figure above. Does anyone have anything to add, or does anyone possibly understand the relationship between Cd and Mach or between Cd and Re better than I?

Making Jeb ride on top of the rocket during ascent. There wasn't enough room for everyone, so he rode on the ladder. Actually worked really well until about 30km or so when things started getting toasty. Luckily things worked out and he got all the way to minmus where he deorbited using his jetpack.

Sorry? Don't be! This was very helpful.

Thanks for the support. I didn't realize there were other logs than just KSP.txt. Here's the log: https://drive.google.com/file/d/116oHZOHOH72Pwat4l4tIvOGh2_C-CaUJ/view?usp=sharing One difference I noticed is that I don't have any expansions installed, I'm not seeing this as being listed as a dependency, however.

I sure didn't. That would be a problem. So now I'm going to look really stupid, but how do I install it? I see there's two files and a folder with more files on the GitHub, but I'm not really sure where these go once downloaded.

I didn't have any luck with KML when I had a similar problem with docking ports. Basically, I had ship A and ship B docked together and couldn't undock them. I created a temporary save file with new versions ships A and B on the launch pad. Then I went into the problem save file, deleted the entire code blocks of Ship A and Ship B, then pasted in the A and B code blocks from the temporary save file, changing the ship positions to match their desired locations. It was a headache for sure, but it fixed my problem. Most save files are going to have dozens (or more) of vessels and it will be hard to find your ship. You can make this easier by going into KSP and renaming the problem vessel something unique like "myvessel123456789"

I wanted to have this done earlier, but I've been busy taking care of some danged coyotes for the past week or so.. Anyway, it's not much, just a simple proof of concept at the moment, but I still can't get over how cool it looks! The finished product will be a program that will de-orbit any craft from a parking orbit to a precise location on the surface using only Hohmann transfers and gravity turns. It should work with any body that doesn't have an atmosphere.

Update: I tried installing it again on a clean install of KSP with the only other mod being kOS. This time, it doesn't crash, but it never calculates the flight envelope. It remains fixed on "Calculating...(0,0%)"

I just installed Kerbal Wind Tunnel 1.2.4 https://github.com/DBooots/KerbalWindTunnel/releases but it keeps crashing everytime I click the wind tunnel icon from the SPH or VAB. I'm running 1.9.1.2788 and have kOS and Astronomer's Visual Pack (as well as the required dependencies for it) installed. I'm not really sure what more info I can give y'all. Has anyone else had issues? Edit: I tried 1.2.3 as well to no avail.

Although ive started work on actually creating an ascent profile in matlab, i havent created any tangible results yet (mostly because of my limited understand long of drag ins stock ksp). That will be my next phase of this project. This is simply a proof of concept. The profile was recorded from a previous launch of the same rocket so that I could guaruntee the profile would be viable. Edit: the guidance is just a list of 1.) coordinates at discrete time increments of where the rocket should be and suggested facing vector and throttle position to stay on track. Position error is decomposed into components along "track error" and perpendicular "lateral error" to the facing vector. I correct the error by prescribing a desired acceleration in the proper direction (by increase in throttle for track error and by adding correction angle theta=Accel*mass/thrust to the unit facing vector for lateral error). Assuming all errors are small, the dynamics are linear(ish) and stability SHOULD be achieved for track and lateral error using the same PID controller. I'm still working on this bit here--digging through my old college textbooks trying to understand a subject area I never was too good at... One area of concern is that im currently using kOS built-in "cooked" steering to actually point my rocket in the prescribed direction. This uses two nested PID loops..blah blah blah...to point the rocket where you tell it. It's a jack of all trades but master of none. I'm thinking I could expand my guidance to use raw control inputs as control variables (rather than desired attitude) but this would open up a whole can of worms I'm not sure I'm ready to deal with right now. I'd be interested if anyone has created their own (or knows someone who has) steering controls already and see how they've done it.

I've been working for the past several days on an ascent autopilot. It's not quite done yet, but I'm excited to have some tangible results at this point, as 90% of the work didn't really yield anything tangible, other than some function libraries. It still needs tweaking, I'm confident I can eliminate the position error to less than 1 meter at least 90% of the time; I chose the values for my PID control by shooting from the hip, so unless I got really lucky, there's room for improvement. Anyway, this is my first kOS program so I just wanted to show off. More details are in the video link. If the position initialization isn't exciting enough for you, just skip to 0:50

No worries. I'm wrong more often than right and just don't know it. Won't turn down free advice or info ever.

I haven't found anything yet, but as you say, I would be surprised if someone hasn't already dealt with this. It seems too elementary of a problem for no one to have touched yet. In the meantime, this little "project" is a great way of distracting me from the whole Wuhan Virus situation.. Using the method outlined above, I've managed to make things work out quite nicely and even managed to speed up the maths performed in the kOS CPU by a factor of 5 by streamlining a few of my user-functions. It can crunch through the entire ascent profile (data covering about 6 minutes of flight) in about 40 seconds now. Not great, but it will do. Yes sir!...(or ma'am...) That's the whole reason behind this. I'm trying to take the coordinates from kOS and transform them into a non-rotating coordinate system in MatLab that I can do some math in. Likewise, when I use MatLab to create an ascent profile, I need to convert it to coordinates that correspond to ksp's.

Thanks for the responses. I've been looking into this and here's what I've found: Once set, the orientation of the X and Z axes in relation to Kerbin remains stationary...kind of. The problem is that they can start moving again if you change your focus (go back to KSC or focus on another craft). I tested this by launching a craft and printing its coordinates at several time intervals while on the pad; they didn't move at all. I then went back to KSC for a few minutes and re-launched my craft. When I returned and printed the coordinates again, they were different. I did the same test, but switched focus to a probe orbiting Eve for a while; when i returned focus to my craft on the launchpad, the coordinates had drifted. In this test, I measured the coordinates and mission time both times so I could find the rotation rate. The coordinates were [537282.21 -973.52 267226.53] and then [540072.76 -973.52 261540.82] ~36 seconds later. If you do the math on this, the coordinate system is rotating 360deg/kerbin day. The weird thing is that I moved WEST! This is backwards from my intuition. If the coordinate system were to suddenly "freeze" when I switch focus while the planet continues to rotate around it, the I should be moving East. Keep in mind that KSP has a left-handed coordinate system--it's worth me mentioning this before anyone "reminds" me It's late and I'm tired, so maybe I'm hallucinating, but could someone check me on that? It IS weird, right? I've read somewhere that under certain conditions, the game calculates physics as if your focus planet/moon is stationary and everything around it is moving (i.e. sun orbits around earth). I'm not sure at the moment how to test this.. My temporary (or maybe permanent) solution: When my ship boots up, I load a position initialization program. One of the KOS functions lets you draw a vector from your present position to any point on the planet's surface based on latitude and longitude. You can also find the vector from your present position to the planet's center. All of these are in terms of the "arbitrary" coordinate system In this "arbitrary" coordinate system, I calculate vectors representing "Standard" X Y Z axes by performing vector subtraction (X axis = Vector to LatLon(0,-90) - Vector to center of planet). Once I normalize each of these vectors, I have unit vectors representing "standard" XYZ in terms of "arbitrary" coordinates and I can then calculate a rotation matrix to go from "arbitrary" to "standard". I proceed to fly my mission normally, using and logging the "arbitrary" coordinates. My telemetry log is set up to paste directly into MatLab where the rotation matrix is used to convert everything into the "standard" coordinates. If I'm creating a flight plan in matlab to be loaded onto my ship, the math is done in terms of "standard" coordinates, loaded onto the ship, and then converted to the current "arbitrary" coordinates using the inverse of the aforementioned rotation matrix. Unfortunately, using the KOS CPU for vector algebra is very very slow; I can't find a way around this, however, as I don't know the inverse rotation matrix until I've loaded my ship on the launch pad and performed the position initialization. I'll be posting my code on another thread in the near future to ask for some suggestions to make it run quicker. Just thought I'd give ya'll a heads up

perfect, thats what I was looking for Neither am I; I grew up with it and spoke quite fluently years ago and am slowly regaining what I've lost. I'm just surprised by the evident lack of German speakers here. I recall seeing a fair number of [Ger] posts over there.

I've been playing around with kos and have started running into some issues with the coordinate system, specifically the locations of the x and z axes. I would like to be able to determine my ship's position in a coordinate system that is centered about kerbin's CoM and use this vector along with other inputs to more precisely control my craft on its ascent. My current program works OK but vastly simplifies things; working with vectors would greatly expand my capabilities. The problem is that I can't find any rhyme or reason to the orientation of the x and z axes. When I first logged in, i plotted my position with "print -kerbin:position" and got an interesting result. I had expected that one of the axes would pass through the prime meridian. What I found is that the x axis passed through 0N 10.791321E. Odd as this is, it would be doable so long as it remains fixed exactly there. When I logged back in later, I realized I was getting funny results. Turns out the x axis was located at 0N ~20E. What I've found is every time I start a new flight, the x and z axes move to a new, random location. I haven't done enough testing to see if they move during a flight, but they certainly do every time I start a new one. I've read the documentation on kos and even it says "However, it’s hard to predict exactly where the X and Z axes will be. They keep moving depending on where you are, to the point where it’s impossible to get a fix on just which direction they’ll point." Can anyone shed some light on this? Worst case scenario, I can get clever and come up with a work-around to find my coordinates, but I'd rather not fool with unnecessary vector addition/rotations just to simply get my position.

It was a VERY expensive trip, 3 separate launches, and I may have "cheated" by using alt F12 to set my lander on the surface during the design process. But I did complete the whole trip from start to finish without cheating...except when i edited the save file to place jeb back in the ascent vehicle; somehow one of the ladders got deleted when I was making iterations to my design in the VAB. But I didn't want to go all the way back, so can I really be blamed? :p

Hey everyone, this is a bit of a late introduction, as I started playing about a month ago. Anyway, I´m switching over from the dark side, having played Orbiter on and off for many years. Since starting, I've managed to get set up surface and orbital stations/fuel depots around minmus and mun and I've sent Jeb to Eve's surface and back (that was a PITA). I've got comm relays set up on every planet and moon all the way from Moho to Duna. I'll be going there next. I'm also slowly tinkering with KOS. I downloaded it two days ago and have a working launch script that follows a pre-computed or recorded launch profile (I'll be using MATLAB to optimize the ascent once i do a little bit more research on how to predict drag). Is there anywhere in this forum (or elsewhere) where I can post bits of my code and get advice? Just a small bit of background on myself. I have a bachelor's in Mechanical Engineering and am an airline pilot by profession. Somehow, these two qualifications don't stop me from killing poor Jeb on a regular basis! Ich hätte gedacht, es gab mehre Deutsche hier. Es gibt viele schon beim Orbiter Forum. Wo versteckt ihr euch alle?

Does the game use velocity relative to the velocity of the surface directly below you, or the velocity of the surface projected to your current altitude? I realize that's a bit confusing, but I thought about it for a few minutes and that's the best explanation I could come up with... For example: at the equator, the surface velocity on kerbin is ~175m/s. If we go up 50km, however, the velocity would be ~190 due to the larger radius. Forgive me if I missed it in you explanation, but are f_mach and f_reynolds independent of individual parts? or are there separate f_mach and f_reynolds functions for each part?

I've been combing through the forums trying to find out exactly how KSP calculates drag and have come across some helpful posts. It seems that the method has changed substantially with new versions of the game, so I'd like to summarize my understand of the current system (please correct me where I'm wrong) and ask a few questions as well. Because I'm stating a lot of my assumptions (which may or may not be true) and asking questions, I'll place the questions in bold font for readability. I understand the basic formula is the 1/2*rho*v^2*Cd*S where rho is atmospheric density, Cd is coefficient of drag, and S is exposed surface area. I also understand that the game has some some mechanic to determine Cd based on drag cubes and the part construction. Furthermore, there is a Cd multiplier for leading faces, side faces, and trailing faces; this multiplier is dependent on mach number (is it dependent on anything else?). I saw some plots of this a few days ago, but at the time of writing this, I can't find it. Can anyone point me to the game file where this information is stored? The whole "drag cube" concept seems somewhat odd to me. How do you model the side faces of a cylindrical part with a cube? Imagine you have a perfectly cylindrical fuel tank flying through the air and it is travelling in a direction parallel to it's axis of symmetry. Now, lets examine two cases in which its attitude is perturbed by a small number of degrees "theta"; first in a direction towards the center of one of the side drag cube faces (such that one side face is exposed), then in a direction towards one of the corners (such that two sides faces are exposed). The actual fuel tank would care which direction it had been perturbed, as it is axially symmetric. The drag cubes, however, are not. The latter case would result in more exposed surface area than the former. Is this how the actual calculations work? Going back to the mach-based multipliers for the Cd. Does anyone know how the values given in the game file are interpolated? (linearly, quadratically..) How are these multipliers applied? If I'm in a rocket, ascending straight upwards, it's obvious that the leading multiplier is applied to the leading face, side multiplier to the side faces, and so on. But what if I have a non-zero AoA? Now there are two components of velocity, "mainstream", and sidestream, causing "drag", and "sideforce", respectively. Does the game do multiple drag calculations (treating the side of the rocket as a side face when resolving drag and as a leading face when resolving side force?) I read somewhere that they swapped surface area with mass??? That doesn't seem very intuitive. Does this still exist? Any light that can be shed on this would be extremely helpful and much appreciated. Thank you in advance. My goal is to understand the methods the good people at Squad used so I can use this information to write accurate scripts for KOS. The first one would launch a rocket and perform a series of simple maneuvers, varying altitude, airspeed, and attitude to either A. determine an "equivalent drag cube" for any given spacecraft or B. use a simple neural net to accurately predict drag based on inputs (pitch, yaw, roll, speed, temp, pressure). I'll then use the ability to very accurately predict drag to create ascent profiles and then scripts to follow them.

Woah, I was totally unaware of KOS's existence. This looks amazing! My dreams came true!! lol

So many posts here, not sure if anyone has posted this. I'm really hoping you can write programs that can be stored in probe cores. The programs will be carried out regardless of whether you're flying it, another vessel, or at the space center. They could do things as simple as extending a Comm Antenna once the probe measures a certain level of atmospheric pressure and weight-on-wheels (this would have saved my Eve rover from going AWOL on me) or as complex as guiding a rocket booster to autonomously land itself back on the launch pad (if your programming skills and PC can handles this). With KSP's simplified physics, I don't think it would be too far fetched to send rovers to the Mun or Duna and have the whole process be automated. In any case, this would be a really nice way of continuing a mission even in areas of spotty CommNet coverage. Also, it would be nice to have certain unmanned flights happen in the background (without the need for crazy levels of programming skills). For example, I've done the flight with my fuel tanker from my Minmus base to my fuel depot at least a dozen times. I'm sick and tired of it. It would be nice to set up flights like this to happen on a regular interval and happen in the background. You could have a "flight-builder" wizard or something similar, where you specify launch conditions and maneuvers to be performed, and so long as the spacecraft meets or exceeds the estimated requirements for the mission, it happens automatically. P.S. to be clear, the first hope (aka suggestion) would not necessarily have be very complicated, in whatever programming language implemented, the inputs would be things that already exist in the game's code (ship's state vector, mass, pressure, temp, wheel speed/position, etc) and the output would simply be an attitude for the ship to steer, a throttle setting, or an action to be performed. The complexity would be entirely up to the user. I realize this would potentially not allow for crazy amounts of time warp, but there are ways around this. For instance, programs could be required to be written in stages, where each stage has a specified "clock speed" (for lack of a better word". An unmanned probe during a reentry or launch phase might be running a program that checks the ship's state every 1/10th of a second whereas it might only need to every 1000 seconds in deep space. For former would not lend itself to time warping whereas the latter would. What I'm asking for here is already possible for someone who know's how to dig through the game's code and make a program that can interact with KSP--all i'm suggesting is that the game makes it more readily accessible. To better describe the second idea, think of it as running "on rails" much the way unattended vessels already do. Just adding a bit more complexity to it.

I like that idea and I was thinking of using some sort of initial condition to work backwards from (i.e. Height above ground, pitch, heading, surface velocity, mass, etc...) This won't suffice entirely, as the mass at this point will be unknown. I could definitely approximate it, however, and run an iterative process to get everything working quite well. I'm thinking the most efficient way would be to integrate backwards from this initial condition, varying the initial pitch until a full throttle gravity turn results in a circularized orbit at some altitude, and then Hohmann Transfer up to whatever the original parking orbit is? This method obviously wouldn't be great for vehicles with a high TWR landing in areas surrounded by mountainous terrain, but this could be overcome by tweaking some parameters specific to the landing location..

Ooooh, I like this idea. So you mean there's an actual equation that the developers used? Or an equation approximation, like using spherical harmonics or something similar? Either way, this seems like the way to go.

I cheated. I sent a rocket to Duna with relay sats and M700 resource scanners. I've set up resource scanners and triangular constellations of comm sats in synchronous orbits around Kerbin, Mun, Minmus*, Eve, and Gilly already, so I really didn't feel like doing it again. It can be tedious, monotonous work. So I used alt+F12 to set the orbits to their proper positions. I landed a rover on Eve and when it landed it was out of comm range (the 500k antenna wasn't extended). So, I temporarily disabled CommNet, extended the antenna, re-enabled CommNet, and pretended nothing happened. I didn't feel bad about this, as it would be so easy in real life to have the probe core automatically do this whenever atm pressure and weight-on-wheels sensors indicate certain conditions for long enough.