Reddy

PEGAS - Powered Explicit Guidance Ascent System - devlog

Recommended Posts

I am proud to present PEGAS: Powered Explicit Guidance Ascent System - a kOS script for automated launches using a real-world guidance algorithm taken straight from the Space Shuttle documentation: the Unified Powered Flight Guidance!

What is PEGAS and what is it capable of?
PEGAS is a launch autopilot made in kOS. Its aim is, given a vehicle description and a mission target, to execute the entire ascent to a orbit. It supports defining orbits by periapse, apoapse, inclination and longitude of ascending node - allowing you to ascend to any (reachable) orbit in any given orbital plane. You can even select a target in the map and launch to the exact plane of this object.

Short list of what PEGAS can do, in the approximate order of when it will be doing it:

  • automatic launch window and azimuth calculation,
  • easy-to-use atmospheric ascent in 3 steps: vertical ascent for a given time, pitch-over by a given angle, hold prograde,
  • event system, allowing you to schedule things like fairings jettison, throttle management, roll maneuvers,
  • flexible automatic staging, allowing for even complex staging sequences requiring separation of a spent stage, ignition of ullage motors (SRB or RCS), ignition of the main engine,
  • precise orbital guidance, able to target any elliptic orbit in any plane (provided the vehicle can physically reach it), including launching to a plane of an existing object,
  • inter-CPU communication (credit to Patrykz94) system made with reusable boosters in mind (also see his Falcon-style landing script).

For a general showcase, see my most recent video, where PEGAS controls an Atlas V ascent to a parking orbit for a rendezvous with an International Space Station:

PEGAS is approximately 2000 lines of code long.

How do I get it, run it, read more about it?
You can get the code from my GitHub (current release: v1.1).

You are strongly encouraged to read the tutorial and reference! PEGAS is not a straightforward "click this to fly" kind of tool and needs to be set up for your vehicle and mission.

If you're interested in the mathematical details of the algorithm itself - check my prototype repository, especially its documentation.
If you've spotted a bug or have a feature request - feel free to post either in this thread, or better yet on my GitHub issue tracker (read this, please).

What is this thread?
This thread carries a history of my development, from the first version of PEGAS that used a very basic formulation of Powered Explicit Guidance, through all my effort to implement the Space Shuttle guidance, to the release of a complete guidance script.

History of progress:

  • Summer 2015 - work on a MATLAB prototype using a basic form of Powered Explicit Guidance (read about the algorithm here).
  • Late 2015 - MATLAB code ported to kOS.
  • February 2016 - release of the first version of PEGAS (watch my video here, but bear in mind that this has very little in common with the current state of the project).
  • Summer 2016 - I'm back at work on PEGAS, researching the Space Shuttle documentation.
  • August 2016 -  working MATLAB prototype of the Unified Powered Flight Guidance taken right from the Space Shuttle GN&C documentation - its Ascent Mode allows targeting orbits in a given orbital plane. Read more here.
  • October 2016 - implementation of UPFG for multiple stages.
  • November 2016 - verification of PEGAS' capabilities with several launch vehicles, sites, and targets, proving its great accuracy (plane error below one hundredth of a degree means correction maneuver of about 1m/s).
  • February 2017 - the MATLAB prototype is complete, work on the kOS port begins.
  • March 2017 - numerical consistency proven between MATLAB and kOS implementations of the key UPFG algorithm.
  • May 2017 - basic version of PEGAS flies a simple rocket in KSP.
  • July 2017 - first release of PEGAS!
  • November 2017 - PEGAS version 1.1 is out!

I will be updating this post with all new developments. Thanks :)

Edited by Reddy
version 1.1 release

Share this post


Link to post
Share on other sites

Awesome! I'm doing something like this in KRPC. I've actually been using some of your code to help me a little bit. I'm trying to create a kind of universal mechjeb for realism overhaul and up-scaled kerbin, using this and maybe the variant of iterative guidance mode used in the apollo missions for landings. Good luck on this in the future! Hope your exam goes well!

Share this post


Link to post
Share on other sites

If you manage to get the code into a usable state for inclination targeting, I'm planning on using it to help with my OSIRIS-REx recreation mission. Good luck, we're all rooting for you.

Share this post


Link to post
Share on other sites

Just sign up for this thread, it's me from reddit :)

Happy to see your thread, well i have one request for your TODO LIST, PEG doesn't work with a very powerfull 1 stage, the stage that do the passive guide thing. If the cut-off orbital speed of the second stage are more than half of the required speed to get to the orbit, as soon as the PEG kick in, the rocket pitches to 90 degrees and the Burnout time going crazy. I hope you can find the workaround for this, i try but i fail.

I'm still a third grader in senior high school, so most of the equation are beyond me. So i need your help :)

EDIT : Maybe this one will help you

Edited by Ilpez
Found some files on x-plane forum

Share this post


Link to post
Share on other sites

UPDATE

I decided to change my approach to this project and went the harder but more promising way. PEG as described in the original paper is inherently limited in its off-plane maneuvering capabilities (no explicit inclination/LAN control, only ensuring the target orbit plane contains some given vector), but the version of it as used in the Space Shuttle is much more agile, allowing for more constrained target orbits. For the past few weeks I was digging in the Shuttle documentation, particularly Guidance, Navigation and Control series. Equation Document 24 by T.J. Brand, D.W. Brown and J.P. Higgins titled Unified Powered Flight Guidance contains a full description as well as a block diagram of an almost complete algorithm (only missing bits are very hardware related, like TVC commands, nothing we have to worry about). The authors state it is capable of (among other things like deorbits and on-orbit maneuvers) guiding a multi-stage vehicle onto orbits defined by insertion altitude, velocity, flight path angle and orbital plane - in other words, target orbits could be defined by apoapsis+periapsis and inclination + longitude of ascending node.

Poorly scanned documents from the 70's are not the most easy to use source of information, but I think I finally cracked it today! For now it's just a bare bones kind of solution in form of a MATLAB prototype, with all fancy parts removed (like multistage support) and tested in simplest conditions (equatorial launch with no out-of-plane velocity), but in principle it almost works :)

J8x3SMq.png

Black curve is Earth surface, red curve is guided trajectory. It looks reasonable and the numbers prove it: cutoff altitude was 251.6km (vs target of 250) but the velocity vector, although of proper magnitude, was not pointed exactly in the right direction (yielding apsis of 421x91km instead of a circular orbit). However, I believe that this is only a matter of minor tweaks, and I'll soon be able to test the algorithm on more complex targets (my goal is INC+LAN constraints), and then move to developing a solution for multistage vehicles! :D

@Ilpez Are you referring to PEG, or PEGAS? For now my script does not fully support first stage guidance: that is, functions are there but you have to somehow come up with your own ascent profile (pitch vs time table). You can't use the numbers I attached with any first stage, especially not those very powerful ones.

I'll let myself call the rest of you guys, @Dman979 and @AHO, I'm not sure if the forum notifies users about updates.

BTW, can anyone enlighten me about the current state of KSP and RO? I wasn't playing at all for like 6 months now, only heard some rumors that worried me...

Share this post


Link to post
Share on other sites

@Reddy Even more targeting controls? That's great!

 

Last I heard, KSP and RO were working quite well together. In fact, someone said it's the best it's been in a while.

But I'll ping @NathanKell and ask him.

Oh, and I wonder if @IonStorm could help, considering that he works for NASA? Maybe he'd be able to get you some documents that you'd need.

Share this post


Link to post
Share on other sites

@Reddy Well i was referring to PEGAS, but it looks like your new algorithm will be better than ever (yaiks ), just forget about my problem.

 

I hope this document will help you(there is a lot of flow chart in there)Shutte Guidance

Edited by Ilpez
Help

Share this post


Link to post
Share on other sites

UPDATE

Nothing is ever perfect, but we only need things to be good enough - I'm bringing you Unified Powered Flight Guidance! :)

This took longer than it should, eventually all bugs were only caused by my own dumbness and overlooks, but the algorithm is now working. By algorithm I mean the single-stage version of a MATLAB prototype, and by working I mean it does guide my "missile" into an orbit constrained by apoapsis, periapsis, inclination and longitude of ascending node - I launched from Kennedy Space Center and targeted a parking orbit in the International Space Station's plane. Below you can see a trajectory graph (thanks Will Campbell for that sweet Earth-looking sphere function) of the ascending rocket: red is powered phase, yellow is groundtrack, magenta is a target orbit groundtrack; cyan lines make a vehicle's frame of reference (navball-like).

JcJtRbe.png

Some numbers:

  apoapsis [km ASL] periapsis [km ASL] inclination [deg] LAN [deg]
target 200.00 200.00 51.65 256.88
reached 239.11 167.86 51.83 257.68

While this orbit is far from circular (over 0.005 eccentricity), plane targeting turned out pretty good. As usual though, there's some caveat: results are quite sensitive to the time of launch - that is: considering the rotation of the Earth, just where exactly is the launch site with respect to the target orbit. One degree makes a huge difference in the plane you end up on. This is understandable, since plane changes are among the most delta-v-expensive maneuvers, and with LAN it's much more difficult: not only the velocity vector is being aligned, but position as well. Just take a look at those plots, particularly the top-left one (pitch is blue, yellow is yaw):

9Hx3knR.png

Over 30 degrees yaw the whole time and it gets to almost 55. The way I see it, the average amount of yaw mostly depends on desired inclination (and launch site latitude) and one can't change it much, but the rate of change of yaw should depend on how well the launch was timed - there's some ideal liftoff moment when the rocket wouldn't have to maneuver in yaw at all and it would get to desired INC/LAN by just taking the right heading, but any deviation from that (earlier/later launch) requires some maneuvering to account for position change and align velocity vector for the right inclination. Correct me if I'm wrong. Anyway, total change (from min to max) in this case was over 27 degrees, which means if I timed better, the precision could increase, too.

So, what now? There are two big things to do: code the general solution for multistage vehicles is coming first. This involves some more equations and logic, but now that the core of the algorithm is working, it shouldn't be a big problem. After that, this all has to be ported to kOS and tested in actual, kerbal conditions! I just can't wait for this part :wink: For now, you can check out the code on my github, if you have MATLAB you can test it yourself (e32d2a97 contains some basic how-to). And stay tuned for more updates!

Edited by Reddy

Share this post


Link to post
Share on other sites

Nice!

@Reddy, one question: did you pass your final graduation exam? You might want to cross that off your list.

Share this post


Link to post
Share on other sites

Oh wow, that looks pretty awesome! @Dman979 do you know how does that happen? Someone picks the TotM, or is it random?

Anyway, nice motivation to keep going =)

Share this post


Link to post
Share on other sites
33 minutes ago, Reddy said:

Oh wow, that looks pretty awesome! @Dman979 do you know how does that happen? Someone picks the TotM, or is it random?

Anyway, nice motivation to keep going =)

Yes, @sal_vager picks the ToTMs. But users can nominate threads that they feel deserve some attention. :)

Share this post


Link to post
Share on other sites

I am not dead. In fact, I spent the last few weeks working hard on PEGAS. Good news: it's getting closer and closer to maturity - it's just a few steps away from being ready to port to kOS. The most recent update is support for multistage launch vehicles!

Unified Powered Flight Guidance (UPFG) algorithm is neatly divided into 2 sections: one is vehicle-specific (blocks 3 and 4 in the original document) and another is vehicle-agnostic. The good thing about it is that if it works well for one vehicle but fails for the other - the error is almost certainly in the first part. This section calculates a description of the vehicle, summarising its capabilities through all available stages in a series of numbers. Those numbers called thrust integrals tell us (most basically) the amount of delta-v the vehicle has and how far it can go (in terms of distance) due to its thrust alone. Math behind them is pretty complicated and I don't have a full understanding of what's going on in there... perhaps if I did, getting it to work for more than one stage would take 5 days instead of weeks.

The Space Shuttle was a 2.5-stage vehicle: 1.5 stage in booster+sustainer mode (SRBs and SSMEs) plus 1 "stage" for orbital operations, the OMS. After jettisoning the boosters, there was one more "staging" point, where the main engines were switched from constant-thrust mode into acceleration-limited mode, where a 3g limit was set to protect the astronauts on board. While it isn't a physical stage, math behind it changes significantly - so I think it's a good example to show the new PEGAS capabilities. Below you have a 3D trajectory plot of a KSC launch into ISS plane (red is powered phase trajectory, yellow is its groundtrack, magenta is a target orbit groundtrack; cyan lines make a prograde-normal-radial frame of reference).

M7nOeDC.png

Target orbit was 200km circular with 51.65° inclination, vehicle (STS Endeavour with 25 ton payload) was launched when the pad was 2° behind the target orbit (8 minutes before the orbit passed directly over the site). Orbit reached: 224x189km, total plane alignment error: 1.02° - a correction maneuver with no orbit shape change would cost 136m/s of Δv. Quite a lot, but I call this a success nonetheless. Vehicle completed the ascent with about 43 seconds of remaining SSME burn time (fuel left in the External Tank), but this is most likely because I haven't yet modelled the SRB thrust profile and its simulation performance is better than the real thing. Plots below show the smooth pitch&yaw commands generated by the algorithm (blue - pitch, yellow - yaw):

OhN3gly.png

The algorithm failed to kill about 19m/s of excessive vertical velocity, also the yaw plot bends oddly in the final moments of ascent. This hints that something that shouldn't happens near completion of the burn (or something that should doesn't). I will be looking into this, as well as a few other minor things, before translating it to kOS. Main post has been edited to reflect the progress.

Edited by Reddy

Share this post


Link to post
Share on other sites

Looks like the source for plane misalignment and orbital shape inaccuracy is common. I don't know what it is yet, unfortunately, but for "easy" launches (ie. target inclination close to launch site latitude, little yaw steering needed) precision is almost astonishing: plane error needs to be measured in arc seconds, while apsis are within ±10km. Most importantly, errors do not increase significantly when manipulating the time window - within some reasonable bounds only the orbit shape slightly degrades, plane targeting is unaffected (so very important for timing a launch!). Things get very messy when we aim at more inclined orbits, and the larger the angle, the worse the performance. At about 50°, resulting plane is skewed by 1-2°; for 60° or more the error goes beyond 15° which would essentially mean a mission failure.

PEG is difficult to troubleshoot, because everything in it is a function of everything else: velocity-to-go depends on estimated gravity effects and thrust integrals, which in turn depend on time to MECO, which depends on velocity-to-go again (just giving an oversimplified image here). One advantage this gives is that one doesn't need carefully calculated initial values to start navigating - you just run it with some half-reasonable first guess and it almost magically converges on good numbers. Additionally, if any errors are introduced (for example due to misaligned thrust vector or residual atmosphere), they are corrected in the next iteration, so in the end everything zeroes out. But if some errors appear in the algorithm itself, getting to their origins is a pain in the ass. Right now I'm digging in PEG entrails, hoping to understand what's going on (so far I have found a weird behaviour of time to MECO: it's supposed to decrease steadily with simulation time, but for "bad" launches it decreases slightly slower than expected and at some point even begins to rise), but it might be a while before I solve the issue completely. Debugging an algorithm which works well for one input but subtly fails for another is frustrating... much easier to understand a singular crash than that. I'm on it though - stay tuned.

Share this post


Link to post
Share on other sites

Again a minor problem with vector algebra set the project back a week (that's how long it took me to find the error - the fix was trivial, 12 characters long). I have tested PEGAS on several launch sites now (Kourou, KSC, Vandenberg, Plesetsk) and various orbits (mostly differing in inclination), with various rockets (Shuttle, Atlas V in configurations 531 and 532) and think it is safe to say that I have a working prototype of a complete system. To back my words: here's a trajectory of a hypothetical Atlas V 532 launch from Vandenberg AFB (34.75°N) into a somewhat retrograde, highly inclined orbit (200x200km, 115°) with LAN also constrained. No pre-flight analysis was made, launch was timed arbitrarily 8 minutes before the launch site rotated under the target orbit.

tf008ue.png

Orbit shape of 214x181km might not be particularly astonishing, but still it's only a matter of about 20m/s to polish it into perfectly circular. But what do we care really, after all it's just a parking orbit - the mission will proceed from here, and maneuver can be easily adjusted for that slight error. It'd be much harder to correct plane alignment, and that's an important thing to get right immediately at launch. So what was the relative angle between target orbit and the achieved one?

0.0046°

Or about 0.6m/s if we needed to manually zero it.

This error is essentially independent from your choice of a launch site or target - as long as your rocket can do it and UPFG can handle your rocket, the numbers will vary slightly but never increase significantly. Just take a look at the following table:

Vehicle Payload Site Target alt. [km] Target plane Angle error Eccentricity Alt. error [m]
STS 25 t Kourou 200 0.00005° 0.00145 0.19
    Kourou 300 0.00002° 0.00145 0.24
    Kourou 200 ISS 0.00060° 0.00164 1.11
    KSC 250 28.5° 0.00005° 0.00151 1.14
    KSC 200 ISS 0.00005° 0.00160 0.99
    Vandenberg 250 polar 0.00673° 0.00175 1.71
    Plesetsk 250 polar 0.00348° 0.00197 1.88
Atlas V 532 17.25 t KSC 200 28.5° 0.00026° 0.00275 2.97
    KSC 200 ISS 0.00556° 0.00276 3.91
    Vandenberg 200 polar 0.00725° 0.00245 4.06
    Vandenberg 200 115° 0.00046° 0.00256 3.96
    Plesetsk 200 polar 0.00228° 0.00230 1.52
    Plesetsk 250 polar 0.00334° 0.00273 4.35
Atlas V 531 15.575 t Plesetsk 250 polar 0.00071° 0.00262 3.31

All of those launches were made with no window calculation, that is: T-0 was not even estimated, just chosen arbitrarily at 8 minutes before passing under target orbit. First stage guidance was the same each time and it was the simplest one imaginable: go straight up for 10 seconds, start pitching over slightly until you reach 10°, hold prograde. PEG took over from where the SRBs were jettisoned, controlling SSME ascent for the Shuttle (formally 2 stages: constant thrust, constant acceleration) and 2 explicit stages of the Atlas (core, then Centaur). Would be of course possible (and probably informative!) to perform tests on a wider variety of vehicles, but I think this proves robustness to various initial conditions and targets. Experiments with more interesting orbit shapes might also be conducted - after all, with such precision why limit the capability at parking orbits if we could try for a direct GTO launch? :)

I have to do some cleaning up in the code and repository - everything seems to work but it's not exactly readable. I'm also thinking about starting a wiki on my github to better explain the project (this readme on the front page is not only very out of date, but doesn't introduce too well). After that there are a few more things to look into: few minor details, I'm only a little worried about one of them which was a problem before so I worked around it (Conic State Extrapolation routine, it's a very efficient function to predict vehicle position and velocity in t seconds from now without integrating the whole trajectory - since I couldn't get it to work, I just... integrate the whole trajectory instead; not sure if this would work for a CPU-limited kOS terminal). This is a plan for now. And once this is done, I will finally be able to start porting PEGAS to kOS code!

Edited by Reddy
words

Share this post


Link to post
Share on other sites

Hmm, for some reason all these wonderful updates weren't notifying me. :(

But this is good news! I look forward to seeing the final product! You've been working on this for at least a year and a half, right?

EDIT: Oh my god, that's astonishing. The precision there would make a German cry with happiness.

Share this post


Link to post
Share on other sites

A year at least, one and a half probably. First video was over 9 months ago, and that was after a considerable amount of work. Then there was my thesis semester, and after that... well, if I finished before the real OSIRIS-REx launch, your recreation mission could turn into a "pre-creation", right? Heh heh heh :D

I want to spend some time cleaning up and documenting the code now, and see into that CSE routine. Making no promises, but I'm hoping to start work on kOS code this weekend. I expect it might take a while too, because I haven't written anything in it in months, and UPFG is quite complex. Debugging in kOS also isn't easy, so I'll have to make many numeric checks and then painful flight tests before the port is complete. Gonna be fun!

Share this post


Link to post
Share on other sites

I have a test for you.

Use an Atlas 411.

Vertical liftoff. Wait 7 seconds, then pitch and yaw as needed to a launch azimuth of 89 degrees. (89 degrees from true north.)

The SRB burns for 94 seconds, and is staged away at T+00:02:09. When the SRB is staged away, hold prograde. Limit maximum acceleration to no more than 5.000G.

At T+00:04:03, BECO. Stage booster at T+00:04:09. RL-10 ignition at T+00:04:19. Fairing staging at T+00:04:27.

Hit a 28.5o, 181x156km orbit.

Is the simulation able to handle that?

Edited by Dman979

Share this post


Link to post
Share on other sites

MATLAB code is now complete. With the CSE routine fixed, everything works as the original implementation specifies and all simulations are good. I added support for real thrust profiles for solid rockets (they ran at constant full thrust previously, yielding better than actual performance) and some features like easily customizable jettisons, coast periods etc. I took your challenge to test the complete architecture.

First, since you did not specify the payload mass, I assumed we're doing OSIRIS-REx and put its mass on the Atlas. I adjusted the launch schedule for that mission by setting the SRB jettison at T+2:19 instead of T+2:09 (per this report). Also, I don't know the Atlas SRB thrust profile, so I took one from the Space Shuttle and scaled it accordingly, figuring that's better than the entirely unrealistic constant thrust mode. For some reason my booster cut off at T+3:54 instead of T+4:03 - maybe the actual acceleration limit is slightly lower than 5G, maybe I didn't get the fuel/dry mass ratio right. BECO and staging events, due to the mechanism of staging I assumed in my MATLAB code, are one and the same thing - simply nothing happens after cutoff, vehicle coasts until T+4:19 when it's updated. I assumed the smallest version of payload fairing, weighing 2127kg.

Results (copied directly from my MATLAB output): Successful insertion at T+607.8 into 145.3x187.0km, 28.5° orbit | Final conditions error: 3.275e-04 (angle)

Insertion at T+10:08 is oddly fast for a single engine Centaur: OSIRIS-REx reached its parking orbit in T+12:23. I suppose there's some mass that I haven't accounted for - perhaps the payload adapter? I have no data on this. Other than that, I found no anomalies. Here are some telemetry plots:

jxnUlSe.png

Acceleration and angle plots (blue for pitch, yellow for yaw) are probably the most interesting. Staging points are easily visible, at T+100 you see SRB cutoff and UPFG activation. I still didn't get something right, it probably has to do with the total mass of fuel burned by the SRB which I must have underestimated because there's a slight jag in the acceleration plot. SRB jettison occurs at T+139, a slight acceleration jump is noticeable. Another similar one at T+267 where 2 tons of fairing are shed (harder to see since Centaur has such a low acceleration). These are all artifacts of the vehicle design, not the algorithm. UPFG still behaves quite oddly between staging points, but I managed to make it a bit smoother. The overall tendency of the pitch plot looks fine, maybe aside from that spike at the end. More on that later though.

0hjy8Ob.png

Here are UPFG internals, displaying thrust integrals and their moments. Easiest to interpret are L and Tgo: L is total delta-v that we still need to expend, Tgo is remaining time until cutoff. In the bottom rightmost plot you can see two sharp jumps corresponding to jettison events. Red line that seems quite out of place represents the constant acceleration phase. The discontinuity is most likely caused by coasting events - since UPFG is unaware of coasting, if we indeed shut down the engines, it's an unexpected situation and the whole solution must be recalculated (although I plan to make it coast-aware later - this is not a crucial feature).

jjwmpH5.png

Finally, a trajectory plot. Least informative, but looks cool :) You couldn't zoom close enough to see any difference between desired ground track (magenta) and the actual (yellow). As mentioned earlier, plane alignment error was below 0.001 degree. The only thing I haven't solved for now is the remaining vertical velocity. I think I know where that comes from: UPFG, when calculating the target position vector, tries to make sure its magnitude is equal to the desired cutoff altitude. Now, in order to reduce the vertical velocity, the vehicle should pitch lower - but then it wouldn't get to this desired altitude, so there's a conflict. Since I suspect that position correction is a higher priority operation than velocity correction (particularly when it does not involve plane changing), we're getting velocity precision traded off for position. I'll try and look into that later.

For now, I'll want to spend a few more hours on the documentation for MATLAB code (there's already a lengthy article I wrote about UPFG, look in the docs branch). Then... kOS :)

Anyone has or knows someone who has a decent RO-level Shuttle replica? I will want to make a video when PEGAS is done, but with a really good looking, realistic rocket this time.

Edited by Reddy

Share this post


Link to post
Share on other sites

As a reminder
 

KSP Coordinate system : X,Z,Y(Left Hand).

Your MATLAB Simulation : X,Y,Z(Right Hand).

Share this post


Link to post
Share on other sites

Damn, I didn't get an email alert for this? @Red Iron Crown, any idea why?

You guessed correctly; I was thinking of ORSRIS-REx. Even with missing information, your code still managed to perform much better than a human-controlled launch, by a huge margin. It's really impressive to see what you're doing here. As for ground track- did it launch autononmously?

 

I found various figures for the thrust of the AJ-60A.

Wikipedia says it has a 379,600 lbf  thrust.

I couldn't find any other info.

Share this post


Link to post
Share on other sites
4 minutes ago, Dman979 said:

Damn, I didn't get an email alert for this? @Red Iron Crown, any idea why?

No idea. Try unfollowing the thread and then following it again with email notifications, see if that fixes it.

Share this post


Link to post
Share on other sites
7 minutes ago, Red Iron Crown said:

No idea. Try unfollowing the thread and then following it again with email notifications, see if that fixes it.

It's the same problem I've had on other threads- I only get notifications from not the OP.

Share this post


Link to post
Share on other sites
On 10.02.2017 at 9:31 AM, Ilpez said:

KSP Coordinate system : X,Z,Y(Left Hand).

Your MATLAB Simulation : X,Y,Z(Right Hand).

Thank you! I would've forgotten that KSP had its vectors the other way around.

@Dman979 It's difficult to talk about SRB thrust. Liquid fuel engines are easy because they consume the same amount of fuel each second (unless you throttle), giving you the same vacuum thrust all the time (the actual thrust changes depending on altitude because pressure outside the nozzle changes, and specific impulse with it). With solid rocket motors we don't have that luxury - they have a thrust profile, meaning their mass flow (and therefore thrust) changes with time. This is how it looked for the Space Shuttle (data from the fatal STS-107 mission):

695px-Srbthrust2.svg.png

High thrust at lift-off, slight decline around T+50 (max-q) then more power for the next half a minute, followed by gradual thrust decline. At some point the SRB acceleration ceases to keep up with the SSMEs and they are jettisoned, still with some remaining fuel. There's a lot of reading on that, you can see examples of different thrust profiles on aerospacengineering.net (figure 1.14 in the article I linked).

Anyway, data on real solid motors is hard to come by (I couldn't find anything on Aerojet AJ-60A), so I'm just using the same profile (Space Shuttle SRB) for all solid motors, I just scale it accordingly (i.e. taking the actual burn time instead of STS 127 seconds and adjusting the max thrust magnitude). This might be inaccurate, or even change the total performance of a rocket, but there's little that can be done about it - better to use this profile than none.

Share this post


Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.