PEGAS - Powered Explicit Guidance Ascent System - devlog

[La Piante]

Ok thank you very much ... i'm not a coder but i'm trying to understand ...

I am using the space shuttle system from spacedock:

https://spacedock.info/mod/1178/Space Shuttle System

I'm already trying to replace my 3 motors pointed towards the center of mass to have less torque, but apparently it's more complicated.

I found a program called Matlab, do you know?

 

Edited May 12, 2021 by La Piante
wrong language

[Reddy]

@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

Edited May 13, 2021 by Reddy

[La Piante]

sorry for the inconvenience you did well to warn me.

 

When I read the different codes to try to understand, I realized that it is too much complicated for me. But I wanted to say congratulations to you for this script because it is very complicated. Well done.

But if you think that it is possible to add a function to calculate the steering vector then, I support you for that.

 

I'll post my issue on your github.

 

thank you

[Razgriz1]

@Reddy yeah, my function should work. I'm more than happy to try and adapt it for your script, though my understanding of delegates is somewhat lacking at the moment and I don't really understand the benefit of doing that over just a normal function call. I'd need to do a bit of learning on that subject before I'm able to help you with that.

But yes, generally what my function does is takes in an input direction, i.e. the normal direction you would use for steering, and outputs a transformed direction that you can lock your steering to. This transformed direction is the direction you need to point in order for your thrust vector to point through your center of mass in the original direction you input into the function. If your nominal thrust vector is already through your center of mass, then my function should just return the same direction (or near enough, due to floating point error) though I'll admit, I've never tested it on anything that didn't have offset thrust.

Edit: Scratch that, I think I get it now: you would do something like LOCK STEERING TO SteeringTransform(<target_direction>) and that SteeringTransform would be a delegate that defaults to just outputting the input with no transformation, but you could set that delegate to something else that does do a transformation instead of like say an if statement with a switch variable. I never really understood the benefit of delegates until just now... Most of my programming experience is just bespoke scripts for things at work or in KSP. I'm not used to generalizing my code.

If you come up with how you'd like to implement this on your end, I can see how I might hook my function into this and see how well it works.

Edited May 13, 2021 by Razgriz1

[Reddy]

7 hours ago, Razgriz1 said:

you would do something like LOCK STEERING TO SteeringTransform(<target_direction>) and that SteeringTransform would be a delegate that defaults to just outputting the input with no transformation, but you could set that delegate to something else that does do a transformation instead of like say an if statement with a switch variable.

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

Edited May 13, 2021 by Reddy
issue opened

[Razgriz1]

@ReddyI'm gonna need to do more testing anyway just to make sure it's doing exactly what I think it should. I've only ever really used it on one vehicle, though I have used it in two separate stages of the vehicle, where the offset is different (i.e. Shuttle+ET vs shuttle alone with OMS).

I'm happy to help you flesh this out some and to add my function as an example of something you can do with it. We can continue this discussion on the issue over on Github.

[Reddy]

1 minute ago, Razgriz1 said:

I have used it in two separate stages of the vehicle, where the offset is different

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

[FabioofSpace]

Hey, does this work with principia?

[Razgriz1]

On 8/24/2021 at 1:17 PM, FabioofSpace said:

Hey, does this work with principia?

Yes

[ElAlien859]

Hi, what does it mean when it says UPFG status: Converging...?
I'm flying an Atlas B from Cape Canaveral and I followed all the steps of the tutorial and read every document that's in Github, and I haven't found anything on "converging", I only found where you explain what it is.
I must've overlooked it, but how can I fix it?

[Razgriz1]

4 hours ago, ElAlien859 said:

Hi, what does it mean when it says UPFG status: Converging...?
I'm flying an Atlas B from Cape Canaveral and I followed all the steps of the tutorial and read every document that's in Github, and I haven't found anything on "converging", I only found where you explain what it is.
I must've overlooked it, but how can I fix it?

It means that the algorithm is searching for a valid guidance scheme to start following. See here. If the launch vehicle is sufficient to reach orbit, and the initial unguided trajectory is decent, then it should converge pretty quickly and begin active guidance. However, PEGAS is not magic and can't find a valid guidance scheme if one does not exist given current parameters.

Typically I have found this to happen if my vehicle is incorrectly defined in the PEGAS setup. Especially with a stage-and-a-half rocket like the Atlas B, you'll need to be very careful about defining the vehicle. Usually, you should set PEGAS to activate only after the booster skirt has jettisoned. (This is pretty historically accurate as well)

[SpaceFlightNut]

Hello!

I am examining your code, and I was wondering one thing: What is the purpose of the launch vehicle descriptor file, such as

PEGAS/kOS/boot/AtlasV-532.ks

It contains parameters (such as massTotal, massFuel, isp, thrust), that can surely be obtained from the vehicle itself, correct? 

It seems as if they are redundantly specified in there, unless I am missing somethng.

Thanks!

[Razgriz1]

9 hours ago, SpaceFlightNut said:

Hello!

I am examining your code, and I was wondering one thing: What is the purpose of the launch vehicle descriptor file, such as

PEGAS/kOS/boot/AtlasV-532.ks

It contains parameters (such as massTotal, massFuel, isp, thrust), that can surely be obtained from the vehicle itself, correct? 

It seems as if they are redundantly specified in there, unless I am missing somethng.

Thanks!

Programatically determining the staging for your rocket via kOS is not a trivial problem, and relies on various assumptions about how a user sets up staging. It also pretty much entirely breaks down in non-traditional staging cases like the booster skirt jettison for the Atlas rocket, which isn't reflected in the stock dV readout at all. You also can't assume any other parameters such as engine ullage requirements or hotstaging requirements (useful in RSS/RO) and so having the user define their vehicle parameters is a much cleaner way to do this.

[Reddy]

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

Edited September 7, 2022 by Reddy

[Dman979]

PEGAS for days!

[Reddy]

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 

Edited October 2, 2022 by Reddy
release version number fix

[asdasdgf]

events inside the sequence Less than four, it can cause  program error.I don't know if it is a bug.

print:

index was out of range 

must be non-negative and less than the size of the collection.

at 0:/pegas_misc.ks,line 480

[asdasdgf]

Sorry, I didn t notice someone had feedback on the issue.

Edited January 16, 2023 by asdasdgf

[Kurld]

When I try to run PEGAS I get:

CONTROLFROM command found a generic part value, blah blah

I have a command pod (RC-001S RemoteGuidanceUnit)  on the ship I'm trying to launch.  Don't really know what to do now.

[Kurld]

I resolved this by adding the kOSProcessor module to the cfg for the command part.

Now I'm getting  ALMOST the same error @asdasdgf was getting, except mine happens at line 406 

How to resolve that?   Based on what was said, I tried adding some extra events to the sequence to make it > 4 but it didn't help.

 

Edited January 18, 2023 by Kurld
more info

[Kurld]

OK, so the latest version of the pegas_misc file solves that issues.  I have it working now.   Sorry for all the noise.

Getting a proper gravity turn working is a lot of trial and error, and I still haven't figured it out, really.   I can set the throttle at increments of time, but again this is a LOT of trial and error.

I noticed in the reference that you can set up some kind of delegate function as a sequenced event.  Today is "day one" for me working around in kOS.  I'm wondering if it is possible to call a delegate and have it manipulate the throttle so that time to apoapsis remains e.g. 45 seconds in the future, or else maintain some relatively constant acceleration BEFORE the active guidance takes over?  

This will be really really cool if I can figure out how to make it work.

 

[Razgriz1]

22 minutes ago, Kurld said:

OK, so the latest version of the pegas_misc file solves that issues.  I have it working now.   Sorry for all the noise.

Getting a proper gravity turn working is a lot of trial and error, and I still haven't figured it out, really.   I can set the throttle at increments of time, but again this is a LOT of trial and error.

I noticed in the reference that you can set up some kind of delegate function as a sequenced event.  Today is "day one" for me working around in kOS.  I'm wondering if it is possible to call a delegate and have it manipulate the throttle so that time to apoapsis remains e.g. 45 seconds in the future, or else maintain some relatively constant acceleration BEFORE the active guidance takes over?  

This will be really really cool if I can figure out how to make it work.

 

You probably can (you can do a lot of things with delegates in PEGAS) but I'm not sure you'd really want to do that. The open-loop guidance portion, a.k.a. before "active guidance" is mostly to get you high enough in the atmosphere so that the closed-loop portion can take over. Your open-loop portion should be over fairly quickly before you'd really want to control your time-to-apogee. You'd probably be better off setting up a pitch program instead of a simple pitch angle. You can make a okayish ascent profile without too much effort.

[Kurld]

Thanks for the quick reply. I will look into pitch program next/instead.

For vanilla, what is "high enough in the atmosphere"?  How far towards the horizon should I be tilted? The docs mention 45km-ish but I suspect that is for the real world atmosphere.  I suspect the example boot files are for real-world performance and I have no idea how they would really translate into vanilla KSP values.

 

 

[Dman979]

Just gonna ping @Reddy in case they have input

[Kurld]

Well I messed around with setting up a pitch program this morning.  Maybe I don't really understand "gravity turn" but in no case have I been able to hand things over to active guidance and not have it pitch up to nearly vertical and reset throttle to 100%.  This results in the apo being 600 to 700km on a planned 115 km flight path (remember I am in vanilla KSP.)  At the handoff I am somewhere around 60km altitude and nearly horizontal with a predicted APO of about 90km  I can't recall what my velocity was but I'm guessing the algorithm must feel it is much too low to continue on to the planned orbit.

I also made PEGAS crash.  If it gets to the end of the pitch program before handing over, it blows up with another index out of bounds error.  I'll try to make a more full report on github after work.