Jump to content


  • Posts

  • Joined

  • Last visited


81 Excellent

1 Follower

Contact Methods

Profile Information

  • About me
    GNC Specialist

Recent Profile Visitors

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

  1. 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
  2. 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
  3. 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?
  4. 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
  5. 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
  6. @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
  7. 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.
  8. 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
  9. @Razgriz1 Thanks for confirming that - I wouldn't have checked myself as I'm still stuck with KSP v1.2.2 (and thus kOS 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
  10. 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", [email protected] ) ). Give a thumbs up if you're still using this in 2021
  11. Hi Reddy,

    I actually made an account just to ask you a question.
    I'm studying control systems, and I just picked up kRPC so that I can start testing control systems, development, and design in KSP.
    I saw that you went and made PEGAS in ksp using kOS. That's really freaking impressive.
    I'm having a lot of trouble coming up with an ascent controller that's any better than:
    "Hit go, wait a bit, okay start turning, keep turning, okay now you're at altitude"

    Which feels really scripted, and not optimal at all, so obviously I'm looking to make something better.
    PEGAS looks like a good system to emulate. Would you suggest I try to come up with a comparable system if I want a really good ascent controller?

    What suggestions, tips, resources, things to look at would you have for someone who's trying to take on this endeavour?

    All the best.

    1. Reddy


      I feel bad for replying you after 2 years but I totally forgot about this forum and that I was registered here. PEGAS is finished and I'm not playing KSP anymore... I shifted towards other interests.

      So in case you ever log back in here to see a reply: you will not come up with a comparable system to PEGAS. I know this may sound conceited but it's the truth, because: PEGAS is based on a real world guidance algorithm (UPFG) which I did not come up with myself - it was mathematically described by scientists long ago, and I only implemented it. Stuff I did myself was all related to events handling, launch timeline and all that - and yes these can be always improved on. But if you're interested in guidance per se, you will never do better than using a real algorithm. And of these, none is documented better than UPFG.

  12. 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?
  13. 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.
  14. 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?
  15. @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.
  • Create New...