PEGAS - Powered Explicit Guidance Ascent System - devlog

[LAND ASAP]

On 2018/2/18 at 3:52 AM, Reddy said:

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?

Thank you for your reply! 

I launch the rocket in Cape Canaveral. Is it where the problem lies in?

Should I use kourou for such launch?

[LAND ASAP]

One more question. After receiving your reply, I tried to launch the vehicle without setting the inclination in the mission config. Still converging most of the time time. I have tried times and times again.

 But when it works, it’s really amazing!

 Or should I submit it to github? Thanks!

Edited February 19, 2018 by LAND ASAP

[ola]

OK, so, after seeing this I've actually started reading articles in Journal of Guidance, Control and Dynamics. Damn you, science!

[martinmike2]

Just a quick question,  tried to use this with the Shuttle Lifting Body mod, which uses the Mk3 cockpit as the control point.  Got the following error: "CONTROLFROM command found a generic part value."  Am I doing something wrong?  or does this not work with manned rockets?

[Desdinova]

I'm working on my own PEG implementation in KOS as a side project. I've got it sort of working, I'm having issues with the delta v - it's off by a factor of about 5. It starts decreasing towards zero, then around 30 seconds before cutoff, jumps randomly by huge amounts, changing sign. As far as I can tell I've implemented the algorithm just as described in the NASA paper / orbiter notes. If I comment out the derivative terms it basically works. Anyone here want to take a peek at my script and see if anything jumps out?

	function GuidanceLoop
{    
    SetOldTime(GetTimer()).
    SetTimer(time:seconds()).
	    local T is GetT().
    local r_v is -ship:body:position.
    local r is r_v:mag.
    //solve for guidance parameters A and B    
    local b0 is -ve() * ln(1 - min(0.9999, T / GetTau())). 
    local b1 is b0 * GetTau() - ve() * t.
    local c0 is b0 * t - b1.
    local c1 is c0 * GetTau() - ve() * t^2 / 2.
    local M_B_0 is r_d_t - verticalspeed. 
    local M_B_1 is r_t - r - verticalspeed * T. 
    //update steering parameters
    if T > 10
    {
        SetB(((M_B_1 / c0) - (M_B_0 / b0)) / ((c1 / c0) - (b1 / b0))).
        SetA((M_B_0 / b0) - GetB() * b1 / b0).
        SetOldA(GetA() + delta_t * GetB()).
        SetOldB(GetB()).
    }
    SetOldT(T - delta_t).
    
    //update state vectors
    local h_v is vcrs(r_v, ship:velocity:orbit). 
    local theta_unit is vcrs(h_v:normalized, r_v:normalized).
    local delta_h is h_t - h_v:mag.
    local r_mean is (r_t + r) / 2. 
    
    //performance
    local omega is vdot(ship:velocity:orbit, theta_unit) / r.
    local C_t is C(r_t, omega_t, GetOldT(), GetTau()).
    SetTau(tau()).
    if T > 10
    {
        SetC(C(r, omega, 0, GetTau())).
    }
    
    //calculate delta v
    local f_r is GetOldA() + GetC(). 
    local f_r_d is GetOldB() + (C_t - f_r) / GetOldT(). 
    local f_theta is 1 - f_r^2 / 2.
    local f_theta_d is -f_r * f_r_d.
    local f_theta_d2 is - f_theta_d^2 / 2.
    //local delta_v is (delta_h / r_mean) + ve()* T * (f_theta_d + f_theta_d2) * GetTau() + (f_theta_d2 * ve() * T^2 / 2 ). 
    //set delta_v to delta_v / (f_theta + f_theta_d * GetTau() + f_theta_d2 * GetTau()^2).
    local delta_v is (delta_h / r_mean) / f_theta.
    SetT(GetTau() * (1 - constant:e^(-delta_v / ve()))).
}
	

 

[Jim DiGriz]

11 hours ago, Desdinova said:

I'm working on my own PEG implementation in KOS as a side project. I've got it sort of working, I'm having issues with the delta v - it's off by a factor of about 5. It starts decreasing towards zero, then around 30 seconds before cutoff, jumps randomly by huge amounts, changing sign. As far as I can tell I've implemented the algorithm just as described in the NASA paper / orbiter notes.

That isn't PEG, that is the old Surveyor-era Atlas-Centaur guidance that precedes both IGM and PEG.  The correct reference for that is here:

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19660006073.pdf

The orbiter notes are incorrect and buggy, and I can't recall exactly where (it's been over a year and I've forgotten the algorithm, not to mention the specific bugs in that wiki).  An implementation of that code that works is here:

https://github.com/MuMech/MechJeb2/blob/7a78a57740a37eeb5509e2c3f8d09c012b347648/MechJeb2/MechJebModuleAscentPEG.cs

(Yes that file is still named "PEG" but I named it incorrectly ages ago)

Where my code agrees with the NASA code and disagrees with OrbiterWiki you should not use the Wiki pseudo-code (where my code disagrees with the NASA paper, I'd bet I've got bugs and NASA knew what they were doing...)

Note that I never got the yaw steering implemented.  The N-stage summations in Terens paper are brutal to implement and debug to eliminate typos.  The actual PEG algorithm is easier to implement fully.

[GRAVITY_TURN]

On 9/23/2018 at 11:52 PM, Jim DiGriz said:

That isn't PEG, that is the old Surveyor-era Atlas-Centaur guidance that precedes both IGM and PEG.  The correct reference for that is here:

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19660006073.pdf

The orbiter notes are incorrect and buggy, and I can't recall exactly where (it's been over a year and I've forgotten the algorithm, not to mention the specific bugs in that wiki).  An implementation of that code that works is here:

https://github.com/MuMech/MechJeb2/blob/7a78a57740a37eeb5509e2c3f8d09c012b347648/MechJeb2/MechJebModuleAscentPEG.cs

(Yes that file is still named "PEG" but I named it incorrectly ages ago)

Where my code agrees with the NASA code and disagrees with OrbiterWiki you should not use the Wiki pseudo-code (where my code disagrees with the NASA paper, I'd bet I've got bugs and NASA knew what they were doing...)

Note that I never got the yaw steering implemented.  The N-stage summations in Terens paper are brutal to implement and debug to eliminate typos.  The actual PEG algorithm is easier to implement fully.

 

My implementation is almost identical to yours, but in MATLAB. I'm getting strange results - I believe it converges as Tgo is consistenly reducing, but the fr term begins to go crazy and ends up being >1, clearly impossible! Did you ever experience behaviour like this? It should be near zero as my velocity vector is near the local horizontal and the vehicle isn't far off the target insertion altitude, but instead it begins to rise hence adding to the radial component.

[Jim DiGriz]

22 hours ago, GRAVITY_TURN said:

 

My implementation is almost identical to yours, but in MATLAB. I'm getting strange results - I believe it converges as Tgo is consistenly reducing, but the fr term begins to go crazy and ends up being >1, clearly impossible! Did you ever experience behaviour like this? It should be near zero as my velocity vector is near the local horizontal and the vehicle isn't far off the target insertion altitude, but instead it begins to rise hence adding to the radial component.

If that's in the last couple of seconds, then its terminal guidance issues, you need to freeze guidance at some point before the end or you get swamped by errors.  Basically the same problem that MJ has when it has nearly burned a maneuver node to zero and if you have the deltav m/s tuned up too high it'll constantly try to 'hunt' the maneuver node and due to errors can never burn it down to exactly 0 m/s.  All guidance has this problem.

[GRAVITY_TURN]

On 10/21/2018 at 7:16 PM, Jim DiGriz said:

If that's in the last couple of seconds, then its terminal guidance issues, you need to freeze guidance at some point before the end or you get swamped by errors.  Basically the same problem that MJ has when it has nearly burned a maneuver node to zero and if you have the deltav m/s tuned up too high it'll constantly try to 'hunt' the maneuver node and due to errors can never burn it down to exactly 0 m/s.  All guidance has this problem.

The issue seems to be occuring earlier than that. Tgo is around 59 seconds before suddently going crazy, with the fr term blowing up too. Very strange behaviour as the plot for Tgo is linear up until this point.

[Rohit007]

can you please share craft file for the same (shown in video for PEG)

[Reddy]

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  

Edited January 17, 2021 by Reddy

[Dman979]

Moved to Add-On Releases.

Congrats on full release!

[Drew Kerman]

Nice to see work still being done here. It's def a thing I'm considering for future missions with more advanced designs that will benefit from something like this

[La Piante]

is this mod's working now ?

[Razgriz1]

On 5/4/2021 at 5:39 AM, La Piante said:

is this mod's working now ?

Yes, this still works with the current version of kOS.

[Reddy]

@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

Edited May 10, 2021 by Reddy

[Razgriz1]

18 hours ago, Reddy said:

@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 haven't had any issues at all. Your code is pretty solid and very clean. I've tweaked it a bit for my personal use, and incorporated the Aram1D's pitch table ascent mode into my own version but the base code still works great.

I'm glad to hear you're still working on it! Any hints on what 1.3 will change/add?

[Reddy]

9 minutes ago, Razgriz1 said:

Any hints on what 1.3 will change/add?

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]

Having more engine-specific throttling control would be very nice.  I'm happy to help you verify that it's still working on the current kOS version again. They do a pretty good job of maintaining backwards-compatibility over there so hopefully it won't be an issue.

Perhaps my biggest vote for UI improvement would be something along the lines of ETA to upcoming events or something along those lines. 

1 hour ago, Reddy said:

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.

What about his PR do you think needs tweaking? I may be able to help with that if needed. I've got a somewhat modified version of his PR in my own version of the script, as well as the ability to steer the craft so that the thrust vector is pointing through the CoM toward the steering direction as opposed to just the facing vector. This is useful for flying the shuttle after booster sep, especially through the roll to heads up maneuver.

[Reddy]

1 hour ago, Razgriz1 said:

What about his PR do you think needs tweaking?

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.

1 hour ago, Razgriz1 said:

ETA to upcoming events

Something like a time-table of events, past and future, with something like a marker denoting where we are?

1 hour ago, Razgriz1 said:

ability to steer the craft so that the thrust vector is pointing through the CoM toward the steering direction

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.

Edited May 11, 2021 by Reddy

[Razgriz1]

32 minutes ago, Reddy said:

Something like a time-table of events, past and future, with something like a marker denoting where we are?

That would definitely be cool. Very launch livestream haha!

32 minutes ago, Reddy said:

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 that's possible.

It's definitely a somewhat niche requirement. The Stock Shuttle Orbiter (which is what I fly) has a bit of a hack that rotates the command direction 15 degrees down, but kOS does not like having the command point switch partway through launch, and it wasn't quite the right angle for the OMS engines, so I thought I'd try and solve it myself. I'm actually fairly proud of my solution. It turned out to be a lot easier than I thought it would be. Basically I just get the position of each of the engines and weights them by their max thrust and sum those vectors. That gives you the offset vector that you need to use instead of your facing vector for steering. Then  you just rotate the desired steering direction around the cross product of your forward vector and that offset thrust vector by the angle between them, and lock your steering to that new direction instead of the initial direction.

My code for that is at https://github.com/Jakathan/shuttle-guidance. Specifically the function is shuttleSteerDir(<direction>) in lib_shuttle_mnv.ks. It's as simple as wrapping whatever steering direction you want to use in the the function and it should take care of the calculation. It should be able to handle both pitch and yaw offset, though I've really only done significant testing on the pitch offset since that's what's required for the shuttle. I need to do more OMS engine out scenarios to test it more.

p.s. Don't look at the entry guidance portion of the repository, it's not very good 

 

Edited May 11, 2021 by Razgriz1

[La Piante]

thank you @Razgriz1

I have a problem, after i'm selecting the target, I start the guidance whith KOS but the programme is not auto time warping. Anybody know why ?

 

[Razgriz1]

9 hours ago, La Piante said:

the programme is not auto time warping

At the risk of speaking for Reddy again, this code does not do any sort of auto-warping.

[La Piante]

aaaaahhh ok thank you .... I try to launch the space shuttle to the iss orbit whith this programme but when  i'm arriving near to the target AP, my shuttle start to flip in every side and its impossible for me to get into orbit... I tried a lot of settings and every time it's flipping . I think i'm doing somthings wrong ...

Spoiler

GLOBAL mission IS LEXICON(
					"payload", 24844,
					"periapsis", 180,
					"apoapsis", 200,
					"inclination", 65,
					"LAN", 100,
					"direction", "north"
).

 

Spoiler

GLOBAL vehicle IS LIST(
					LEXICON(
						"name", "External Fuel Tank",
						"massTotal", 767475,
						"massFuel", 631381+106094,
						"gLim", 3,
						"minThrottle", 0.65,
						"engines", LIST(LEXICON("isp", 453, "thrust", 3*2090000)),
						"staging", LEXICON(
										"jettison", FALSE,
										"ignition", FALSE
										)
					)
).
GLOBAL sequence IS LIST(
					LEXICON("time", -4, "type", "stage", "message", "RD-180 ignition"),
					LEXICON("time", 0, "type", "stage", "message", "LIFTOFF"),
					LEXICON("time", 6, "type", "roll", "angle", 180),
					LEXICON("time", 125, "type", "stage", "message", "SRB jettison"),
					LEXICON("time", 200, "type", "roll", "angle", 0)
).
GLOBAL controls IS LEXICON(
					"launchTimeAdvance", 150,
					"verticalAscentTime", 11,
					"pitchOverAngle", 4,
					"upfgActivation", 130
).
SET STEERINGMANAGER:ROLLTS TO 10.
SWITCH TO 0.
CLEARSCREEN.

 

thanks for your help 

[Razgriz1]

1 hour ago, La Piante said:

my shuttle

Is it an actual shuttle-style spacecraft where the thrust vector is not necessarily in line with the forward vector of the vehicle? If so, you can't really use this code as it currently is to fly a ship like that, as the estimation the script does assumes that your thrust is all acting in the same direction that your ship is facing. If it's like the Space Shuttle, and you don't have a way of compensating for that, then the script will think you're getting less thrust than you actually are, due to some of it acting perpendicular to your facing vector. This invalidates the scripts calculations, and thus it cannot plan its burn duration or attitude correctly. This doesn't really become apparent until the end of the burn, where it's trying to fine-tune the orbital insertion.

That's why I wrote the function I was describing above

23 hours ago, Razgriz1 said:

Specifically the function is shuttleSteerDir(<direction>)

There's also just some inherent issues with kOS's built in steering if you're trying to fly vehicles where the thrust is significantly offset if you don't appropriately correct for it.