PEGAS - Powered Explicit Guidance Ascent System - devlog

[Reddy]

As of 25c9e84 the kerboscript version of UPFG has been completed and passes numerical consistency tests between MATLAB and kOS. Proof in pic attached:

Minor differences may result from truncating of some of the input values: MATLAB operates on high precision data, but unless told otherwise it will output only 4 decimal places. I may have just blindly copied some truncated/rounded value into kOS instead of exporting a precise version. Fortunately, the difference is insignificant from practical point of view.

This only tested internal correctness of the port: I ran the script on a vehicle consisting of a single part (probe core with kOS module), put in the same data MATLAB uses and compared the output with what the MATLAB version would compute. Next step is to integrate the algorithm with the KSP coordinate frame and perform some tests on an actual, live vehicle. I updated the first post accordingly.

[Dman979]

I don't want to jinx it, but you're coming up on a year working on PEGAS, and that's not counting the work you did before this thread!

Quality comes first! (Well, after real life, of course.)

[Ilpez]

Finally an update #yey!

Just want you to know, that i already port your UPFG to kRPC(Without multistage feature), and it works !

At least now you know that your code works in KSP

[Ilpez]

On 3/30/2017 at 5:20 AM, Reddy said:

As of 25c9e84 the kerboscript version of UPFG has been completed and passes numerical consistency tests between MATLAB and kOS. Proof in pic attached:

Minor differences may result from truncating of some of the input values: MATLAB operates on high precision data, but unless told otherwise it will output only 4 decimal places. I may have just blindly copied some truncated/rounded value into kOS instead of exporting a precise version. Fortunately, the difference is insignificant from practical point of view.

This only tested internal correctness of the port: I ran the script on a vehicle consisting of a single part (probe core with kOS module), put in the same data MATLAB uses and compared the output with what the MATLAB version would compute. Next step is to integrate the algorithm with the KSP coordinate frame and perform some tests on an actual, live vehicle. I updated the first post accordingly.

As a reminder, pitch in KSP is a function of SIN (value between 90 and -90)
i don't know about yaw, but i use atan2 in my kRPC version of your UPFG

[Reddy]

@Dman979 Real life is exactly the reason why this is taking so damn long. I am a researcher in pursuit of PhD (machine vision and deep learning); sometimes after spending a day in my lab coding, even more coding is the last thing I want to do right after coming back from work As poor excuse as that is, I haven't played KSP at all in well over a year!

But I'm going to finish this soon. Since the prototype is working, I am now very confident PEGAS is going to be completed shortly. I don't wanna jinx it further and definitely say "by the end of April", but I am hoping for just that. After all, I am now more experienced in kOS and KSP reference frames than I was when writing the first PEGAS - and those are pretty much the only problems left to solve now The plan is to release a basic working version of kOS script package, so that everyone can try it on their own vehicles, and then gradually introduce features.

@Ilpez I sent you a private message.

[Reddy]

Quick update. I have the UPFG running in KSP, along with some infrastructure code for launch window calculation, staging sequence management (including ullage), coordinate conversions (I decided not to reimplement UPFG for KSP reference frame but instead convert KSP-style coordinates into MATLAB-style) - everything for a most basic launch. For proof of progress, here's a little video of it performing in vanilla KSP: https://www.youtube.com/watch?v=TI9F0omwPjM (please note it is private, just for this forum and anyone following the thread - I humbly request you don't publish it anywhere else).

TODOs for now involve coding support for constant-acceleration phases and cleaning up the hacky pieces of code (although most of it is release-ready, you might've noticed some stagnation in my repository because a few crucial bits still need refactoring/polishing). For an official release I want to prepare a better demo video (in RO of course) and some tutorials - in order to run PEGAS you will have to perform some manual configuration (likely involving some rocket maths ). We're almost there guys, hold on with me just a little bit more!

EDIT: Mind the video description. I tried adding adnotations but turns out youtube does not allow that anymore.

Edited May 26, 2017 by Reddy

[Reddy]

I just wanted to thank Squad and Steam for a forcibly pushed update which ruined my install and my saves and wasted several hours of my time on recovery of the data and (partial) reconstruction of my universe.

Edited May 30, 2017 by Reddy

[Slainte Maith]

Where does the latest code for this live nowadays?  I only see pegas_upfg and pegas.cser--which just do "program ended" when you run them.
(I'm sure I'm missing something)

 

Edited June 6, 2017 by Slainte Maith

[Slainte Maith]

Nevermind.  I was missing something.  My brain.  I found it.  =)  Great work!

 

[Slainte Maith]

Okay, so how would the boot file look for, say, an Atlas or sputnik rocket which doesn't stage normally--but only drops boosters while the center engine continues to burn?  I've been playing with the values, but the logic doesn't seem to be set up for it.

[Dman979]

Well, I'd guess that you need to calculate the pitch/time program yourself.

But you can include those staging events, if I understood what @Reddy is doing correctly.

[Reddy]

No worries @Slainte Maith. The front page hasn't been updated in a while but I don't want to waste time on tiny changes to it right now, with the big release just around the corner. Right now you are right, a lot of things are missing - or maybe I should say, only available in my local repository

@Slainte Maith, @Dman979, you will not need a pitch/time program. I figured out something much simpler than that: you will we able to specify vertical ascent time and initial pitch angle - something akin to what Ferram mentions in his Launch Vehicle tutorial. PEGAS will hold a zero-AoA trajectory until the UPFG kicks in, allowing for a fully automatic launch without the need to perform complex calculations in MATLAB. I realize only a tiny handful of people would be able (and willing to!) do something like that. As to staging events, yes you will be able to bind spacebar to time. This will be enough for SRB or fairing jettison events, but for main stages I have something better in store. Since those will potentially require performing an ullage burn, you will have the option to have ullage motors automatically activate (or deactivate, if you prefer RCS push instead of dedicated SRB motors). Okay enough talking for me, time to get back to code!

[Slainte Maith]

Thank you so much!  I look forward to trying your hard work!

 

[Reddy]

The moment we've all been waiting for has finally come - PEGAS is now complete. I think it is capable of running any vehicles at this moment, as I tested both on a high-TWR Atlas V and low-TWR and more complex Saturn V with success. Now the most difficult test before it: whatever you guys can come up with

Link to the repository: github.com/Noiredd/PEGAS - you need to get the kOS folder, optionally with the example boot files. Link to the tutorials are on the front page, be sure to check those out. I'm not doing any mechjeb-level magic, so you'll need to provide plenty of information yourself. Yes, some basics of kOS might be useful, if not necessary. Also, do watch my video, as it makes a pretty good explanation of what PEGAS now is and how it works - as well as a progress report since my last messages:

Thank you all for staying with me this whole time. I hope you will get your vehicles flying with PEGAS successfully In case of any problems - you can leave me messages here, or directly at github.

One word before I close this post: quite likely this is not the end of the route for PEGAS. And I don't mean just the fact that I'll be providing bugfixes and other forms of support. While working on it, I think I figured out a way to turn it into a general orbital maneuver executor. Most of the facilities needed for that are already there, so I think it's quite possible. I also have an idea for doing landing using it - though this is a much more remote vision. Anyway, for now I'm taking a little break from it (except support for the existing version) - but I will surely let you know if I move it into a new direction.

[Dman979]

That's a great video. It really explains how the PEGAS code works. Beleive it or not, I had no idea until now how it worked.

It also reminded me of this one.

 

[Slainte Maith]

Interestingly, there's a PEGAS module also being worked on for MechJeb.  It's been released in the latest dev version.

 

[Starwaster]

7 hours ago, Slainte Maith said:

Interestingly, there's a PEGAS module also being worked on for MechJeb.  It's been released in the latest dev version.

 

Except that it's based on Atlas / Centaur instead of the newer guidance used by the shuttle and others.

[Reddy]

15 hours ago, Slainte Maith said:

Interestingly, there's a PEGAS module also being worked on for MechJeb.  It's been released in the latest dev version.

Indeed that is interesting... care to share a link? I couldn't find it anywhere. I know they use PEG, which is unsurprising, but PEGAS?

EDIT: Starwaster cleared it up. By the way, I also coded the basic formulation of Atlas/Centaur PEG in an earlier version of PEGAS (now only to be found in my prototype repository).

Edited July 31, 2017 by Reddy

[Jim DiGriz]

@Reddy i'm wondering if this line is a bug in the MATLAB code?

https://github.com/Noiredd/PEGAS-MATLAB/blob/1ff2b11e8b8e860e0c5d041bf1bcfa5056d06d87/MATLAB/unifiedPoweredFlightGuidance.m#L228

I don't see that in section 4.8 or 4.8.1 (or, i think the other 4.8.x blocks) of the UPFG No 24 doc.  Although it's still early here and my coffee may not be working yet...

EDIT:  well deleting that line from my code makes my yaw steering problems much worse and it doesn't fly right at all...

Edited August 8, 2017 by Jim DiGriz

[Reddy]

Ha, this is a very peculiar line, and I completely understand your confusion. Indeed, it does not appear in the original document - I added it myself as one of several tweaks I came up with during a painstaking, months-long process of debugging UPFG. Without the line, I had similar problems to yours, the algorithm performed much worse - unfortunately, I can't really explain why.

At least I can tell you what it does: in general, it enforces the desired position, r_d, to lie in the target orbit plane given by vector i_y. What happens here is we take our predicted position r_p and subtract the off-plane component from it - what remains, is only the in-plane component. Then we adjust its magnitude (line 229), obtaining a new desired position which not only has the right altitude, but also lies in the right plane. This makes the algorithm converge faster and on a more reasonable solution. Personally, I have a much better understanding of this modification, than how the original algorithm actually worked - and how could it work without it.

[Jim DiGriz]

so i physically (ew) went to the engineering library on campus today and made a hard photocopy (yuck) of https://ntrs.nasa.gov/search.jsp?R=19790048206

page 17, equation 36 is 

rd = rd unit [ rp - ( rp dot iy ) iy ]

they applied that to rd instead of mutating rp, but rp isn't state that recycles so i don't think it matters.

their corrector is also different, after CSE they define:

vp = v + vthrust + vgrav

vmiss = vp - vd

vgo = vgo - 1.0 * vmiss

where 1.0 is a damping factor with a note that it can be set to 1.0 for ascents.  i don't see where vbias is used at all.

their vthrust and rthrust is also substantially different, and i think they're using a more normal form of the linear tangent steering law, still digesting all this though...

[Dman979]

9 hours ago, Jim DiGriz said:

so i physically (ew) went to the engineering library on campus today and made a hard photocopy (yuck) of https://ntrs.nasa.gov/search.jsp?R=19790048206

Get that blasphemous talk away! Physical copies are amazing! They don't run out of battery! You can write on them! Fold them!

Anyway, good on you for doing the research. In practical terms, what does it mean?

[Starwaster]

1 hour ago, Dman979 said:

Get that blasphemous talk away! Physical copies are amazing! They don't run out of battery! You can write on them! Fold them!

Anyway, good on you for doing the research. In practical terms, what does it mean?

Yes but you can't copy and paste them onto an adjacent computer / tablet....

(I should know, I tried once in a moment of stupefaction wherein it seemed logical to me that I should have been able to do so... I sat there for several seconds looking from one to the other wondering why it wasn't possible yet)

[Starwaster]

@Jim DiGriz Would you be willing to share a scan of that document?

[Jim DiGriz]

4 hours ago, Dman979 said:

Anyway, good on you for doing the research. In practical terms, what does it mean?

Reddy came up with the right fix for that problem.

3 hours ago, Starwaster said:

@Jim DiGriz Would you be willing to share a scan of that document?

Yeah, although it'll have to be a scan of a scan.  Next time I'll be smart and bring a USB drive, but that was my first time at the university library in 20 years...