Project Multistage2015 - Development Thread

[Donamy]

That's Ok, Maybe it can be done via genericvessel.

 

[Cosmic Penguin]

As someone who has tweaked various multistage autopilot scripts throughout the years, I wonder if the new version can have these abilities:

1. The option to specify the final stage of the rocket to make only one burn (i.e. direct ascent) - some real life rockets' uppermost stage cannot re-ignite (e.g. the HM7B engine on Ariane 5 ECA's second stage) and it has to make the target orbit without re-igniting, even to GTO and beyond. Unfortunately most of the autopilot program used right now probably can't do such calculations. Can the autopilot be tweaked to fly like this?

2. There's one function that I would like to see - can the "argument of perigee/apogee" (i.e. the angle of the point of perigee/apogee from the equator, shown in Orbit MFD as the angle between the circle dots and the square dots) be included in the program? Many launches, especially those targeting geostationary transfer orbit, will set this value as 0 or 180 degrees (i.e. the circle and square dots would overlap in Map MFD), as this means that the satellite can use the least fuel to lower its inclination at its highest point after launch.

This requires the autopilot to calculate which time to fire at the LEO parking orbit with the whole burn duration evenly spread north and south of the equator. Is it possible to do so?

Thank you, and I am very excited to see a new version of MS coming soon! :banana:

 

[fred18]

1. The option to specify the final stage of the rocket to make only one burn (i.e. direct ascent) - some real life rockets' uppermost stage cannot re-ignite (e.g. the HM7B engine on Ariane 5 ECA's second stage) and it has to make the target orbit without re-igniting, even to GTO and beyond. Unfortunately most of the autopilot program used right now probably can't do such calculations. Can the autopilot be tweaked to fly like this?

Mmmm, I can add a call in the ini, "reignitable=1 or 0" default is 1. If set to 0 the specified stage cannot be reignited once turned off. Would that do the trick that you mean?

2. There's one function that I would like to see - can the "argument of perigee/apogee" (i.e. the angle of the point of perigee/apogee from the equator, shown in Orbit MFD as the angle between the circle dots and the square dots) be included in the program? Many launches, especially those targeting geostationary transfer orbit, will set this value as 0 or 180 degrees (i.e. the circle and square dots would overlap in Map MFD), as this means that the satellite can use the least fuel to lower its inclination at its highest point after launch.

This requires the autopilot to calculate which time to fire at the LEO parking orbit with the whole burn duration evenly spread north and south of the equator. Is it possible to do so?

Mmm. This seems a bit hard to do, especially because Multistage2015 is a general module, so its autopilot must fit all the possible rockets. Maybe with a math document I can think of something but for this release I see this almost impossible to do. It is a combination of launch latitude, target inclination and target orbit, which are all inputed by users. I think that for this purpose maybe a separate tool can be developed to provide the user with the appropriate inputs to plug into ms2015 autopilot, what do you think?

 

[Cosmic Penguin]

Mmmm, I can add a call in the ini, "reignitable=1 or 0" default is 1. If set to 0 the specified stage cannot be reignited once turned off. Would that do the trick that you mean?



Mmm. This seems a bit hard to do, especially because Multistage2015 is a general module, so its autopilot must fit all the possible rockets. Maybe with a math document I can think of something but for this release I see this almost impossible to do. It is a combination of launch latitude, target inclination and target orbit, which are all inputed by users. I think that for this purpose maybe a separate tool can be developed to provide the user with the appropriate inputs to plug into ms2015 autopilot, what do you think?

1. Well, yes that's the first part. I guess in a later release it might be possible for the autopilot to calculate how to fly given a certain target orbit parameter and reignitable=0? I know it might be very difficult... (can anyone who have such programming experience comment on that?)

2. Thanks for considering in the far term. I don't think it would be easy to calculate that automatically anyway....

 

[boogabooga]

You gave me a great point! I implemented it!

Now thrust of live payload is added, rotated and offset. I think that this opens up a big set of new opportunities for developers that can play with live payloads!

For example space shuttle can be implemented with SRBs as live payloads now or you can put an invisible Multistage under another craft to use the Multistage autopilot etc.

Note: Only main thruster are rendered, RCS thrusters are not.

Not true anymore: linear RCS is accounted

So you can have a live Eridanus?

 

[fred18]

1. Well, yes that's the first part. I guess in a later release it might be possible for the autopilot to calculate how to fly given a certain target orbit parameter and reignitable=0? I know it might be very difficult... (can anyone who have such programming experience comment on that?)

Wait wait wait: the target orbit is already reached with that!
The new autopilot is a PEG derived, working with original nasa equations (a math nightmare to solve, but finally it's done). There is no coast phase while flying to orbit, no waiting for apogee and circularization burn etc, it's a direct insertion flight from ground to final orbit, like launch MFD but working with multistage as well! So the reignitable option can be added, but I think that your purpose is already achieved here!

2. Thanks for considering in the far term. I don't think it would be easy to calculate that automatically anyway....

agree, it's a mess :lol:

So you can have a live Eridanus?

Oh yes! :thumbup:

For example I'm making tests for other effects in this moment with the space shuttle provided by vinka as example and the shuttle is live, I can simply jump in and enjoy the flight from there

 

[4throck]

Sounds good, really good indeed.

 

[IronRain]

This project really excites me! Keep up the good work :thumbup:

 

[kerlix]

How will this be implemented into addons that currently use the old MS? Is it just a simple unzip and replace the old one? Or will addon guidance files have to be rewritten from scratch?


Sent from my iPhone using Tapatalk

 

[fred18]

How will this be implemented into addons that currently use the old MS? Is it just a simple unzip and replace the old one? Or will addon guidance files have to be rewritten from scratch?

MS2015 is totally backward compatible with the old MS! All the old Vinka autopilot functions are implemented and working. From now on you can simply choose which method you prefer to use, but alll the old addons will simply ... work


In the meantime I attach here a screenshot of the first two screens of MS2015 MFD, general info and Fuel Display

 

[Michael_Chr]

Wow... Fred
I´m so impressed with the speed and apparent "ease" you implement new things. This is truly going to be one of the "core-addons" for Orbiter in the years to come and a very important step in keeping Orbiter a viable simulation platform in the future. A truly "well-done" from here
------------
Just have to add this...I can see you added total payload mass in the General info display. This is an important feedback since it tells what the your DLL "sees". If you start to ad more complicated payload structures with attached "sub payloads" in Velcro is seems that some of this payload is unseen by the velcro DLL. It might be an intrinsic feature of Orbiter but still ...for flight planning purposes its important to have this feedback (I compensate by adding a "ghost" payload with a null mesh giving the correct overall payload mass).
------------
And here I go again
Would it be possible in the HUD to put the MS2015 Autopilot projected Flight Path vector. Adding this with a capability to disconnect (and possibly reconnect?) the autopilot gives a possibility to "handfly" an ascent. Even though this is highly inaccurate fidelity wise it would be great fun. But moreover...you also get a feedback if the system is at all capable of performing the maneuvers required by the autopilot(i.e. the defined attitude thrust is to low). Maybe the roll -cueing right after ignition could be done via a dedicated MFD screen if its tricky to show that on the hud?

 

[4throck]

Looking really good! You have all the mission control data there.

 

[fred18]

Wow... Fred
I´m so impressed with the speed and apparent "ease" you implement new things. This is truly going to be one of the "core-addons" for Orbiter in the years to come and a very important step in keeping Orbiter a viable simulation platform in the future. A truly "well-done" from here

Thanks!! :tiphat:

Just have to add this...I can see you added total payload mass in the General info display. This is an important feedback since it tells what the your DLL "sees". If you start to ad more complicated payload structures with attached "sub payloads" in Velcro is seems that some of this payload is unseen by the velcro DLL. It might be an intrinsic feature of Orbiter but still ...for flight planning purposes its important to have this feedback (I compensate by adding a "ghost" payload with a null mesh giving the correct overall payload mass).

In Ms2015 for live payloads there is the possibility to manual override the payload weight value, in order to simulate ballast or other effects :thumbup:

And here I go again
Would it be possible in the HUD to put the MS2015 Autopilot projected Flight Path vector. Adding this with a capability to disconnect (and possibly reconnect?) the autopilot gives a possibility to "handfly" an ascent. Even though this is highly inaccurate fidelity wise it would be great fun. But moreover...you also get a feedback if the system is at all capable of performing the maneuvers required by the autopilot(i.e. the defined attitude thrust is to low). Maybe the roll -cueing right after ignition could be done via a dedicated MFD screen if its tricky to show that on the hud?

Good point, not so easy but I have a couple of ideas:
- on the Hud it's a mess, so I will use a dedicated screen of the MFD
- I will show on the screen where the autopilots wants us to go and simply add the option to turn on or off attitude control on the rocket from the MFD, I think this will do the job, right?

 

[Michael_Chr]

Thanks!! :tiphat:



In Ms2015 for live payloads there is the possibility to manual override the payload weight value, in order to simulate ballast or other effects :thumbup:

OK...so no more fussing with null meshes etc... exellent

Good point, not so easy but I have a couple of ideas:
- on the Hud it's a mess, so I will use a dedicated screen of the MFD
- I will show on the screen where the autopilots wants us to go and simply add the option to turn on or off attitude control on the rocket from the MFD, I think this will do the job, right?

I agree...Having a dedicated MFD is a good and workable solution . How do you plan to implement the initial roll cueing after lift-off? A point here is that when you implement AP cueing (Both for roll as well as for pitch and yaw) It most likely will work better if you implement a type of logarithmic algorithm so if of have large cueing offset (the Delta value between current Flight Path Angle - FPA and AP directed angle is large) then is should result in small cueing values (small flight director movements) whereas the offset gets smaller then the flight director should exhibit larger movements as it gets close to zero. If the offset gets above a certain value then perhaps an arrow showing the direction to fly to in order to get the flight director inside the MFD. This would keep it inline with the "industry standard". Hope you understand all this

Having said all this it must also be emphazised that what you already have accomplished is astonishing - and if this leads to "over complication" it is perhaps better to just keep things simple and not implement advanced cueing features.

 

[fred18]

Having said all this it must also be emphazised that what you already have accomplished is astonishing - and if this leads to "over complication" it is perhaps better to just keep things simple and not implement advanced cueing features.

First of all thanks! I understand and agree with what you're referring to, but relevant to MFD I'm still learning and for the first release I would leave it a bit simpler without cueing but with on screen target values so you can have anyway a reference.

For future releases I would like to implement detailed cueing!

---------- Post added at 15:46 ---------- Previous post was at 14:10 ----------

Here's the screenshot of the control display done:

 

[Michael_Chr]

Totally agreed...
Its much better to have something more "simple" to start up with faster and then identify and realize the growth potential later. And I'm using the word "simple" here just for lack of better words because in essence everything about this addon is indeed "rocketscience" ...on every level :lol:

 

[kerlix]

Something that might be a cool feature down the road would be an MFD function that would add to the MCC aspect of it. Basically, be able to draw the "desired/optimal" ascent trajectory and then show the actual ascent trajectory in real time. Similar to the shuttle ascent displays.

It would be a good way to monitor performance and such. So if a failure of some sort (engine out, etc.) occurred, then it could be switched over to manual control (or even further down the road, engine out AP capability) and still get the vessel to a proper orbit. And depending on when the failure occurred, either a type of ATO, or proper guidance information to still achieve the desired orbit even after a failure.


I know it's a tall order to request and would require a lot of work. Especially since (I believe) you said you're still working on creating MFD's and stuff.

But it was just a thought that occurred to me that might be a cool feature to see/use.

Edit: :ninja:

Good point, not so easy but I have a couple of ideas:
- on the Hud it's a mess, so I will use a dedicated screen of the MFD
- I will show on the screen where the autopilots wants us to go and simply add the option to turn on or off attitude control on the rocket from the MFD, I think this will do the job, right?

Is this basically the same thing as I mentioned? I'm guessing so. Sorry. I didn't read thoroughly enough.

 

[fred18]

Is this basically the same thing as I mentioned? I'm guessing so. Sorry. I didn't read thoroughly enough.

Partly, but not entirely. Actually I have the intention to implement exactly what you said in the flight monitor screen: Graphs with the relevant flight parameters that can show also preloaded value, I have already an idea on how to do it. Let's see if I can do it

 

[kerlix]

Awesome. Again, thank you so much. This will definitely become a "must-have" part of Orbiter.

Thank you for all your hard work on this. I can't wait until it's all up and running. It's going to be a game changer.

 

[fred18]

Big news of today:

Optional parameter eng_dir=(x,y,z) added to the config file. If set, turns the engine exhausts in the set direction! Nice effect for example for the space shuttle:

Another important factor as far as realism: Optional Parameter thrust_real_pos=1 added to the MISC section of the ini file. If present the thrusters of stages and boosters are applied in real mesh positions, and no more in (0,0,0) and are oriented towards eng_dir, which means high realism.
Peg Attitude control has been updated to account for real thrust direction.

Another really important news:
Guidance Display of the MFD terminated with some cool features!
There will be the possibility to add or remove guidance steps of guidance program directly from the mfd and by clicking on "SAV" a default txt file containing the guidance program will be saved in the orbiter directory, available for later on usage!

I don't think I can make the release for this week, but I promise I will keep the pace up