KSP- Space Shuttle Autoland with kOS
Вставка
- Опубліковано 15 вер 2024
- I showcase my progress on automatic landing of the Space Shuttle using real-life guidance algorithms
System : i5 13600k@ 5.1 GHz , 64 Gb RAM, RTX3090Ti
KSP version 1.12.3
Modlist (non-exhaustive) :
-Real Solar system + dependencies
-EVE Raymarched Volumetrics (Early access)
-ballisticfox's RSS Reborn
-Realism Overhaul + dependencies
-Kerbal Operating system
-Principia
-Kerbal Konstructs
-KerbinSide props
-OSS statics
-Tundra space center
-Katniss Cape Canaveral
-My own fork of Ferram Aerospace (github.com/giu...)
-My own fork of Space Shuttle System (github.com/giu...)
-my new kOS Shuttle OPS3 script, still work in progress (github.com/giu...)
![Space Shuttle Columbia Disaster Video [With Real Video] | Mayday: Air Disaster (4K)](/img/n.gif)
Wow! Impressive! I look forward to seeing the combined entry and landing script in action! A while back I was working on a similar entry and autoland script, but it got put on the back burner. I'm never able to focus long enough to finish these big kOS projects lol
I remember it!!
This is really quite impressive. I've thought about something like this for years but never even knew where to start
Congrats! I'm waiting for your Buran Energia version
amazing work!!!
This is really pretty cool. My knowledge of controls is also somewhat limited, but from what I know, if your output is experiencing oscillations, you need dampening somewhere.
well, I did know that much, there is plenty of damping already.
Damping helps with oscillations in the response , but the problem is that oscillations in the response also cause oscillations in the target in this case, that's wat coupling means.
The target vertical speed (hdot) is the tangent of the desired path angle times groundspeed, plus an altitude error correction term.
Pitching up or down to compensate for hdot erorrs cause drag to change, which perturbs the true airspeed which, in turn, affects groundspeed and target hdot.
thats incredible!
Good job
for the variable coupling issue, maybe it makes more sense to use the airbrake to set the airspeed/energy, then use pitch to control for the glide angle instead of hdot error and h error, much like what the pilot already does in CSS mode
from what i understand the advantage here over your current scheme is that glideslope is much more resistant to perturbations in pitch, which should help avoid most of the hunting you're experjencing
Thanks for the suggestion! but I have some comments to make :
- the airbrake already controls airspeed, it controls qbar actually, with active control below mach 1.5
- controlling airspeed does not equate controlling energy because at this stage of flight most of the energy is potential given by altitude, deliberately so because of the poor L/D
- the glideslope is generally referred to as flight-path-angle (fpa) in literature
- controlling just fpa alone is not enough because fpa is only valid if you are exactly on glidepath, if you have an altitude error you need to alter fpa to get back on it first
- geometrically, tan(fpa) = airspeed/groundspeed, for this fact the control scheme you suggest should be mappable to mine through the controller gains
- I'm not sure what makes you claim that fpa is more resistant to perturbations in angle-of-attack but I don't see that, after all the L/D curve is roughly proportional, which is true for the Shuttle at subsonic speed and AoA 15 or less, and changing lift certainly affects both vertical speed and fpa
- I'm familiar with the aviation technique of controlling rate of descent with throttle and airspeed with pitch but I'm not sure that can be applied here, certainly not for a prrogram that's supposed to handle a low-energy case as well when the airbrakes are fully retracted
- advances I made since this video have already made it smoother already, I only have issues when the Shuttle is empty and more susceptible to aerodynamics because of the lessened inertia
@giuliodondi thank you for the detailed reply! I'm going to skip to your 3rd last point since I don't have much to add for the points prior; my thinking was that (and I apologise for not explaining this) you can use your actual position in space to define the fpa you'd need to make your landing location, and then via a cascade of controls (aoa > current fpa > desired fpa) you'd control for the ideal descent profile. I think my thinking was that since this is dependent on your relative position to the landing point, it starts off very relaxed at long ranges and automatically tightens up as you approach the runway.
Certainly I was only thinking about on-energy states where closing the airbrake can bail you out, in a low-airspeed case the pronlem is much harder and I don't have a good answer >
Der knall feld
Oof! That was a hard landing. 😹
Amazing work as always! I'm a first-year computer engineering student and I would love to eventually write my own guidance software for KSP/RSS/KOS from scratch. I plan on basing them off of the algorithms NASA used for Apollo and/or the Space Shuttle (for educational and realism purposes) but I honestly don't know where to start. I've tried reading through some of original NASA papers on PEG and UPFG but (perhaps unsurprisingly) I wasn't able to understand most of it. So far I haven't been able to find many resources online other than a few UA-cam videos such as yours - maybe I'm just not using the right keywords here... Any suggestions? Also, how much Math/Physics/CS should I know before trying to tackle these papers? Love your videos, thanks!
I've been working on a version of LTS adapted for spherical earth, I could give you a rundown on what I know, if you want. It's not UPFG, but I think I understand that, if you also want. I know this isn't what you were expecting, but I figured I could try and help. As for the math you need to know, if you want to understand the derivations, I think you need multiple calculus courses, maybe a diff equations course. But for the equations themselves you don't need that as long as you know what they do (I'm an HS senior taking Calc right now).
@@jmstudios457 Sure thing, that would be very helpful actually! I don't think I've heard of LTS before though, but I'm interested. Thanks in advance :)
@@LuccasLab I do confirm that, if you want to understand every single equation from a GN&C paper, you need several calculus courses, solutions to differential equations under constraints and the like. I can also tell you that you can generally get by only understanding the general gist of some calculation and what the variables represent, and take some of the maths for granted.
I'm a physics graduate but I left the field several years ago, and honestly I don't always want to spend time re-deriving everything before I start coding, which is what I'm really interested in.
Also beware that GN&C papers are not laid out as lecture notes, they're written by specialists to be read by other specialists, so the conventions and formalism can vary a lot (also depending on the era) and there is quite a lot taken for granted.
Something else that was really useful to me are all the courses I took on computational physics, which teach you how to move from equations on paper to lines of code, some numerical algorithms and tools to evaluate how the code performs. Those came in very handy in my kOS endeavours.
LTS(Linear Tangent Steering) is a concept for a pitch program, where the pitch varies linearly with time, given the equation tan(y) = a + bt where y is the pitch angle. It's been used in a lot of launch guidance algorithms especially at high altitudes because you can pretend air doesn't exist and still get good results. The hard part comes here: calculating the steering coefficients a and b. for a single stage it isn't terrible, but for multiple stages it can get tricky. The second thing is LTS was derived assuming a flat earth with a uniform gravity field (g = constant). Once you're going high and fast enough, this assumption is invalid. So you have to solve the issue of how much gravity will change your position and velocity with time, and the force of gravity depends on your position and velocity. It's a bit of a nightmare, but when it comes together it's really neat to see how it's done.
@@giuliodondi Thank you so much for your insights! Welp guess there's a lot of math i'll still need to learn... nothing a quality book or two can't fix, fortunately. I'll be sure to take a look at some computational physics principles too, that sounds very interesting. Cheers!
Hey that looks great! I never realized how steep it has to glide to come in.
Is this stock aerodynamics or is this FAR?
This is full RSS - Realism Overhaul,so of course it's FAR.
Precisely, it's a personal fork of FAR that I made to build a custom aerodynamic model just for the Space Shuttle, built from real-world technical data
Sup bro, can you make your mod for the stock KSP map and for the stock shuttle?
No, I'm not interested in stock KSP
How did you get past the speedbrake issues with the shuttle model?
First, I re-baked the rudder part in Blender so that the rudder panels were two separate transforms.
I then configured the part to use two stock ControlSurface modules, one for each transform, exactly like SOCK does. I tweaked the drag to suit my realistic Shuttle aero model, which is considerably draggier in the low Mach regime compared to SOCK like the real thing.
The juicy part however is the kOS controller, which deploys the body flap in concert with the speedbrakes to null the pitch moment. The controller is actually a unified flap-speedbrake controller so that I can mix the two inputs on the body flap
@@giuliodondi Outstanding work!
I wonder, can it be used for Buran?
Considering the fact, that Shuttle and Buran are pretty similar in many things, but their aerodynamics are a bit different
In principle, maybe.
In practice, no because this script is tuned to the custom Space Shuttle aero model which, in turn, is calibrated to the real-life Cl and Cd data tables that can be foundonline.
I looked and could not find any such tables for Buran, sadly.
@@giuliodondi sad, honestly
can I get your modlist pls ?
I updated the description, beware the script is not fit for use yet
Amazing work!