Reddy

Glad to hear that, thanks. Well, that's one bug swatted off the v1.3.1 list

I have "fixed" the pitch program issue. The problem was that PEGAS crashed when altitude exceeded the final keypoint in your pitch program. I say "fix" not fix, because I made it no longer crash in this situation, but emit a critical error instead - your flight will probably still be doomed. You should never allow this situation to happen, and in order to help people understand why, I added this extra bit of documentation. Give me a thumb up if this makes sense.

Some errors you've encountered have been fixed (e.g. the one @asdasdgf pointed out). If PEGAS behaves weirdly, always check github for the freshest code - I sometimes push fixes which can only be grabbed if you download the code directly (i.e. not as a release). The plan is to fix several outstanding problems and package them as a v1.3.1 in the near future. I'm aware of the pitch program "issue" you mention @Kurld, but haven't yed decided whether that's a bug or a feature (and it should be the user's job to specify proper control points). Perhaps it would be nicer if the script didn't crash... As to tuning PEGAS to vanilla atmosphere - I don't have a clue; haven't played vanilla in over 6 years, don't remember how the atmosphere looks. But @Razgriz1 is right: surprisingly, you will likely have a harder time launching in vanilla than in RO. The idea to set the engine thrust limiter is good, just remember to change the thrust value in your vehicle configuration accordingly. If you spot any other problems, please do keep updating me via github or this thread (I've fixed the email notifications for the forum which I haven't previously been receiving)

PEGAS v1.3 "Olympus" is out now! At this point I think it's safe to say that this project is complete, and it has all you might possibly use - hence the release name "Olympus" feels appropriate. Below is a short list of features v1.3 brings: GUI overhaul: better reporting of the vehicle and guidance status, including an event-by-event flight plan display; made possible because... ...UPFG is now aware of jettison and shutdown events before they happen (via a mechanism called virtual stages) new passive guidance mode, pitchProgram, allows fine-tuning the ascent with a pitch-altitude schedule - contribution by Aram1d (thank you!) new event type: shutdown, allows shutting down specific engines (by part tags), also during active guidance new event type: action, allows execution of standard action groups new ullage type: hot, allows hot-staging by reversing the jettison-ignition order new staging option: postStageEvent, allows jettison after ignition (e.g. an interstage ring, Saturn-style) addons: you can now create custom extensions to PEGAS; an addon sharing repository has also been started Aside from those, there's over a dozen of other tweaks, fixes and under-the-hood improvements, making this the largest update to PEGAS yet. Read details on the release page. Given how complete the program now is and how little free time I've got to work on it, I decided to call v1.3 the final major release of PEGAS. There might be a minor update, should anyone find some bug needing a hotfix (I've deliberately delayed this release to test it properly, and I'm fairly confident it's good, but I've been surprised in the past so...), but it's highly unlikely that I'll want to add more features or carry overhauls as large as this one ever again (and, with KSP2 around the corner, I don't think we'll even need any). This has been a really long journey, with the project being alive (on and off, admittedly) for well over 6.5 years (initial commit in my repository dates back to 12th February 2016). Thank you all for following my work and your support <3 PS: Give me a holler when KSP2 is out and we have a stable Realism Overhaul & kOS in the new game EDIT: As always, I forgot to change the UI version number from "v1.3-alpha" to "v1.3" - the release has been updated

There's also the reason of my own laziness: I chose to do it this way (i.e. settle with having to manually describe each launch vehicle) rather than go through the effort of coding up a solution that would (attempt to) figure all those things out automatically. Due to reasons @Razgriz1 mentioned, I thought this effort would be simply immense, and would add a whole lot of extra failure modes (and worst of all, in order to solve those failures, we'd probably need a way to override the automatic discovery by inputting this data manually... so back to square one). PS: Anyone still using PEGAS? I'm working on a v1.3 as we speak EDIT: @Razgriz1, that upcoming-events-ETA display that you asked for ages ago - I've got it done

I very much like the idea behind this mod. However, I see several problems with it that make it rather unpleasant to play for me. So let me ask a few questions: The RWs store momentum in 3 axes independently and I can lose control e.g. in yaw only while still maintaining roll authority. I can regain control by spinning in the opposite direction. Question: how do I know which way to spin in order to "dump" momentum? There is the feature to dump momentum using monopropellant. How does that work? Does adding a reaction wheel and a monoprop tank allow me to magically unload momentum, or does it automatically interface with the RCS on my vessel? Finally, in Realism Overhaul careers there is no such thing as monopropellant. Is there a (reliable) way to dump using whatever RCS my vessel currently has installed?

This is an extremely important piece of information! Thanks for mentioning it - we'll have to figure out a way to let this handle such cases as well. Since I saw you both post under the issue, let's move further discussion on this particular subject there

You get it right @Razgriz1, this is exactly what delegates (aka function pointers - I'm more used to this term due to my extensive C/C++ background) are for! Such a modification should be very easy to implement. I'll I've put it on the list of things to think about (link below). The only difficulty I see about this is testing. If you could help with this (since you've got a craft and transform function at hand), that would take a lot of hassle off my back @La Piante you can join the discussion I've opened myself: https://github.com/Noiredd/PEGAS/issues/38

@La Piante I suggest you consider opening a separate thread, because your issue, as @Razgriz1 points out, is quite complicated and currently its solution lies outside the scope of what PEGAS is capable of. Usually I'm okay with providing help, but we're at a risk of drifting off-topic here. Alternatively, you can open an issue (or even a pull request) on my github, if you feel a feature like this should make it into the program. If this is the case, I would rather we focused the conversation here on coming up with a general approach that would let users fly all kinds of weird spacecraft, not only the Shuttle. Perhaps I should add a sort of optional "steering intercept" function? Something like a delegate that the user could provide that would act like a sort of hook into the system, allowing any kind of transformation of the steering vector. By default it would be something like f(x)=x, but it could be overridden (e.g. in CONTROLS) with whatever (e.g. shuttleSteerDir). I'm not sure if I understand your approach @Razgriz1, I haven't had the time to review your code in detail -- would that work? Edit: @La Piante Yes, I do know Matlab. I have programmed the entire prototype of PEGAS in Matlab. Please read this thread to gain some perspective

I haven't reviewed his PR in detail, haven't even tested his solution. But after glancing through the changes, it was obvious to me that it needs a bit of cleaning at least. I'll get to it in due time, I hope Aram1D will want to help me with this. Feel free to join the discussion in the meantime. Something like a time-table of events, past and future, with something like a marker denoting where we are? That sounds awesome. I've never flown anything like a Shuttle, so haven't even realized something like this is necessary. I'd love to take a look at that, if possible.

I want to merge Aram1D's PR but this needs some more work. Would be absolutely great to have it in 1.3 but it relies mostly on me being able to get in touch with him. Other than that, I'm working on one other big feature: virtual stages - representing some physical vehicle stages with more than one logical stage. We've already had this to some extent, for example stages with an acceleration limit set - under the hood they were actually treated as two separate stages: one with max throttle until some point, then a new stage with automatic throttling to maintain constant acceleration. This is getting a major extension to allow shutting down selected engines (so it will be possible to tag the center engine in an S-IC and shut it down like in a proper Saturn V launch sequence) and more accurate handling of jettison events. These two are already implemented, I'm working on smoothing things out a little bit on the UI side. Along the way, the staging mechanism is getting refactored (it's just a technical thing with no effect on the user, at least no intended one). I'm also planning to use this framework to allow throttling during UPFG control - useful for things like Falcon Heavy, where for some time the boosters provide the most thrust while the core throttles down to conserve fuel. Among the minor things on my radar there's the long-neglected KAC compatibility patch, post-launch task scheduling, better pre-launch checks (partially done alread). I'm also planning a small extension to the staging sequence (currently limited to jettison, ignition and ullage events), another optional item that would happen after everything else. This would allow things like on Saturn V again, where the S-II had that extra interstage ring which was jettisoned soon after the J-2's ignited (I happen to need this for one of my own designs). Finally, I started to hate the current UI and I'm thinking of reshaping that area a little bit... add some more telemetry (TWR? remaining delta-v?), maybe the list of upcoming events. But whether I'll get around to it for 1.3 or will it get pushed for a hypothetical 1.4 - we'll see

@Razgriz1 Thanks for confirming that - I wouldn't have checked myself as I'm still stuck with KSP v1.2.2 (and thus kOS 1.1.0.0) due to my savefile which wouldn't endure an update. I feel too connected to my builds. Anyways, if you ever encounter any problems with the newest KSP/kOS, please let me know (preferably through an issue on github) and I'll fix such a problem as soon as possible. PEGAS is still being worked on, in fact I'm planning a 1.3 release in a few weeks

I've just pushed version 1.2, featuring delegate events and a new CSE routine. You can now execute custom tasks during the ascent using KOSDelegates, like so: FUNCTION myCustomOperation { SET curState TO acquireState(). // You can use PEGAS internal functions... SET lastCSER TO upfgInternal["cser"]. // ...and variables // do whatever you want here } // Assuming the craft boot file has already set the main sequence, we'll just edit it sequence:ADD( LEXICON( "time", 450, "type", "delegate", "function", myCustomOperation@ ) ). Give a thumbs up if you're still using this in 2021

It sounds like a common problem with kOS and RCS steering. Try to run something like this: LOCK STEERING TO RETROGRADE. WAIT 20. UNLOCK STEERING. and see what happens. If you observe the same symptoms, it's the kOS fault (or your vehicle, but I'm not sure). @LAND ASAP I see you're trying to launch to zero inclination orbit. Where is your launch site located?

Great mod, just the engines I needed - especially those tiny ones for small upper stages! Thank you I found one error however: the RO config for S5.92 seems off. Looks like you've calculated the mass ratio for propellant volumes instead of masses, and the dry mass of the engine is a tad too high (confused with the S5.98M?). Please compare the numbers with RO's own config (RealismOverhaul\Engine_Configs\S5_92_Config.cfg). Btw, the same thing with propellant ratio with S5.98M.

Not at all, this is what the PRs are for - all improvements are very welcome, thank you @Pand5461! I've researched the apses difference thing back during the prototyping days - it's interesting, but the error is always there, even in a MATLAB simulation running at 1ms precision. Something tells me that this is just how the UPFG is and nothing that can be done about it at all. As Jim DiGriz said a few posts above, this implementation most likely never really flew the Shuttle - it was a good first draft, but likely received many improvements before actually being used in the GN&C. And there had to be something to improve on, right?

@JohnMcLane Thank you =) Staging a payload can only occur if you have a sequence event set up... or if there is stage in vehicle but no corresponding physical stage to be dropped. PM me with the details of this issue as it sounds weird.

Thanks, @JohnMcLane! One thing you must be aware of is that masses are not for the individual stages, but for the entire vehicle at this stage. So the CCB mass in PEGAS must also include the Centaur upper stage. I will make this more clear in the next update of the tutorial

@Gousaid67's bug reminds me of a feature I wanted to request - or rather ask if it's even possible. I dream of a mod setup in which I am only allowed to see what my craft sees (preferably using onboard cameras - like Hullcam VDS), and the map view is only an astrodynamics reference. That is, all the nice scatterer effects, volumetric clouds, shaders etc. are only visible in the in-game view. Map view only shows maps, not the amazingly rendered planets; kind of like in SpaceX' streams when the vehicle coasts. In short, map view would look like this: But only after getting my vehicle in space I would get to see this: Could something like this be done, @Phineas Freak?

PEGAS v1.1 is out now! Get it while it's still hot! List of new features includes: inter-CPU communication system by Patrykz94, roll control via user events, better throttle control via user events, new user event type (jettison) to account for the amount of jettisoned mass, stages can explicitly shut down engines (useful for Falcon 9 style missions), LAN and inclination as optional parameters (default inclination will be equal to launch site latitude, defualt LAN will be set for the launch to occur in 30 seconds from "now"), launch direction (northerly and southerly, as well as "nearest opportunity"), automatic seizing control from the kOS CPU part, as well as a few bugfixes: throttling now obeys the way Realism Overhaul works, sustainer-type stages are now handled properly, minor code clean-ups, GUI and documentation fixes. @Jim DiGriz I am tempted to shamelessly say that plus or minus, what matters is that it flies To be honest, I just don't have as much time as I used to, certainly not enough to research the intricacies of the algorithm again. I have already limited my activity to maintenance, bugfixes and features related mostly to KSP-side infrastructure (like events, stage handling, action group support etc.). For anything that touches the UPFG itself: I will review pull requests, perhaps assist in testing, but digging deep into it like I did in mid 2016 - unlikely. Though I am curious to read about your findings! You know, I started fiddling around with kOS in early 2015 because I pretty much mastered the game and flying a hundred ascents to build&resupply my orbital station became boring. This was when I wrote my first autopilot. Soon, in search of a bigger challenge, I tried RO, but found that my toy-level script was no longer sufficient. Later I found Orbiter forums and PEG, and this was about the last time I've really played KSP. Ever since it was only pencil&paper, MATLAB and if I ever launched the game, it was just to test/debug PEGAS. Rendesvouz launches were always on the horizon of what I wanted to do (orbital station servicing, right?) and initially I thought this could be done with the basic PEG the Orbiter wiki describes (or some extensions of it). Realization that it's not was what pushed me to research further, to come across UPFG and subsequently to spend another year working on this project. Implementing the algorithm made PEGAS everything that I ever wanted it to be. It might not do everything, there might be things that it could do better, and sure I do have more ideas to add - but for most practical purposes it's more than enough. To me it's at its pinnacle as a tool. Of course it's not over yet: there will be more bugs and fixes, requests and features - bigger and smaller, but for now I am happy with how it turned out. I feel kind of like the South Park guys at the end of the "Make Love Not Warcraft" episode. I can finally play the game

@windystig The tutorial is what you're looking for. @Jim DiGriz I've just tried it. After changing this to +, it failed spectacularly. Although it's a nice find on the phidot identity - nothing should change and indeed nothing changes if this line is removed. It is very strange, why is this term even there (I'm thinking about figure 5-6 in the block diagram for block 5 in the original UPFG paper). In the current form it introduces nothing - vehicles fly perfectly with and without it. Changing it to anything else just makes things crash in all sorts of ways. It's just hard to believe that they would burden the GN&C computer with such a heavy line if it does exactly nothing...

First of all, I have tried following your discussion from pages 3 and 4 but I'm not really sure whether the problems you're discussing are a matter of PEGAS code, that is: does it do something wrong or fail in some case? If so, please make it clear what happens and when, and if you have a suggested solution - go ahead I also welcome github issues or pull requests. Now, to answer some of your posts: @Pand5461 This is a bit tricky and very very empirical. I have tried approaches basing on steering vector and Tgo, trying to measure differences between the values calculated in consecutive iterations. The main problem that I was having was that UPFG sometimes converged (measured either way) on very wrong results (i.e. pointing 30+ degrees below the horizon and crashing) - especially on later stages. The basic logic is that I measure Tgo and see how it's changing. You have to be aware that kOS takes a good while to run through the entire UPFG routine, so some considerable time passes between the calls. What I'm doing is I measure that time and adjust the expected Tgo before comparing it with the algorithm's prediction. If the difference is small enough, I count that as a hit and run again. The point is to get 2-3 such hits in a row - this means that predicted Tgo is steadily decreasing with time. Now comes the trick part. Sometimes after staging, UPFG would converge (that is, pass said verification algorithm), but the result would be rubbish (pointing down). I admit I have failed to find the cause of that, but I located the issue to be somewhere in the internal state of UPFG that has to be preserved between iterations. Simply reseting it in those situations would make things run smoothly. The very idea was to check whether the steering vector is similar to the "good" vector that the previous stage had. If they were very different (above 15 degrees), the UPFG state would be reset and reconverged with brand new state - for some reason, it would always (to the extent I tested) converge on a good solution (good = one that got it into orbit instead of RUD on reentry). The reset mode would print a PRIORITY_CRITICAL message in the GUI upon being called. However, I haven't seen this message in a good while when flying my rockets - it might very well be the case that this behavior is not an issue anymore. @Jim DiGriz It appears so, yes. I will fix this the next time I sit down to code. The reason this was never a problem is that this branch of code is executed only when the alphas parameter is less than zero - and IIRC this can only happen when the vehicle is in a hyperbolic trajectory. @gsarducci Currently there is no such option. This is kind of counterproductive, since the whole point of PEGAS is to not have the vehicle locked at one attitude, but continuously change it in order to maintain an optimal trajectory. Wait, haven't I replied you in issues? Anyway, I'm considering implementing a more general event type - including one in which you could pass a function delegate into an event. This would basically let you do anything. Still, making the vehicle spin when PEGAS tries to change attitude (to a new steering vector calculated at every iteration) is not a good idea, because you would be effectively fighting against what it's trying to do.

I am sorry I was absent for a while. As some of you might know, I am a PhD student - there are periods where I simply don't have time to pay attention to PEGAS and this thread. I've just pushed some updates to the main repository, here's the list of new features: roll control - you can define initial roll (vehicle will roll to that angle during the initial pitchover maneuver) via controls["initialRoll"], and then control the vehicle's attitude using events, better throttle handling - RO does not treat the throttle slider in an absolute way: 50% slider does not correspond to 50% throttle, but 50% of throttle range that an engine allows. PEGAS can now handle this (fixing issues with g-limited stages), at the expense of users having to input an additional key ("minThrottle") along the "gLim" in their stage definitions, new event type: jettison - allows user to inform the system of the amount of mass lost in a staging event, which is also important in acceleration-limited stages (eg. if a stage's dry mass included fairings, and then these were jettisoned, the vehicle will weigh less than PEGAS planned for - as a consequence, throttle will be lowered at a slower than expected rate, consuming fuel slower, causing the engine shutdown later than PEGAS scheduled the next stage ignition: as an effect, the constant-acceleration stage could smash into the next stage), several minor tweaks: PEGAS will change the control part to the currently running terminal on boot, lack of "message" key in user event will no longer cause it to crash, etc. We're almost halfway to the 1.1 release, which will include also the following features: launch with no LAN constraint (something like a "launch now" function - LAN will still be constrained, but it will be hidden from user and dynamically calculated), launch opportunities (ability to pick northerly or southerly launch, together with the option "nearest from now"), better atmospheric ascent control (I'm thinking of something akin to aim points for optional, additional control over pitch during early ascent). I'll read up on that thread later and try to reply you guys

@Alpha_Mike_741 Thank you for that comment! Glad to hear such words of support @Pand5461 It looks right... INC and LAN explicitly, SMA, ECC and anomaly from the remaining 3 - although in a not so very transparent way. I agree. Confusion was on my end, probably due to my lacking understanding of anomaly, which is now more thorough thanks to you pointing that out. Regarding projections - I use that in my position corrector, yes, but not in initialization. I choose the initial rd by rotating the current r, instead of projection of r on target plane. But I suppose it would save 1 iteration of convergence at most, since right after that first iteration it is constrained to the plane by said corrector. You and @Jim DiGriz mention an important thing: accounting of rotating reference frame. This is of course merely a KSP quirk, since the SolarPrimeVector constantly changes for some reason and the axes of the reference frame with it. However, both our current state (r, v) and desired state (rd, vd) change in the same way - shouldn't that make fixes unnecessary? Or do the intermediate vectors, like biases, thrust integrals etc. have to be explicitly corrected? I spent a while pondering on that when coding the kOS version, but decided to try running without any corrections first, see how it works and fix if it's wrong - but it doesn't look wrong. This conversation would be nice to have on github issues, too, as it has potential of improving PEGAS I will also let you know that I don't feel strong enough in control theory to do anything regarding coast phases optimization. I tried reading a few papers months back, but this level of math is far beyond me.

@Pand5461 What a coincidence, I was about to reply to you First, I agree with your finding that rgoxy wouldn't have to be calculated separately, and this optimization is something I would expect to find in assembly code for the actual guidance computer. But for the purpose of explaining the logic of the solution, I think they left it in a longer but clearer form deliberately. Same with normalization of iz, it might just make it easier to explain the maths in the simplest way possible. Regarding the usage of projection of r instead of r in the initialization, I was surprised that you noticed this as I was certain that my final code already does it. I am 100% sure I had it in place at some point, since I spent several hours on trying to come up with a good initialization method - none of the documents I read contained anything on that. Simplest answer would be that I temporarily removed this at one of the debugging sessions and forgotten to put it back in Now, onto your question, but please clear a few things for me first. Why is the current state "next to unusable in stock", and how would inclusion of coasting fix it? I see a potential source of confusion in the fact that you're mistaken about the current constraints: actually only 4 of 6 orbital elements must be specified: semi-major axis, eccentricity, inclination and LAN (argument of periapsis and true anomaly are free).