Noiredd / PEGAS

Powered Explicit Guidance Ascent System - a KSP & RO autopilot using the Space Shuttle guidance algorithm, UPFG
http://forum.kerbalspaceprogram.com/index.php?/topic/142213-pegas-powered-explicit-guidance-ascent-system-devlog
MIT License
114 stars 31 forks source link

Custom engine spool-up config #48

Open Noiredd opened 2 years ago

Noiredd commented 2 years ago

As first observed in #47, RO engines sometimes take so long that the thrust watchdog mistakes this for a lack-of-thrust event and terminates the flight. This is however only the most extreme variant of a more common scenario.

PEGAS does not account for engine spool-up in any way. This means when the ignition sub-event occurs, it is assumed that the engine is "on", produces maximum thrust amd consumes maximum fuel. This is obviously untrue, as several seconds can pass between "ignition" and "max thrust". As a result of this delay, vehicle uses less fuel per unit of time than PEGAS calculates. Consequently, the actual burn time of the stage will be longer, potentially causing issues with staging (e.g. accidental hot-staging).

Potential solution might involve adding an extra key to the engine config to allow specifying the spool-up time per engine. PEGAS could obey this by introducing an additional flag, e.g. engineIgnited which would be set after this spool-up delay, triggering all the internal calculations (i.e. keeping track of fuel consumption) which would otherwise be suspended until then. What do you think about this, @theLXMB?

(Now perhaps I'm reaching too far into the future but this might just allow determining the complete flight plan even before lift-off - at least for all non-sustainer vehicles. I've always wanted to do away with initializeVehicleForUPFG or execute it as early as possible, something that would be even more cool from the point of view of the flight plan print out 🤔)

theLXMB commented 2 years ago

Telling PEGAS the spool up time per engine sounds like a pretty straightforward idea to me, so I think your potential solution could be quite elegant. The underlying problem could very well be why so many of my tests have experienced unwanted hot staging :D

I'm getting two ideas from this, correct me if I'm wrong here: Either PEGAS resumes UPFG calculations AFTER the preset spool up time and ignores everything between staging and full thrust, OR while spooling up it assumes engine performance as a fraction of full thrust and isp. As in, if an engine needs 5s to go to full thrust, i.e 240kN @ 468s isp, at 2.5s this virtual stage has 120kN and reduced efficiency. Although this linear scaling probably wouldn't make much sense in the real world. Would an engine have 24kN @ 46.8s while at 10%? There's also RCS/SRB ullage thrust and fuel consumption to consider, but this could be so minor that the loop simply glosses over it.

Here is something else: Engine bell extension RL-10 style ;) This too takes time between ignition (as in KSP staging in the engine) and startup.

I'm not familiar with how RO handles spool up, as I actually don't use it and simply added the stock jet engine response time to those rocket engine configs I use. So with my rockets I potentially always have the full range of throttling, even though outside of startup and stop anything less than 40% never happens. Isp obviously doesn't change with the throttle value in this case.. An RO engine would probably start at 40% and then go to full thrust.

So, technically with the script having a full understanding of every aspect of vehicle performance, this could be such a great solution for another problem: spool down time. At finalisation, PEGAS holds attitude, assuming thrust instantly goes to zero, which of course no engine can do. So I "undershoot" any Orbit I want to achieve by trial and error to make the residual thrust get the vehicle where I want it to go.

We are nearing having a launch being basically on rails here 😁