• Content Count

  • Joined

  • Last visited

Community Reputation

22 Excellent

About arthur106

  • Rank

Recent Profile Visitors

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

  1. 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.
  2. Thanks for the support. I didn't realize there were other logs than just KSP.txt. Here's the log: 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.
  3. 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.
  4. 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"
  5. 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.
  6. 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%)"
  7. I just installed Kerbal Wind Tunnel 1.2.4 but it keeps crashing everytime I click the wind tunnel icon from the SPH or VAB. I'm running 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.
  8. 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 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.
  9. 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
  10. No worries. I'm wrong more often than right and just don't know it. Won't turn down free advice or info ever.
  11. 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.
  12. 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
  13. 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.
  14. 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.