Project Multistage2015 - Development Thread

[4throck]

My first stage has 4 rockets, so I have 4 Eng_x=(xx,yy,zz) commands.
How to use Eng_dir=(xx,yy,zz) with that ?

 

[fred18]

Since you know the engine diameter, I think that a good goal for multistage2015 would be to model nozzle over-expansion (i.e. thrust increase with altitude). I can help you with the math.

I think this is already modelled in orbiter, but I don't know exactly how to appy this to MS2015 since isp is calculated from thrust and burntime (vinka did this and I cannot change this or we will loose retrocompatibility completely)

from oapi docs:

THRUSTER_HANDLE VESSEL::CreateThruster ( const VECTOR3 & pos,
const VECTOR3 & dir,
double maxth0,
PROPELLANT_HANDLE hp = NULL,
double isp0 = 0.0,
double isp_ref = 0.0,
double p_ref = 101.4e3
) const

Add a logical thruster definition for the vessel.


Parameters:
pos thrust force attack point in vessel coordinates [m]
dir thrust force direction in vessel coordinates (normalised)
maxth0 max. vacuum thrust rating [N]
hp propellant resource feeding the thruster
isp0 vacuum fuel-specific impulse (Isp) [m/s]
isp_ref Isp value at reference pressure p_ref [m/s]
p_ref reference pressure for Isp_ref [Pa]

Returns:
Thruster identifier
Note:
The fuel-specific impulse defines how much thrust is produced by burning 1kg of fuel per second. If the Isp level is not specified or is = 0, a default value is used (see SetISP()).
To define the thrust and Isp ratings to be pressure-dependent, specify an isp_ref value > 0, and set p_ref to the corresponding atmospheric pressure. Thrust and Isp at pressure p will then be calculated as

[math]
{Isp}(p) = \mathrm{Isp}_0(1-p\eta), [/math]
[math]{Th}(p) = {Th}_0(1-p\eta), [/math] [math]{where}\qquad \eta = \frac{{Isp}_0 - {Isp}_{ref}}{p_{ref} {Isp}_0} [/math]



If isp_ref = 0 then no pressure-dependency is assumed [math](\eta=0). [/math]

My first stage has 4 rockets, so I have 4 Eng_x=(xx,yy,zz) commands.
How to use Eng_dir=(xx,yy,zz) with that ?

The eng_dir parameter is shared among all the engines of the stage/booster group. if your first stage has 4 engines, you need to write only once eng_dir=... and all the 4 engines of that stage will have the indicated orientation.

 

[4throck]

OK got it.
For Little Joe I need the engines to point a bit outward. Also there are 4 small rockets that only burn for a few seconds.

Looks like I'll have to set it up with invisible meshes and boosters.
Sounds like fun :hmm:

 

[fred18]

NEW UPDATE

Changelog:
- interstages now should save/restore correctly
- reignition parameter should now be persistent also when saving/restoring a scenario
- some small documentation update

I think this is almost ready for official release, I hope there won't be much more issues!

In the meantime I started to work on the beta version!

I was thinking: if I can make this work in the beta, then suddenly a huge number of launchers and addons will become available in the beta as well! I think that now this becomes a mission :yes:

 

[4throck]

Yes, fix those touchdown point and Orbiter Beta starts to come alive

Just to say that my initial tests of Little Joe, with the proper booster + main engines setup and launch angle are reaching the historical altitude. Spot on!

 

[fred18]

We're almost there also for the beta (i'm not including orbiter sound yet, I know it has some issues with the beta, so it's there sitting for the time being)

the very last thing I'm working on, and then I'm done, it's the generation of a gravity turn table which rensembles the results of all the iterations done, and show it to the user (it will generate a separate text file and it will be available in the MFD)

This will allow users to have more precise idea and an orientation of what gravity turn initial pitch choose.

 

[boogabooga]

It seems that the reignitable=0 flag only applies if the autopilot has been activated.

Another fun thing to add would be burn to completion, where the stage can't be turned off once lit. This is the case with many solid upper stages.

 

[ISProgram]

Is it possible to delay stage separation after engines are shut down, as is done with payloads? Or does the stage separation occur immediately after propellant in the firing stage is exhausted?

 

[fred18]

It seems that the reignitable=0 flag only applies if the autopilot has been activated.

It seems like that because I had to set a minimum time of waiting for the not reignition. At the moment is 3 seconds but I will turn it down to 1 second or half a second. Try to wait 3 secs and then reignite, it should not catch fire again.

Another fun thing to add would be burn to completion, where the stage can't be turned off once lit. This is the case with many solid upper stages.

I thought about this connected to the reignitable flag, but honestly I was a bit scared of messing up some working features to implement this because I have to force engines at full thrust even if the users presses the cutoff button or if an mfd tries to shut it down. I'll see if it's not too messy to do.

Is it possible to delay stage separation after engines are shut down, as is done with payloads? Or does the stage separation occur immediately after propellant in the firing stage is exhausted?

It is possible through guidance (file or MFD). you can disable autojettison and then call the jettison program whenever you like. Or you can set the guidance so the main engines of a stage cutoff just moments before finishing the fuel, and then you can again call the jettison program at your wish.

 

[Interceptor]

Hey Fred18,can you please give an example of the G limit option,I don't understand how this works,because the AP doesn't throttle back up again.

 

[boogabooga]

You probably wouldn't want to throttle back up. Acceleration can get very high toward the end of a stage's burn because the stack is light.The G limit option keeps it from being insane. The throttle will go back to 100% after staging.

I will have an example soon.


Edit:

Okay, here is an Atlas V 421 that I have been working on as a demo of multistage2015. Thanks to BrianJ.

Requires:
[ame="http://www.orbithangar.com/searchid.php?ID=3711"]MRO[/ame]
[ame="http://www.orbithangar.com/searchid.php?ID=6473"]Solar Probe[/ame]
[ame="http://www.orbithangar.com/searchid.php?ID=3687"]LRO / LCROSS[/ame]

I found it necessary to adjust the 4th "height" from 35km to 50 km. Also, I manually adjusted the 1st pitch angle.

 

[fred18]

wow boogabooga that's amazing! thank you!!!

i tested it and it works perfectly! Also I had for the first time the opportunity to test the telemetry reference made by someone else, and I enjoyed it much!

I found it necessary to adjust the 4th "height" from 35km to 50 km. Also, I manually adjusted the 1st pitch angle.

I think that this is why the target orbit is 300x300 km, that is quite high as direct insertion. the default conditions are thought for a perigee from about 160 km to about 230 km. But your modifications are perfect, the flight is very smooth! Did it take long to achieve it?

@Interceptor: what boogabooga said and the examples are exact, from the guide:

Glimit(xx): When triggered will spend 250 seconds checking if the vehicle is accelerating more than xx*G. If so it trhottles down the vehicle (warning, it will not throttle it back by itself)

 

[boogabooga]

The lower energy orbit is not necessarily the most efficient to reach.

The reason for the high orbit is that the second stage burn takes ~10 minutes. The Centaur can't hold itself up for that long with its relativley puny engine: https://en.wikipedia.org/wiki/Gravity_drag

The first stage has high acceleration and gravity losses are minimal. By lobbing the second stage with the first, you give the former time to reach orbital velocity before it comes back down again.

Also, it seems that one should avoid entering the closed loop phase very near a staging event as this seems to cause instability in the guidance routine.

 

[fred18]

yep, you're absolutely right, let's say I took quite a standard case as reference but I left to the users the freedom to personalize almost all the parameters (also peg pitch limit could be useful to change in case of needing)

I was thinking that it could be good to find someone willing to make a guide/tutorial for tweaking the launch parameters, maybe I found the best candidate :yes:

---------- Post added at 17:41 ---------- Previous post was at 14:30 ----------

In the meantime I spent a lot of time in the last days trying to have a reliable pitch table for the gravity turn. I changed the algorithm and I created one of my own. I refined everything but still it's too dependent on too small corrections for such an estimation. So I will use this new algorithm for determining the "suggested" Gravity Turn Initial Pitch (the single result is ok), but I won't add the table generation, since it will be too inaccurate and could be misleading. Actually I realized that it is so sensitive to even decimals of degrees that the more I refine the evaluation, the less it is precise because it starts to depend on too many factors that are difficult to predict.

I'll clean up the code from this "table generation" thing now, so I can release the module sooner for both 2010P1 and the new beta.

Actually I'm finding some difficulties with the new beta relevant to touchdown points. They are set correctly (also relevant to the vertical_angle parameter) but when the rocket starts to ignite its engines instead of staying there where it is it starts to dance all over the place... I've tried a lot of values for stiffness and damping but I can't find a proper formula up to now...

 

[boogabooga]

I have also notice that the indicated "predicted MECO" time steadily increases during the flight. I would expect that that this should stay fairly constant.

Perhaps some loss is not being considered?

 

[K_Jameson]

Perhaps the predicted MECO increases as the throttle goes down for G reduction (and thus the burn time rises). An hypothesis.

 

[fred18]

Actually gravity drag is not computed. That's the reason why predicted MECO keeps increasing if pitch is not aligned with velocity. I don't know if this is refineable, I will look at it.

 

[Interceptor]

Nice job with the Atlas421 sceneario boogbooga,the orbit was spot on right at 300X300,but I did notice something you had set the Glimit to 4.6,but in the load mfd it showed up to 4.8,not a big deal,but just was wondering.Thanks

 

[boogabooga]

Nice job with the Atlas421 sceneario boogbooga,the orbit was spot on right at 300X300,but I did notice something you had set the Glimit to 4.6,but in the load mfd it showed up to 4.8,not a big deal,but just was wondering.Thanks

That the orbit ended up spot on is all due to fred18. My contribution was smoothness and efficiency.

I can't do anything about the Glimit. My guess is the throttle couldn't quite keep up with the rate that mass was being lost. :shrug:
Actually, I think it was quite close.

Actually gravity drag is not computed. That's the reason why predicted MECO keeps increasing if pitch is not aligned with velocity. I don't know if this is refineable, I will look at it.

I haven't looked at the reference material yet but, perhaps for display purposes you could just scale the remaining time of flight by 1/cosine of the current pitch angle? But perhaps not for the first stage, and protect against divide by 0 if the pitch is vertical. Make sense? Would that work?

 

[Interceptor]

Yeah fred18,you done a great job perfecting this,thanks once again.