Razgriz1

Yes, this still works with the current version of kOS.

Aaaaaand just when I think that I've started to make some progress with reentry guidance, someone else comes along and WAY outdoes me...

I am not really aware of any autopilot mods that are particularly well suited to landing spaceplanes without some sort of engine to maintain speed in the atmosphere. Your best bet is probably a custom made autopilot using kOS. That is my current pet project, but I am focusing more on the entry guidance portion of it than the landing right now.

It's not that hard to either create your own config file from the Restock config that matches the weight of Benjee's, or to edit the config file that copies the stock vector to copy the restock one instead. I had done that in the past, but I don't have access to the computer with those files on it right now or I would post an example.

Looks like you've got Waterfall Plumes on the SSMEs, which is the only engine included in that config. The SRB's do not have Waterfall configs, and there really aren't any plans to create SRB plumes per Nertea from the Waterfall team.

If you have Restock, you'd also have to take out the &!ReStock part of the SSME patch I posted as well, otherwise it won't use that patch. Strictly speaking, that isn't really necessary anyway since Benjee's SSME copies the stock vector, not the Restock Vector, so I should probably remove that anyway.

Module manager patches can go anywhere in GameData. I personally keep all of my own patches in my own folder in there to keep track of them. You probably will need Stock Waterfall Effects though, as I believe it uses the templates included in that as a basis for these.

I found that @Knight of St John's Stock Waterfall Effects Vector and Puff OMS effects worked quite well for Benjee's shuttle engines. I made my own config for them based on these, by essentially just tweaking the plume scales and offsets.

You first need to load them into memory. Since my files only contain functions (and the lazyglobal modifier) just run the scripts as you would any other script. That's what the first two lines of the example are doing. Once you do that, you should be able to run the functions from the terminal (I think you can do that in kOS anyway). Alternatively, that example script in the readme should be a complete script that will calculate and perform the reentry burn and entry guidance, as long as you replace the <coordinates of KSC> bit with the actual coordinates of the landing site you want to target. I should probably reword that, as it can really target any arbitrary geocoordinates, not just KSC. You may also need to change the path of the files depending on where you place them on your local machine. In the future, if you have more questions like this, you should probably message me, or create an issue on GitHub so that we don't bog down this thread with only tangentially related content.

So the "nominal" entry I based the guidance on was a 5 ton downmass from a 350km orbit, but I tested several different altitude and downmass combinations. Really the whole point of this is to make it so it doesn't really matter what the downmass is. In theory, a higher downmass/higher energy reentry should cause it to have a higher roll angle. It's more sensitive to the downrange position of the entry interface point than anything else, which is kind of the next thing I'm looking at solving. My script does use the stock fuel valves to drain the remaining OMS fuel prior to reentry, but it shouldn't make that much of a difference, and I have not noticed too much difference in controllability keeping the fuel in the shuttle. I did that primarily for realism purposes.

@DJ Reonic (and anyone else who may be interested!) So I think I actually have the entry guidance scripts in a somewhat usable state right now. The deorbit node creation function should be usable pretty in pretty much any situation you'd want to use it, targeting any ground coordinates at any inclination, as long as those ground coordinate will reasonable pass under the orbit ground track. Right now the burn anomaly and the target periapsis are hard-coded to what seemed to work well, but I'm looking into the math to figure out how to target a specific entry interface downrange distance and flightpath angle instead, which should help generalize it to planet size and initial orbit somewhat. If anyone has any knowledge about that, suggestions are welcome! Entry guidance is definitely dicier and much more WIP, but I've tested a few configurations and it seems to preform reasonably well. The current entry guidance function is designed to work with FAR and JNSQ Kerbin, though there is some commented out code in there from testing with stock aerodynamics on JNSQ Kerbin that should still work. Essentially it uses a target altitude vs downrange distance curve that I worked out by flying some nominal flights and then spline fitting in Matlab. I'd like to eventually switch to using something like a target total energy state or a target drag value, but this was the easiest to get working first and seemed to give decently consistent results. It's nowhere near as smooth as I'd like it to be, but I feel like it's in a state now that can be shared with other people. With that in mind, I've set up a GitHub repository: https://github.com/Jakathan/shuttle-guidance I have some grandiose plans of trying to build out a pretty solid general purpose guidance computer for the shuttle, but apparently I decided to start with one of the hardest parts... Oh well. Please feel free to give it a try and see how well it works for you the README should give you a pretty good idea of what's in the code and how to use it. I'm new to git, so I think I set everything up right but I'm not entirely sure. Yell at me if it's not working for you and I'll see what I can do! Eventually I'm also gonna post this over on the kOS subreddit and let them tear it apart, but I still want to iron a few things out first.

Music to my earholes!

KSP drag is not the easiest thing to wrap your mind around either. I might be able to get Close Enough™ by just getting a "nominal" altitude/downrange relationship and using roll angle to follow that. That's the next thing I'm going to try. As long as it's close, the Approach & Landing phase should be able to handle quite a bit of error. Once I've got something good working decently, I definitely plan on sharing it here. I've put too much time into this now to not

I think you're probably referring to Relatively Adequate Mission Planner and yeah I started out by attempting to adapt that into what I wanted, but it turned out to make too many assumptions and simplifications. I'm still using the Approach and Landing script from that script pack for final approach and landing but once I sort out reentry a little better, I plan on writing my own version of that too. Right now, I have the capability to target deorbit burns from an inclined orbit, and perform roll reversals during reentry when crossrange gets too high. I'm currently trying to work out a good way of using roll angle to control downrange instead of alpha modulation, as that's how the real shuttle did it, but that's proving to be a very complicated task lol. Unfortunately the Trajectories mod does not seem to account for roll angle in its calculations, so it assumes the lift vector is vertical. When trying to use roll, even just to correct crossrange error, the Trajectories prediction is off. I may just switch to only using roll to correct crossrange and then using alpha modulation with trajectories to control downrange but I want to avoid that if I possibly can. I have lots of data logs from a lot of flights that I have pulled into Matlab at this point lol.

Edit: Good job me clicking submit instead of add image... Here are the plumes I was talking about, now that I have a chance to actually fire up the game again.

IRL most docking mechanisms are only compatible with one other type of docking port Often times there's even the added constraint of active vs. passive ports.

Am I correct in thinking that Trajectories assumes a roll angle of zero degrees when calculating the trajectory as opposed to whatever roll the vehicle is currently at?

Use translational RCS to make small velocity changes, just like you would when you are getting close to docking. Edit: also, unless you're actually getting to the point where you're actually physically docking, or you're attempting to station-keep like some of the Gemini missions did, you don't really need to COMPLETELY zero out your velocity. You just need to get it close enough so that you can plan your next step.

For those of you who use Kerbal Operating System, I wrote a function that calculates the angle offset between the ship's center of thrust vector and it's forward facing vector, and then uses that to adjust a steering direction you input so that the thrust vector points through the center of mass in the same direction as your input direction. It should even be able to handle OMS engine out scenarios, though I have not really tested that yet. //lib_shuttle_mnv.ks @lazyGlobal off. function shuttleSteerDir { //Returns a direction that aligns the thrust vector through the center of mass toward the input direction parameter steerDir. local thrustAng is round(vang(ship:facing:forevector,centerOfThrust()),2). local rotationAxis is vcrs(ship:facing,centerOfThrust). local newDir is angleAxis(thrustAng,rotationAxis)*steerDir. return newDir. } function centerOfThrust { //Calculates the center of thrust for currently active engines. Returns a vector in ship-raw coordinates local eList is list(). local avgPos is V(0,0,0). local maxT is 0. list engines in eList. for eng in eList { set avgPos to avgPos + -eng:POSITION * eng:MAXTHRUST. set maxT to maxT + eng:MAXTHRUST. } SET avgPos to avgPos / maxT. return avgPos. } This is part of an attempt to completely fly a mission with the shuttle autonomously and return. Reentry is proving to be somewhat challenging though

What are you seeing that's not working with FAR and the Stock Shuttle Orbiter Kit? I'm currently playing with both. I had to bump up the heat tolerance of some of the internal parts a bit but other than that it seems to work fine.

Fortunately for the RS-25, the stock vector has a wonderful plume found in Stock Waterfall Effects, and since this one just uses that same model, it's pretty easy to copy the config and edit it to apply to this one instead. The config for the O-10 "Puff" works decently for the AJ-10 as well, though that one requires a bit of scaling to work correctly. I'm glad benjee added the RCS waterfall configs, it makes the whole thing look so much better when maneuvering. I was planning on making some myself but he beat me to it

I exclusively use the Furlong-Firkin-Fortnight System.

Just a heads up, I believe there are some issues running the source code on newer versions of MATLAB. Mathworks are not particularly good at maintaining backwards compatibility. I tried running it on one of the 2019 versions (iirc) a while ago and ran into errors that I didn't feel like taking the time to debug. Pretty sure that was about when they switched to the new App designer, and that messed up the default arguments of some of the functions dealing with creating UIs.

Kinda the opposite of the SSME controllers, huh

I've done a bit of digging through your source code, and I found the startParallelPool function where you're having the program start a parallel pool. Running just the code in that function (minus the writeOutput commands) seems to properly start a parallel pool with no exceptions thrown. My next guess is that there's something up with the permissions on my end or something like that. Will do more investigating.