Jump to content

arthur106

Members
  • Posts

    27
  • Joined

  • Last visited

Reputation

23 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. 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"
  6. 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.
  7. 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%)"
  8. 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.
  9. 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.
  10. 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
  11. No worries. I'm wrong more often than right and just don't know it. Won't turn down free advice or info ever.
  12. 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.
  13. 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
  14. 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.
×
×
  • Create New...